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

61–67 of 67 posts

Re: The Stainless SDK Generator

#61

Post by simplesager »

lapusta wrote: post #44
pksunkara wrote: post #14

How do you guys differ against https://www.speakeasyapi.dev and https://www.buildwithfern.com and https://liblab.com ?

We've recently evaluated all four platforms—Stainless, Fern, Speakeasy, and Liblab—and here are our key takeaways: Stainless: The standout for maturity and idiomatic code generation. While method signatures across products may look the same, Stainless shines during developing & debugging - making their codebase easier to navigate. They have a practical separation of SDK configuration from OpenAPI specification, setti…

Thanks for the mention! We do move fast and to help manage the changes better we've introduced a number of change management concepts recently like breaking change detection and more controls around semver. The updates can also be stacked by the user into PRs and versions updated and published in one go. Definitely choices that we can guide you through

On the Speakeasy branded classes. We got rid of that some time ago based on customer feedback. Check out our new TS generator https://www.speakeasyapi.dev/post/how-we-built-universal-ts

Re: The Stainless SDK Generator

#63

Post by rattray »

serjester wrote: post #55

Out of curiosity how difficult has it been hosting OpenAI's SDK? Is there one off stuff that goes into that? Their API seems really challenging - SSE's, tons of complex generics, async, docs - it's endless. Really impressive stuff, I can't imagine doing all this with a team as lean as yours.

It definitely isn't easy, but it's the kind of challenges we love! You mentioned many of the big ones, but there's also just the sheer scale of the userbase, which means the libraries will be run under every permutation of runtime and configuration under the sun. It's a lot of edge cases to get right!

Their team is great to work with, which helps make it worth it.

(Note that a lot of the SSE type stuff we do generally so we're able to support a variety of AI companies and other streaming use cases, though disclaimer it is a premium feature)

Re: The Stainless SDK Generator

#64

Post by eskibars »

brandur wrote: post #29

I helped maintain the public API language bindings at Stripe for many years, and although I'd defend it to the death as the right DX (SDKs are so much easier to use than raw web APIs), it's hard to appreciate just how onerous of a process this was before Alex pioneered a codegen-based solution. Some of the language SDKs were dynamic (e.g. Ruby, Python) and could adapt automatically to small API changes like if a new…

I've worked on 4 different (pretty heavily used) developer-focused products in my career in product management, and we hand-built SDKs for each of them. This experience is so common: in all cases, a lot of the leadership went into it thinking it would be an easy-to-maintain "background task" to maintain 4-6 SDKS because we generally hired pretty well seasoned and hard working developers

Inevitably in all cases language-specific problems exactly like this happened, but also just some frustrating drift. One of those heroic workhorses would go out on parental leave and maybe a backup would go on vacation or out for extended sick time and the SDKs would start drifting away from the API. Someone would be stuck maintaining code in their absence. At one point, I (a product manager at the time) got tasked with maintaining a Perl SDK while a developer was out on leave for several months because my background is in software development and I was the only person that could really maintain it in the company.

I'm happy to see tools like this come about because it seems everyone underestimates how much work SDKs take to really build functional SDKs. You can get bad ones cheaply by just putting a few people on and accepting bugs and drift. The counter-argument against these tools that I've generally heard is that they'll also produce worse ones cheaply or require effectively the same maintenance to figure out a machine-generated problem as a human-generated problem.

Re: The Stainless SDK Generator

#66

Post by kmlx »

jamietanna wrote: post #22
kmlx wrote: post #7

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

Thanks for thinking of oapi-codegen (I'm one of the maintainers) but agreed, we only target Go - maybe that'll change in the future, but there are a lot of great companies out there working on this as a problem that I'm happy not trying to compete against

thanks for being a maintainer!

Re: The Stainless SDK Generator

#67

Post by yencabulator »

Frankly, this looks horrible. Generics and weird calling conventions instead of setting struct fields, no thanks.

    zone, err: = client.Zones.New(context.Background(), zones.ZoneNewParams {
        Account: cloudflare.F(zones.ZoneNewParamsAccount {
            ID: cloudflare.F("023e105f4ecef8ad9ca31a8372d0c353"),
        }),
        Name: cloudflare.F("example.com"),
        Type: cloudflare.F(zones.ZoneNewParamsTypeFull),
    })
Post reply on HN