国外王炸技术栈 next.js14+supabase+vercel ?

218 天前
 zhonj

最近接触了很多美国公司的远程工作,不出意外的是这些公司几乎都是使用这一个技术栈,研究了几天还是没明白者技术栈到底优势在哪里?

你说省去了后端开发,直接 nextjs 直接连 supabase,你不还是前端去写后端逻辑么?人数省了一个,时间上没差多少,2 个人一天的工作量,一个人最少也要 1.8 天以上完成。

这一套技术栈个人感觉又回到了那个 jsp 时代,all in one,代码看着也是很凌乱,外国人那群 b ,有直接在页面里面写 sql 的,抽都懒得抽出来。已经看不懂趋势了。

然后反观国内,单应用->前后端分离->微服务。思想层面卷 DDD 。国外就是一把梭代码和人有一个能跑就行,不知道 v 站各位大佬对这个有啥看法?

2618 次点击
所在节点    前端开发
19 条回复
cat
218 天前
前几天刚有一篇帖子讨论 next.js 为什么火: https://v2ex.com/t/1032461
superedlimited
217 天前
外国人“那群 b”,虽然页面里写 sql ,但是人家设计表的时候,字段名不会用拼音首字母啊🤔
admol
217 天前
@superedlimited 外国人设计表的时候会用单词的首字母么?
cat
217 天前
@superedlimited 这就有点无脑黑了吧,国内的这群 b 也不是都用拼音首字母啊
Donaldo
217 天前
@superedlimited #2 他们用的不全是拼音?
netabare
217 天前
外国也是 DDD 和微服务是主流吧。我感觉随便找一下基本上都是这套技术,vercel 做技术栈的企业我还没见到。
zhonj
217 天前
@netabare 可能你碰到的都是大公司吧,我这边接触了十几家中小型公司,都是这个技术栈清一色的,哪怕新写项目我想给他做分离,他们强烈不让分离,说别的公司都是这一套,我们不用这一套拿不到融资,你敢信
zhonj
217 天前
@superedlimited 国外那群 b 虽然不用拼音首字母,但是设计表不会设计任何冗余字段,复杂一点的业务,直接一个视图,里面大量子查询,目的只是为了简化逻辑,降本增效🤣,我碰到一个公司,面试前说他们有一个非常牛逼的后端,我看了下他们代码,根本没有后端服务,有的只是一个数据库和大量的视图,这就是他们全部后端
chuck1in
217 天前
@zhonj 现在这套 next.js 主要是所谓的初创企业和 geek 用的比较多,初创企业根本不在乎扩展设计,系统能用就行。很多人就出最开始写页面的,next 火了以后顺便写后端。

这些人来写后端大概率就是搞成 sql 写逻辑了,没有什么后端业务逻辑上的抽象认知。

这种所有业务写到 sql 里面,在后端看来就是回到了 20 年前,把 20 年前的老路又走了一遍。到时候看那种几百上千行的 sql 谁能看懂。

等再往以后发展,发现这种业务逻辑全在 sql 里面的大杂烩又无法维护了以后,又会重新拆成前后端分离,然后再进化成微服务,进入毅种循环。
newbie111
217 天前
前端发展的趋势看不懂了,十年后才知道是进步还是倒退。
huijiewei
217 天前
我用 Remix + Drizzle ORM + Neon + Vercel 。。。。
ck65
217 天前
虽说 scale 时火葬场,但实际情况是项目到死都无需 scale ,所以索性把项目搞成单兵全栈的模样,起码苟活的期间实打实省了 n 张嘴。
wlm201219
217 天前
我觉得没啥问题,中小型公司,可能明年的时候,项目都没了,甚至公司都没了,一把梭挺好,先活下来。
倒是很多国内的小公司,开发团队不超过十个人,也在玩微服务,甚至见过一个团队十来个人,八十多张表,四十多个微服务,这才是真的看不懂了
haiku
217 天前
历史是个圈,
从经济学角度看的话,技术发展也可以往利率水平上凑,像微服务云原生 ddd ,属于 zero interest rate policy (ZIRP)时期的宠儿,
现在世界经济脱钩成几块,欧美高利率,融资难,
短平快项目糊上线融资才是正式
frankies
217 天前
很简单,vercel 太好用了,对 nextjs 初创公司几乎零成本启动 mvp
hugepizza
217 天前
supabase 的 sql sdk 真是翔一样难用 内置 auth 的拓展性也很差 还得写 db 级的 function 和 trigger 搞得业务逻辑这一块那一块的
既然都 next14 用上 server function 了 supabase 的客户端直连也就用用 select mutation 放 server function 更方便 也不用配各种 update create 的 rls 规则

最近在看类似的 firebase 准备搞个项目练练 毕竟在 upwork 上搜一下 firebase 的活儿比 supabase 多的多
Casbin
217 天前
auth 这块可以试试 casdoor: https://github.com/casdoor/casdoor
hugepizza
217 天前
以上是吐槽 supabase

但是总归来说 想要把一个 idea 快速实现 一个 mvp 的 webapp 和一个 app 我也会选 nextjs+xxbase 这一套

我之前在中等规模的厂干后端 几十个云原生微服务那种的项目 前端后端运维客户端还有专门写 bff 的
一个几十行代码的功能变动 这一伙人一通开会同步需求任务分配开发提交合并发布 不得整个两天 纯属脱裤子放屁事倍工半 个人全栈流程可能一杯咖啡都没嘬完就搞定了

和迷信各种高大上高拓展架构什么的比起来 还是把业务先跑起来攒点用户快点盈利比较实在
对一个开发大头兵来说 节约各种在无意义沟通上花费的精力 也能少掉点头发 多活几年
Foso
217 天前
企业不同规模,不同阶段,有更合适的技术栈选择
一把梭走天下不是不行,但有时候就要付出点代价

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1033978

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX