这是一个创建于 216 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近接触了很多美国公司的远程工作，不出意外的是这些公司几乎都是使用这一个技术栈，研究了几天还是没明白者技术栈到底优势在哪里？
你说省去了后端开发，直接 nextjs 直接连 supabase,你不还是前端去写后端逻辑么？人数省了一个，时间上没差多少，2 个人一天的工作量，一个人最少也要 1.8 天以上完成。
这一套技术栈个人感觉又回到了那个 jsp 时代，all in one,代码看着也是很凌乱，外国人那群 b ，有直接在页面里面写 sql 的，抽都懒得抽出来。已经看不懂趋势了。
然后反观国内，单应用->前后端分离->微服务。思想层面卷 DDD 。国外就是一把梭代码和人有一个能跑就行，不知道 v 站各位大佬对这个有啥看法?
19 条回复 • 2024-04-20 09:01:24 +08:00
 |
1
cat 216 天前
前几天刚有一篇帖子讨论 next.js 为什么火： https://v2ex.com/t/1032461
|
 |
2
superedlimited 216 天前 via iPhone
外国人“那群 b”，虽然页面里写 sql ，但是人家设计表的时候，字段名不会用拼音首字母啊🤔
|
 |
3
admol 216 天前
@superedlimited 外国人设计表的时候会用单词的首字母么？
|
|
4
cat 216 天前
@superedlimited 这就有点无脑黑了吧，国内的这群 b 也不是都用拼音首字母啊
|
 |
5
Donaldo 216 天前
@superedlimited #2 他们用的不全是拼音？
|
 |
6
netabare 216 天前 via iPhone  1
外国也是 DDD 和微服务是主流吧。我感觉随便找一下基本上都是这套技术，vercel 做技术栈的企业我还没见到。
|
 |
7
zhonj OP @netabare 可能你碰到的都是大公司吧，我这边接触了十几家中小型公司，都是这个技术栈清一色的，哪怕新写项目我想给他做分离，他们强烈不让分离，说别的公司都是这一套，我们不用这一套拿不到融资，你敢信
|
|
8
zhonj OP @superedlimited 国外那群 b 虽然不用拼音首字母，但是设计表不会设计任何冗余字段，复杂一点的业务，直接一个视图，里面大量子查询，目的只是为了简化逻辑，降本增效🤣，我碰到一个公司，面试前说他们有一个非常牛逼的后端，我看了下他们代码，根本没有后端服务，有的只是一个数据库和大量的视图，这就是他们全部后端
|
 |
9
chuck1in 216 天前
@zhonj 现在这套 next.js 主要是所谓的初创企业和 geek 用的比较多，初创企业根本不在乎扩展设计，系统能用就行。很多人就出最开始写页面的，next 火了以后顺便写后端。
这些人来写后端大概率就是搞成 sql 写逻辑了，没有什么后端业务逻辑上的抽象认知。 这种所有业务写到 sql 里面，在后端看来就是回到了 20 年前，把 20 年前的老路又走了一遍。到时候看那种几百上千行的 sql 谁能看懂。 等再往以后发展，发现这种业务逻辑全在 sql 里面的大杂烩又无法维护了以后，又会重新拆成前后端分离，然后再进化成微服务，进入毅种循环。 |
 |
10
newbie111 216 天前
前端发展的趋势看不懂了，十年后才知道是进步还是倒退。
|
 |
11
huijiewei 216 天前
我用 Remix + Drizzle ORM + Neon + Vercel 。。。。
|
 |
12
ck65 216 天前
虽说 scale 时火葬场，但实际情况是项目到死都无需 scale ，所以索性把项目搞成单兵全栈的模样，起码苟活的期间实打实省了 n 张嘴。
|
 |
13
wlm201219 216 天前 via Android
我觉得没啥问题，中小型公司，可能明年的时候，项目都没了，甚至公司都没了，一把梭挺好，先活下来。
倒是很多国内的小公司，开发团队不超过十个人，也在玩微服务，甚至见过一个团队十来个人，八十多张表，四十多个微服务，这才是真的看不懂了 |
 |
14
haiku 216 天前 via Android
历史是个圈，
从经济学角度看的话，技术发展也可以往利率水平上凑，像微服务云原生 ddd ，属于 zero interest rate policy (ZIRP)时期的宠儿， 现在世界经济脱钩成几块，欧美高利率，融资难， 短平快项目糊上线融资才是正式 |
 |
15
frankies 216 天前 via Android
很简单，vercel 太好用了，对 nextjs 初创公司几乎零成本启动 mvp
|
 |
16
hugepizza 216 天前 via iPhone
supabase 的 sql sdk 真是翔一样难用 内置 auth 的拓展性也很差 还得写 db 级的 function 和 trigger 搞得业务逻辑这一块那一块的
既然都 next14 用上 server function 了 supabase 的客户端直连也就用用 select mutation 放 server function 更方便 也不用配各种 update create 的 rls 规则 最近在看类似的 firebase 准备搞个项目练练 毕竟在 upwork 上搜一下 firebase 的活儿比 supabase 多的多 |
 |
17
Casbin 216 天前
auth 这块可以试试 casdoor: https://github.com/casdoor/casdoor
|
|
18
hugepizza 216 天前 via iPhone
以上是吐槽 supabase
但是总归来说 想要把一个 idea 快速实现 一个 mvp 的 webapp 和一个 app 我也会选 nextjs+xxbase 这一套 我之前在中等规模的厂干后端 几十个云原生微服务那种的项目 前端后端运维客户端还有专门写 bff 的 一个几十行代码的功能变动 这一伙人一通开会同步需求任务分配开发提交合并发布 不得整个两天 纯属脱裤子放屁事倍工半 个人全栈流程可能一杯咖啡都没嘬完就搞定了 和迷信各种高大上高拓展架构什么的比起来 还是把业务先跑起来攒点用户快点盈利比较实在 对一个开发大头兵来说 节约各种在无意义沟通上花费的精力 也能少掉点头发 多活几年 |
 |
19
Foso 215 天前
企业不同规模，不同阶段，有更合适的技术栈选择
一把梭走天下不是不行，但有时候就要付出点代价 |
Select Language