Architect a different approach to web application development

by Tom Wilson

It is the year 2021 and serverless is starting to go mainstream, kubernetes has emerged as the top enterprise network solution and the React web library is the most sought out frontend skillset. On one side the frontend development world is struggling with the complexity of scale versus technical debt with frontend frameworks. On the backend development side you have complexity of scale with the amount of services that need integration to produce effective applications. There is certainly much more to the story, but the gist is, at this point in time, to become a full-stack developer is the most complicated it has ever been.

In this post, I want to take a look at some different approach that may make you go hmmm. Do I need the power of react? Do I need to manage my on cloud infrastructure? Do I need to create custom css? Do I need more than a function for my web server? It is worth looking at alternate approaches.

Architect

Architect is an opinionated serverless framework that supports several different server runtimes, but for the purposes of this post, we will be focusing around NodeJS. Architect takes the complexity of cloud formation, aws's schema language and distills it down into a declarative specification that is clear and concise. When you look at the configuration file, you are able to determine exactly what is going on.

@app
myapp

@http
get /
post /assets
delete /assets/:id

Here we have a serverless application that supports three endpoints:

  • get /
  • post /assets
  • delete /assets/:id

From that simple configuration, architect can generate serverless function handlers arc init, and aws cloud formation scripts to deploy a serverless application. arc deploy

This is a declarative approach to serverless that handles all of the general tasks and empowers you the developer to focus on the special tasks that pertain to your application.

How does it work?

When you call arc init, architect generates the following directories:

  • /src/http/get-index
  • /src/http/post-assets
  • /src/http/delete-assets-000id

In each of these directories is an index.js file that contains a handler function for AWS Lambda. 

exports.handler = async function http(req) {

  return {
    statusCode: 200,
    headers: ...,
    body: '<h1>Hello World</h1>'
  }
}

The function provides a Request object, that represents the incoming http request, and expects a Response object to be returned, the Response object should contain a body, with optional http status code and http headers.

Each one of these directories will be deployed as a different AWS Lambda function and provide incredible scalability without having to think about ingress services, load balancers, ip ports, web proxies, and web servers. You create your function, it gets called and you return a response.

What about shared libraries?

Architect has a couple of conventions that are built-in where you can put your shared library code: (Each of these conventions are configurable if desired via your arc manifest file)

  • src/shared directory (contents gets copied to all lambdas)
  • src/views directory (contents gets copied to just @http GET lambdas)

You can include them in your lambda function:

const template = require('@architect/shared/template')

exports.handler = async function http(req) {
  ...
}

This results in a clean separation of concerns and provides general purpose reusability to your applications.

Running in local environment

One of the challenges with serverless is the ability to run in a local development environment, this is not an issue with architect

Getting setup

There is a bit of work involved in getting setup with architect:

You will need:

Summary

Leveraging declarative concepts, architect has taken something as challenging as web servers and has leveraged AWS Services to create a conventional approach that scales. There is a lot more to unpack with architect, check out https://arc.codes for more details.