Saltar al contenido

15 partes de cómo creé la aplicación de entrega de alimentos, lecciones e ideas a través de Laravel y Vue

Introducción

Hay muchas aplicaciones creadas para la entrega de alimentos en las grandes ciudades, pero no muchas de ellas están diseñadas para pequeña ciudades.

El artículo cubre cómo se crea la aplicación, su estructura, problemas comunes y soluciones.

¿Por qué el artículo puede ser importante para ti?

¿Planea crear una aplicación de entrega, o desea comprar una, o está interesado en iniciar una aplicación de entrega?

¿O quiere ver cómo se puede resolver un problema usando la web?

Entonces, este contenido es para ti.

“Asegúrese de comprender los principios fundamentales, es decir, el tronco y las ramas grandes, antes de entrar en las hojas / detalles, o no hay nada a lo que aferrarse”. – Elon Musk

Aquí está la aplicación. Echar un vistazo.

Existe una gran posibilidad de que los datos de la aplicación sean llenados por usuarios aleatorios porque el acceso a casi todas las cuentas está abierto al público. Por favor no llene la aplicación con cosas no relacionadas. Si no puede iniciar sesión, intente crear una nueva cuenta.

Enlace: https://dostava-online.com

Usuario cartas credenciales:

Enlace: https://dostava-online.com/restaurant

Restaurante cartas credenciales:

Enlace: https://dostava-online.com/admin

Administración cartas credenciales:

Descripción general

  • en la página principal se muestran:
    • 3 alimentos principales, de acuerdo con las ventas / calificaciones
    • todos los restaurantes ordenados según las ventas / calificaciones / patrocinio / disponibilidad
  • carrito para usuarios
  • adiciones para alimentos, libre y pagado adiciones
  • múltiples direcciones de usuario
  • entrega / recogida lo antes posible o en el momento deseado
  • entrega / recogida de comida
  • 6 tipos de notificaciones para usuarios; orden es:
    • aceptado
    • no aceptada
    • en proceso
    • en la entrega
    • entregado
    • puedes venir a recoger la comida
  • ingredientes de cada plato
  • un clic para cambiar la disponibilidad de alimentos en el lado del restaurante
  • CRUD completo de alimentos para restaurante
  • categorías de alimentos
  • panel de administración para descripción general de ventas, confirmaciones, patrocinios

Resumen técnico

  • Laravel 6, Vue 2.0, Vuex, Vuetify, Socket.io (Laravel-echo), Node, Redis, MySQL, OAuth 2.0
  • Notificaciones webpush implementadas para usuarios y restaurantes
  • Notificaciones flojas para administradores
  • Multiauth
  • Almacenamiento en caché de la mayoría de los recursos almacenables en caché, tanto en el back-end como en el front-end
  • Copia de seguridad 3-5 veces / semana
  • Marcas de agua de imagen
  • Sin mezcla de Laravel; configuración avanzada del paquete web
  • Totalmente probado; ~ 800 pruebas (características y pruebas unitarias)
  • Estructura completamente extensible y comprobable para algoritmos para clasificar los 3 alimentos principales en la parte posterior
  • SPA de usuario / restaurante / administrador separados
  • HTTP 2.0 para carga diferida de componentes de Vue; producción raw ~ 400 archivos
  • API y front-end completamente separados
  • Comandos artesanales personalizados para pruebas de producción
  • Fácilmente ampliable para varias ciudades
  • Fácilmente conectable a la aplicación móvil (API separada hecha con eso en mente)
  • Diseño móvil primero

Plan de base de datos

Numero de mesas: 46

  • Problema: los elementos del carrito deben verse desde todos los dispositivos, por lo que guardar elementos en la memoria de cookies o en la base de datos del navegador no ayudará porque el usuario va a verificar el carrito desde los distintos dispositivos

  • Solución: el concepto de carrito completo está en la parte trasera

  • Problema: Varias direcciones de usuario (para que el usuario pueda escribir la dirección una vez y acceder a ella en cualquier momento con facilidad)

  • Solución: direccion de casa en la principal usuario mesa, y dirección_usuario mesa; relación uno a muchos

  • Problema: el carrito también debe contener adiciones pagas y gratuitas

  • Solución: Carro de compras, shopping_item, shopping_item_free_addition, shopping_item_paid_addition; uno a muchos relaciones

  • Problema: algunos restaurantes no funcionan los fines de semana, pero todos funcionan de lunes a viernes de forma regular

  • Solución: mesa separada para fines de semana con doce y cincuenta y nueve de la noche relación

También hay tablas de telescopio, tablas de OAuth, notificaciones, fail_jobs, migraciones, tres tipos de usuarios (usuario, restaurante, administrador)…

Orden en proceso

  • Coloque los artículos con / sin adiciones gratuitas / pagas en el carrito desde la página principal / página del restaurante
  • Ir a la página del carrito
  • Elija si viene por la comida o la dirección deseada para la entrega
  • Elija si la entrega / recogida es lo antes posible o en el momento deseado

Después del pedido exitoso, el restaurante puede aceptarlo o rechazarlo.

Si pasan los 10 minutos y el restaurante aún no acepta o rechaza el pedido, el usuario puede rechazar el pedido.

El rechazo del restaurante puede suceder por varias razones, como que el restaurante se olvide de establecer la indisponibilidad para el plato.

Visualización del proceso de pedido

Diagrama de proceso de pedido, lado del usuario:

Diagrama del proceso de pedido, lado del restaurante:

Descripción general de la historia

El problema de la historia se resuelve fácilmente. Una vez finalizada la orden, el trabajo se agrega a la cola de Laravel, por lo que es sin bloqueo.
Lo que hará el trabajo es una transferencia de los carros activos a los carros terminados, todo tiene terminado mesa – carrito, artículos y adiciones gratuitas / pagadas.

El problema que surge es cambiar el precio de los complementos / alimentos en los pedidos terminados porque terminado los elementos / adiciones están vinculados a la información actual. La solución es hacer una instantánea serializada de los datos relevantes a la vez. Aún no implementado en este sistema.

Colas

Existen 6 colas necesarias para que la aplicación se ejecute correctamente (250-350 MB de RAM).

Todos ellos funcionan a través de Redis.

  • cola general
  • cola para notificaciones de restaurantes
  • cola para notificaciones de usuario
  • cola para notificaciones de administrador
  • cola para procesar imágenes

La cola general está en la frontera para la mayoría de las otras colas y para los datos no críticos.
Debido a que esta aplicación depende en gran medida de las notificaciones, hay 3 colas separadas para las notificaciones, de las cuales la cola del restaurante tiene alta prioridad.

Resumen de trabajos de cron

En el fondo de esta aplicación, 6 los procesos se ejecutan alternativamente.

  • evento de tarifa mensual (calcular las deudas de los restaurantes)
  • comprobar cada hora qué patrocinio ha caducado
  • eliminar cada hora los carritos de la compra viejos inactivos
  • limpie diariamente las copias de seguridad antiguas
  • base de datos de respaldo diaria
  • archivos de respaldo semanales

Seguridad

El framework Laravel está tratando de ser lo más seguro posible.

Se verifica cada entrada del usuario ambas cosas en el lado del cliente y del servidor.

La copia de seguridad se realiza a diario.

Muchas barreras para prevenir ataques de DOS, desde el lado de la aplicación y en el sistema operativo.

Validaciones y notificaciones

Cada forma se hace con un pesado centrarse en los detalles.

Desde la mecanografía de respuestas incorrectas a las correctas y recomendadas.

Las notificaciones se realizan a través de notificaciones push web y notificaciones en la aplicación. Las notificaciones en la aplicación se realizan utilizando un paquete básico de Laravel que hace (casi) un gran trabajo.

Duplicación de datos en la base de datos

Gran parte de la comida tiene los mismos ingredientes, por lo que tener muchos ingredientes duplicados no hace alguna sentido.
Lo mismo ocurre con las adiciones pagas y gratuitas.

La solución es hacer Enlace mesas. Entonces, por ejemplo, varios platos se pueden vincular al mismo ingrediente, sin duplicación.

Desactivación

La comida, la adición de pago / gratuita, el usuario, el restaurante y las tablas de administración se eliminan temporalmente, lo que significa que los datos permanecerán en la base de datos, solo que no se mostrarán en ningún lugar como se eliminaron. Datos restos con fines analíticos, de marketing …

Modelo de negocio

El modelo de negocio en su esencia es el mismo que el modelo Grubhub. 10% del precio del pedido. Un modelo de negocio basado en valor, el mejor tipo de modelo de negocio (subjetivo).

Los beneficios de la aplicación se pueden ampliar incorporando la extensión de entrega, de modo que el repartidor independiente pueda trabajar y ganar algo de dinero.

Historia

La aplicación web está hecha para las ciudades pequeñas y los lugares alrededor de la ciudad. La mayoría de las grandes empresas de reparto de comida incluyen la única ciudad y ese es el lugar donde esta aplicación difiere de los otros.

La aplicación es una buena puesta en marcha para el foco en la primera ciudad. La estructura es fácil extensible para varias ciudades.

La aplicación se tradujo rápidamente del bosnio al inglés. Hay algunos errores en inglés.

Este es también mi primer gran proyecto, que hice durante los 6 meses y 21 días, con solo 3 días de descanso. #hustleCulture 🤣

Lo que yo aprendió:

  • Laravel – dentro y fuera

  • Vue – mucho (comunidad, gracias por este regalo)

  • Webpack – el dolor de cabeza es la traducción correcta

  • MVC: la estructura de partes independientes independientes en desarrollo (si tengo que describirlo usando mis palabras)

  • SCSS: buena adición al CSS básico

  • Verdadero problema del desarrollo de software: mantener la misma velocidad de desarrollo en un sistema grande y robusto donde es tan fácil perder el ritmo; por lo que el único camino a seguir es la calidad, el código limpio, la implementación de principios definidos

  • Redis: fascinante pub-sub; velocidad fascinante; y lo más difícil, no acoplado estrictamente a Redis, pero a menudo relacionado con él: invalidación de caché … Un buen lugar para buscar creatividad lógica.

  • Simple es mejor

  • Mejor pasar más tiempo en el planificación la estructura de la base de datos que para soportar un mal diseño semanas / meses después

  • ORM es el camino agradable y rápido a seguir (no tenía contacto con los sistemas donde el rendimiento es el problema real, pero supongo que el ORM no es la mejor opción)

  • Ubuntu es fácil, comprender el permiso El sistema en el sistema operativo multiusuario es uno de los conceptos clave para la seguridad (la siguiente etapa para mí es la nube). El problema de escalamiento de las soluciones basadas en VPS es fácil de notar, por lo que el gran surgimiento en la nube tiene sentido.

  • Usar paquetes es una desordenado cosa

  • GraphQL es una forma de avanzar en grande API, REST desperdiciará mucho debido a su inflexibilidad

  • Desarrollando detallado esquemas de front-end antes incluso de decidir qué tecnologías usar en el back-end es la forma de evitar muchos de los arrepentimientos

  • Escribir código importante sin probar es una crimen

  • PHP es bonito y evolucionando, pero en la empresa siempre se utilizará Java / C #

  • La mayoría de las muertes en este planeta en los últimos 25 años son causadas por Javascript. Y eso es un hecho 😂

Gracias por leer. ☄️