I’ve just “summited the hill” on the most substantial reworking of Super Scaffolding I’ve undertaken since I first created it in 2017.

If you’re not familiar, Super Scaffolding is Bullet Train’s code generation engine. Its goal is to allow you to produce production-ready CRUD interfaces for your models while barely lifting a finger, and it handles a lot of other grunt-work as well.

As an application developer myself, having Super Scaffolding in my toolbox has been an incredible productivity boost and I couldn’t imagine trying to develop new applications without it anymore. I’ve been able to translate rough domain models into working applications in a few hours instead of days or weeks.

Here’s a list of what Super Scaffolding takes care of for you each time you add a model to your application:

• It generates a basic CRUD controller and accompanying views.
• It generates a Yaml locale file for the views’ translatable strings.
• It generates type-specific form fields for each attribute of the model.
• It generates an API controller and an accompanying entry in the application’s API docs.
• It generates a serializer that’s used by the API and when dispatching webhooks.
• It adds the appropriate permissions for multitenancy in CanCanCan’s configuration file.
• It adds the model’s table view to the show view of its parent.
• It adds the model to the application’s navigation (if applicable).
• It generates breadcrumbs for use in the application’s layout.
• It generates the appropriate routes for the CRUD controllers and API endpoints.
• It generates headless-browser feature tests for the CRUD workflows.

None of these things are particularly difficult per se, but if you’re doing all of that manually every time you generate a model, it adds up fast. In total, when adding just one model, Super Scaffolding generates 28 different files on your behalf.

(As an aside, I’ve noticed that when Super Scaffolding is doing all the heavy lifting, I’m a lot more likely to go back and rework my domain model when I realize there is a better way to represent something. It’s a lot easier to tear something up and rebuild when it didn’t involve that much effort in the first place.)

Anyway, as I said, Super Scaffolding has already been working really well, but there have been some specific edge cases where things went a little less smoothly, particularly when dealing with complex namespacing schemes.

Namespacing is one of the best tools we have for keeping growing domain models organized and easy-to-understand. However, there aren’t established conventions about the best way to implement namespaced models in Rails applications. I’ve written about namespacing conventions in Rails a little before, but one of the design goals for Super Scaffolding is to allow developers to namespace their models liberally without having to think about conventions around naming collections or naming instance variables or structuring routes.

For the most common use cases that’s already been true, but as the scale of applications I’ve been building with Bullet Train has grown and as the scale of Bullet Train itself has grown, I’ve been running into some of the edge cases more regularly. They’ve never been a show-stopper, I’ve always just gone in and done whatever manual tweaks were required to get the generated code working as desired, but this still left a lot to be desired for me.

Well, that’s over now!

I’ve now substantially reworked the Super Scaffolding engine itself and completely recreated the foundational code templates on which the code generation depends. Going forward, Super Scaffolding will perform even better than before, generating code that Just Works™ in as many situations as I've been able to throw at it.

If you’re not already a Bullet Train customer and you’ve got an upcoming project in mind, I recommend scheduling a call so I can show you how quickly a rough model of your problem domain can be turned into a working structure for your product.