Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Stainless SDK Generator

stainlessapi.com

Post reply on HN
Print view View original

31–40 of 67 posts

Re: The Stainless SDK Generator

#31

Post by itslennysfault »

androa wrote: post #28

I'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. One thing I do not see with Stainless is also using it to generate the server side of the API. We use OpenAPI as a design doc, and generate client SDKs and Datos for the server from the same spec. This gives us pretty…

Thats what I used at my previous startup and had a lot of luck with it. Our backend used NestJS which allowed us to define APIs and DTOs using decorators which automatically generated OpenAPI json files. Then our clients would load the json and generate their own SDK as a library. It worked extremely well. It worked so well that I don't really understand what problem Stainless is solving. We didn't ship public SDKs. So, maybe that's what I'm missing, but for our internal clients OpenAPI generators worked great. We generated SDKs on the fly for TypeScript (Node services and Angular clients), Dart (flutter), Kotlin (android), and Swift (iOS). For the most part it all "just worked" for our use case.

Re: The Stainless SDK Generator

#32

Post by ezekg »

I run an API SaaS and this looks great. I've wanted to add more SDKs to my lineup, but it'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't know where to start to actually codegen an OpenAPI spec from a Ruby/Rails API. Writing and maintaining the spec by hand sounds like a nightmare for any decent sized API, but I guess it's not worse than maintaining multiple SDKs (or even one). How did Stripe handle this?

Re: The Stainless SDK Generator

#33

Post by itslennysfault »

rattray wrote: post #9
kmlx wrote: post #7

what’s the difference between this and https://github.com/deepmap/oapi-codegen

oapi-codegen looks pretty cool (it seems I starred it some time ago) but for starters, it's Go only. Stainless does a bunch of languages with more on the way. You can see an example of the Go code Stainless produces here: https://github.com/cloudflare/cloudflare-go (I'm the Stainless founder)

That one only does Go, but it is just one of many OpenAPI generators. I used openapi-generator and was able to produce SDKs for TypeScript (angular and node), Dart (Flutter), Kotlin (andoird), and Swift (iOS). They worked great for our purposes and I really had no complaints or issues.

I guess my question is, what is the key differentiator that Stainless offers above just using OpenAPI and its huge library of existing generators?

https://github.com/OpenAPITools/openapi-generator

Re: The Stainless SDK Generator

#36

Post by ucarion »

Lots of these have been popping up lately, they all seem really good. This is the first one I've seen with an answer for "I want to customize the output by hand", which is neat.

https://buildwithfern.com/ https://liblab.com/ https://www.speakeasyapi.dev/

Between this and fancy API doc generators (Mintlify, etc.), I feel like we're finally getting close to being able to just go from OpenAPI to Stripe-level "polish".

Re: The Stainless SDK Generator

#37

Post by amne »

ezekg wrote: post #32

I run an API SaaS and this looks great. I've wanted to add more SDKs to my lineup, but it'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't know where to start to actually codegen an OpenAPI spec from a Ruby/Rails API. Writing and ma…

From experience I can tell you that you just need to do it manually. And keep maintaing the spec manually. That keeps you aware of it. It is your contract with the outside world. You don't want tools to automatically update it everytime you push. On the contrary, you want tools to slap you hard every time you push and you forgot to update the spec. Now you're going to think hard why did you change the spec and if you maybe need to bump to /api/v2/*

As far as generating the first spec from an existing API I think there was shown here on HN a while ago a tool that can generate the spec from you just "browsing" the API with developer tools or something. Maybe even from a HAR file IIRC.

Re: The Stainless SDK Generator

#38

Post by rattray »

htunnicliff wrote: post #35

Question for Stainless folks: For Node.js/JavaScript SDKs, did you consider using Proxy instances in lieu of classes for each resource, to reduce the amount of actual code generated?

Yeah, we opted for classes like this to ensure simple, reliable static typing.

The amount of runtime code generated per endpoint is typically around 3 short lines – here's an example, also posted elsewhere on this thread: https://github.com/lithic-com/lithic-node/blob/36d4a6a70597e...

Re: The Stainless SDK Generator

#39

Post by rattray »

ezekg wrote: post #32

I run an API SaaS and this looks great. I've wanted to add more SDKs to my lineup, but it'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't know where to start to actually codegen an OpenAPI spec from a Ruby/Rails API. Writing and ma…

> I don't know where to start to actually codegen an OpenAPI spec from a Ruby/Rails API… How did Stripe handle this?

Stripe built their own Ruby DSL for exactly this, and it worked great. It looked something like this:

    class CreateCustomerMethod
Unfortunately, I don't know of an open-source equivalent for Ruby; FastAPI in Python is the closest I know of in any language. At Stainless, we're building a TypeScript version of this, but it's still deep in dogfooding.

Most people just end up maintaining by hand and using a tool like Optic or Akita to check that it's not wildly out-of-date.

Post reply on HN