I’m a believer in the power of frameworks, and for good reason — the bulk of my career as a programmer and technology leader involved the use of Rails. During those early years (starting in 2006), I witnessed first hand how the potent combination of innovation, community, and proper stewardship could lead to massive advantages in product efficiency, hiring potential, and more. Since then, more than one company that relied on Rails has gone public, and dozens more companies have likely generated billions of dollars of revenue. Besides that, I still feel comfortable and confident using Rails, after all these years, and feel like it would be difficult to match its productivity for its chosen domain.
Since Rails was born, I’ve seen plenty of frameworks come and go, and have poked at a few here and there out of curiosity — I wondered if any could capture the right combination of nailing the abstractions and providing the right community framework. The first that has really caught my attention in that time is called Architect, and just as Rails leveraged Ruby to unleash massive potential for web development, Architect leverages Node and NPM to finally bring some structure and insight to the AWS Serverless landscape.
After seeing one of the framework’s creators Brian Leroux speak at a conference about Architect, I decided to try it out. A lot of the ideas that Brian covered in his talk appealed to me: the desire to paper over AWS’s abstractions, the power of the NPM CLI ecosystem, how confusing it could be to approach a Serverless application that doesn’t follow conventions, and more. From his presentation, I was especially intrigued with the .arc file format, which describes an Architect application. Before I say anything more about what the functionality of the application I made, take a look at the .arc file:
[@app](http://twitter.com/app) brainjams [@html](http://twitter.com/html) post /sms [@events](http://twitter.com/events) sms-emitter stats-recorder [@tables](http://twitter.com/tables) recommendations phoneNumber *String jams id *String
I think even without knowing much about the framework, you can get a pretty good idea about what these lines do. Similarly to describing database tables or routes in Rails and then having functions generated for you by running a script or at runtime, Architect takes an .arc file like the one above as input, and when you invoke the npx create command (documented here), it compiles your directives into configured and provisioned AWS infrastructure . No need to set up API Gateways, wire components together, fuss with security roles, configure countless services, or really even know very much about how these pieces work together. It just works. Just as I like it.
The .arc file for Brain Jams creates one HTTP endpoint, scaffolds two SNS events for sending SMS messages and recording stats in a database, and configures two DynamoDB tables with primary keys. All of this infra is provisioned and configured for me, and the UX is a pleasure.
Beyond being used to generate infrastructure, the .arc file is the entry point into all Architect applications — sort of like running rake routes was the entry point for a lot of Rails programmers when trying to find their way around an application. Here’s what the capabilities of the framework include at this point:
The current list of .arch file sections, which is growing regularly.
Note that Architect is been actively developed —at this point you can use .arc files to provision all kinds of useful infrastructure for developing event-driven cloud applications, from S3 buckets to DynamoDB tables to CSS and XML HTTP routes. In the future, who knows what this file will let you do, or the diverse set of services or patterns it may encapsulate.
An intro to Brain Jams
On to the application I built, called Brain Jams (named after a segment of my on-hiatus podcast with AQ called Beats, Rye and Types) — here’s a use case scenario (sorry, I’m a marketer):
Let’s say you’re out and about, and suddenly you need a jam to fit your mood, but your old standby playlists won’t do. We’ve all found ourselves in this situation, right? Well now instead of just listening to the same old thing, you simply text some words to Brain Jams, which very naively measures the sentiment of your text, and it responds with a song that has been tagged by hand (by me) to match that sentiment.
Dope, right? Here’s a screenshot of the application in action:
SMS gateway to the jams
Perfect jams, every time. Guaranteed.
The entire application is around 150 Lines of Code, and was built using Twilio and Architect. Here’s a diagram of how the pieces fit together:
A high-level overview of Brain Jams’ application internals
Check out Architect, and Contribute
In the past year or so, I’ve become quite bullish on Amazon’s implementation of the services which have been come to be used in Serverless architectures, but I haven’t had very many nice things to say about the experience of actually trying to use them on my own.
Now that Architect exists to make me not have to worry about or care how most of the moving parts work, I’ve been able to put together more than one experiment to scratch various development itches I have. It’s going to be an interesting experiment seeing how getting a few of these things into production will fare. Currently I’m relying on AWS Console tools like Cloudwatch to figure out what’s going on behind the scenes when necessary, but I’m planning on giving IOPipe a shot to see what kind of insight that product can provide.
Building this project has been a blast. Kudos to the Architect team for focusing on users and realizing that a key strategic position will belong to whichever community seizes on the opportunity to make Serverless as usable as it is cool.
Find Architect at http://arc.codes
If you check out Architect and make something with it, let me know how cool you think it is!