Hacker News Reader

Comment by jasonkester | Hacker News Reader

That's cool. You're not the guy we built it for.

We built that SDK so that Junior Dev Jimmy can make calls to our API and actually finish integrating our service without giving up. That guy can't code his way out of a paper sack, and certainly couldn't successfully send us an HTTP request or parse the result that we sent back. We built him a client library so that he'll stop sending us stupid emails asking how to call our server-side API using jQuery or, not making this up as it's happened several times from several customers, a form on an HTML page.

Anything we can do to get that guy up and running and done implementing our API, we'll do. Because the guy who hired him is paying us money, and the last thing we want to do is explain why he needs to fire his only developer and find a new one.

View on HN

Or, in a rather less condescending tone, you might have built the SDK for Busy Bob, who is using your API, which is is important but peripheral, to the problem he is writing software to solve.

If his solution works, and is widely adopted, then he will revisit and add all those things that the OP mentions, but right now he is just trying to get something working.

An SDK is great for that.

I agree. I would just add that there are lots of Busy Bobs, all of whom just want to consume your service, and don't want to have to bother with creating their own JSON/XML/EDN/etc marshaling/unmarshaling code, translating HTTP error codes to whatever idiomatic error-handling construct is used for the language at hand, etc.

When I build an app that needs to consume some REST API, if the REST API provider doesn't already provide an SDK, I'll create my own in each programming language that is useful to me (Objective-C to build an iOS app; Java to build an Android app; etc). To me its the logical thing to do, especially if I intend to create more than 1 app that consumes the REST API in the same language (iOS POC app 1, iOS POC app2, ...).

Wow, what a pain.

However, creating your own SDK is pretty much what the OP suggests--it gives him the level of control that he needs.

That's a great point, but I'll take it further. Even if you know how to build all that stuff, you still have to build it, there are a lot of decisions to make up front. Depending on the company (Stripe comes to mind), I might choose to trust the SDK's decisions by default and only move away from it when I have specific pain points. A lot can be solved simply by isolating the SDK's usage inside a wrapper that defines our application's usage of the SDK.

I concede this point. The article was written from the perspective of a user who's running a high volume app and wants maximum control over how they communicate with foreign services (i.e. my perspective).

I certainly don't want to dissuade companies from writing SDKs. They're great products and really help in getting people much needed traction as quickly as possible. For the GA of the new Heroku API we'll be shipping SDKs in as many languages as we can support!

In reading the title of the post in question, as well as this comment, I'm going on a bit of a brief tangent:

Why can't we all just get along?

I think it's great for someone to say:

    "Hey guys, I find it fits in my workflow really well to not use SDK's, and I
    feel I get a lot of benefit from it."

I think we'd all agree that a similarly toned response would be great:

    Interesting approach, thanks for sharing why you do things that way. If I
    may chime in as someone who designs these SDK's, we really target them
    towards people who have less experience, and who need simpler tools to get
    things done. We'd counsel everyone to keep this in mind when picking tools
    to use for their projects. Remember, always be thorough in exploring your
    options and choose the best tool for the job!

See how nice that could have been, for both parties? I don't think we benefit from titles that come across as vaguely hostile like "Why I Don't Want Your SDK in Production", or from responses that might be interpreted as overly dismissive like "That's cool. You're not the guy we built it for".

I am conscious that this post might come across as condescending or insulting, but I'm genuinely not trying to go for that. I like hearing the different opinions people have, and it bothers me that there's such low level hostility and tension in much of the discussion I see. I hope we can all be a little nicer when we talk online.

Seriously, we can all get along!

Fair point!

I'll admit that my original title was somewhat linkbait-y and fully respect the moderator's decision to amend it. That said, while the title was designed to incite discussion (and there is disagreement in a good discussion), I hope that the article's actual content conveys the intended respectful tone. Let me know if it doesn't.

> "... he'll stop sending us stupid emails asking how to call our server-side API using jQuery or, not making this up as it's happened several times from several customers, a form on an HTML page."

Have you considered that maybe an API should be callable using `jQuery.ajax(...)` or a simple `application/x-www-form-urlencoded` POST?

(...or was this satire?)

I'll assume you missed the "server-side" in the above, or that I wasn't clear in what that meant.

I'm referring to API calls that you really really only want to ever do from your server. Things like starting and stopping EC2 instances, where you need to send along your API keys that are essentially the keys to your bank account and your business's future survival.

Now imagine, as the owner of that service, that your customer is sending those keys in plain text to the client, and wondering why he's having a hard time starting EC2 instances using javascript from his user's browser.

I wrote a thing to start & stop OpenStack servers via JavaScript. HTTPS is a thing.

I have trouble thinking of any API that shouldn't be callable from a client.

Any API that uses some form of authentication token that is not obtained via some user-based interaction like OAuth may need to be at least proxied via a server side piece to prevent exposing credentials/keys.

Err.. why?

Clearly the keys need to be obtained somehow, but that was out of band for my application. Once they are obtained I don't see any reason why passing them from a 3rd party app over HTTPS (using CORS) is any less secure than using session based authentication with a 1st party app.

In both cases you are vulnerable to MTM and XSS attacks. Sessions expire which is nice, but that's the only real difference.

I think he's saying that their API is callable from jQuery, they just don't want any more questions emailed to them about it.

I think it more was the junior devs who tried calling it with jQuery.ajax, but did stupid stuff like send the wrong content type for their data and then "Why isn't it working?! Can you send me an example?!"

excellent point...more developers really need to learn to take the business/owner perspective on the use of technology. The person whose money is on the line wants a working solution, not technical purity.

Even with the gratuitous dick-swinging aside, I don't think I could disagree more with this reply. SDKs provide a much needed layer between provider and consumer to prevent unnecessary coupling.

SDKs built by the provider have the benefit of getting a developer up and running quickly. The downside is that you really don't know the quality of the underlying code without some deep auditing and, as the author wrote, the underlying implementation is outside of your instrumentation, logging (etc.) framework. It's a black box you import into your app. This has nothing to do with abstracting the API . If you wanted to work with the HTTP API directly it you'd just abstract it yourself, because that's just good practice.

Reply on news.ycombinator.com