Forms without servers — handling form submissions with Lambda

Converting from server-side form management is a key step in migrating websites to serverless.

In a traditional website, one of the most common dynamic functions performed by the web server is handling form submissions. Typically, when a visitor completes a form, the submit action sends a POST request to the web server, which then returns the entire page back to the client browser with a message indicating the form was submitted.

For developers moving their sites to a serverless architecture, handling form submissions is a small but important part of completing the migration. Fortunately, it’s easy to convert your forms. In this post I’m going to show you how. This method offers speed, scale, and security advantages to traditional form posting, while providing an improved user experience for end-users.

From POST to JavaScript.

The traditional form posting process uses the form action attribute to tell the browser which server-side script will handle the POST:

The traditional form post with server-side processing.

The end-user usually expects to see the same web page after a form submission (with a success or failure message), so the server builds this entire response even though it’s mostly identical to the previous page. In the serverless method, we don’t need to perform this unnecessary page reload — we can complete the whole transaction much more elegantly.

The main change in the front-end is to remove the default POST behavior and replace it with a JavaScript handler that will submit the post data asynchronously and update the user interface. In this implementation we no longer reload everything from the web server — instead we post the form data to API Gateway and use asynchronous JavaScript (AJAX) to provide feedback dynamically on the front-end.

The second part of the solution is building the back-end to capture the form data. In this tutorial, we’re going to deploy the back-end first, and then test it with a a simple front-end. The resulting architecture will look like this:

We will store the form data in a database table and send an email to an administrator, mirroring the behavior of many server-based form scripts. There are four AWS services used in this solution:

• Amazon API Gateway provides the https endpoint that our web page calls.
• AWS Lambda parses the form data, store the item and send the email.
• Amazon DynamoDB is the database for storing the form data.
• Amazon Simple Email Service (SES) sends the email.

Validating an email address in Amazon Simple Email Service

To use SES, you must either validate domain ownership or the individual email address receiving messages. For this tutorial, we will validate a single email — without completing this step, you will receive an error from the Lambda function when it attempts to send an email.

To validate an email address in SES:

1. Sign into your AWS console and navigate to the Simple Email Service (SES).
2. Under Identity Management, choose Email addresses” and then click the “Verify a New Email Address” button:

3. Enter the email address to verify (this will be where the submitted user forms are emailed to). You will receive a confirmation email — click the link in the email and the dashboard will confirm the email is verified:

Deploying the back-end using SAR

I’ve created an application in the Serverless Application Repository (SAR) that will deploy and configure the other services needed. The application uses a Serverless Application Model (SAM) template to automate the resource creation.

To deploy this application:

1. Go to https://console.aws.amazon.com/serverlessrepo, choose “Available Applications” on the left and use the search box to find “serverless-form-handler”:

2. Click the application card to open the detail page:

3. Scroll down to the “Application settings” card, enter the email address you validated in SES in the ValidatedEmail field, and then choose “Deploy”.

4. After a few minutes you will see the application deployment is complete. Click the “Test app” button:

5. The Resources card shows the DynamoDB table, API Gateway REST API and Lambda function that were deployed as part of this application. Expand the plus icon next to the “ServerlessRestApi” link in the Logical ID column:

6. Finally, right-click “API endpoint” and copy the link URL — this is your https endpoint we will be using in the next section.

At this point, you have validated an email address in Amazon SES, and successfully deployed the resources needed to handle a form submission via API Gateway.

Connecting the form to the serverless back-end

For testing, we need a simple form on a web-page, so I’ve created a Fiddle with an example form — click here to open:

Interactive Fiddle available at: https://jsfiddle.net/jbeswick/wmq972xc/

At the moment this code is missing your API endpoint, but before we configure this, let’s walk through the code to see how it works:

• Structure: this web page is split into HTML (lines 34–57), which renders the form displayed in the bottom right of the Fiddle, and JavaScript (lines 59–94), which handles the entire process when the form is submitted.
• Submission: the form method attribute (line 37) causes a POST action when the ‘Submit’ button is pressed, but the form.onsubmit event handler prevents this (line 66). Since there is no web server, we instead send the form data to another URL — the API Gateway endpoint we created earlier.
• Feedback: The main body of the handler creates a JSON object containing the form data (in lines 69–70). At line 72, it displays a message to provide user feedback before the process starts — this is one of the greatest features of the AJAX approach because the code can interact directly with the UI and provide immediate feedback to the user.
• Response: the handler creates an XMLHttpRequest to send the data to the API endpoint (lines 75–78). Finally, the callback processes the response (lines 83 to 91) and updates the front-end with either a success or failure message, depending on the server response.

To test this form, take the API endpoint URL you created from deploying the back-end application and paste this into the formURL value on line 63, ensuring the path ‘/submitForm’ is appended:

Click Save and then click Run. In the form on the right, enter an email, name and message and click Submit. You can see the form dynamically updates the status of sending the message.

The front-end has updated as expected, and the form data has been stored in a DynamoDB table and sent in an email.

Go to the DynamoDB service in the AWS console, choose the Tables option in the menu on the left, and open the table with the prefix ‘serverlessrepo-serverless-form-handler’. Here you will find the contents of the form submission:

Check the email account you configured earlier and you will find an email summarizing the form contents:

The benefits of the serverless approach for form handling

Switching from a server-based to serverless form handling method has a number of important benefits. The first is speed —by separating out the functionality, we are not impacting the performance of serving the web-pages. While the difference might be subtle in testing, it can make a much bigger difference on busy sites.

Security is also another factor — the Lambda function handling the form is operating separately from the site delivery, and only has minimal permissions to perform its task. It does not access a web server that might contain any sensitive information, which helps improve the security of your site.

Finally, this approach helps scaling. For example, if you have a form on a marketing landing page featured in TV advertising, it will receive large bursts of traffic when commercials are aired. In a web-server based solution, this type of traffic can cause significant slow-downs and even outages, whereas the serverless solution will scale up automatically and invisibly.

Next steps

Congratulations! You have created a web page that collects form data, stores the result in a database, and sends an email to the account owner — all without running a web-server. This serverless solution will run every time a visitor submits the form on your test web page.

For a production use-case you can modify this example to connect to Slack, send SMS messages or integrate with marketing automation systems. With minimal changes to the HTML and JavaScript, you can make this work with different types of forms, and embed in pages from CMS systems like WordPress and Drupal.