I have built a rest api written in nodejs with serverless and when deployed will create lambdas and an api gateway that gives url which works fine. However, I will have multiple clients who would want to use this application (with their clients consuming the api) and I wouldn’t want to duplicate the lambda’s for each client as the business logic wouldn’t change. What would be different is the stage variables set in the api gateway for each client.
Is there a way I can deploy and manage this using serverless, so that when a new client comes on board, I should be able to do something like update the serverless.yml with new api gateway details and then running the deploy command would generate the new gateway with it’s own stage variables sharing the previously created lambdas. Hope, the question is clear and apologies if this has been previously asked and answered.
No really. With Serverless you define the functions you want to upload and the events that trigger them. From that it automatically builds the API GW. You could look an exporting the function ARN’s from your CloudFormation stack then have a second CloudFormation template (possibly the resources in a different Serverless project) that creates an API GW using the functions from the first by importing their ARN from the first stack.
Out of curiosity, if the business logic is the same, why can’t you just use the “stage name” to programmatically differentiate between customers? For example, if your API URL is https://api.mycompany.com and you’re creating a stage for “/companyA” and “/companyB”, why not use a path parameter and then just have your Lambdas handle the “stage” logic?
If my understanding of your goal is correct, the way to achieve that is to make service name dynamic (client specific in your case).
In your serverles.yaml you can define something like:
service: my-api-for-{opt:client}
functions:
- your shared functions
Now, when you deploy for client1, you can go with: sls deploy —client client1, which will produce respective CloudFormation in scene behind and create ‘client specific’ API instance.
That sounds like a good idea. Thanks heaps for your suggestion. But I am not sure if that will create duplicate functions as well. Will give it a try anyways.