我如何通过 Laravel 和 Vue 构建食品配送应用程序的 15 个部分、经验教训和想法

注意：目前网站已关闭，我会尽快修复

介绍

有很多针对大城市送餐的应用程序，但针对小城市送餐的应用程序并不多。

本文介绍了该应用程序的制作方法、结构、常见问题以及解决方案。

为什么这篇文章对你来说很重要？

您是否计划制作送货应用程序，或者您想购买一个，或者您有兴趣启动送货应用程序？

或者您想了解如何使用网络解决问题？

那么，本内容适合您。

“在深入研究树叶/细节之前，务必先了解基本原理，即树干和大树枝，否则它们将无所依附。” ——埃隆·马斯克

这是应用程序。看一下吧。

由于几乎所有帐户的访问权限都是公开的，因此应用程序数据很有可能被随机用户填充。请不要将不相关的内容填充到应用程序中。如果您无法登录，请尝试创建一个新帐户。

链接：https://dostava-online.com

用户凭据：

电话号码：+387 99/999-999
电子邮件: johndoe@gmail.com
密码：123123123

链接：https://dostava-online.com/restaurant

餐厅资质：

1
- 电话号码：+387 22/222-222
- 电子邮件: ristus@gmail.com
- 密码：123123123
2
- 电话号码：+387 33/333-333
- 邮箱：star@gmail.com
- 密码：123123123

链接：https://dostava-online.com/admin

管理员凭据：

电话号码：+387 11/111-111
电子邮件: dostava.online@gmail.com
密码：123123123

概述

在主页上显示：
- 根据销量/评分排名前三的食品
- 所有餐厅按销售/评级/赞助/供应情况排序
用户购物车
食品添加剂，免费和付费添加剂
多个用户地址
尽快或在指定时间送货/取货
送餐/取餐
为用户提供 6 种类型的通知；顺序如下：
- 公认
- 不接受
- 正在制作中
- 正在交付
- 发表
- 你可以来取食物
每道菜的配料
一键切换餐厅食物供应情况
完成餐厅食物的 CRUD
食品类别
管理仪表板，用于查看销售概览、确认、赞助

技术概述

Laravel 6、Vue 2.0、Vuex、Vuetify、Socket.io（Laravel-echo）、Node、Redis、MySQL、OAuth 2.0
为用户和餐厅实施 Webpush 通知
管理员的 Slack 通知
多重授权
缓存大多数可缓存资源 - 在后端和前端
每周备份 3-5 次
图片水印
无需 Laravel 混合；高级 webpack 配置
经过全面测试；约 800 个测试（功能和单元测试）
用于在后端对前 3 种食物进行排序的算法的完全可扩展和可测试的结构
用户/餐厅/管理员 SPA 分离
HTTP 2.0 用于延迟加载 Vue 组件；生产原始文件约 400 个
完全分离的 API 和前端
用于生产测试的自定义工匠命令
可轻松扩展到多个城市
轻松连接到移动应用程序（为此而制作的单独 API）
移动优先设计

数据库计划

桌数：46

问题：购物车中的商品应该在所有设备上都可见，因此将商品保存在 cookies 内存或浏览器数据库中不会有帮助，因为用户将从各种设备检查购物车
解决方案：完整的购物车概念位于后端

问题：交易历史
解决方案：购物车解决方案的相同表格，前缀为“finish”

问题：多个用户地址（因此用户只需输入一次地址即可随时轻松访问）
解决方案：主用户表和用户地址表上的home_address；一对多关系

问题：购物车还应包含付费和免费附加商品
解决方案：shopping_cart，shopping_item，shopping_item_free_addition，shopping_item_paid_addition；一对多关系

问题：免费/付费添加物和成分的重复
解决方案：免费/付费添加物和成分链接表

问题：有些餐厅周末不营业，但所有餐厅在工作日都正常营业
解决方案：为周末创建单独的表，并采用一对一的关系

问题：不同地点的送货价格不同
解决方案：餐厅表和送货表上的default_delivery_price；一对多关系

问题：每月餐厅费用
解决方案：使用 cron 授权的 Laravel 调度程序

问题：食物类别
解决方案：单独表，一对多关系

还有Telescope表、OAuth 表、通知、failed_jobs、迁移、三种类型的用户（用户、餐厅、管理员）......

订购流程

从主页/餐厅页面将包含/不包含免费/付费添加的商品放入购物车
前往购物车页面
选择您是来取餐还是希望送货的地址
选择尽快送货/取货还是在指定时间送货/取货

下单成功后，餐厅可以选择接受或者拒绝该订单。

如果 10 分钟过去了，餐厅仍然没有接受或拒绝订单，用户可以拒绝订单。

餐厅拒绝点菜可能出于多种原因，例如餐厅忘记设置该菜品不可用。

订单流程可视化

订单流程图，用户侧：

餐厅端订餐流程图：

历史概述

历史记录问题很容易解决。订单完成后，该任务会被添加到 Laravel 队列中，因此它是非阻塞的。
任务会将活动购物车中的订单转移到已完成的购物车中，所有订单信息都包含在完成的表中——购物车、商品以及免费/付费的添加订单。

出现的问题是由于已完成的商品/新增商品与当前信息关联，导致已完成订单中新增商品/食品的价格发生变化。解决方案是一次性对相关数据进行序列化快照。目前该系统尚未实现。

队列

应用程序正确运行需要 6 个队列（250-350 MB RAM ）。

所有这些都是通过 Redis 提供支持的。

通用队列
排队等待餐厅通知
用户通知队列
管理员通知队列
图像处理队列

通用队列位于大多数其他队列和非关键数据的前端。
由于此应用程序严重依赖通知，因此有 3 个单独的通知队列，其中餐厅队列具有高优先级。

Cron 作业概述

在这个应用的后台，有6个进程交替运行。

月费事件（计算餐厅债务）
每小时检查哪些赞助已过期
每小时删除旧的不活跃购物车
每日清理旧备份
每日备份数据库
每周备份文件

安全

Laravel 框架正在努力做到尽可能的安全。

每个用户输入都会在客户端和服务器端进行检查。

每天都进行备份。

从应用程序端和操作系统方面，存在许多防止 DOS 攻击的障碍。

验证和通知

每种形式的制作都非常注重细节。

从输入错误答案到正确和推荐答案。

通知通过网页推送和应用内通知两种方式实现。应用内通知使用一个基本的 Laravel 包实现，效果（几乎）非常好。

数据库中的数据重复

很多食物的配料都一样，所以添加很多重复的配料毫无意义。
付费和免费添加的配料也存在同样的情况。

解决方案是创建链接表。这样，多个菜肴就可以链接到同一种食材，而不会重复。

停用

食品、付费/免费附加功能、用户、餐厅、管理员表均已软删除，这意味着数据将保留在数据库中，只是不会像被删除一样显示在任何地方。数据将保留用于分析、营销等目的……

商业模式

其核心商业模式与Grubhub模式相同，订单金额的10%，基于价值的商业模式，最佳商业模式（主观）。

通过引入配送扩展功能，可以扩大应用程序的利润，这样独立的送货员就可以工作并赚取一些现金。

故事

这款网页应用是为小城市及其周边地区设计的。大多数大型外卖公司只针对一个城市，而这正是这款应用与其他应用的不同之处。

这款应用专注于首发城市，是一个不错的初创项目。其架构可以轻松扩展，覆盖多个城市。

申请表是从波斯尼亚语匆忙翻译成英语的，有一些英文错误。

这也是我的第二个大项目，我花了 6 个月零 21 天的时间，只休息了 3 天。#hustleCulture 🤣

我学到了什么：

Laravel - 输入和输出
Vue - 很多（社区，感谢这份礼物）
Webpack - 头痛是正确的翻译
MVC - 正在开发中的独立部分的结构（如果我必须用我的话来描述它）
SCSS - 对基本 CSS 的良好补充
软件开发的真正问题：在一个庞大而强大的系统中保持相同的开发速度，很容易失去节奏；所以唯一的出路是高质量、干净的代码，执行定义的原则
Redis - 令人着迷的发布-订阅；令人着迷的速度；而困难的事情，并不严格地与 Redis 耦合，但通常与之相关 - 缓存失效......寻找逻辑创造力的好地方。
简单就是更好
最好花更多时间规划数据库结构，而不是在几周或几个月后支持糟糕的设计
ORM 是一种很好的、快速的方法（我没有接触过性能才是真正问题的系统，但我认为 ORM 不是最好的选择）
Ubuntu 很简单，理解多用户操作系统中的权限系统是安全的关键概念之一（对我来说，下一阶段是云）。基于 VPS 的解决方案的扩展问题很容易被注意到，因此云的巨大发展是合情合理的。
使用包是一件麻烦事
GraphQL 是大型API中的一种方式，REST 会因为其不灵活性而浪费很多
在决定使用哪种后端技术之前，先制定详细的前端方案，可以避免很多遗憾
编写重要的代码而不进行测试是一种犯罪
PHP很好并且正在不断发展，但在企业中总是会使用 Java/C#
过去 25 年里，地球上大多数的死亡都是由JavaScript造成的。这是事实 😂

感谢您的阅读。☄️

文章来源：https://dev.to/keno_sej/15-parts-of-how-i-built-food-delivery-app-lessons-ideas-through-laravel-and-vue-6pp