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