What I’ve learnt building plugins for Architect 10

Photo by Call Me Fred on Unsplash

With the launch of Architect 10 came the stabilization of the Plugins API, after the earlier experimental version from Architect 9. I’ve been using Architect for over two years now across a wide range of projects. The speed and utility of Architect has been a considerable improvement in my web development workflow. Not least because the amount of boilerplate and task-orientated work I previously had to perform, away from actual project-specific coding, have been taken away from me by the opinionated, best practice approaches baked into the framework.

As a freelance developer, I have many projects on the go at the same time, and it’s not uncommon to find your own patterns and workflows that would be handy to carry across many projects. For a while, Architect has allowed tasks that are specific to the deployment stage to be tackled with macros, but now plugins enable us to author workflow improvements that hook deep into the inner workings of not only deployments but also the local development sandbox and our internal function’s logic too.

This is hugely valuable for my day-to-day work as I can more easily share common patterns across projects, further improving productivity. From provisioning additional S3 buckets, to hooking into Slack or Discord to provide project-related notifications, to baking DNS set up into the wider Infrastructure as Code foundation of a project - where there’s an itch that needs scratching, you can typically find a way to bend Architect to your whim via plugins.

But also, I’ve found some ideas are neatly encapsulated enough that they make great open source contributions, and I have so far open-sourced two plugins:

• Tailwind CSS
• Named Routes.

Tailwind Plugin

The Tailwind plugin handles all the initial work integrating the just-in-time CSS compiler into an Architect project. With a quick npm install and adding the plugin to app.arc, the Sandbox automatically launches the Tailwind watcher. It is pre-configured to monitor the most commonly used paths within Architect. Further, it hooks into deployment time to build and minify the final CSS file prior to deployment, which can be an easily forgotten task without (formerly) manually building a relevant deployment script.

Named Routes

Named Routes allows optional names to be added alongside routes defined in app.arc and then for those names to be referenced inside HTTP functions. This technique is present in several other web frameworks to allow you to dynamically reference routes within view templates, during redirection logic, etc. This makes any future refactoring of your web app paths significantly less fraught as all your views and URL-related code map to the name rather than the path at the time of development.

Taking the example of Named Routes a little further, it feels like something that could make an interesting future core feature of Architect’s Sandbox, but the beauty of plugins is it gives an easier way to demonstrate functionality as a standalone. The functionality can be used immediately by anyone, but through trialling the concept, you can see if there’s enough interest to consider making it a built-in feature in the future, rather than embarking on a pull request “blind”.

In Conclusion

The speed at which a plugin can be up and running local to your current project, then later, if you spot a commonality in the task you’re approaching, port it to its only module, is such a welcome improvement to my daily work. And being closely coupled to the best practice principles of Architect itself typically encourages you to do "the right thing” with regard to IaC, environment separation, and the core tenets of Functional Web Apps.