Reputation: 21802
We have a NodeJS Express application that we have implemented a custom analytics backend for. Now, we are deciding on how to implement the tracking mechanism, for JS-disabled browsers like feature phones.
One design approach that we are considering is to create a middleware, that intercepts every request, extracts the params from the request/context and sends them to the backend. This is very scaleable and makes perfect sense for a custom analytics solution such as ours.
The other approach would be to create a tracking pixel like Google analytics does and then extract data from that. But that seems to be a much less scaleable solution for custom tracking solutions, as the params and the data structure could change or scale up at any point, unlike GA.
My question is this - are there any flip sides to making a middleware that makes Async requests? Is there anything we need to be cognizant about while creating it, as every request to our server is going to pass through this middleware? Ours is a fairly large app, with a traffic of hundreds of thousands per minute.
Upvotes: 1
Views: 2898
Reputation: 106
So long as you keep your middleware asynchronous and call the next()
method when necessary, you should be fine. Express can handle quite a bit of load provided your server instance is configured for it.
The real issue is when you start doing synchronous methods, which you could/should utilize promises to properly handle their resolutions.
PROTIP: avoid nested promise resolutions as much as possible in your middleware/controller logic. Utilize something like Bluebird's .all()
method so you're not wasting processing time on blocking requests, and if you have to issue sequential callbacks, consider async waterfall or async series (depending on your promise library of choice) which will allow you to sequentially run your promise resolutions if they depend on prior information. Helps keep your code clean.
Upvotes: 5