laf next 重构计划说明

[maslow]

现版本为 v0.8.12，laf 决定做一次全面彻底重构，目前重构代号为 next。

📆 背景

• 详见 laf 的发展背景和方向讨论 #178

👉 关键点

• 使用 kube api-server 取代原 laf system-server
• 使用 go 代替原 node.js 为主要开发语言
• 放弃 docker compose 部署方式，采用 kubernetes 为唯一环境
• 采取 k8s crd + controllers 做为新架构的实现方式

❓ 为什么要采取 kubernetes 架构？

1. 现版本（v0.8）迭代的过程，在没有考虑使用 kubernetes 架构之前，就已经在向「datastore + controller」的方向演进了，如 gateway-controller、instance-controller），迫于越来越多的需求和迭代效率压力，有日益强烈的解耦愿望。

2. 现版本的 laf #是没有经过顶层设计的，他的开发过程是自下而上的，工程中需要什么功能，就开发什么功能，每个按钮都是被开发者催出来的，这个在初期务实的，但是在接下来的需求和定位上，已经无法匹配和满足了。 laf 的发展背景和方向讨论 #178

3. laf 接下来的设计原则和优先级是, api -> cli -> web client -> ide plugin，对一套抽象、扩展、良好设计、稳定的API 的需求是迫切的，选择 kubernetes api 的第一原因是这条。

4. 选择 kube api 后， laf 和 sealos 的关系，未来会有更多可能性， 这两个产品是孪生，不可不考虑。

❓ 为什么采取 go 语言？

最初并没有任何计划要用 go 代替 node.js ，最终选择 go 主要是因为：

1. 选择 kubernetes crd 的实现方式，使用 kubebuilder 开发 crd 实在太方便和成熟，并且没有替代品（在了解 kubebuilder 之前，我是打算用 node.js 写 crd 的，那样工作量要翻数倍了，仅因为 kubebuilder 是 go 语言生态）

2. 主要原因就是上一条， 此条是附加的，laf 和 sealos 是孪生项目，选择 go / crd / kube 之后，团队的技术栈高度统一，消除了社区和团队的隔裂，能从 sealos 社区获取大量帮助，共同沉淀。

❓ 为什么现在分精力去做重构，而非聚焦用户产品需求？

有 laf 用户发出质疑：

很多云开发用户并不关心你是什么架构， 你们是不是走偏了，偏离用户需求了？

“我有不一样的看法，看看主流laf玩家，(小白用户居多)，喜欢什么功能可以考虑下。很多时候专家级玩家，不懂小白玩家的需求。我就是普通小白玩家”

本次重构，看似是不务正业，搁置现版本迭代去“推新版”，实际上是为了更快速的迭代，为了后面的无摩擦迭代，能省出更多的精力去做用户体验、做产品生态。

这个质疑中的观点，我是极度赞成的，laf 一定是始终围绕用户需求的，从开始、现在到未来都会是。 其实做架构的调整，就是为了从架构上省时省力，一劳永逸的解决掉一部分问题。从而让我们能更专注的考虑和满足“所谓小白”的需求。

这个立场是很明确的， 这样说更容易明白：

我最想做的事情根本不是”开发 laf“，我只想使用 laf 开发有意思的小应用。

这是我做 laf 的初衷，为了能让我早日从 laf 的开发工作中解脱出来，和大家一起开发各种小程序。 才做了这次架构大调整，

同时，良好的设计，也更有利于协作和吸引更多的贡献者。

❓ 怎么参与/跟进 laf next 的开发？

• 当前 next 版本代码在 与 现版本代码并存，其开发进度在： https://github.com/orgs/labring/projects/5/views/1
• 现版和新版的代码还没有做清理，主要代码在 controllers 目录下
• 你需要的前置技术点：熟悉 kubenetes、理解 kubenetes crd、掌握 kubebuilder 的开发、了解 golang

⚠️ TODO 尽快编写「开发者指引文档」详细描述如何参与贡献

❓ 哪里可以了解 laf next 的架构原理？

👉 laf 架构说明文档

❓ 哪里能看到 roadmap ？

👉 laf roadmap