Skip SDKs in Simple Integrations | Hacker News Reader

Skip SDKs in Simple Integrations

epicweb.dev

17 pointstosh10 comments

I agree for the most part, but I think another reason to use the SDK is bugs: for dirt-simple APIs and auth methods, this might not be a concern, but for anything else, you might write your own integration that seems to work properly, but fails in strange ways -- possibly intermittently -- later on.

Source: I've done this, and this happened, and it was a pain in the ass to track down the problem. Ultimately I'd wished I'd just used the official client library in the first place.

On the flip side, I've used plenty of first party SDKs with weird timeout values, poor error handling, and non-idiomatic APIs for the language.

I find the first party SDK is likely to work without a lot of trouble but boy do you find people have weird ideas like "I don't know anybody who develops web sites who doesn't use .NET" or "it's no problem that it takes developers two hours to get up and running with our SDK even if they can get up and running with our competitors in five minutes".

It's fair to put a timebox in for a first party SDK and it ought to be a short timebox like 15 minutes because a bad SDK written by people who don't really care if it works properly can steal 15 hours from you pretty quickly.

I've experienced both of these -- Good SDK that save you time over the raw API and bad SDK that steals your time. In fact, sometimes both are created by the same organization targeting different platforms!

I don't think you have any hard and fast rules about this you have evaluate each product and each situation individually.

Yeah, have had to switch to home made sometimes because the SDK for instance didn't use connection pooling, and the server on their end was slow setting up new tcp connections.

Or that they have opaque logging in their own weird format and don't properly hook into a common log interface, so don't know what's going on inside the SDK. Which is bad if it's a big component of the app you're making.

Super happy to have a Kent C Dodds article to point to from now on when I am making this case at work next time.

I've long held that SDKs, like ORMs, make easy things easier... But make hard things harder.

Years ago, I did a trial of vision recognition APIs from roughly 8 vendors, some of which were tech giants and some of which were little startups you probably haven't heard of.

I got 7 of these up and running in less than 20 minutes each. Number 8 was Google which uses a Rube Goldberg machine like

https://www.youtube.com/watch?v=o2ObCoCm61s

to log in that somehow trashed the Python installation on my machine and forced me to reinstall Python. So I think messing around with SDK's from arrogant tech giants is like playing Russian roulette. Sure you survive most of the time but every so often you take a bullet.

A good database toolkit should never make your life harder. Any decent ORM should allow you to run custom SQL if need be.

This isn't always true, but one nice thing about using an HTTP API directly is the responses are usually documented well enough that creating mocks for testing can be easier than the SDK. Additionally, I find working in an HTTP tool like Postman or Insomnium easier than in a full dev environment when I'm in the exploratory phase.

I understand the desire to minimize dependencies and the impact of third-party code. In practice, I’m lazy. I don’t want to build my own integration if someone has already done it.

I also don’t always know how complex my integration will be, and would rather not go back and replace custom code with the SDK, so I start with the SDK.

Reply on news.ycombinator.com