一个独立的开源项目是如何发展成完整的TypeScript SDK并被MailChannels采用.
有时,开源项目从一个很小的问题开始.
你制造东西是因为你自己需要它, 出版它是因为你觉得别人可能觉得它有用, 然后继续改进它,仅仅因为你喜欢建造软件。
这就是背后的故事。
最初作为一个小的Nuxt集成,最终成为了MailChannels的完整节点.js和TypeScript SDK.
一路走来,我从"Vue","Nuxt"和"UnJS"的生态系统中学到了很多东西,从Resend等其他以开发者为重点的工具中汲取了灵感,最终有机会加入"MailChannels"并获得该项目的通过和正式维护.
事情就是这样发生的。
TL; DR 数据 为MailChannels构建了小型的Nuxt集成,并逐渐发展为完整的TypeScript SDK.
SDK专注于开发者的经验(骆驼Case,TypeScript类型,局部模拟器)并覆盖了40+端点.
我加入了MailChannels,现在帮助维护SDK;欢迎贡献和反馈.
你会学到什么 为什么我建造SDK和它解决的问题 项目如何从Nuxt模块演变为节点. js SDK 关键设计选择 以及接下来的发现 MailChannels I在2022–2023年首次发现 MailChannels ,同时在几个个人和专业项目上工作,需要简便且负担得起的方式发送电子邮件.
我主要是一个网络应用开发商,在当时我和Cloudflare Workers合作了很多.
电子邮件是常见的要求:联系表、欢迎电子邮件、登记通知和其他交易信息。
MailChannels很适合这些项目, 因为它直接融入了Cloudflare Workers, 并免费使用, 包括DKIM签名和域名认证等。
作为实际要求开始的东西逐渐成为我真正感兴趣的东西。
我继续使用MailChannels, 随后在2024年10月,MailChannels宣布结束对Cloudflare工人的支持.
我已经在MailChannels周围建造了几套应用软件, 并且用另一个供应商来取代所有这些集成系统并不特别有吸引力。
幸运的是,MailChannels提供它的Email API免费分级.
我签了字,获得了API密钥,并通过电子邮件API继续使用MailChannels.
这解决了眼前的问题。
但它也暴露了另一个。
API还不错 但我发现自己在不同的项目上 不断建造同样的请求结构 您需要了解工作等属性, 记住可用的选项, 正确构建请求, 并确保有效载荷符合 API 规格 。
做一次很简单 跨多个项目进行这项工作会重复进行。
我开始觉得TypeScript可以让这种经历变得更好一些.
而不是每次手动构建 API 请求, 我希望的东西更接近: 邮箱电子邮件 API 不一定是问题。
我想有一个更好的开发者的经验 围绕它。
从Nuxt开始 我的第一个解决方案不是Node.js SDK 我主要在自己的网络项目中使用Nuxt,因此我最初创建了小型的Nuxt模块(nuxt-mailchannels),使MailChannels更容易被整合入这些应用程序.
那个小项目解决了我眼前的问题 但纳克思生态系统内部的工作也影响了我对图书馆的想法。
Vue, Nuxt, 和更广泛的UnJS生态系统一直是我灵感的一大源泉.
大力关注开发者的经验,TypeScript,干净的API,可相容性,可移植性,以及使复杂事物感觉简单.
与项目合作