A guest post by Ameya Charnalia on his journey to migrate from Heroku to AWS via Architect.
After Heroku axed its free-tier in 2022, I was approached by Simon MacDonald—head of developer experience at Begin and my JavaScript mentor—to migrate my Twitter bot, Billbot, to Amazon Web Services (AWS).
While I was at it, he also recommended moving to Mastodon since there was talk Twitter would be restricting access to its free API service in the coming weeks.
Access to the API remains free for write-only cases at the time of publishing.
This innocuous suggestion from Simon made me slightly nervous.
See, Heroku made it very easy for frontend developers like me to deploy our backend projects. Create a procfile, push your code up, make sure your environment variables are set up properly and, before you know it, you’re off to the races.
But I was only delaying the inevitable.
As my projects became more mature and scaled up, I became more involved in writing server-side code. Being a primarily self-taught developer, I knew I had to become familiar with industry-standard cloud solutions such as AWS, but I was spooked by the deployment process. I was warned the process could be cumbersome and the learning curve steep.
Did I say I was a tad nervous?
My bot, for example, runs every morning at 7 a.m. and tweets—or toots, depending on your social media platform—government bills scheduled for debate in the Canadian parliament for that day. How would I migrate my Node.js code from Heroku to AWS while learning about AWS cloud formations, lambdas and databases? I was worried my application would break and leave its users in the dark, scrambling to find out about the day’s bills. (OK, I admit I’m being a tad dramatic—the bot’s 200-odd followers could go to the House of Commons or Senate website to see the day’s projected business. But. I did want to ensure my application’s reliability)
That’s where Architect comes in.
Made by Begin, Architect is a simple, open-source framework for building and delivering powerful Functional Web Apps (FWAs) on AWS.
Off the hop, we decided we’d be using AWS lambda functions triggered through a daily cron job. To achieve this, we made use of Architect’s events-based helper functions. The Architect team has two Node.js runtime helpers: those for general purpose operations such as events and those designed solely for delivering dynamic data via HTTP endpoints.
We wrote two lambda events functions—one each for Mastodon and Twitter—and one scheduler function that dealt with most of the application’s business logic, which included making calls to parliament’s API, filtering the bills and returning all the necessary data to the handler function. When triggered by the schedule’s handler function, the Architect publish function checks which event subscriptions are associated with each event function and makes the calls to the Twitter and Mastodon APIs, respectively.
All of this makes sure that Billbot’s tweets and toots are on time, every day.
In the root of the application sits the app.arc file. Here you can declare the application namespace, its lambda functions, and any AWS regions and plugins it may use. Once I set up my AWS credentials via the AWS command line interface, I was ready to deploy.
@app
billbot
@scheduled
checkbills cron(0 11 ? * * *)
@events
postbill
tweetbill
@aws
profile default
region us-east-2
architecture arm64
runtime nodejs18.x
That was pretty much it.
Architect’s documentation is well-crafted and guides you in deploying your application, regardless of your comfort level with AWS. The developer experience was intuitive, and Architect stripped away much of the AWS complexity, allowing me to get right to learning about, and deploying with, lambda functions.
What’s more, is that it will to save me nearly $16 a month in Heroku bills.
If you want to learn more about Architect check out our documentation or join us on our Discord to ask a question.
Top comments (0)