I’m in a position where I converse with our customers and cloud service providers, and I keep track of conversations happening through blogs and social media. I then sift through all this data to identify patterns and trends. Lately, I’ve seen some talk about an architectural pattern that I believe will become prevalent in the near future.

I first heard about this pattern a few years ago at a ServerlessConf from a consultant who was helping a "big bank" convert to serverless. They needed to ingest data from an API and put it in a DynamoDB table. The typical way this is implemented looks like this:

There’s nothing inherently wrong with this approach. It will scale just fine… unless you hit your account-wide Lambda limit. Oh, and you’re also paying for invocations of the Save Record function that isn’t really providing business value intrinsically. Also, we now have added maintenance liability for the code running in Save Record. What if that’s Node.js 6.10, which is approaching EOL for AWS Lambda?

A Functionless Approach

The "big bank" consultant was ahead of the curve and helped them implement a better approach. What if, instead, we could do the following:

This may seem magical, but it’s possible using advanced mechanisms built into AWS API Gateway. Let’s step back and think about what happens when you integrate an API route with a Lambda Function. We’re used to using frameworks like AWS SAM that abstract away how the integration is implemented under the covers, but in simple terms, the API Gateway Route is set up to make an HTTP request to the AWS Lambda service and wait for the response. Some lightweight transformations are used to enable passing request parameters to the Function and to pass response parts (status code, headers, and body) from the Function response back to the HTTP client.

The same techniques can be used to integrate an API Gateway Route with any other AWS service. API Gateway can handle authentication itself, meaning as long as you can do a small transformation on the incoming API request to generate a request to an AWS service you don’t need a Lambda Function for many API route actions.

While this functionality has been obscured in API Gateway (for a multitude of reasons), it’s front and center in AppSync: AWS’s fully-managed GraphQL service. With AppSync, DynamoDB Tables, SQL Databases (via Aurora Serverless), Lambda Functions, and ElasticSearch domains have all been elevated as first-class "Data Sources" for GraphQL resolvers. Here’s an example API built using these default “Data Sources”:

This API can query a stock price from a third-party API (Alpha Vantage and record trades in a DynamoDB table, all without needing to write code for, nor provision, Lambda Functions.

What Skills Do Engineers Need For This New Technique?

All this sounds great, but how do you build and operate API-Integration driven applications? Because this is such a new technique, there aren’t a lot of examples to learn from, and the documentation available is mostly of the "reference" variety rather than “how-tos” or “use cases”.

Developers tend to be comfortable with SDK contracts: "When the API route is invoked, my Lambda Function will get this data in JSON, and I can call that AWS service using their SDK with public docs." Unfortunately, direct integrations are currently a bit more difficult to build.

Engineers need specific new skills and information. In particular how to:

• Write Apache Velocity macros to translate API requests to AWS service actions. This is a standard mechanism for declaratively transforming HTTP requests in not only AWS API Gateway and AppSync, but many other contexts, including Web Application Firewalls

• Construct infrastructure templates (e.g. CloudFormation / SAM to integrate API resources with other AWS services (e.g. DynamoDB Tables and Aurora Serverless Databases)

• "Operate" a functionless, API-integration-driven application (i.e. where are request logs, how are they structured, how will errors be surfaced and acted upon, etc.)

At Stackery, we help our customers figure out the above. If you want to try your hand at this type of development, sign-up for Stackery and don’t be afraid to reach out if you have any questions or need help on your own serverless journey! Drop us a line via email (support@stackery.io), fill out our contact form.

Also, be sure to join the Stackery livestream on this subject on April 24th at 10 AM PDT. I'll be hosting it, alongside iRobot's Richard Boyd. We'll dive a bit deeper on Lambda Functions and REST APIs and answer any questions you might have!