Paul Hill presents a case study of building an API with a short deadline using Node.js, WebSocket, MongoDB, JSON, Promises, Swagger, Memcached, Varnish and Hypermedia ReST.
Paul Hill is a software architect, designer and developer at KIXEYE, and resident expert on all things ReST and Hypermedia. An enterprise Java developer for most of his career he is now very much a polyglot paratrooper, spending most of his time designing and building APIs with Node.js to provide delightful features to KIXEYE's online competitive gaming community.
Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
Appreciate the Candor
In terms of "backpressure" it was mentioned that NodeJS threads block on I/O. Is this correct? If so that is not a scalable design. On Windows / .Net one can use event-driven IO where the thread is assigned from a thread pool upon completion of IO activity.
One can even use async database calls to SQL Server by using "Asynchronous Processing=true" in the connection string.
I'm wondering if you use message queuing much? Eg: RabbitMQ.
Re: Appreciate the Candor
So yeah, Node uses non blocking IO. The back pressure I was referring to (and it's kind-of a corruption of the phrase) comes from non blocking responses that take much longer than expected to complete. This is ok for a little while but those callbacks eventually stack up and things go pear shaped.