4 ms·
Almost every time I use an SDK I get burned. Happened for firebase, github, and a few others. Same with ORM's.
by MarcelOlsz 2y ago
Almost every time I use an SDK I get burned. Happened for firebase, github, and a few others. Same with ORM's.
- noitpmeder 2y agoIn what regard? The SDKs change out from underneath you?
- edoceo 2y agoNot OP but yep. Forced SDK upgrade, dependency chain and vendor driven churn. But, eg, Twilio been using the same HTTP methods for like 10 years. Many other SDK based interfaces (not necessarily Stripe) have forced that churn.
- noitpmeder 2y agoTrying to understand, wouldn't you see the same issues if you depended on an API that had a breaking change? I guess my view is that shitty interfaces are shitty and people don't think enough about forwards/backwards compatibility, but it's not tied to a pure SDK or API problem
- csomar 2y agoMost serious enterprises should have their API versioned.
- MarcelOlsz 2y agoIt adds an extra layer of maintenance. Instead of a breaking API change now you might also have an SDK that hasn't updated yet or is incompatible for any number of reasons, and you don't want to be embedded in it before you find out. It's just easier using a REST API.
- csomar 2y agoSDKs are just bad because they are unnecessary. 90% of the time they'll be doing something that you should be doing; and because of that they'll be doing a bad job. I don't want an SDK that starts processes, wants to read my env variables or do some other sh*t like that. The best SDK is a REST/GraphQL endpoint. After all I am just querying the database of the service. I'd like to do it on my terms.
- MarcelOlsz 2y agoIt's either there isn't full coverage, or some convoluted way to migrate, or documentation is missing, or it's a 3rd party library by some guy in living in the mountains of Bhutan who happens to be on vacation at the moment, or any combination of these.