3 ms·

So in summary - HTTP calls for front-end, but not back-end to back-end services?

• kh_hk 8y ago
  I wouldn't be super quick on drawing the front-end and back-end distinction. A front facing interface using sockets could (depending on how flexible we are with terminology of course) be considered front-end too. And I think that's the entire point of the article. I have seen huge benefits, performance being one, communicating using ZMQ (at the cost of complexity and reliability). A worker, running on your computer, consuming data fed through a socket from a broker, running on your server.
• lotyrin 8y ago
  Not exactly. Transactional CRUD (post a form, submit an email, add to cart) is pretty well adopted and standardized as HTTP, so probably use that (even backend to backend, if the contract fits CRUD resource semantics). RPC (non-CRUD interactions) or streaming updates (e.g. a spinner in a app representing a pending job) or low latency (chat messages / presence status, etc.) don't really fit to HTTP requests so great (requiring e.g. polling) so you should look at alternatives (probably something proxied over a websocket in the case of a browser front-end app).