Anyone else thinking this sort of blog post is actually really bad PR?
There are some very obvious architectural issues here, issues that aren't tied to the choice of Node.js. I wouldn't want to use a provider whose stack was this immature, to be perfectly blunt.
For example, an API shouldn't do any of the processing they describe. The API's role is to handle submitted requests as fast as possible, so it must off-load the actual work to a queue that can be processed elsewhere.
I'm also skeptical of solutions like YAL, at least the way it seems to be used here. IMHO you'll want local spooling via something like rsyslog, so that you're impervious to network failures. Logging directly to a remote server means you become completely reliant on that server.
There are some very obvious architectural issues here, issues that aren't tied to the choice of Node.js. I wouldn't want to use a provider whose stack was this immature, to be perfectly blunt.
For example, an API shouldn't do any of the processing they describe. The API's role is to handle submitted requests as fast as possible, so it must off-load the actual work to a queue that can be processed elsewhere.
I'm also skeptical of solutions like YAL, at least the way it seems to be used here. IMHO you'll want local spooling via something like rsyslog, so that you're impervious to network failures. Logging directly to a remote server means you become completely reliant on that server.