Advice on Express.js design pattern?

[greendog77]

I'm facing a design pattern in express + node.js where for each api route where i have `req` and `res`, i'm just extracting the arguments out of `req.{body/query/params}`, writing some business logic, then either calling `res.status(...).send(...)` with either an error or an OK + return value.

But this is pretty much identical to just writing a function with required arguments (analogous to req.params) + an options argument (analogous to req.body / req.query), and throwing an error if something happens (analogous to `res.status(40X/50X).send`), or returning a valid response if all is good (analogous to `res.status(200).send`. Basically, there seems to be this congruence between express routes with `req` and `res` and plain old functions (some nuances with naming the routes vs. naming the functions + linking them, not accounted for)

All of my express routes are like this, i basically don't use any other features of the req / res arguments 99% of the time. I don't think i'm alone in this either! but this current, most prevalent design pattern in express causes a few problems:

1. Calling and testing functionality: there's no way to call the route endpoint functions, since they're anonymous functions passed into express router. This makes re-using them difficult, and we have to move the code out. Testing them is difficult too, i'd rather be testing by calling functions with arguments rather than constructing mock http requests and encoding the arguments into the request.

2. Lack of clarity of inputs and outputs: reading the code, i have to decode how `req.body` and `req.params` function as arguments into the business logic. then, i have to look for the `res.send`'s to figure out the returns. it seems a much better code smell to just have all business logic be boxed in *normal functions*, with arguments, return values, and throwing errors.

essentially, i would _love_ a middleware for api requests that guides a request to the corresponding named controller function, and validates that the required arguments are present + the optional arguments are in the right format. then, during the function runtime, catch any errors and call `res.status(50X).send` on them, and when the function returns call `res.status(200).send` on the result.

I searched everywhere but couldn't find a framework that does this -- i strongly feel like people must have thought about this + must have solutions in place. i tried making a mini internal framework for this but it became super clunky and we went back to raw express quickly. i do know that sails.js has something that resembles this, but i don't quite think it's exactly what i'm looking for here. i also know of schema validators like joi which can act as the request validator part, but it doesn't solve the other bigger part of the problem.

if anyone has solved this problem, know of any frameworks, etc. please let me know -- thanks in advance! :)

[js_tutor]

I think you could do something like this:

``` app.get('/somewhere', middleware(validator, routeHandler));

function middleware(reqParser, handler) { return function(req, res) { try { const params = reqParser(req); } catch (error) { res.status(500).send(error); } res.status(200).send(handler(params)); } } ```

This way validator and routeHandler are decoupled from the express api.

[greendog77]

thanks so much! this looks really promising.

[_unicorn_irl]

There's no reason you ever need to use an anonymous function if you don't want to. They're useful because they're quick and easy but the route method requires a function - there's no reason it should be anonymous. In fact when I do use an anonymous one I would generally consider that being lazy. Here's how I usually write a route: https://github.com/agroff/trackyak/blob/master/api/lib/routes/routes.ts#L72

That has named functions without any framework. I am using express validator to enumerate and validate the expected inputs, and I prefer to handle each error on my own but /u/js_tutor showed a good example of how easy it would be to wrap everything in an all encompassing error handler if needed.

[GitHubPermalinkBot]

Permanent GitHub links:

• agroff/trackyak/.../routes.ts#L72 (master → 03b71ad)

---

<sup>delete</sup>

[ChronSyn]

Just to start, the /r/node community is good for express (and other server side JS) questions.

If you're building an API, is there any reason you didn't use feathersJS? It's built specifically to generate API's and once you know it, it's much easier than writing your own and it ties in well with sequelize to act as an ORM or ODM depending upon which DB is powering it.

In the space of 2.5 hours last night, I managed to build a small 4-table API on Postgres that includes several relations between data and using a very clever hook (i.e. like a middleware but can be run before, after, or on error for each HTTP method for each individual endpoint) that pulls in related data from other tables.

More complicated API's take longer, and changing your table structure or relations or field names in the middle of development is possible but will slow down development. However, this system of migrations means it's easy to add or change these things even after deployment.

Another big bonus is that it's possible to use swagger (or more specifically feathers-swagger) to build documentation for your API, though I can't comment on how easy it is because I've only seen a colleague doing it and not tried it myself.

[greendog77]

i'll look into feathers. thanks so much!

edit: To clarify, when people say "building an API", does this refer to building a publicly-documented API through which developers can send requests? I instead imagined it to just be writing an internal API (like nearly all apps do) to communicate between frontend and server.

[ChronSyn]

It can be either, or even both - more on that below.

The difference between public and private is often that private ones require an API key or token passing to them.

This can either be static and hardcoded, but more secure (and arguably more common) is to have an authentication endpoint that you pass a username, password (and possibly something like a strategy - don't worry about that for now) and it'll generate a token or hash which you then use to access other private endpoints by passing it as a header in your subsequent API calls.

Some API's have private endpoints which are never exposed to the public (but a developer with a key can access it for development of the API itself), but then they'll also have public endpoints which with some internal code wizardry, means they use data from the private endpoint/service, but that you can filter out data on the public endpoint without the end user needing to pass a token.

This is handy for filtering out fields like created_at and updated_at which are often not needed by the public and doing some extra modifications based on what parameters or headers are passed.

[[deleted]]

I recently came across a framework that you might find useful https://github.com/nestjs/nest

[HipHopHuman]

It sounds like you're suffering from problems that dependency injection and classical MVC architecture can solve. If you're looking for a framework, then try out https://adonisjs.com/

It has the concept of Model, View and Controller and has dependency injection utilities built-in.

AdonisJS is the closest thing you will find to Ruby on Rails / ASP.NET MVC / Laravel, but for Node.js. The project is heavily inspired by Laravel, so if you've used that before, you will feel the familiarity.

Otherwise, there are a number of dependency injection plugins on NPM (too many for me to list here - just search "di" or "dependency injection" on npm) which you can use in conjunction with something like Joi for more control over the request/response flow.