3 ms·
Good to see this. I was sold on Thrift but I think the popularity of REST made people take some weird decisions. Internal services talking to each other using
by zapf 12y ago
Good to see this.
I was sold on Thrift but I think the popularity of REST made people take some weird decisions.
Internal services talking to each other using REST seemed like a bit too much, a place, where I though services like Thrift would have worked so well.
- thlt 12y agoplease excuse my ignorance but may I ask why REST is too much compared to Thrift?
- Xorlev 12y agoI think you mean HTTP+JSON. REST as a philosophy while applied mostly to HTTP isn't really tied to it. We personally decided to stick with HTTP (even though Thrift would be "superior") since tools are numerous and simple. It's hard to beat curl and a browser. We also found that services end up used in ways that are hard to predict, especially in bash-written tools and the like. Thrift is a barrier to entry. Additionally, you could do HTTP+Thrift. It's possible, it works, but you lose some of the overhead benefits of Thrift at that point (IMO). In my experience, fulfilling a Thrift request with a Thrift server has tighter latencies at much lower CPU usage for similar request loads.
- sbilstein 12y agoIt's a tough tradeoff between performance flexibility. Relying on HTTP + JSON is very nice when you have lots of teams, codebases in several languages, and want to preserve the ability to talk quickly to any service over HTTP. I like working HTTP but certainly tools like thrift have there. LinkedIn is all about http://rest.li/ http://rest.li/ for our services though I've been working with DropWizard on a side project and really love it.