IssueRaiser

Their "microservices" are kind of macro.

Their "microservices" are kind of macro. Rendering a PDF file and sending an email are reasonably large operations, so the overhead of local HTTP isn't that bad. For a finer-grained application, such as the way Facebook generates pages from about 20 servers feeding data in to be assembled, that wouldn't scale. Facebook has Thrift and Google has protocol buffers. Both work, but result in a somewhat complex build procedure with a pre-compiler for interface specs. (Serializing and de-serializing data into and out of databases and networks is either interpreted and slow, or compiled through clunky tools. Technology in this important area still sucks. There's a long history of clunky solutions to this problem, from DCOM, CORBA, and ASN.1, to SOAP to REST/JSON. Part of the problem is political. If you expose an API defined in any of those except REST/JSON, there's a formal, checkable definition of the API in machine readable format. If the API doesn't match the spec, the server is broken. With a REST/JSON API, you get to blame the caller for doing it wrong. This is convenient for API developers.)

Posted by Animats on Mar 4, 2015, 6:35 AM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.7,500 issues0 comments

reliability (Sysadmin)

Their "microservices" are kind of macro.

AnimatsMar 4, 2015, 6:35 AM

Their "microservices" are kind of macro. Rendering a PDF file and sending an email are reasonably large operations, so the overhead of local HTTP isn't that bad. For a finer-grained application, such as the way Facebook generates pages from about 20 servers feeding data in to be assembled, that wouldn't scale. Facebook has Thrift and Google has protocol buffers. Both work, but result in a somewhat complex build procedure with a pre-compiler for interface specs. (Serializing and de-serializing data into and out of databases and networks is either interpreted and slow, or compiled through clunky tools. Technology in this important area still sucks. There's a long history of clunky solutions to this problem, from DCOM, CORBA, and ASN.1, to SOAP to REST/JSON. Part of the problem is political. If you expose an API defined in any of those except REST/JSON, there's a formal, checkable definition of the API in machine readable format. If the API doesn't match the spec, the server is broken. With a REST/JSON API, you get to blame the caller for doing it wrong. This is convenient for API developers.)

Comments (0)

No comments yet. Start the discussion.

Comment on this issue