Introducing Architect 4.0: faster, lighter, simpler serverless

Ryan Block’s avatar

by Ryan Block
@ryan
on

white rods illustration

"white rods illustration” by Pierre Châtel-Innocenti

We’ve been listening to your feedback and today we’re extremely excited to introduce Architect 4.0 (Yeti), the fastest, simplest, most powerful way to build serverless applications.

Less, but better.

✨ Skip to the part where you create a serverless app with Architect in 30s

About Architect

Architect is a fast, lightweight, open source, zero-config serverless framework for AWS focused on a frictionless developer experience.

Architect apps are composed of many small, individual, fully isolated cloud functions, which confers some pretty nice characteristics: better security, separation of concerns, fast and surgical deployments of single functions, and parallelized, globally available deployment of your entire application in just seconds. As a result, development time, deploying, runtime, and latency are all incredibly fast.

Architect has been downloaded over 45,000 times since joining the JS Foundation last year. (Architect is also the open core of our serverless application hosting platform, Begin.)

4.0 is the best Architect yet. Let’s see what’s new! 🎉

What’s new in 4.0 (Yeti)

HTTP Functions

With Architect 4.0 @http functions you can now respond to web requests with any HTTP method, Content-Type, or Status Code.

Even better, @http functions have no dependencies by default, so they’re even lighter and faster than ever before.

Web servers aren’t standards — but HTTP is, and these tiny functions are a very pure and easy to work with abstraction of HTTP.

Examples

Let’s look at an example function defined in the following .arc file under the @http pragma:

@app
superfun
@http
get /

The generated code for get / is terse, easy to reason about, and has no dependencies:

HTTP functions support responding with: status, type, body, cors, location , and cookie 🍪

We think this is a pretty big deal for how using cloud functions will be used to develop sites, web apps, APIs, and a whole lot more.

🔬 Read more in the Architect HTTP Functions Guide

Frontend friendly public folder for static assets workflows + S3 sync

Front-end workflows like bundling and transpiling are super important to modern application developers, so we went back to the drawing board and re-thought how we could better enable folks to manage and ship assets within their Architect projects.

With Architect 4.0, common workflows — from Webpack, to Babel, to Typescript–are now possible with minimal configuration. Just point your scripts at the new public folder, and Architect will automatically syncs its contents to the S3 buckets you’ve specified in your project’s @static pragma.

Add any (compiled) JS and CSS, images, gifs, binary distributions, or other files you want to publish, and they’ll deploy to the appropriate S3 bucket whenever you deploy your project with npx deploy.

🎨 Read more in the Architect Static Assets Guide

JSON + YAML Architect manifest support

Architect’s .arc project manifest format is terse, easy to learn, and expressive syntax. We also heard that folks coming on board wanted to author in classical configuration formats like YAML and JSON, too — so now you can in Architect 4.0!

Add memory, CPU, & processing time with per-function configurations

Architect provisions cloud functions with sensible and affordable defaults. But sometimes you need to crank up a Lambda’s processing time, or available memory (which is also a proxy configuration for CPU power).

Architect 4.0 supports this by dropping a .arc-config file into the directory of any function you wish to configure. An example configuration file looks like this:

# src/http/get-index/.arc-config
@aws
timeout 30000   # timeout in seconds
memory  512     # 64MB increments from 128MB to 3008MB

Then, just run npx config apply to instantly update your Lambdas’ configurations.

Even better security with per-function IAM roles

A request we commonly heard from large enterprises and companies with strict compliance requirements was for Architect to support custom IAM roles, defined per-Lambda.

As applications grow in complexity, ensuring they conform to the principle of least privilege becomes increasingly important, so managing roles for your functions should fast and simple.

In the directory of any Lambda function, add a role.json file containing a policies array of IAM ARNs to attach. For example:

// src/http/get-index/role.json
{
  "policies": [
    "arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess",
    "arn:aws:iam::aws:policy/AlexaForBusinessReadOnlyAccess"
  ]
}

Then, just run npx audit apply to instantly update your Lambdas’ IAM roles.

Try out Architect in 30 seconds

Ready to give Architect a swing? No AWS account required, Architect runs locally and offline!

  1. Create a vanilla Node project:
    mkdir testapp && cd testapp && npm init --yes
  2. Install Architect:
    npm i @architect/architect
  3. Create a basic .arc file:
    @app
testapp
@http
get /
  4. Generate your project locally:
    ARC_LOCAL=1 npx create
  5. Fire up the Architect sandbox to preview your work:
    npx sandbox

Alternately, if using Windows, use these instructions:

mkdir testapp
cd testapp
npm init --yes
npm i @architect/architect
  [follow step 3 above]
$env:ARC_LOCAL = 1
npx create
npx sandbox

Thanks + love 🌈

With this release, as always, we’d like to give a shout out to all the members of the community who’ve helped guide our development, file bugs, and provide feedback. We see you!

Of course, if you’re not too busy, we’d certainly appreciate a ⭐️ on GitHub.

Yeti with a coffee