[远程/开源] 全职 Golang + Nextjs/t3 全栈

[newshbb]

开源初创小公司新立项的关联开源项目，技术方向类似 https://github.com/zabbix/zabbix

目前公司实现盈利，账面上大部分融资还没有花出去。

现在还在选型，初步确定用 Go 写 Agent ，控制台使用 nextjs/t3 技术栈，UI 倾向于 https://ui.shadcn.com 需要实现插件系统。

薪资, 15K-30K

希望你是开源技术爱好者，有成熟作品，对上面提到的技术有所涉猎，面试也是围绕选型开展

请投递简历到：emhiMTIzNDVAZ21haWwuY29t

[areyoucrazytom]

已投 🥰

[yrj]

好巧，前段时间还打算用 go 写一个多服务器管理面板呢 初步打算用 mqtt 协议通信🤣

[redtech]

t3.gg 吗

[nullcloud]

zabbix 直接用不行吗 为啥要另做一个

[ahhtree]

请问需要兼职吗？简历：
https://rxjs-way.vercel.app/post/L3ZlcmNlbC9wYXRoMC9wb3N0cy_nroDljoYubWQ

[rail4you]

还是没忍住，在这里留言下吧。
大家尽量别投这个了，对方相当没诚意。

我也正好有这个方向的项目在做就试着发信问问的，也分享了自己做过的架构希望能进一步讨论下。
但对方一定要给原型实现才行，这也算了，但后面加了一句话"说到不如做到”，这已经不是正经招人做工作了。

[newshbb]

@rail4you 并无恶意，如造成误解，请原谅

[newshbb]

这里贴一下原对话，以免大家误解。原文表达如果不带上语气，的确容易误解，在此表示道歉。

[newshbb]

@yrj 我比较倾向于传统 http

[newshbb]

@redtech 是的

[newshbb]

@nullcloud 不是 zabbix

[newshbb]

@ahhtree 谢谢

[rail4you]

我本来也不想回复的，我介绍自己和给方案，都有不少文字量，还特意把架构图画了，用不用我把架构图也贴上来？

这是态度问题，但凡回复里能客气一些都不至于这样。
这个项目的意义也存疑，也有说套方案的，给 V2EX 里的朋友提个醒。

[newshbb]

之所以提出原型实现的要求，因为 chatgpt 的时代，方案实现很容易得到，毕竟不是生僻的技术领域，但是原型实现比较能体现能力，我表达的“说到不如做到”也是想要表达这个意思，的确容易产生误解。

[rail4you]

@newshbb 您别辩解了，越抹越黑，连 chatgpt 都背锅了。
既然是招人的，就得有招人觉悟，别当儿戏，浪费大家时间和精力。

说到不如做到，这个更别提了，我原谅你行了吧。这话一般人说不出口。

[wkong]

@nullcloud 同问（ zabbix 直接用不行吗 为啥要另做一个）

[newshbb]

@wkong 不是 zabbix ，但是技术路线是一样的

[sofukwird]

好奇 OP 年龄，感觉是完全不懂的外行，伸手党
一开口就要原型，原型是要付费制作的，一个面试机会就要白嫖原型想太多

[newshbb]

@sofukwird 我们的实力还行，985/211 团队（的确没有清北），搞前后端也有 10+年经验，用的技术栈也都比较新，从 asp/php/.net/jquery/angular/react 一路走来（暴露年纪了），目前项目用 rust 和 react 比较多，不至于到这里来白嫖原型。

[gogogo1203]

nextjs 未来的目标是做全栈, 结合 rsc. 要做开源项目，还要和 go 结合，对使用者来说太多未知，需要知道的栈也太多了点。

[sofukwird]

@newshbb 机器人？前言不搭后语。是哪位大佬投放的某种社会实践机器人吗？

[newshbb]

@gogogo1203 这个项目的确有点复杂性

[newshbb]

好的，我会重新调整面试方式

[gogogo1203]

@newshbb 我建议好好考虑一下选型，毕竟是开源。大家用起来方便才是主要的。 后端，前端，ngnix 反向代理，再加上每个部分都要 dockerize. 让所有人都够喝一壶了。

[newshbb]

@gogogo1203 选型也没有确定，是开放的，你有什么建议吗？

[gogogo1203]

@newshbb 我最早写 go ，go 处理 json 是非常繁琐的。如果后台要集合各个服务的 log ，我不敢想象这些 struct 要怎么写。nextjs 未来要捆绑后台，预处理各种 js rsc 。如果前端只是展示各种表格，没有必要搞得那么复杂。 选最简单的方式就好了。 我反而觉得 ux 上用 react-flow 这种可以自由组合和排列的画板形式会更实用一点。

[newshbb]

@gogogo1203 谢谢， 你的思考方向很好，比如 rsc ，react flow ，而且这个 react flow 我们还真能用上

[newshbb]

@gogogo1203 也不是非要用 go 写 agent ，我们的原则还是生产力优先，在部署/性能角度可以妥协，rust/zig ，甚至新出的 mojo/bun 都可以考虑。

[gogogo1203]

@newshbb react-flow 让用户自己排列和调整大小，一个 fitview 就能自动排列好所有表格组件.

[shui14]

这又不冲突，nextjs/t3 这类可以做前端（与用户相关的），然后实际业务 go 开发。这一点都不冲突，如果 n 自家的 vercel 主流语言都支持，自己的话可以先 rpc 之类的，后面可以用它们的方案自己包装一下，v 是用的 aws 的一个 firecracker ，先跑通利润再说。