前端的全栈之路Meteor篇(二):容器化开发环境下的meteor工程架构解析

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 本文详细介绍了使用Docker创建Meteor项目的准备工作与步骤,解析了容器化Meteor项目的目录结构,包括工程准备、环境配置、容器启动及项目架构分析。提供了最佳实践建议,适合初学者参考学习。项目代码已托管至GitCode,方便读者实践与交流。

 本文主要介绍容器化meteor工程的目录架构解析

1 工程准备

1.1 创建工程目录

使用git初始化一个项目,创建如下的文件,接下来将逐一解析

image.gif 编辑

2.2 准备容器环境定义文件

使用docker compose插件运行容器,对于本地开发来说是更轻便的选择。

docker-compose.yml文件

version: '3'
services:
  meteor:
    # [a] 使用镜像 geoffreybooth/meteor-base:{version}
    image: geoffreybooth/meteor-base:3.0.2
    ports:
    # [b] 本地端口:容器端口
      - '3000:3000'
    volumes:
      - "../:/home/project"
    env_file:
      - ../.env.dev
    # 进入app目录
    # 检查目录app是否存在
    # 不存在则创建项目 meteor create app --template typescript
    # 存在则进入目录并运行 meteor
    command:
      - bash
      - -c
      - |
        cd /home/project
        if [ ! -d "/home/project/app" ]; then
        # [c] 创建项目 - 可修改模板,默认为 --typescript 支持 --bare , --apollo , --react , --vue, --full, --minimal, --svelte
          meteor create app --typescript
        fi
        cd /home/project/app
        meteor run

image.gif

1.3 环境变量-配置文件

.env.dev

APP_ROOT_URL=http://localhost:3000
TZ=Asia/Shanghai

image.gif

1.4 启动容器开发环境

cd dev
docker compose up

image.gif

2 初始化工程(首次启动)

2.1 修改环境变量

.env.dev文件解析:

1. APP_ROOT_URL 用于配置对外暴露服务的访问url,如果只是本机测试可使用localhost,不然需要设置成本机ip或者域名等

2. TZ 用于配置时区,以保证Date相关的字符串化可读性更高,不然处理不好可能获得的时间并不是东八区的

2.2 修改容器配置

配置的点见docker-compose.yml文件 ,注释部分的[a].[b].[c]

[a]: 用于配置使用的镜像以及版本,可以修改版本号来使用不同的meteor版本,一般不用修改,但是如果你在2025年或以后的时间阅读本文,还是建议修改下,格式就是 geoffreybooth/meteor-base:{version} 具体的版本号可以在这里查询:geoffreybooth/meteor-base Tags | Docker Hub

[b]: 本地端口指的是宿主机的端口,容器端口就是容器内的meteor应用监听的端口,这个映射就是在访问宿主机的端口时,将请求转发到容器内,实现服务的对外暴露。一般修改本地端口就可以了,容器内的端口是独立的、各个容器不会冲突所以不需要修改。但是主机端口可能会出现冲突,于是乎就需要改这个映射的端口了,注意不要改错了。

[c]: 项目创建的模板修改,初始化时 if [ ! -d "/home/project/app" ]; then 下面的代码会执行,因为此时还没有app目录,会使用模板应用来创建一个新的meteor项目,具体的参数可以查看项目,个人推荐是使用typescript,然后默认前端是用的react,你也可以加一个--vue来使用vue的前端。但个人还是建议用typescript,同时前端用于做管理平台一类的,如果是面向普通应用或者混合开发,虽然meteor可以胜任,但实际生产还是不太推荐的-除非探索性的赶时间的项目

2.3 启动容器

修改好配置之后,后续就不需要配置了,但是不同的设备还是有必要修改下.env.dev文件的。

这个过程会比较长,因为需要创建项目,下载依赖,以及编译构建前后端+数据库的准备。

3 工程架构解析

3.1 就绪的工程目录

image.gif 编辑

项目代码默认在app下面,.meteor下面是meteor的包配置等,client是前端的代码,imports是模块代码(一般前后端共用的),server是后端独有的代码和入口文件。

package.json里有meteor的入口文件配置:

"meteor": {
    "mainModule": {
      "client": "client/main.tsx",
      "server": "server/main.ts"
    },
    "testModule": "tests/main.ts"
  }

image.gif

3.2 前端代码

如下图所示,client目录的代码是纯前端运行的部分,一般放个入口文件就可以了。当然还可以包含纯前端组件(无业务的那些)。

image.gif 编辑

3.3 共享模块

imports下面用于存储模块文件,可以根据文件类型或者特性分成多个子目录。个人推荐是根据特性来,但比较小的项目,基于文件类型来划分也是不错的。

image.gif 编辑

然后在不同的入口文件引入这些文件导出的功能-函数、状态等就可以了。

最好是遵循一个准则:将业务和通用功能区分开,哪怕很多时候会变得比较繁琐,但增加一层会相应的增加灵活性,以及提升项目迁移时的可复用度。

3.4 后端入口

image.gif 编辑

后端入口默认是一个main.ts,这也是应用启动时加载的文件,在这里一般注册方法、注册发布源、做一些初始化的工作,或者把类似的功能放在这个目录的其它文件。虽然也可以放在imports下面,但有时候引用错误(例如很多api是浏览器没有的,有一些接口又是nodejs没有的就会报错,而每次用Meteor.isServer判断又比较繁琐),所以还是推荐纯后端运行的功能,全部放在这个目录下面

3.5 .meteor特有目录解析

image.gif 编辑

.meteor目录下没是基于Meteor创建项目特有的目录,local是一些缓存、数据库、工具的缓存地址,已经默认被gitignore的。

finished-upgraders是工具维护的版本升级文件,.id是一个独特的项目文件,便于云上快速部署。

packages是使用的meteor包文件(meteor有类似npm的功能,由于它出现的比较早,以前的npm并不像现在这样)。

release是meteor的版本号,不建议修改,而是使用meteor upgrade来操作比较好一点

4  最佳实践

  • 纯后端代码放在server目录
  • 纯前端代码放在client目录
  • 前后端可共享的数据结构 - 数据集、状态、工具函数放在imports
  • 使用docker简化meteor工程开发环境准备

5 小结

   本文主要是详细的介绍了使用docker创建meteor项目的准备工作和步骤,并解析了基于容器化的meteor项目架构,介绍了一下最佳实践。对于刚入门的新人来说,了解到这里就差不多了,暂不需要深入了解local、docker配置,只需要用文中提供的模板即可,希望多动手练习,有任何问题欢迎反馈。工程目录也放在git库dockerized:一些类容器化实现的前后端工程模板 - GitCode

相关文章
|
2天前
|
监控 网络协议 安全
DNS服务器故障不容小觑,从应急视角谈DNS架构
DNS服务器故障不容小觑,从应急视角谈DNS架构
17 4
|
2天前
|
人工智能 资源调度 数据可视化
【AI应用落地实战】智能文档处理本地部署——可视化文档解析前端TextIn ParseX实践
2024长沙·中国1024程序员节以“智能应用新生态”为主题,吸引了众多技术大咖。合合信息展示了“智能文档处理百宝箱”的三大工具:可视化文档解析前端TextIn ParseX、向量化acge-embedding模型和文档解析测评工具markdown_tester,助力智能文档处理与知识管理。
|
2天前
|
监控 安全 Java
构建高效后端服务:微服务架构深度解析与最佳实践###
【10月更文挑战第19天】 在数字化转型加速的今天,企业对后端服务的响应速度、可扩展性和灵活性提出了更高要求。本文探讨了微服务架构作为解决方案,通过分析传统单体架构面临的挑战,深入剖析微服务的核心优势、关键组件及设计原则。我们将从实际案例入手,揭示成功实施微服务的策略与常见陷阱,为开发者和企业提供可操作的指导建议。本文目的是帮助读者理解如何利用微服务架构提升后端服务的整体效能,实现业务快速迭代与创新。 ###
18 2
|
3天前
|
JavaScript 前端开发 Docker
前端的全栈之路Meteor篇(一):开发环境的搭建 -全局安装或使用容器镜像
本文介绍了如何搭建 Meteor 开发环境,包括全局安装 Meteor 工具和使用 Docker 镜像两种方法,以及创建和运行一个简单的 Meteor 项目的基本步骤。 Meteor 是一个全栈 JavaScript 框架,适用于构建实时 Web 应用程序。文章还提供了遇到问题时的解决建议和调试技巧。
|
9天前
|
存储 人工智能 前端开发
前端大模型应用笔记(三):Vue3+Antdv+transformers+本地模型实现浏览器端侧增强搜索
本文介绍了一个纯前端实现的增强列表搜索应用,通过使用Transformer模型,实现了更智能的搜索功能,如使用“番茄”可以搜索到“西红柿”。项目基于Vue3和Ant Design Vue,使用了Xenova的bge-base-zh-v1.5模型。文章详细介绍了从环境搭建、数据准备到具体实现的全过程,并展示了实际效果和待改进点。
|
9天前
|
JavaScript 前端开发 程序员
前端学习笔记——node.js
前端学习笔记——node.js
25 0
|
10天前
|
人工智能 自然语言处理 运维
前端大模型应用笔记(一):两个指令反过来说大模型就理解不了啦?或许该让第三者插足啦 -通过引入中间LLM预处理用户输入以提高多任务处理能力
本文探讨了在多任务处理场景下,自然语言指令解析的困境及解决方案。通过增加一个LLM解析层,将复杂的指令拆解为多个明确的步骤,明确操作类型与对象识别,处理任务依赖关系,并将自然语言转化为具体的工具命令,从而提高指令解析的准确性和执行效率。
|
9天前
|
存储 弹性计算 算法
前端大模型应用笔记(四):如何在资源受限例如1核和1G内存的端侧或ECS上运行一个合适的向量存储库及如何优化
本文探讨了在资源受限的嵌入式设备(如1核处理器和1GB内存)上实现高效向量存储和检索的方法,旨在支持端侧大模型应用。文章分析了Annoy、HNSWLib、NMSLib、FLANN、VP-Trees和Lshbox等向量存储库的特点与适用场景,推荐Annoy作为多数情况下的首选方案,并提出了数据预处理、索引优化、查询优化等策略以提升性能。通过这些方法,即使在资源受限的环境中也能实现高效的向量检索。
|
9天前
|
机器学习/深度学习 弹性计算 自然语言处理
前端大模型应用笔记(二):最新llama3.2小参数版本1B的古董机测试 - 支持128K上下文,表现优异,和移动端更配
llama3.1支持128K上下文,6万字+输入,适用于多种场景。模型能力超出预期,但处理中文时需加中英翻译。测试显示,其英文支持较好,中文则需改进。llama3.2 1B参数量小,适合移动端和资源受限环境,可在阿里云2vCPU和4G ECS上运行。
|
9天前
|
前端开发 算法 测试技术
前端大模型应用笔记(五):大模型基础能力大比拼-计数篇-通义千文 vs 文心一言 vs 智谱 vs 讯飞vsGPT
本文对比测试了通义千文、文心一言、智谱和讯飞等多个国产大模型在处理基础计数问题上的表现,特别是通过链式推理(COT)提示的效果。结果显示,GPTo1-mini、文心一言3.5和讯飞4.0Ultra在首轮测试中表现优秀,而其他模型在COT提示后也能显著提升正确率,唯有讯飞4.0-Lite表现不佳。测试强调了COT在提升模型逻辑推理能力中的重要性,并指出免费版本中智谱GLM较为可靠。
前端大模型应用笔记(五):大模型基础能力大比拼-计数篇-通义千文 vs 文心一言 vs 智谱 vs 讯飞vsGPT

热门文章

最新文章

推荐镜像

更多