tags:

views:

557

answers:

3

Has anybody done or seen a deployment of Apache Thrift in an iPhone app?

I am wondering if is a reasonable solution for a high-volume, low(er)-latency network service for iPhones compared to HTTP.

One noteworthy thing I found is a bug report about running Thrift on the iPhone, which seems to have been fixed. But that doesn't necessarily indicate that it's a done deal.

+3  A: 

I've always disliked frameworks that use a common interface definition that builds out both server and client code. It keeps both sides too much in lockstep where in reality server API changes must be very flexible in the versions of clients that are communicating with it.

There are helpful libraries that make JSON or PLIST communication over HTTP pretty easy, and decades of debugging and understanding the HTTP protocol and how to use it well. I would ignore that at your peril.

Kendall Helmstetter Gelner
Thanks, Kendall. I agree with you about the risks! I am considering a asking a new question: just when and why one would move off of HTTP? To me it is a steep price to pay.Still, for a successful iPhone app approaching a million users, maybe it's worth bending over backwards to eek out more speed and lower latency. (I am skeptical. Most iPhone apps are data-driven; serialization isn't the problem; latency can't be helped.) Still I want to know the feel from the broader community.
jhs
Specifically, I am considering using a binary serialization over UDP for frequent, non-critical updates from handsets such as location info. I'm still not persuaded but I'm open to it.
jhs
Now that actually sounds like a good use that may not be nearly as easy to do otherwise. I stand corrected.
Kendall Helmstetter Gelner
I wanted to add a little more (I saw your last question first). I think it makes a ton of sense to worry about scalability early on with so many devices potentially hitting you - but the great thing about using HTTP and web services is so many people have thought out scalability carefully before. That's why I suggest using RESTful web services over SOAP, because there are so many levers you have to help your system deal with large scale quickly...That said your question about frequent non-critical non-ordered updates are a great way to use UDP exactly the way it was intended.
Kendall Helmstetter Gelner
Thanks for all your thoughts, Kendall. I'll +1 you even though technically you didn't share a Thrift success story :) You nailed my main confusion on the matter. HTTP is human readable and has so much tooling built around it and is horizontally-scalable. Most new apps are data-driven and your DB architecture is another matter. How fast you serialize and your carrier protocol seem moot to me. But why are Protobuf and Thrift so popular? Is it a bunch of cowboys who don't know better?
jhs
Is Thrift that popular? I have not heard of a lot of people using it... but even so I can see people using things like it because of a certain initial convenience. I just think it kind of binds you later down the road and that's why I avoid it if I can.
Kendall Helmstetter Gelner
+1  A: 

Thrift as an external API doesn't make sense. Use it internally rock and roll.

ABCoder
+2  A: 

Thrift and HTTP aren't mutually exclusive. In fact thrift now ships with an HTTP transport implementation to use. It's also a really nice way to auto-generate server/client code that avoids a lot of marshalling/unmarshalling boilerplate while still being really fast. Its internal representation is basically binary JSON, so it's very similar to a RESTful web service (except being easier to code and much, much faster).

So... anyone able to answer the original question? If not, I'll dive in myself with thrift's included Cocoa support and see how it works on the iphone.

samkass
Awesome, thanks for the update!
jhs