7

I'm building a serverless app using API Gateway and Lambda (Serverless Framework) and trying to find a way to provide multiple versions of our app's API.

Here's the way I can think of.

serverless.yml

 handler: list.handler
 events:
     - http:
         path: {ver}/list
         method: get
         cors: true
         authorizer: aws_iam

list.js

 export async function handler(event, context, callback) {
     const ver = event.pathParameters.ver;
     if (ver >= '1.0') {
         return fooUtil.getNo(ver);
     } else {
         return 1;
     }  
 }

fooUtil.js

 export function getNo(ver) {
     if (ver >= 1.3) {
         return 3;
     } else {
         return 2;
     }
 }

However, I need to pass "ver" parameter to all functions this way.

Is there any way easier (and testable) to fetch version no from request like below?

fooUtil.js

 export function getNo() {
     if (session.getValue('ver') >= 1.3) {
     }
 }

I prefer not to divide repositories or git branches to manage multiple versions.

rhythm
  • 469
  • 9
  • 24

2 Answers2

2

What is about to have for each version its own resource and separate it by folders?

Like this

 handler: v1.list.handler
 events:
     - http:
         path: v1/list
         method: get
         cors: true
         authorizer: aws_iam

 handler: v2.list.handler
 events:
     - http:
         path: v2/list
         method: get
         cors: true
         authorizer: aws_iam

That gives you the flexibility to test everything and its easier for newcomers to your project because the versioning is explicit through folder separation.

MaiKaY
  • 4,422
  • 20
  • 28
  • 2
    I agree that this is clear and testable, but when we have 10 versions (major or minor) and 100 methods for each, there will be 1000 resources. I think it will be hard to manage resources manually. We’d like to make small improvements (minor versions) without caring about the hassle of adding a version. – rhythm Apr 22 '18 at 11:28
  • 1
    @rhythm I would suggest that maintenance might seem more complicated, but when you have 10 versions, you don't want to be backporting bugfixes unless absolutely necessary, and when you do, it should be exactly that -- deliberate backporting. Too much intermingling will lead to regressions. Once a version is released, it should be touched as little as possible. – Michael - sqlbot Apr 22 '18 at 13:41
2

After reading many sources and trying to understand how AWS API Gateway works (from the versioning perspective), I decided to simply duplicate the API on my major versions and keep track on them through diff branches. The benefits:

  • Update/Remove each version without impacting any other version. Ex: If I am on V4 and want to make changes on V1 I just switch branches, make my changes and then push the code.
  • The versioning may not be only on Lambda Level. It could have proxies and may have changes on their structure as well.
  • This will help on deployment process, as the clients could move gradually to a new version but still have access to the old one.
  • It will help to keep track of the history of each version.
  • I will have a isolated flow for my CI/CD.
  • Each version will have a new domain. v1.maindomain.com/api, v2.maindomain.com/api
  • Easy to any developer of any level to understand and maintain.
  • To create a new version, I just create a new branch and update the version at the config file.

I am using serverless-custom-domain which creates a recordset during my deployment.

Cleriston
  • 750
  • 5
  • 11