Ecommerce moderna con quasar + vue 3, mariadb, s3, nodejs, Caddy y docker. Capítulo I

Creando una Aplicación Web Moderna con Caddy, Quasar, Vue 3, Node.js, MySQL y S3

1. Caddy: Un servidor Web sencillo y eficiente desarrollado en GO. Un servidor con muchas características y fácil de utilizar. Si no lo conoces, te asombrará.

2. Quasar: Framework para Aplicaciones Vue.js. Es un framework que permite el desarrollo de aplicaciones web, móviles, PWA y de escritorio.

3. Vue 3: La Evolución del Framework.

4. Node.js: El Entorno de Ejecución del Lado del Servidor

5. MariaDB: La Base de Datos Relacional.

El ejemplo ya disponible LAPAYAS.A. 

Todos los días surgen ecommerce, los comerciantes buscan ampliar su mercado sin abrir nuevos locales, los fabricantes buscan eliminar intermediarios y mayor margen de beneficios, y todos lo quieren ya. 

Con ellos ha surgido un nuevo nicho de mercado que son las plataformas de ecommerce que busca democratizar las tiendas para todos. Otros acuden a los diseñadores que por poco más de 2000€ te proporcionan un WOOCOMERCE y tienen algo más de control sobre cómo cubrir sus necesidades. Y si solo quieres tener una infraestructura ya creada que te proporcione soporte para vender, aunque compitiendo con otros vendedores iguales que tú o incluso mucho más preparados, siempre tienes Amazon, Miravia, ...etc. 

Con la incorporación de la IA se incorpora una nueva herramienta que busca producir mejores resultados en la creación de páginas web con unos pocos pasos y con los mejores resultados. La promesa es que no necesitas saber casi nada para crear una web  con buen diseño y que cumplas tus expectativas.

Todas las soluciones son muy válidas y las diferencian unos pocos aspectos pero muy importantes. En todos los casos trabajas para una plataforma o suerte de framework que alimentas con tus productos, fotos, contenido y que no controlas. Deberás cumplir todas las reglas que te impongan y pagar las comisiones correspondientes, a cambio te dejarán competir con los demás usuarios.

Poner todos los huevos en la misma cesta conlleva peligros que dejo a tu imaginación. El hecho es que muchos de estos usuarios no solo compiten en una plataforma sino en varias, esto supone muchas más actualizaciones de productos, precios, stock, ...penalizaciones por rotura de stock, por no cumplir el envío en fecha, y en muchos casos, continuar con las ventas en el local comercial.

Mi propuesta siempre ha sido trabaja una vez y que la información se distribuya en todos los canales ocupando solo una fracción de tu tiempo, de esta forma es posible disponer de negocios que no requieran de grandes inversiones en infraestructura y personal, que puedan crecer en características a medida que tu empresa las necesite. Este pensamiento es el que me llevó a crear KGESTION (PYTHON 3.11 + PYSIDE 6 + MARIADB ) allá por el 2021 un poco antes de la PANDEMIA, permitiendo que muchas personas pudieran realizar su trabajo desde el domicilio durante los días de aislamiento. 

El siguiente paso ha sido seleccionar las mejores tecnologías, aunque siempre hay algo mejor de lo que puedas seleccionar, la perfección siempre es enemiga de lo bueno, y llegué hasta quasar 2 + vue 3 + nodejs que junto a la base de datos ya creada para KGESTION, me ha permitido desarrollar una SPA mucho más ligera y parametrizable que cualquier sistema desarrollado en PHP.  El reto posterior ha sido proporcionar información a los buscadores (crawlers) desde la SPA, que no es imposible pero necesita algo de paciencia y pruebas, pero es posible a pesar de que todo el mundo aconseja desarrollar una SSR.

Otra de las ocurrencias ha sido disponer todos los archivos estáticos como imágenes, videos, documentos, ...etc en un S3 ( me refiero a S3 porque es el servicio más conocido por todos por ser de AWS, pero en realidad me refiero a un servicio 'block storage' disponible en muchos proveedores). 

Además, como es posible crear tantos dominios y/o webs distintas para multiplicar los canales de ventas y competir en mejores condiciones, se hace imprescindible crear un API que englobe todos los servicios comunes como accesos a la base de datos, securización de usuarios, plataformas de pago, plataformas de envíos, accesos a block storage y disponibilidad de imágenes, vídeos, documentos,... KODAMA ( nodejs + sequelize + mariadb ).

Aunque blog estuvo dedicado inicialmente a PYTHON, es posible compartir información entre varios sistemas, es en este punto final cuando se muestra la conexión y sincronización del sistema KGESTION con SHOPPRO que ha sido el nombre clave proporcionado al proyecto ecommerce.

Podrás seguir el desarrollo del proyecto SHOPPRO desde la dirección PURO QUASAR

Cómo optimizar tablas en MySQL

Al final se puede resumir que EXPLAIN MySQL es una herramienta indispensable (no la única) a la hora de realizar tareas de otpimización sql.

Explain MySQL no es más que una manera de mostrar como MySQL procesa las sentencias SQL mediante sus índices y uniones. El uso de Explain MySQL permite ayudar a los DBAs, en una primera instancia, a mejor el diseño de base de datos agregando índices y permitiendo una selección de consultas más óptimas.

Lo único que debemos hacer para hacer uso de Explain MySQL es anteponer “Explain” a la SQL deseada.

EXPLAIN SELECT * FROM `localidades` WHERE id =1

Ejecutando esta SQL, MySQL nos indica como la está procesando y nos mostrará un listado con información sobre índices, tablas, resultados, etc.

En el resultado de explain de mysql visualizaremos una tabla con 10 columnas de información para cada tabla implicada
explain mysql
De las columnas anteriores cabe destacar:

type: Esta columna indica el tipo de unión que se está usando (de más a menos óptimo).
const: Es la más óptima y se dá cuando la tabla tiene como máximo una fila que coincide. Como solo hay una fila coincidente, MySQL la considerará como constante por el optimizador.
eq_ref: Una fila será leída de la tabla A por cada combinación de fila de la tabla B. Este tipo es usada cuando todas las partes de un índice son usados para la consulta y el índice es UNIQUE o PRIMARY
ref: Todas las filas con valores en el índice que coincidan serán leídos desde esta tabla por cada combinación de filas de las tablas previas. Si la clave que es usada coincide sólo con pocas filas, esta unión es buena.
range: Sólo serán recuperadas las filas que estén en un rango dado, usando un índice para seleccionar las filas. La columna key indica que índice se usará, y el valor key_len contiene la parte más grande de la clave que fue usada. La columna ref será NULL para este tipo.
index: Este es el mismo que ALL, excepto que sólo el índice es escaneado. Este es usualmente más rápido que ALL, ya que el índice es usualmente de menor tamaño que la tabla completa.
ALL: Realiza un escaneo completo de tabla por cada combinación de filas de las tablas previas. Este caso es el peor de todos.
possible_keys: Esta columna indica los posibles índices a utilizar en la consulta
key: Esta columna indica el indice que MySQL actualmente está usando. Esta columna es NULL si no se ha elegido ninguno. Es interesante saber que podemos forzar a MySQL a usarlo (y también a ignorarlo) mediante el uso de FORCE INDEX, USE INDEX o IGNORE INDEX
key_len: El tamaño del índice usado. A menor valor mejor.
ref: La columna ref muestra que columna o constante es usada junto a la key para seleccionar las columnas de la tabla
rows: Indica el número de columnas que MySQL cree necesario examinar para ejecutar la SQL.
extra: Indica información adicional de como MySQL ha resuelto la SQL y hay que prestar atención si aparece USING FILESORT o USING TEMPORARY. En el primer caso, indica que MySQL debe hacer un paso extra para recuperar la información. En el segundo, MySQL necesita generar una tabla extra para mantener la información y después mostrarla y es típico al usar GROUP BY u ORDER BY.

En ocasiones, MySQL puede mostrar ALL en la columna type cuando:

La tabla es tan pequeña que MySQL ve más rapido hacer un escaneo completo de la tabla.
No hay restricciones usando las cláusulas ON o WHERE.
Se compara columnas indexadas con valores cosntantes
Las claves utilizadas devuelven muchos registros que coinciden con el valor.



Cada columna que devuelve EXPLAIN tiene el siguiente significado:

id - identificador, es sólo una secuencia numérica autoincrementada para cada una de las filas del explain
select_type - Debe ser uno de los siguiente tipos
SIMPLE - No usa subqueries ni UNION
PRIMARY - Último SELECT
UNION - Segunda o última sentencia SELECT en una UNION
DEPENDENT UNION - Segunda o última sentencia SELECT en una UNION, dependiente de otra query
SUBQUERY - Primera SELECT en una subquery
DEPENDENT SUBQUERY - Primera SELECT en una subquery, dependiente de otra query
DERIVED - Tabla SELECT derivada (subquery en una clausula FROM)
UNCACHEABLE SUBQUERY - Una subquery cuyo resultado no puede ser cacheado y debe ser re-evaluado para cada file de la otra query.

table - la tabla a la que se refiere la información
tipo - el tipo de unión empleado, que puede ser:
sytem - SYSTEM SELECT sólo hay una fila en la tabla (tipo especial del tipo const)
const - La tabla tiene como mucho un sola fila resultado, que es leída al principio de la operación convirtiéndose en una constante para el resto de las operaciones del select (operación muy rápida)
eq_ref - Una fila es leída de la tabla por cada combinación de filas en las tablas previas.
ref - Todas las filas con valores de índices validos son leídos de esta tabla por cada combinación de filas de las tablas previas.
fulltext - El join se utiliza mediante un índice FULLTEXT
ref_or_null - Este tipo de join es como el ref, pero además MySQL hace una busqueda extra por filas que contengan valores NULL
index_merge - la columna key en la fila de salida contiene una lista de indices a utilizar, y key_len contiene una lista de las claves más largas para los índices utilizados.
unique_subquery - Este tipo sustituye al ref para algunas subqueries IN de el siguiente tipo de estructuras: value IN (SELECT primary_key FROM single_table WHERE some_expr)
index_subquery - Este tipo join es similar al unique_subquery. Este sustituye subqueries IN, pero funciona para índices no únicos en subqueries del siguiente tipo: value IN (SELECT key_column FROM single_table WHERE some_expr)
range - Solamente las columnas que están en un rango dado son retornadas, empleando un índice para seleccionar las columnas. La columna key indica que índice es utilizado. key_len contiene el índice más largo de la parte del índice más larga utilizada. ref es NULL para este tipo.
index - Este ipo de join es el mismo que el de ALL, con la excepción de que sólo se realiza el escaneado a través de un índice. Esto es mas rápido que ALL ya que los ficheros índice son generalmente más pequeños que el fichero de datos.
all - Se realiza un escaneado de toda la tabla por cada combinación de filas de las tablas anteriores.

Estos tipos están ordenados en cuando a lo mejor o peor en cuanto a optimización. Así un tipo all sería lo peor y un tipo system sería lo mejor. Reducir de un tipo a otro, cambiando o creando índices para una determinada tabla o modificando la estrucutra misma de la petición es la tarea básica que debemos intentar para optimizar nuestra querys.

possible_keys - La columna indica que índices se pueden seleccionar para ser usados a la hora de encontrar filas en la tabla.
key - Índica que índice es empleado finalmente (podría se uno que no estuviera listado en las possible_keys).
key_len - Longitud del índice empleado
ref - Muestra que columnas o constante son empleadas para comparar con el índice
rows - Número de filas que MySQL piensa que debe examinar al ejecutar la petición
extra - Información adicional sobre la consulta.

Cuando modifiques la estructura de una tabla o añadas índices recuerda ejecutar un:

ANALIZE TABLE nombre_tabla;

Esto hará que el optimizador analize adecuadamente la tabla, los datos los usará para ayudarle a determinar la mejor estrategia en consultas posteriores. Tras modificar la tabla ejecuta ANALIZE y vuelve a ejecutar un EXPLAIN para observar las modificaciónes en el plan de ejecución de la consulta