Used by Airporting
NodeJs 18.x and 20.x.
Automatically injects Plaid client into lambda context.
import middy from '@middy/core';
import plaidMiddleware from '@airporting/middy-plaid';
middy(yourHandler).use(plaidMiddleware({ apiKey: 'YOUR_API_KEY' }));
export default async ({ body }, { plaid }) => {
// direct usage of body as an object
};
At Airporting, we apply some common good practices (hope you too). Mainly, we DRY, we SOLID, we continuously updates ours deps. And we love dependency injection.
Numerous of our endpoints need the use of plaid client. Instead of repeating this in all our handlers files:
import Plaid from 'plaid';
const plaid = new Plaid(apiKey);
// ...code
We prefer to use a middleware dedicated. Our serverless entrypoints, which references all the handlers are generated, so it's easy to generate a call to a middleware usage instead of repeating ourselves again and again.
S stands for Single responsibility. Our business code doesn't need to know how to get the Plaid client instance. It just need this instance ready to use.
As you can see in our files structure, we strongly use renovate to be always up-to-date. It's true for our public and private dependencies and, of course, for all our reporsitories. If we upgrade this middleware with some helpers (for example), if we fix something, we will just let Renovate upgrade everything for us. If we don't use this middleware, we would have to update each repo by our hands. Boring.
No matter the way you test your code, mocking a require
/import
module is often painful. With dependency injection, you can just pass your mock as a parameter. Quite more easy.