Writing Serverless Service in a Functionless way
I assume the audience of this newsletter already knows what a serverless programming paradigm is about. In this article, we talk a type of serverless backend service: functionless backend.
If you happened to hear some folks talk about this term from time to time and wondering what it is, please read on.
What is a functionless way?
In a functionless service implementation, you remove the needs of writing lambda code, CRUD logic has already been assumed in the infrastructure building components, i.e., API-Gateway or App-Sync components.
An example with available code repo to illustrate the above architecture can be found here. Essentially, in the above architecture, we use the ‘AWS
’ integration type (see the AWS document here) at API-Gateway layer to make API-Gateway as the proxy of DynamoDB:
AWS
: This type of integration lets an API expose AWS service actions. InAWS
integration, you must configure both the integration request and integration response and set up necessary data mappings from the method request to the integration request, and from the integration response to the method response.
Pros and cons of a functionless service
There is a list of pros to implement a functionless service, here we list some obvious ones (but the following list is by no means a full list):
One obvious advantage of functionless service is that it removes the lambda “cold start” problem;
another advantage of functionless service implementation is that it removes the $$ cost of lambda invocations.
There are some cons to implement a functionless service:
One potential “drawback” is that you have less flexibility to read and write data into your data tier, because with a lambda function, you can almost do anything you wanted to leverage your persisted data; but in this functionless way, your option on the table is limited
Examples of functionless patterns
Other than the API-Gatway / DynamoDB architecture, there are other situations such as
API-Gateway / Amazon Kinesis
API-Gateway / Amazon CloudWatch;
API-Gateway / SQS
…
Why not expose these services directly to clients?
You may have noticed that DynamoDB, Kinesis, Cloudwatch … are all services that provide HTTPS service themselves. Why on earth do we need to put an API-Gateway in front of it? Can’t way expose them directly on to the clients?
The answer is yes, but it depends on your use cases. Here we list a few great reasons to integration API-Gateway with these services (below is a list of reasons that AWS shared with us here)
You might want to enable your application to integrate with very specific functionality that an AWS service provides, without the need to manage access keys and secret keys that AWS APIs require.
There may be application-specific restrictions you’d like to place on the API calls being made to AWS services that you would not be able to enforce if clients integrated with the AWS APIs directly.
You may get additional value out of using a different HTTP method from the method that is used by the AWS service. For example, creating a GET request as a proxy in front of an AWS API that requires an HTTP POST so that the response will be cached.
You can accomplish the above things without having to introduce a server-side application component that you need to manage or that could introduce increased latency. Even a lightweight Lambda function that calls a single AWS service API is code that you do not need to create or maintain if you use API Gateway directly as an AWS service proxy.
What’s next
If this discussion interests you, please share your use cases and which route you plan to pursue
implement a lambda based logic tier?
implement a direct API-Gateway / data tier service in a functionless way?
or directly expose your data tier service to your client?