Multiple services behind a single API Gateway?

Serverless Framework
1

I fully support the new services of 1.0 over the old project one. But have you addressed the main ting project was a good for API Gateway? Say I have one API for my Foo product that contains many service like auth/* user/* and so forth.

So my main question is this. Can you have many services deploy to the same API? Now? Or planed for later? If not how do you recommend i create a more unified API for my client without creating the same project mega-service we had in 0.5.

If you feel that my assumptions is very wrong for how serverless should be used then just fire away the new and improved best practice.

2

Basically Serverless will deploy separate API Gateways for separate services. If you want all of those services behind the same API Gateway you can either deploy that whole API as one service (which leads to lots of code in that one service), or you create a separate API Gateway that you then connect to the different functions deployed independently through serverless, or you have another API Gateway that proxies requests to the actual services that are running behind the scenes.

At the moment this is a bit cumbersome and we have to find better ways to do this in the future.

3

Thanks for the reply. Plan to continue to use 0.5 there are a few other things missing in 1.0 that makes a simple port a bit had and will require some redesign. The other missing feature was that it seems its one IAM role per service not per function and use different for the auth module where only one function can request the private key.

I guess it will work just need some mental re-aliment. That i will look at on the other side of the deadline :wink:

4

Per function IAM Role is definitely a feature that will be coming soonish. Don’t know how soon, but its something we want and we have some contributors thinking about contributing it.

5

Having support for a single APIG API -> multiple serverless services would be so great.
I could imagine the serverless services can take an APIG API id and maybe even a base resource path for the endpoints in that service (feels more microservice-y).

3 Likes
6

Thanks for those suggestions @flomotlik. I’m working on a project and having to deal with a similar situation.
Does proxying result in counting a single call as double? In other terms, would that impact the APIG cost? (I’m new to all this …)

7

Hello,
would it not be a good solution to have a “infrastructure” services that create the API Gateway resource and export the API Gateway Id for cross stack references?(https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html)

The other services could now import the values with the cross stack references for just add the resources to the gateway and not create a whole new api gateway?

I have just look at the source code (javascript is not my primary language) but is looks like that there are just smaller changes required to make this possible e.g.
replace Ref ApiGatewayId with !Import ApiGatewayId if its set via the serverless.yml

2 Likes
8

@flomotlik
I have setup 2 very simple templates to illustrate how it could be possible to share the ApiGatewayId and the ApiRootResourceId between services.

I thing to implement this solution via a variable (if set use !import instead of Ref RestApiGateway) should be easy.

Is it possible to create from this discussion a issue in github?

{
“AWSTemplateFormatVersion”: “2010-09-09”,
“Resources”: {
“MyApi”: {
“Type”: “AWS::ApiGateway::RestApi”,
“Properties”: {
“Name”: “MyApi”
}
}
},
“Outputs”: {
“ApiGatewayId”: {
“Value”: { “Ref”: “MyApi” },
“Export”: {
“Name”: “ApiGatewayId”
}
},
“ResourceId”: {
“Value”: { “Fn::GetAtt”: [ “MyApi”, “RootResourceId” ] },
“Export”: {
“Name”: “ResourceId”
}}}}

{
“AWSTemplateFormatVersion”: “2010-09-09”,
“Resources”: {
“AGM4WGN5”: {
“Type”: “AWS::ApiGateway::Method”,
“Properties”: {
“RestApiId”: { “Fn::ImportValue” : “ApiGatewayId” },
“HttpMethod”: “GET”,
“AuthorizationType”: “NONE”,
“ResourceId”: { “Fn::ImportValue” : “ResourceId” }
}}}}

1 Like
9

I have a similar request. To have multiple services behind the same API gateway.
Is there any plan to add this support in the near future ?.

10

If it helps, you can have different API Gateway definitions behind the same CloudFront definition. So you could end up with the same URL (api.yourspecialdomain.com) going to different API gateways depending on the path defined under the behaviors of your CloudFront definition.

I wanted the same segmentation of my project as well, and this is how I ended up solving it.

1 Like
11

For Example in our project we have the micro service subscriptions.

As an admin it is allowed to access the /subscriptions endpoints without limitation.
But customer access there scoped endpoint /customers/{id}/subscriptions

With that scenario it is not possible to use the base path mapping.

Arw there some problems at Serverless that prevent this feature or just to less interest in this feature?

12

It should be possible, you just have to use cloudfront’s simple regex matching on the path patterns and a proper order. The first possible match to the path will determine the origin. So in your case you would want something similar to the following:

  1. /consumers//subscriptions pointing to the proper API Gateway
  2. /subscriptions* pointing to the second API Gateway.

If I’m understanding your case correctly, this would meet it.

I’m not entirely sure why we cant merge together multiple services under a single API gateway definition. I imagine it has to do with either priorities or the known work around.