This Is the End

Recently, I shared a project skeleton and a post that allows you to easily turn almost any relational database schema into a REST API.

It took me about a month to develop the first release, just a few hours at night when the kids were asleep and during weekends, since I’m currently working full-time.

The feedback was mixed. Some people liked it, others simply hated it. At some point on Reddit, people even downvoted the project without explaining why. Fortunately, some benevolent users also took the time to tell me what they liked or didn’t about the project.

---

The Need and the Vision Behind the First Release

My initial goal was to solve a problem I had: reusing an existing, functional relational data model and its data from a monolithic application, and turning it into a headless architecture, where the backend is a REST API, and the resources are consumed by both a web app and an admin portal using Nuxt UI and Flutter respectively.

After benchmarking the first release candidate, I was impressed by the performance and decided to share the code under an MIT license for anyone facing the same challenge.

I’m not a Go expert. I recently learned the basics through Grok, and this was my first real project involving more advanced use cases. I managed to build something genuinely useful, and overall, the performance was quite decent, so why not share it?

---

So, Why Kill It So Fast?

Sometimes, programming languages are more than just ways to give instructions to a machine. They come with implicit rules, conventions, and structural philosophies. Go is no exception.

The first and most important issue with GoREST 0.1 wasn’t specific to Go: separation of concerns. Nobody wants to mix their business logic into a skeleton project unless that skeleton is meant to evolve directly into their final product.

Then there’s maintainability. Having a boilerplate that requires regular updates quickly becomes a burden and makes long-term maintenance painful.

And finally, flexibility. I wanted to offer multiple ways to use and implement GoREST, either as a library integrated into an existing project or as the foundation of a brand-new one. There are thousands of ways to code business logic, and I don’t want to impose just one.

So, there’s no reason to maintain this skeleton anymore.

Let’s cut off its head (no headless architecture related nerdy joke intended, literally).

---

RIP GoREST 0.1.0

Long live GoREST 0.2.0!

Yup, from the fresh ashes of GoREST 0.1 comes a complete rewrite as a library and toolbox. It aims to help you quickly scaffold your business objects and write your business logic with ease.

A new release marks a new chapter for GoREST. Yes, I know this is a total breaking change and should be a major version, but since no one is using it yet except me, and we’re still far from version 1.0.0, there’s no harm in making it a minor upgrade.

In my opinion, this new 0.2.0 release is a healthy foundation to iterate from. It keeps the same features and benefits as the previous version but is now decoupled into a library of Go modules and useful commands.

---

Road to 1.0.0

Here’s what I want to accomplish before releasing the first stable, long-term support version:

• Better performance
• A fully modular middleware layer with install/uninstall hooks
• 100% test coverage (currently around 80%)
• gRPC support
• Support for more database engines
• Scaffolded clients
• Some kickass new features I haven’t even thought of yet...

---

Contribute

Wanna join the adventure and contribute to the project?

All kinds of contributions are welcome, even just ideas or suggestions.

Read the contributing section.

You can fork it and/or star the project if you like it.

Thanks for reading.