middyjs / middy

🛵 The stylish Node.js middleware engine for AWS Lambda 🛵

Home Page:https://middy.js.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Http router / path mapping

florianbepunkt opened this issue · comments

Is your feature request related to a problem? Please describe.
Not sure whether this is a bug report or feature request. Kind of both. We are stitching microservices together in a unified API gateway by utilizing path mappings (https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-mappings.html).

So for example our identity api known about its endpoints, e. g. /tenants but it doesn't know that in the broader picture it resides under /identity. So the full path used by api clients is /identity/tenants.

This does not work with the router at the moment, as the event.path prop is always the full path (/identity/tenants) including the path mapping.

Describe the solution you'd like
Not sure whether this covers all cases, but there is another property on the event (at least for REST APIs) that allows determining the path base mapping:

const apiEvent = {
resource: "/tenants", // <-- using this for routing would solve the issue
path: "/identity/tenants"
}

Checking for a match on resource (v1) or routeKey (v2) shouldn't be too hard to include, but I don't think it's necessary.

Try adding in /{stage} to the start of your path:

const routes = [
  {
    method: 'GET',
    path: '/{stage}/tenants',
    handler: getHandler
  }
]

This should do it for you. I would recommend you validate the pathParameter stage is one of the allowed values configured in API Gateway as well.

I‘m not sure if I understand what you are proposing. What has the stage to do with it/how would that help?

{stage} == identity or anything else in this case, stage is just the term I've heard used with this pattern.

Ah okay. I see. This is what I did actually, but it leads to strange inconsistencies. For example testing an endpoint in the api gateway console throws a route not found error (since the base path is stripped) while testing the same path e2e works fine. It‘s a weird behaviour in aws but using the resource key would work around that.

For example testing an endpoint in the api gateway console throws a route not found error (since the base path is stripped) while testing the same path e2e works fine.
Ohhhh, that's interesting. Might be worth reporting to AWS?

Alternatively you could have 1 lambda per endpoint, and not need the router all together. This is the approach I use, most so I can have an IAM role for each endpoint.

I'm going to close this issue, I don't see us adding in logic only for console testing support (sorry).

Understood. AWS logic is correct. This was never about adding logic but fixing the existing logic to be in line with Api Gateway concepts, where (internal) routing happens independently of the base path. With the workaround that you suggested a service now needs to know its place (base pth, e. g identity) in a stitched/federated or versioned api. That is acceptable knowledge creep in most cases, so it probably does not warrant the effort, since the logic is easy to fork/adapt.