Re:RPC over AMQP
by hydrogen18 on Friday June 13, 2014 @09:20AM
(#7888640)
You're absolutely right. The performance and security implications of YAML make it an awful choice.
Unfortunately, upgrading the server component is trivial but upgrading all the clients is next to impossible. The logical next step after this project is to implement a saner set of endpoints that breaks up all the amalgamated functions. At some point in the future, there will come a day in which we'll simply ignore the requests from older clients.
Re:RPC over AMQP
by Iftheshoefits on Friday June 13, 2014 @01:12AM
(#7887524)
Not only is it faster than the serializations you mentioned, messages generally have a much smaller memory footprint, and it is therefore very friendly for use in contexts where bandwidth is likely to be at a premium (e.g. mobile carrier data limits). I use it exclusively in mobile apps I develop.
Native mobile apps or hybrid?
Re:RPC over AMQP
by Iftheshoefits on Friday June 13, 2014 @11:07AM
(#7889185)
Native. I haven't worked on any mobile apps that are webapps for mobile, so I haven't used it with the JavaScript implementation.
Using MessagePack would speed that up significantly, too. I've done a comparison of MessagePack vs. JSON vs. YAML vs. Ruby .marshal in the past[0], and I'm currently building a system using AMQP+MessagePack (as of now the only part that's public is [1]).
Basically, YAML is great for configuration files because of its flexible syntax, but terrible for communication because of its flexible syntax.
[0] http://blog.mikebourgeous.com/2012/10/12/optimizing-message-... (missing numbers for MessagePack, but mentions 2x speed up beyond best other option)
[1] https://github.com/deseretbook/classy_hash (includes a benchmark script that shows how ridiculously fast MessagePack is compared to YAML)