3 ms·

At my job, before I joined, I was told we were torn between using Go and Rails and ended up with both. Now we have a Rails frontend (for web requests / authenti

At my job, before I joined, I was told we were torn between using Go and Rails and ended up with both. Now we have a Rails frontend (for web requests / authentication) and a Go backend (for business logic), which communicate over Thrift RPC. I don't think it was a very wise decision because not only are you doing things twice, you're doing it three times, because you have to serialize/deserialize to/from Thrift for every request. It adds development time, more tests, and Thrift's binary protocol makes debugging RPC almost impossible. This isn't really an argument for/against Go, but it just shows that you should try to avoid using multiple codebases that have to be tightly integrated. Personally, I would've gone with a Ruby-only codebase that used Thrift RPC only if there was some backend task that was too slow in Ruby, and that Go's concurrency and speed might be better at. Then I'd serialize it and send it over to be processed by a better language. I wouldn't do it for every request. That being said, if I had the choice between writing an API in Go vs Rails, I would do it in Rails for the faster iterative development speed and quick debugging capabilities that is made possible by an interpreted language.

bm1362 9y ago
Have you tried thcurl or yab for debugging RPC? I’ve found that most services I consume using thrift have a yab template for easy testing and trace ids so I can follow the request- I haven’t really missed hand writing JSON curls yet. https://github.com/yarpc/yab/blob/dev/README.md https://github.com/yarpc/yab/blob/dev/README.md
heavenlyblue 9y ago
For god's sake - does the structure of this project do any good to the company, or is it just there to familiarise the developers with a variety of technologies so that then they could go to another company and boast having used all of them? Hard to debug binary-based RPC? You have picked the wrong technology for communication, having forgotten that you'd need to build the necessary tools in order to debug it. There's literally nothing wrong with binary protocols, except developers forgetting about the necessary overhead of re-parsing the passed data in the debugger. But it's not an overly expensive overhead, if the architect had taken this into account. Having heard this point absolutely not for the first time, the only question that remains is: who and why did make a decision to have it this way?

bm1362 9y ago

Have you tried thcurl or yab for debugging RPC? I’ve found that most services I consume using thrift have a yab template for easy testing and trace ids so I can follow the request- I haven’t really missed hand writing JSON curls yet. https://github.com/yarpc/yab/blob/dev/README.md https://github.com/yarpc/yab/blob/dev/README.md

heavenlyblue 9y ago

For god's sake - does the structure of this project do any good to the company, or is it just there to familiarise the developers with a variety of technologies so that then they could go to another company and boast having used all of them? Hard to debug binary-based RPC? You have picked the wrong technology for communication, having forgotten that you'd need to build the necessary tools in order to debug it. There's literally nothing wrong with binary protocols, except developers forgetting about the necessary overhead of re-parsing the passed data in the debugger. But it's not an overly expensive overhead, if the architect had taken this into account. Having heard this point absolutely not for the first time, the only question that remains is: who and why did make a decision to have it this way?