Full-Service Serverless: Front-End to Full-Stack in Minutes

Server architecture doesn't have to be and serverless makes it possible to build something that can scale to meet your business success. Serverless and related platforms like Stackery are a direct answer to breaking up that pesky developer hierarchy, which stunts the very purpose of the job.

Dec 17th, 2018 10:40am by Nočnica Fee

Featued image for: Full-Service Serverless: Front-End to Full-Stack in Minutes

Stackery sponsored this post.

Toby Fee

Toby is a community developer at Stackery. Her roles and experience combine working as a software engineer, writer and technology instructor, building interesting projects with emerging tools and sharing her findings with the world. Prior to joining Stackery, Toby was an engineer at NWEA, Vacasa and New Relic.

Serverless offers a highly managed model of web hosting. Generally understood as an improvement for operations teams looking to offload some of their responsibilities, the platform allows you to go straight from writing amazing front-end experiences to serving your site without a single Unix command.

And yet.

As recently as five years ago, development roles existed within an endemic hierarchy. I want to say upfront that this cultural hierarchy has always been garbage for a handful of reasons, chiefly in that it went out of its way to denigrate roles typically filled by women.

Regardless, self-taught developers began their education with HTML and CSS, moving into the server-side code later and ending with the management of Linux servers to run that code. Next, alongside gaining advanced database and code optimization skills, developers in training learned highly managed environments, such as Amazon Web Services (AWS) and Azure. The architecture of such managed services was a distant goal for people who’d mastered everything else.

However, front-end coding is a vast technical field and it has always taken acumen to get HTML and CSS to match a design board. Meanwhile, modern front-end developers are expected to handle pre-processing, accessibility and a million tiny touches of JavaScript interactivity. Can’t someone who understands all of this get a real, scalable web service working without all those steps in between?

To some, the answer to this question was Heroku. One acquisition and vicious write-up later, Heroku is more of a hobbyists tool — it is great for building Twitter bots, but not so great for reinventing how people buy mops.

A Pure Serverless Solution

Since it dominates the serverless market, I’ll build this example on AWS, though an exact replica of this could absolutely be built on Azure. The three services you’ll need to connect are Amazon S3 to store your files, Lambda to control your service logic and DynamoDB to act as your site database. To make your Lambda, which reads from your DB- publicly available, you’ll also want to have an API endpoint.

Here’s an image of this stack, along with a bit of error collection:

This map was built with Stackery. If you want to avoid both Unix AND the AWS console, Stackery can create and deploy all these resources in just a few clicks.

This map was built with Stackery. If you want to avoid both Unix AND the AWS console, Stackery can create and deploy all these resources in just a few clicks.

The Basics

In a noted contrast to containers, serverless doesn’t require you be a full-time specialist. For this reason, I believe it will replace containers as the preferred new tool for ops teams.

Primarily, you need to learn how to create a basic Lambda. This version was created with Node 6, which is a good starting place for all stacks:

'use strict';
exports.handler = (event, context, callback) =&gt; {
console.log('Welcome from the Lambda-land!');
const response = event;
console.log(JSON.stringify(response));
callback(null, response);
};

1

2

3

4

5

6

7

'use strict';

exports.handler = (event, context, callback) => {

console.log('Welcome from the Lambda-land!');

const response = event;

console.log(JSON.stringify(response));

callback(null, response);

};

What’s going on here? Almost nothing other than the two critical initial steps for every lambda:

Log what comes in — AWS documentation is (to avoid a verbose elaboration) incomplete. The only real way to know what’s calling our lambda and with what payload is to log it out.
Send a valid response — Wrestling with proper JSON formatting is pretty easy in Node, but you don’t need to be dealing that while trying to debug the rest of your stack! In almost all cases, the event you were called with is a valid starter response

After this lambda is up and running, here are the next steps for expansion:

Test events to heck and gone — Now that you’ve logged out a real event, set up a test event to test your lambdas. Why not test them through the API gateway or whatever else triggers them? Again, we’re trying to learn* these tools, so keeping things as simple as possible is key. Service returning 402’s or 500 errors? Before you suspect the lambda code, send a test event.
Get good observability into your stack — Observability is how well you can understand your system and its malfunctions without cracking open the source code. A tool like Epsagon can help you get good observability into your stack beyond the logging AWS does automatically

Stackery can also add a single consumption point for all errors experienced by all your Lambdas.

Conclusions

The front-end is extremely technical and complex. The revelation? Server architecture doesn’t have to be and serverless makes it possible to build something that can scale to meet your business success. Serverless and related platforms like Stackery are a direct answer to breaking up that pesky developer hierarchy, which stunts the very purpose of the job.

Feature image via Pixabay.

Nica Fee helps teams adopt serverless and optimize their costs on AWS. She is a Serverless Developer Advocate for New Relic.