这是一个创建于 212 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前在用 Go 做后端开发，前端打算使用 next.js ，但是看了几个帖子下来说 next.js 做全栈会更好一点，还有建议使用 vite 创建 react 项目的。所以比较好奇，这样的技术栈搭配会不会有什么问题？
36 条回复 • 2024-04-18 21:19:13 +08:00
 |
1
NessajCN 212 天前  2
没啥问题，有些小的后端任务懒得用 go 写了就直接 nextjs 里搞定了
|
 |
2
ryougifujino 212 天前 2
用 nextjs 可以用 trpc ，前端不用写接口请求 api 还能做到端到端类型安全
|
 |
3
vczyh 212 天前 1
我感觉用 nextjs 挺好的，下可以只写写前端页面，上可以前后写一起全栈，我当时学 react 都是直接在 nextjs 干的。
|
 |
4
loveshuyuan 212 天前 1
nextjs 一些轻量的后端可以做，但是要加上中间件、消息队列、授权等之类的话就比较乏力。
|
 |
6
Cola98 OP @loveshuyuan 了解，谢谢大佬解答，目前后端技术上是有中间件和消息队列这些，这样的话，能够明白了
|
 |
7
terranboy 212 天前 3
还在以渲染为主 ，后端不建议交给前端框架 ，他们现在真的有点飘
|
|
8
terranboy 212 天前
早几年 prisma 吹得听牛逼 用了下 坑一大堆 感觉跟后端的 ORM 还差得远 现在不清楚
|
 |
9
lstz 212 天前 via Android
纯粹渲染挺好的，至于更复杂一些的程序，我选择用 go 来实现
|
 |
11
MrYELiex 212 天前
next 很擅长前端渲染 重用户体验的场景 前端部分偏向官网/营销/电商 后端部分偏向接口拼接及面向前端的业务接口 不适合传统意义上的后端和后台管理应用
|
 |
13
Track13 212 天前
看你要不要服务端渲染了。不要就 vite+react 。
|
 |
14
fescover 212 天前 via iPhone
试试 remix spa
https://remix.run/docs/en/main/future/spa-mode |
|
15
MrYELiex 212 天前
@horizon #12 你要硬用来写后台那也不是不行 但是没必要啊 后台管理是 spa 不管前端用什么路由模式相对服务端都是单页 但是 next 默认你就是多页应用 所有的设计思路都是多页 建议上服务端渲染的 后台应用上 ssr 和 mpa 不是脱裤子放屁吗 vite,cra 才是适合这种场景的解决方案
|
 |
16
tianzx 212 天前 1
感兴趣可以看下我开源的 Saasfly 。https://github.com/saasfly/saasfly
|
 |
17
horizon 212 天前
@MrYELiex #15
问题在于后台管理为什么就一定是 spa 。。 而且 nextjs 的 DX 很好啊，什么都给配好了，无脑写就行。 也没说用 nextjs 就一样要 ssr 啊。。我现在全部 dynamic import 我反而认为后台就适合用 nextjs 来写，因为不需要什么高并发、中间件 前后端一把梭了 |
 |
18
oliveira 212 天前 1
Go 和 JS 两门语言切换不觉得会有心智负担吗？
nextjs + trpc + prisma 一把梭不香吗？ |
 |
19
Makabaka01 212 天前 1
@terranboy 一般 nextjs 不做数据库操作，都是做 bff 拼 rpc 请求的
|
 |
20
djkloop 212 天前 2
|
|
21
Makabaka01 212 天前
@oliveira 我日常就是这俩，说实话这俩语言其实切换没啥心智负担，目前唯一遇到的就是 switch 循环 go 不需要 break ，这个有时候会写错
|
 |
22
herozzm 212 天前
不知道 next.js 的 ORM 怎么样
|
 |
23
epiloguess 212 天前
@horizon nextjs 写后台是没问题的,现在客户端导航 CSR , 非常完善, 纯 SPA 的优势在哪里我不知道...MPA 一样可以做到预读取,无缝渲染,路由权限也可以用 并行路由/条件路由来实现...
|
 |
24
wuhao666 212 天前
有人用 sveltekit 吗
|
 |
26
raw0xff 212 天前 1
对 next.js 一无所知，弱弱的问一下如果我用 next.js 写一个带页面的后端服务给别人用，是不是就相当于把源代码都给了别人？
|
 |
27
qingyingwan 212 天前
后台管理：页面性能要求不高，业务复杂难度高、交互复杂度高。前后端分离，vite+react
博客官网：页面性能有要求，没啥业务难度。nestjs 一把梭。 问题不是渲染或者路由方案的事，而是有的复杂业务问题没有解决方案，你可以在大部分情况用的很爽，但一个核心问题没有现成方案或者不支持就是致命的 |
 |
29
xiaohanyu 212 天前 1
用 Next.js 写了自己的 SaaS 产品： https://ppresume.com ，大概 13k 代码左右。
Go + Next.js 肯定是没有问题的。不过根据场景，也需要具体的技术选型。 - 纯 SPA 程序？用 react 就行 - 有搜索 SEO 需求？最好 next.js ，加上单独的后端 - 后端和 next.js 通信又有几种方式，可以采用 next.js 前端和 Go 直接通信，也可以 next.js 的前端 -> next.js server -> go server 通信 如果有比如重的 content management 需求，或者需求一个 admin dashboard ，可以考虑采用一些 headless CMS ，如 strapi 这种直接生成后端，这就是非 Go 的后端方案了。 |
|
30
xiaohanyu 212 天前
@raw0xff 并不是的，next.js 的代码有一部分会在前端浏览器里运行，另一部分是在后端运行的，后端的就不用说了，前端的代码也是经过编译和混淆的，基本上也是不可读的状态。
|
|
31
xiaohanyu 212 天前 1
前后端都用 JS/TS 还有一个好处，就是利用 npm/yarn workspace 这种功能，可以将部分前后端共享的代码抽出来共享，比如一些数据类型定义，一些 utility 等等（楼上也有人提到了 trpc 这种方案，我没有用过）。
|
 |
34
kailpony4396 211 天前
go+htmx 挺有趣的
|
 |
35
opentrade 211 天前
相比前后端分离，效率并没有提高，反倒引入了更多复杂性，使用一个月后的观感
|
Select Language