这是一个创建于 540 天前的主题，其中的信息可能已经有所发展或是发生改变。
一种是把所有服务都在本地跑起来，前端改一点，后端改一点。
另外一种就是后端先开发好一部分，部署到某个测试环境，然后再开发前端的部分。
问这个问题，主要是因为在团队中不管单独做前端、后端，体验都很好，可以专注在当下的事情上，这是我认为第二种做法的好处（基础设施前人已经配置好了）。
但如果是个人项目，我觉得最重要的是快速做出效果，配置自动化逻辑和运行条件会花很多时间（或者流水线故障了也需要花时间解决）。
第 1 条附言 · 2023-07-03 23:35:53 +08:00
我可能表达的不是很清楚：其实先开发前后都是可以的，如果先开发前端，也可以先mock最后再联调。
我想问的是后端这边，你们会做完一部分，就部署一次吗？因为部署也是花时间的。
但是如果全都在本地的话，那么可能需要同时跑很多服务，举一个例子，可能需要开这么多：
- docker：redis、mysql、nginx....
- 后端：不同语言的后端
- 前端：Vite之类的
这样会干扰比较大，而且其中一个没有打开，项目都跑不起来
因为每次因为这个都心烦意乱的，但是觉得为这个搞些自动的东西又麻烦，想问问你们是怎么做的 😂
 |
1
gujuji 2023-07-03 22:35:03 +08:00 via iPhone
肯定是先细分然后后端最后前端
|
 |
2
xiaoxiaoming01 2023-07-03 22:42:25 +08:00 via Android  1
先写前端，就当做画原型，理思路，然后再写后端。
|
 |
3
hustlibraco 2023-07-03 22:54:04 +08:00
独立开发前后端不分离岂不快哉
|
 |
4
haikea 2023-07-03 22:58:45 +08:00
先后端吧，再前端
|
 |
5
mzDV4TUeHyesLbUQ 2023-07-03 23:01:54 +08:00
先分块，针对一个块是先后端再前端最后调调，然后第二个块。
|
 |
6
xiaoqidev 2023-07-03 23:10:38 +08:00 6
独立开发多年，现在基本是：写一个前端组件->写后端->前后端调通->下一个组件，想到那写到那，没有原型、没有任何规范可言、也不跟其他人协作、主打一个能用就行
|
 |
7
dode 2023-07-03 23:17:27 +08:00 via Android
总是有点误差，后台接口还要微调
|
 |
8
jeesk 2023-07-03 23:21:38 +08:00
先有功能，再交互，再看需要哪些接口， 然后反推。 不够的接口在追加。
|
 |
9
vsitebon 2023-07-03 23:23:47 +08:00
先弄好原型图，然后想会有哪些接口需求，做好数据模型，接着先开发前端，而后开发后端来满足前端能跑的需求，接着优化后端，最后优化前端（不断循环）
|
 |
10
Leviathann 2023-07-03 23:30:40 +08:00
我一般是先前端，接口直接返回伪数据即可
|
 |
11
hamsterbase 2023-07-03 23:34:32 +08:00
为了以后能更好的维护，我选择先文档，然后测试，最后开发。
1. 先写需求文档 2. 写模型的 spec 3. 写后端 service 4. 写后端单元测试 5. 写后端 API 6. 写后端集成测试（测试 API 7. 写前端集成测试 (测试交互 8. 写前端 |
 |
12
pytth 2023-07-03 23:57:42 +08:00 via iPhone
写后端先，然后写前端的时候有数据可以用，交互也可以一次调通，我认为省时一些。
|
 |
13
alexapollo 2023-07-04 00:11:58 +08:00
先用 https://github.com/geekan/MetaGPT 生成整体骨架，然后再填内容或许是个好主意。
如果是我完全手写，我现在越来越不倾向于在一个人工作时做明确的前后端接口定义，OpenAPI 3.0 的 spec 描述本身就已经非常冗长了。如果可以用 gradio/streamlit/pyreact 等框架做的，我肯定不会再独立写一套前端 |
 |
14
liuhan907 2023-07-04 00:12:30 +08:00 1
我选择用 blazor server 一把梭 (
|
 |
15
star7th 2023-07-04 08:50:17 +08:00
先画好大致原型，确定有什么功能。这个原型不必好看，主要是给自己固定下来，明确需要什么功能。
不然每写一下代码都要在脑海里拉一遍整个产品，很累的。有原型是最好的。 然后，按功能分解。比如说登陆注册功能。我会把登陆注册后端接口写好，然后写登陆注册的前端。 然后是另一个功能的后端，接着是前端。 至于你说的部署后端花时间，比如说 redis 、mysql 、nginx , 我感觉你的工作方式有问题。这种都是自动化的东西，一次性配置好的东西。你不愿意花时间去做好自动化，那你就要每次都烦。一次性付出的时间精力，跟每次都付出时间精力，很明显后者麻烦多了。 你的问题只是来源于下不了决心做基础环境的配置。那你的效率肯定没法高起来，无论做前后端。 |
 |
16
flytsuki 2023-07-04 08:55:22 +08:00
先写 api,再写界面
|
 |
17
cangcang 2023-07-04 09:05:05 +08:00
对哪边框架不熟，就先写哪边
|
 |
18
dddd1919 2023-07-04 09:18:41 +08:00
先写页面，再 API ，然后就可以直接页面调试了，mock 不是给自己找事么
|
 |
19
chengguang 2023-07-04 09:28:42 +08:00
@xiaoxiaoming01 实际体验来看，这个靠谱！
|
 |
20
horizon 2023-07-04 09:30:04 +08:00
nextjs 一把梭，不过先要画好原型。。
|
 |
21
tool2d 2023-07-04 10:12:43 +08:00
我以前是重后端，轻前端。因为前端要实现复杂功能，挺麻烦的。
但是现在随着前端技术越来越强，反而是轻后端了，甚至直接把后端当成轻量级 RPC 模块。主体逻辑尽可能都塞进前端。 |
 |
22
gogogo1203 2023-07-04 10:23:15 +08:00
对独立开发者来说 前后端确实比较重. 所以现在 firebase\supabase 这种数据库即后台的服务很流行。 我用了 supabase + sql function + edge function, 全部解决我需要的 curd 功能。使用 vercel 自动部署前端。 大部分精力都放在前端了。
|
 |
23
unco020511 2023-07-04 11:38:54 +08:00
当然是分开,分开是最快的
|
 |
24
javahuang 2023-07-04 12:41:06 +08:00
同时开发前端和后端。写一个新功能时，先设计好数据库，再给后端代码框架写出来，然后开发前端功能，中间穿插着改前后端代码。
|
 |
25
witcat OP @gogogo1203 确实，冷静下来想 supabase 就足够了。
|
 |
26
kinge 2023-07-04 13:17:58 +08:00
先出设计稿,在写后端,最后写前端. 必然是前后端分离更有优势,后期容易维护一点.全部写在一起会导致你的 project 越来越大,文件越来越多
|
|
27
gogogo1203 2023-07-04 13:58:04 +08:00 1
@witcat 现在的工具就是几行代码搞定的事. rate limit 弄个 upstash redis. file storage 自带，auth 自带。supabase doc 里有个可以白嫖的 chatgpt, 代码让它写，自己改改测测，粘贴到 sql editor 就可以上线了。 整个流程不要太舒服。 以前用 Go CURD, 框架稳定以后,各种 hanlder/model 加上数据 parser ，全是体力活。
|
 |
28
wcao 2023-07-05 14:45:19 +08:00 2
我是前后端一把梭，使用 pnpm workspace 。
数据库用的 sqlite + prisma, 接口用 trpc ，桌面 App electron 不区分前后端。 单元测试用 vitest.  |
|
29
wcao 2023-07-05 14:51:11 +08:00
补充：代码层面好像也区分了前后端，但是运行的时候，直接启动就行了，不依赖 nginx docker 等。
我感觉 pnpm workspace 方式比较适合独立开发者。 写 API 接口 的时候，我会先写一点简单的单元测试，保证 API 正常调用没问题，等在应用层调用的时候，不会前后端到处定位 Bug 。 |
Select Language