TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The Stainless SDK Generator

216 点作者 brandur大约 1 年前

36 条评论

brandur大约 1 年前
I helped maintain the public API language bindings at Stripe for many years, and although I&#x27;d defend it to the death as the right DX (SDKs are <i>so</i> much easier to use than raw web APIs), it&#x27;s hard to appreciate just how onerous of a process this was before Alex pioneered a codegen-based solution.<p>Some of the language SDKs were dynamic (e.g. Ruby, Python) and could adapt automatically to small API changes like if a new field was added in a response. Some were not (e.g. Java, Go), and for every API change, someone had to manually make the change to that SDK&#x27;s codebase (add a field, add a struct, add a function for a new endpoint), get it reviewed and merged, and cut a release. As Stripe got bigger and there were API changes all the time, the only way this was even remotely functional was that we had a couple heroic workhorses that&#x27;d watch for changes and open hundreds of PRs a year for them. Honestly, in retrospect, it&#x27;s amazing this even worked.<p>Getting everything switched over to a generated solution was an arduous process because the new generated code had to be API-compatible with the existing code so that the cutover to generated bindings didn&#x27;t break every Stripe user under the sun. We eventually got there, but it took a long time.<p>I like Stainless&#x27; mission because after seeing the crazy maintenance hassle that all of this was at Stripe, I think it makes way more sense to save all that engineering time for your more concerns, and outsource this problem to someone else. A plug-and-play way of getting high quality SDKs in all common languages that get pushed to appropriate repositories for distribution and comes with quality companion documentation.<p>We&#x27;ve actually had pretty good luck at my current job with open source tools like openapi-generator [1], but this sort of codegen is so convoluted that the sustainability of a pure open source solution makes me a little afraid, and you still end up doing a lot of the last mile work yourself.<p>---<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;OpenAPITools&#x2F;openapi-generator">https:&#x2F;&#x2F;github.com&#x2F;OpenAPITools&#x2F;openapi-generator</a>
评论 #40153528 未加载
评论 #40148503 未加载
GeneticGenesis大约 1 年前
Disclaimer: We&#x27;re an early adopter of Stainless at Mux.<p>I&#x27;ve spent more of my time than I&#x27;d like to admit managing both OpenAPi spec files [1] and fighting with openapi-generator [2] than any sane person should have to. While it&#x27;s great having the freedom to change the templates an thus generated SDKs you get with using that sort of approach, it&#x27;s also super time consuming, and when you have a lot of SDKs (we have 6 generated SDKs), in my experience it needs someone devoted to managing the process, staying up with template changes etc.<p>Excited to see more SDK languages come to Stainless!<p>[1] <a href="https:&#x2F;&#x2F;www.mux.com&#x2F;blog&#x2F;an-adventure-in-openapi-v3-api-code-generation" rel="nofollow">https:&#x2F;&#x2F;www.mux.com&#x2F;blog&#x2F;an-adventure-in-openapi-v3-api-code...</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;OpenAPITools&#x2F;openapi-generator">https:&#x2F;&#x2F;github.com&#x2F;OpenAPITools&#x2F;openapi-generator</a>
bterlson大约 1 年前
Grats on the release! It will be awesome to see how far y&#x27;all can push codegen quality from an OpenAPI source of truth.<p>I worked on this extensively inside Azure and I know it is not an easy problem (and with more JSON Schema coming in 3.1&#x2F;4.0, it is only getting harder). There are a lot of API patterns that you want to expose purpose built client abstractions for. Pagination is a big example. If you stick to OpenAPI, you have to ensure your specs use the patterns your client generator recognizes, and it&#x27;s not always trivial for authors to know how to express that pattern and for your codegen to infer that pattern. In Azure we tended to rely more on custom extensions to OpenAPI because it made the contract a lot clearer and less error prone, but then you lose interoperability.<p>One thing to consider - I work on TypeSpec[1], and one of the main reasons we built it is to allow encapsulation and reuse of patterns in a first-class way. So, rather than the contract being &quot;endpoints which declare parameters and&#x2F;or return types with these shapes are inferred to be paginated endpoints&quot;, the contract can be &quot;use Page&lt;T&gt;&quot; and the emitted OpenAPI conforms to the contract without effort. It would be fun to see a Stainless TypeSpec library for all the patterns your codegen supports!<p>1: <a href="https:&#x2F;&#x2F;typespec.io" rel="nofollow">https:&#x2F;&#x2F;typespec.io</a>
mmcclure大约 1 年前
We&#x27;re in the process of (slowly) switching our SDKs over to Stainless. I&#x27;ll be transparent that it hasn&#x27;t been the easiest&#x2F;quickest process ever, but the biggest pain point so far is that we were forced to clean up some rough spots around our OpenAPI spec. It was something we needed to do anyway, so definitely not a knock on Stainless, but it did take the first SDK rollout from being a month or two to many months.<p>The biggest reason we started working with Stainless was to migrate from the open source generator process we were struggling with, but actually ended up transitioning our hand-rolled Node&#x2F;JS SDK first because it&#x27;s both our most popular SDK and because the fragmentation of the JS ecosystem has been a surprisingly big headache[1]. Went into it for reduced maintenance, came out pleasantly surprised at how useful I was finding my own SDK&#x27;s features around `for...of` on paginated routes, etc.<p>Congrats on the launch, Stainless crew!<p>[1] <a href="https:&#x2F;&#x2F;www.mux.com&#x2F;blog&#x2F;keeping-up-with-the-node-ish-ecosystem" rel="nofollow">https:&#x2F;&#x2F;www.mux.com&#x2F;blog&#x2F;keeping-up-with-the-node-ish-ecosys...</a>
pksunkara大约 1 年前
How do you guys differ against <a href="https:&#x2F;&#x2F;www.speakeasyapi.dev" rel="nofollow">https:&#x2F;&#x2F;www.speakeasyapi.dev</a> and <a href="https:&#x2F;&#x2F;www.buildwithfern.com">https:&#x2F;&#x2F;www.buildwithfern.com</a> and <a href="https:&#x2F;&#x2F;liblab.com" rel="nofollow">https:&#x2F;&#x2F;liblab.com</a>?
评论 #40148439 未加载
jenanwise大约 1 年前
I’ve been working with the Stainless team over the last year, and I rapidly went from being highly skeptical of outsourcing SDKs to being one of the team’s biggest fans.<p>Separately, as a consumer of many afterthought-ish SDKs for popular services, I’m extremely excited to see their work opening up to more developers. I hope it raises the bar for SDKs everywhere!
ucarion大约 1 年前
Lots of these have been popping up lately, they all seem really good. This is the first one I&#x27;ve seen with an answer for &quot;I want to customize the output by hand&quot;, which is neat.<p><a href="https:&#x2F;&#x2F;buildwithfern.com&#x2F;">https:&#x2F;&#x2F;buildwithfern.com&#x2F;</a> <a href="https:&#x2F;&#x2F;liblab.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;liblab.com&#x2F;</a> <a href="https:&#x2F;&#x2F;www.speakeasyapi.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.speakeasyapi.dev&#x2F;</a><p>Between this and fancy API doc generators (Mintlify, etc.), I feel like we&#x27;re finally getting close to being able to just go from OpenAPI to Stripe-level &quot;polish&quot;.
评论 #40150814 未加载
androa大约 1 年前
I&#x27;ve been using openapi-generator for this for quite some time. I love the principle, but find that their generators are not all top notch, and the template-based approach is very hard to contribute to.<p>One thing I do not see with Stainless is also using it to generate the server side of the API.<p>We use OpenAPI as a design doc, and generate client SDKs and Datos for the server from the same spec. This gives us pretty solid control over interoperability.
评论 #40147871 未加载
评论 #40148471 未加载
morgante大约 1 年前
Stainless and Alex have been great to work with! We&#x27;ve partnered with them to incorporate automated migrations for several APIs (ex. <a href="https:&#x2F;&#x2F;docs.grit.io&#x2F;patterns&#x2F;library&#x2F;cloudflare_go_v2" rel="nofollow">https:&#x2F;&#x2F;docs.grit.io&#x2F;patterns&#x2F;library&#x2F;cloudflare_go_v2</a>) and everyone at Stainless is consistently technically brilliant and kind.
nknj大约 1 年前
Proud to have Stainless as a partner at OpenAI. All our SDKs are generated by them. Alex, Robert, Philip and team are extremely thoughtful about SDK design and push us to improve our API + other products while they&#x27;re at it. Stainless is bringing a new standard of SDKs to our industry and this is a great thing for all developers.
twitchard大约 1 年前
Congratulations to Alex and team! Had the pleasure of working with Alex on SDK generators back in 2019 and 2020 and it&#x27;s very exciting to see these ideas and the fruits of this become available to the entire world. Stainless would definitely be where I looked first if I were starting a developer-facing SaaS today.
sloanesturz大约 1 年前
We&#x27;ve been happy customers of Stainless since the beginning. Alex and the team are thoughtful and care a lot about API design. Recommended!<p><a href="https:&#x2F;&#x2F;github.com&#x2F;increase">https:&#x2F;&#x2F;github.com&#x2F;increase</a>
bgentry大约 1 年前
I was fortunate to be able to watch Stainless evolve while at Mux when we were evaluating it to replace open source &amp; homegrown generators. Alex &amp; team were incredibly responsive to feedback throughout, and the product improved quickly.<p>Generated code has a bad rap for results that are not idiomatic or user-friendly, but I think it&#x27;s clear that it doesn&#x27;t have to be that way—getting it right just takes a lot of care and effort that is typically overlooked.<p>Stainless is definitely best-in-class here as far as I&#x27;ve seen.
pm大约 1 年前
A couple of months ago I tried to generate a Swift SDK using Cloudflare&#x27;s OpenAPI spec with Apple&#x27;s Swift OpenAPI generator, to no avail. Apple&#x27;s generator is quite strict from what I can tell, so I&#x27;m curious about the differences between Stainless&#x27; and Apple&#x27;s work.<p>(I haven&#x27;t tried it since then, so it may work now).
serjester大约 1 年前
Out of curiosity how difficult has it been hosting OpenAI&#x27;s SDK? Is there one off stuff that goes into that? Their API seems really challenging - SSE&#x27;s, tons of complex generics, async, docs - it&#x27;s endless.<p>Really impressive stuff, I can&#x27;t imagine doing all this with a team as lean as yours.
评论 #40153364 未加载
ezekg大约 1 年前
I run an API SaaS and this looks great. I&#x27;ve wanted to add more SDKs to my lineup, but it&#x27;s a big commitment for a single person to maintain. Right now, I have a minimal Go SDK to test the waters and definitively see how much effort it takes. One hurdle I have with services like Stainless (which looks great!) is that I don&#x27;t know where to start to actually codegen an OpenAPI spec from a Ruby&#x2F;Rails API. Writing and maintaining the spec by hand sounds like a nightmare for any decent sized API, but I guess it&#x27;s not worse than maintaining multiple SDKs (or even one). How did Stripe handle this?
评论 #40148181 未加载
评论 #40148113 未加载
TehShrike大约 1 年前
I&#x27;m curious to see the output. Most of the time I specifically avoid using the SDK published by the API provider because it&#x27;s thousands of lines of code when all I need is ten lines wrapping fetch.
评论 #40147545 未加载
vvoyer大约 1 年前
What about jsii? The technology behind AWS cdk sdks: <a href="https:&#x2F;&#x2F;aws.github.io&#x2F;jsii&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.github.io&#x2F;jsii&#x2F;</a><p>Is Stainless similar, different?
评论 #40153349 未加载
ashryan大约 1 年前
I’ve been keeping a simple list of SDK generators here: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;ashryanbeats&#x2F;7806079820e0c83b35b94ae867289850" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;ashryanbeats&#x2F;7806079820e0c83b35b94ae...</a><p>Nothing fancy but maybe more helpful than picking through SEO articles in you’re looking for options.
Max_Horstmann大约 1 年前
Congrats!<p>Any C# support in the works? :)
评论 #40147331 未加载
enepture大约 1 年前
Congratulations to Alex and the team. After chatting with them recently at a NYC meet-up, you can tell they live and breathe client SDK generation. They are thoughtful about creating an excellent experience for those generating SDKs (Stainless Studio) and those consuming them. Good luck!
yencabulator大约 1 年前
Frankly, this looks horrible. Generics and weird calling conventions instead of setting struct fields, no thanks.<p><pre><code> zone, err: = client.Zones.New(context.Background(), zones.ZoneNewParams { Account: cloudflare.F(zones.ZoneNewParamsAccount { ID: cloudflare.F(&quot;023e105f4ecef8ad9ca31a8372d0c353&quot;), }), Name: cloudflare.F(&quot;example.com&quot;), Type: cloudflare.F(zones.ZoneNewParamsTypeFull), })</code></pre>
htunnicliff大约 1 年前
Question for Stainless folks: For Node.js&#x2F;JavaScript SDKs, did you consider using Proxy instances in lieu of classes for each resource, to reduce the amount of actual code generated?
评论 #40148127 未加载
kmlx大约 1 年前
what’s the difference between this and <a href="https:&#x2F;&#x2F;github.com&#x2F;deepmap&#x2F;oapi-codegen">https:&#x2F;&#x2F;github.com&#x2F;deepmap&#x2F;oapi-codegen</a>
评论 #40147521 未加载
评论 #40147233 未加载
评论 #40147153 未加载
jacoblee9315大约 1 年前
Congrats on the launch! Incredible customer list!
gp大约 1 年前
This is a very exciting product - I&#x27;m surprised this didn&#x27;t exist until now. Would love to see C++ support in the future.
tango12大约 1 年前
Love this!<p>Curious, wouldn’t this be great for folks with internal APIs as well?<p>Team 1 can consume team 2’s API with an SDK instead of a raw REST client.
addcn大约 1 年前
Alex and team are top notch. Met some of their customers who also use Optic and hear great things.<p>Definitely the place to go these days if you have a public API and want it to be as developer friendly as they come.
aazo11大约 1 年前
We use Stainless. Great team and product.
beastman82大约 1 年前
Is gRPC too easy or ?
shidoshi大约 1 年前
Congrats, folks.
ramijames大约 1 年前
That is a very nice landing page.
Harriet_大约 1 年前
Been waiting for this! Nice!!
geekodour大约 1 年前
is this an alternative to buf.build?
评论 #40147497 未加载
评论 #40147461 未加载
yreznikova大约 1 年前
Great solution!
simplesager大约 1 年前
Congratulations to the Stainless team on a fantastic launch! I&#x27;m one of the co founders of Speakeasy (<a href="https:&#x2F;&#x2F;www.speakeasyapi.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.speakeasyapi.dev&#x2F;</a>). We do similar things in the SDK space and some other things too.<p>I resonate with a lot of what is said in the comments. Last mile API tooling is underrated and most companies don&#x27;t have the deep API platform expertise to build from scratch. The OSS options in the space proved SDK generation could be done but the actual product that you got in hand still needed a lot of work to be enterprise ready. The code was poor quality, wasn&#x27;t customisable and there was no change management story. We&#x27;re seeing a new wave of work in this space that&#x27;s making api platform engineering much more accessible.<p>The API devex story starts with SDK creation and maintenance but there is a lot more to come!