本文主要介绍容器化meteor工程的目录架构解析
1 工程准备
1.1 创建工程目录
使用git初始化一个项目,创建如下的文件,接下来将逐一解析
编辑
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
1.3 环境变量-配置文件
.env.dev
APP_ROOT_URL=http://localhost:3000 TZ=Asia/Shanghai
1.4 启动容器开发环境
cd dev docker compose up
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 就绪的工程目录
编辑
项目代码默认在app下面,.meteor下面是meteor的包配置等,client是前端的代码,imports是模块代码(一般前后端共用的),server是后端独有的代码和入口文件。
package.json里有meteor的入口文件配置:
"meteor": { "mainModule": { "client": "client/main.tsx", "server": "server/main.ts" }, "testModule": "tests/main.ts" }
3.2 前端代码
如下图所示,client目录的代码是纯前端运行的部分,一般放个入口文件就可以了。当然还可以包含纯前端组件(无业务的那些)。
编辑
3.3 共享模块
imports下面用于存储模块文件,可以根据文件类型或者特性分成多个子目录。个人推荐是根据特性来,但比较小的项目,基于文件类型来划分也是不错的。
编辑
然后在不同的入口文件引入这些文件导出的功能-函数、状态等就可以了。
最好是遵循一个准则:将业务和通用功能区分开,哪怕很多时候会变得比较繁琐,但增加一层会相应的增加灵活性,以及提升项目迁移时的可复用度。
3.4 后端入口
编辑
后端入口默认是一个main.ts,这也是应用启动时加载的文件,在这里一般注册方法、注册发布源、做一些初始化的工作,或者把类似的功能放在这个目录的其它文件。虽然也可以放在imports下面,但有时候引用错误(例如很多api是浏览器没有的,有一些接口又是nodejs没有的就会报错,而每次用Meteor.isServer判断又比较繁琐),所以还是推荐纯后端运行的功能,全部放在这个目录下面。
3.5 .meteor特有目录解析
编辑
.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