3 ms·
Brandur, this is indeed very actual topic (and will be even more with the rise of APIs). As with everything, the issue is twofold. In the case of Heroku and yo
by zdne 13y ago
Brandur, this is indeed very actual topic (and will be even more with the rise of APIs).
As with everything, the issue is twofold. In the case of Heroku and your user-base it is reasonable to expect your users are closer-to-wire than an iOS guy hacking in Cocoa Touch.
From your point I can't agree more. A well designed HTTP APIs goes a long way here. Putting a Cocoa Touch developer's hat on and I can't be bothered learning HTTP, checking all the possible responses, handling redirects and errors when the only thing I need is to just fire a single Mixpanel track event...
Sort of C/C++ vs. let's say a Ruby. Assembler anyone? Stay on the metal or develop (and crash:) faster with some trade-offs.
Anyways, good stuff. Important bringing it on the table!
- brandur 13y agoZ, > As with everything, the issue is twofold. In the case of Heroku and your user-base it is reasonable to expect your users are closer-to-wire than an iOS guy hacking in Cocoa Touch. Certainly! Regarding the overall question of "SDK vs. custom HTTP wrapper" there isn't a right answer; different parties have different requirements and should use the right option for them. I'm not even saying that users of Heroku shouldn't have an SDK here -- they should absolutely have one if it will help them, and Heroku ships SDKs for just that reason. I was trying to make the point that me, as a maintainer of a Heroku backend service that talks to other services, would like the option of not having an SDK; like you said, I want to be as close to the wire as possible. Thanks for the feedback and reading!