3 ms·

It's just a ton of work to make a good SDK in every major language. Something I haven't seen mentioned much on this thread is that the ~top feature people want

It's just a ton of work to make a good SDK in every major language. Something I haven't seen mentioned much on this thread is that the ~top feature people want from SDKs at this point is good static types – so you can get autocomplete, docs-on-hover, etc in your editor. Way better than switching back and forth to the docs and crossing your fingers. Doing that well means copying every little change into the SDKs (forget about it) or using a generator. The open-source codegen tools (ie, https://openapi-generator.tech/ https://openapi-generator.tech/) are pretty crappy, so you need to either build the SDK yourself fully, or spend a bunch of time wrestling with the generator get it halfway-decent, and then you're still letting your customers/developers down. Disclaimer, I'm starting a company to make it easy for anyone to ship a great SDK with their REST API: https://stainlessapi.com https://stainlessapi.com

whitfieldsdad 3y ago
Yeah, making a good SDK for every major language would be an absolutely Sisyphean task with negligible returns - it'd be great to have at least one solid reference implementation though. e.g. a reference implementation in Ruby if they're a Ruby shop, a reference implementation in Java if they're a Java shop, etc. I wonder if you can generate a "good enough" API client to start out with using say, OpenAPI and then tweak it to suit your needs? Then again, maybe this is where something like gRPC would really shine compared to REST APIs - I'm not sure, but, it seems like an area that could be improved significantly. Your startup sounds promising, and hopefully it helps to simplify things!
- rattray 3y ago
  Yeah, the path you're talking about is pretty common actually. Companies handwrite one SDK in the language they're most familiar with, then use OpenAPI-Generator to produce a few others and try to patch up the obviously broken things. They tend to get quite sick of both hand-maintaining any SDK (even in the language they love), and of dealing with the problems/toil of the openapi generator (or the user complaints of the non-idiomatic code they didn't understand, because it was in a different language). Still, it's better than nothing, so I applaud those who take on the effort! Thanks for the kind words – we hope to help bring the well-typed nature of gRPC to REST, without making things more complicated.
deleted 3y ago
[deleted]

whitfieldsdad 3y ago

Yeah, making a good SDK for every major language would be an absolutely Sisyphean task with negligible returns - it'd be great to have at least one solid reference implementation though. e.g. a reference implementation in Ruby if they're a Ruby shop, a reference implementation in Java if they're a Java shop, etc. I wonder if you can generate a "good enough" API client to start out with using say, OpenAPI and then tweak it to suit your needs? Then again, maybe this is where something like gRPC would really shine compared to REST APIs - I'm not sure, but, it seems like an area that could be improved significantly. Your startup sounds promising, and hopefully it helps to simplify things!

rattray 3y ago
Yeah, the path you're talking about is pretty common actually. Companies handwrite one SDK in the language they're most familiar with, then use OpenAPI-Generator to produce a few others and try to patch up the obviously broken things. They tend to get quite sick of both hand-maintaining any SDK (even in the language they love), and of dealing with the problems/toil of the openapi generator (or the user complaints of the non-idiomatic code they didn't understand, because it was in a different language). Still, it's better than nothing, so I applaud those who take on the effort! Thanks for the kind words – we hope to help bring the well-typed nature of gRPC to REST, without making things more complicated.

deleted 3y ago

[deleted]