Localtower v2: It’s never too late.

Genesis of the idea

Back in March 2017, I was teaching Ruby and Rails to junior developers.
The natural way to learn Rails is to create an app from scratch, adding models, controllers, views, etc. A simple exercice to learn how things are connected.

Rails has a fantastic tooling with database migrations when it comes to creating models or migrations. The API allows you to manage your database schema like a charm.

And with 12+ years with Rails, I still do mistakes very often.

The creation of a migration to add a new table is prone to error. It’s easy to do mistakes or typos in the file generated when adding columns.
I always go back to other migrations, copy the line that looks like what I want, adapt the naming, and run rails db:migrate. If I have an error, I go back to the migration file, check the Rails documentation if needed, modify it, and run the db:migrate again.

I wanted something more user friendly:
A clean UI with buttons and dropdowns to create models and migrations.

So I created the first version of Localtower as a PoC in a few days. Surprisingly, two weeks after the release, it was featured in Ruby Weekly (issue #341) and the downloads went up to more than 38,870 downloads and 402 stars on Github. (stats are here on BestGems.org)

It was enough to convince me to keep this project alive.
Not only as a tool to make better migrations but also as a learning tool for junior developers to understand all the possibilities they have with migrations.

The rise of developer tools

Things have evolved a lot since 2017 in term of developer tooling. Even if I use Rails everyday and I love it. Not everyone is comfortable to code when it comes to creating prototypes. That’s why low-code or no-code tools became popular. For a good reason:

Their UI interface are really awesome.

Just to name a few: Make, Zapier, Supabase, BuildShip, Bubble.

That’s why I decided to completely rewrite the UI of Localtower and provide a better developer experience when it comes to manage your database. The ability to quickly iterate on your SQL schema is key to prototyping and even later when your app starts to have more than 10 tables.

Differences between v1 and v2

Everything changed between v1 and v2 regarding the UI. All the core backend components are the same (with a small refacto) but the interface is brand new.

All the documentation is on the Localtower Github repo: https://github.com/damln/localtower

Full demo (2min)

Some Screenshots

Technical constraints with Rails Engine

Since Localtower is a Rails Engine, it lives inside an existing Rails app. You don’t control the parent app. Some people can use Localtower with Rails 5.2, Rails 6, Rails 7, or Rails 8. That means you can’t use the latest Rails features like Turbo or Streams because the parent app might be using an old Rails version. Most importantly: the engine can’t set its own version of Rails. You are completely locked to the version of the Rails app hosting the engine.

That means I ended up doing weird things. The asset pipeline had to be full javascript and not rely on sprockets or propshaft in order to be future proof. And the backend components needed to support various versions of Rails. The backend side was easier to manage since I only use the native migration API.

ReactJS joined the chat

Why React? Not because I like it. But its popularity makes it a great choice for a simple open source project.

Creating migrations and models is about adding entry to a table in a clean way. Add a row, change a row, dynamic selectors, removing a row, etc. All these interactions had to be instant. So the new UI is managed by ReactJS. My JS code is absolutely bad. I need to refacto some parts and reuse more components. But first I want to gather feedback see what deserves an evolution.

As a result of using the native migration API and using ReactJS, I managed to have Localtower compatible with Rails 5.2 up to Rails 8.

Conclusion

On one side I am a huge fan of having code to create prototype and use the command line everyday. But on the other side I wonder why we get stuck in this paradigm when it comes to Rails. We already have awesome interfaces for Sidekiq, SolidQueue (Mission Control), GoodJob, ActiveAdmin, RailsAdmin, and many other tools that helps you develop and monitor Rails apps. Why not having one for database migrations ?

If you want to try it I recommend you to read the README.md in the Github repo.

If you want to talk about it and share feedback and ideas,
you can find me on X: https://x.com/damian_lnd

You can also open an issue on Github here.

Happy db:migrate!