gutenberg VS dbmate

So after shopping around a bit I found a simple, dependency-less static site generator called Zola. The lack of dependencies sounded very attractive after all the headaches trying to update my Gatsby modules. I wanted to give Zola a try and see what tradeoffs I would need to make coming form a React-based framework to this Rust-based generator.

I think you're thinking about Zola: https://github.com/getzola/zola

But yes, if I were to recommend something, it'd be Zola given that there's just one executable that you need to run and there's absolutely no setup required.

If I were to start again from scratch, I'd likely use Zola as SSG (https://www.getzola.org/)

I've used Zola (https://github.com/getzola/zola) for a static project homepage a few years ago to showcase examples with a simple description and a wasm app embedded in the page, it worked perfectly for me and the docs was clear on how to use it. It was very easy to set up along with a GitHub action to automatically update the wasm binaries when needed. It is definitely a tool I keep in my mental toolbox as a good default.

I'm currently learning https://www.getzola.org/.

It's more manual than idy like but it's gonna be for a small personal and work website so I don't mind much.

It's super fast.

Doesn't seem to fit your use casr but still.

(Note: that list is overwhelming; you don't need to go through it. Order by popularity and look at the top 3-5 at most. Hugo, Jekyll, Gatsby... Personally I'm using Zola [ https://www.getzola.org/ ] for a couple of sites, but that's just me.)

A regular code repo with the scripts (with pull/merge requests for review) and then a CI job that builds containers with something like dbmate https://github.com/amacneil/dbmate that can then be run against any staging/prod environment.

As we want to maintain the track of our changes to the DB, we are going to use migrations. In this case, we are going to use dbmate. But, you can use any other tool you want.

> For example having database migrations built in etc.

I actually went the exact opposite route, at least when possible: https://github.com/amacneil/dbmate

Pure SQL migrations, regardless of the back end technology that you use, completely decoupled from how each framework/library views things and therefore not dependent on them (you could even rewrite the back end in another technology later on, if needed; or swap ORMs; or avoid issues when there's a major ORM version update).

It's really nice when you can generate entity mappings based on a live database, like with https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor...

So in my case, I can have:

  * a DB that has migrations applied with dbmate, completely decoupled from any back end(s) that might use it

You can run dbmate as part of your CI/CD pipeline. You just keep a dbmate directory in your repo and deploy migrations with your code.

In general with ORMs, you will face a problem in one way or another. I ended up simply using https://github.com/gajus/slonik and https://github.com/amacneil/dbmate for migrations. My life is way much better since then.

I like dbmate, super simple and straightforward to use. For your specific use case, it can also be configured using your .env!

Would always go for a language agnostic migration tool, e.g. https://github.com/amacneil/dbmate to stay flexible and stay away from lock-in effects (besides sql).