Logto Bounty Hunter series: 解决开源项目 issue，拿礼品卡

看起来很不错，现在有哪些开源系统支持使用 logto 互联了？

试了好几天还没在测试服务器上部署上 @_@ 尴尬了

不想用 docker ，本地服务器是连不上服务器，用腾讯云的测试无 sudo 吧没权限，sudo 吧总提示：

const pgOutput = safeExecSync('postgres --version') ?? '';

崩溃

@hiugo #1 互联具体是指什么呢？
@Maxwe11 #2 我们刚刚发布了新的 CLI ，可以试试看哈。还是不行的话欢迎随时进入社区沟通

和 casdoor 对比如何？

我手上也有自研的 OIDC 用户系统，也是 ts 写的，核心功能在五千行左右。

我稍微看了两眼你这项目的代码，

我觉得以现在这个规模却不使用 OOP ，只使用函数，然后像前端项目一样用文件系统分割，代码太散太碎，并且有很多重复的脚手架。

你作为这项目的作者维护起来没啥问题，但别人想要进来，太难了，缺少线索。

@Aloento #4 我们暂时没有对比过哈

OOP 在 js 圈一直不太普及，前端项目维护不住容易重写背后是有结构性问题的
像这种基础设施类型的后端项目，应该多借鉴一下 java 世界，起码把可维护性拉起来

@nomagick 没用的，之前给他们提过，KPI 项目不会管这些的

@nomagick #5 您好，感谢关注项目。
> 以现在这个规模却不使用 OOP ，只使用函数
这个更多是哲学问题，软件工程没有银弹，只有取舍和权衡。

> 然后像前端项目一样用文件系统分割，代码太散太碎
请问是怎么得出「太散太碎」的结论的呢？我理解按功能和模块进行文件夹分层是一种基础文件结构优化，现在工程师团队以及社区贡献者并没有遇到「找不到文件」的问题。
我很好奇，如果是 OOP ，能避免这样的情况吗？为什么呢？

> 并且有很多重复的脚手架
这个我没有看出来哈。我们各种配置文件都做了共享，并且 pnpm 管理 monorepo 十分方便，不知道你有没有尝试过。

> 你作为这项目的作者维护起来没啥问题，但别人想要进来，太难了，缺少线索。
请问「太难了」的结论是如何得出的呢？因为我们看到事实是社区里有来自不同国家、行业、和年龄段的贡献者，我们也都单独做了深入沟通，到目前为止还没有人抱怨「上手太困难」的问题。当然还有一种可能是觉得难的开发者直接放弃了，这部分确实无法捕捉到，但只要有贡献的意愿，我们 Discord 基本都会很快回应，并和大家一起解决问题。

> 像这种基础设施类型的后端项目，应该多借鉴一下 java 世界，起码把可维护性拉起来
还是很好奇，如何定义「可维护性」，以及为什么 java 的 convention 就会比「 js 圈」更有可维护性？

@Aloento #8 嘿朋友，友善讨论我们愿意，但乱下结论可不理性。你的「 KPI 项目」是从何得出的呢？

另外，「之前和我们提过」如果是指 t/870546 这个帖子里面的：
「 @logto 用 JS 写的吗，真的大丈夫？」
「鄙人不才，只是如果我自己做相关产品的话不会使用 JS ，您就当我在瞎扯就好」
那我们确实无法回复，毕竟您说的不是设计模式，而是要让项目全部推倒重来了。

@Aloento 说实话，面对 KPI 项目的评价我不知道该高兴还是伤心：
- 伤心的是我们被误会了，从我的发言记录就能看出是在创业，团队对这件事都十分热情（希望他们别看到这个帖子）
- 开心的是原来我们的公司已经被当作大公司了，都能有 KPI 项目的生长土壤 :-)

@pseudo 本来看记录，以为可以硬杠一下 js 不如 ts ，但是点进项目一看，已经是 ts 了，我寻思按最近的趋势用 ts 写后端也没啥毛病啊，突然想起来我有个朋友说过，提问题聊优化都可以，只批评没内容就当看不见了。

创业不易，加油

@pseudo 创业不易，加油，我只是站在使用者的角度看，不是很愿意说很多

我分享这个帖子给我的同事，大家一致认为这是一个 KPI 项目，所以我这么回复了，就当我是在口嗨吧

好心说一下吧，KPI 项目是一种行为模式，不一定代表它真的就一定是因为 KPI 而产生的。

祝好

@pseudo 为什么？ 因为有沟通成本啊，代码和代码之间的，代码和人之间的，人和人之间的

给你打个不太恰当的比方，OOP 就好比人说的话，spoken language, 但人更基础的沟通方式其实是互相比划，body language.
你说为什么一般人发展到一定阶段一定要使用 spoken languange 呢，继续使用 body language 不行吗，当然行了，手语也能交流，盲文也能交流
你说有没有更好的方式，表达能力更强的方式呢，我想可能有，但手语肯定不是那个更好的方式，这个问题也不是哲学问题

OOP 实在是软件行业里面一个基础的东西，不是什么高大上的，它是如此的有效和普遍，以至于你不使用，不会被理解为你的特色或者特立独行，而会被理解为你的 disability ；就像一个人如果拒绝使用 spoken language ，不会被理解为有见地或者特立独行，而会被理解为 disability 。

别的不用说就说写 API 这一件事，别的语言已经演进到什么阶段了，你可以花点时间仔细看一下 Java 现在的 API 是咋写的，Python 那边 fastapi 是咋写的，人家的 openapi 文档是怎么自动带出来的，这里面发生的所有事的认知成本是如何减轻的

大致看了一下你们的后端代码，koa/ts 的技术栈问题不大。产品使用也体验了。
主要感觉是完成度上，功能丰富程度，对比成熟的开源项目还有一些距离吧，期待项目以后的发展

@nomagick 您说的对，是我才疏学浅了

@lovepocky 谢谢。我们项目尚处早期，确实还有很多值得做的功能。最近的几个月我们会专注产品研发，早日满足更广泛的需求。如遇到问题或者有产品上的建议，欢迎随时和我们交流。