AWS Lambda Plugin option awsgateway_compatible can't reproduce path templates to resource property

[TyAssis]

Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

3.10

Current Behavior

Setting option awsgateway_compatible = true I expected to receive the event payload in the lambda function strictly equal from AWS API Gateway and Kong + AWS Lambda Plugin.
Although, Kong creates resource property with literal matching values and AWS API Gateway set it to the defined resource route itself instead.

Using Kong the event resource property is is:

resource: /site/my-site-slug-123

Expected Behavior

But to be fully compatible with AWS API Gateway, the event resource property should be:

resource: /site/{siteSlug}

Steps To Reproduce

1. Create a simple lambda function to console.log(event)

export const handler = async (event) => {
  console.log(event);
}

2. Integrate it to AWS API Gateway using a route with path template variables
3. Call it through API Gateway and confirm event.resource. It should be like resource: /site/{siteSlug}.
4. Configure a Route + AWS Plugin in Kong using expressions, e.g. http.path ~ "^/sites/(?<siteSlug>[^/]+)" *. (I tested other operators and regex patterns).
5. Call it using Kong and confirm event.resource. It should be like resource: /site/my-site-slug-123.

* using named capturing groups was the closest I got to have named pathParameters.

Anything else?

No response

[windmgc]

Hi @TyAssis, thanks for the thorough testing. I think what you've observed is correct due to a limitation that Kong does not have a 100% same concept of "resource" as AWS API gateway, so the value of the resource was designed to be the URI that matches the regex(if any) in the first place, and stays in this behaviour till now. There are also some other scenarios where you may find the resource field empty, for example, if your route only matches the hostname and there is no path matching. Under such a scenario, it is a Kong only usecase as you cannot create a resource that matches the hostname in the AWS API gateway, so it is also hard to define what should be the value of the resource should be.

Could you please kindly let us know why you need the resource value to be strictly equal to the AWS API gateway? I know that some of the serverless frameworks are using this field to check if the request actually comes from the API gateway, hope we can have a better understanding of yours and see if we can improve on this part

Thanks

[TyAssis]

Hi, @windmgc! Thanks for your response.

Yes, totally get that reading the source code, but I decided to open the issue anyway just for the records. Feel free to close it if you believe it's not relevant.

Although I believe it might be a somewhat common scenario.

I'm migrating services exposed by AWS API Gateway to be handled by Kong. The AWS API Gateway resources were all created using serverless framework.

functions:
  api:
    command:
        - /function/dist/api.handler
    events:
      - http:
          path: sites/{siteSlug}
          ...
      - http:
          path: articles/{siteSlug}/{articleId}
          ...
      - http:
          path: comments/{siteSlug}/articles/{articleId}/thread/{threadId}
          ...

As you can see, I got one AWS Lambda to handle many AWS API Gateway resources.
In my particular case, the handler code depends on event.resource to determine which logic to run once it gets there.

if (event.resource ==== 'sites/{siteSlug}') { 
     doSitesStuff()
}
if (event.resource ==== 'articles/{siteSlug}/{articleId}') { 
     doArticlesStuff()
}
if (event.resource ==== 'comments/{siteSlug}/articles/{articleId}/thread/{threadId}') { 
     doCommentsStuff()
}

I'm not arguing that's a good approach or anything, but it might be the way others do serverless code too.
In my case, I've already changed the code to use event.pathParameters and env.path instead and it's working fine.

My point is that when I set awsgateway_compatible option to true I expected the payload to be strictly equal to AWS API Gateway, but that was not the case to resource property.