DBCore can now generate a TypeScript/React CRUD UI that is automatically hooked up to the generated REST API (in Go).

The UI has full support for login, viewing (and filtering), editing, and creating database entities.

PostgreSQL, SQLite and MySQL are supported.

How to use?

The goal of this project is primarily to provide as much useful boilerplate as possible for full-stack applications. The system is probably not sufficient to be an entire application development platform. It's currently missing hooks, overrides, and per-row/per-table authorization.

The UI code generation may be even less useful in the long-term than the API because UIs are by necessity very diverse. But it is good not to need to build the same browser-side API, authentication, and routing logic again now that it's taken care of in code generation.

Screenshots

Here are a few screenshots of the examples/todo application. Every page here is auto-generated after reading the database schema. The browser application is hooked up to the similarly auto-generated API.

What's new in DBCore: a TypeScript/React UI generated from your database schema and hooked up to the similarly generated Go REST API.

So you can now generate an entire full stack application from your database schema. Screenshots in the post.https://t.co/BTGRVBsfUR

— Phil Eaton (@phil_eaton) June 14, 2020

I recently published an alpha version of a code generation tool, DBCore, that reads a database schema from PostgreSQL or MySQL and generates an entire Go API with CRUD operations, pagination, filtering, and authentication.

But more than just generating code like xo/xo or gnorm, DBCore defines a standard REST API that can be implemented in any language -- and includes a reference implementation in Go. I'm eager to add Java and Ruby implementations as well. And I'd be more than happy to accept community contributions.

Boilerplate & code generation

Web application boilerplate is boring. You should do it once from scratch (preferably down to the socket layer) and never do it again. I struggled for the last few years to find the right system to reduce boilerplate. If I were building a new line-of-business application as an employee I'd pick one of Rails, ASP.NET, Spring, Django, or similar.

I've never worked on one of those frameworks professionally and I've never been able to force myself to learn any of them in my free time. But even if I could use one of these, none of them get close to giving you an entire functioning application with authentication, pagination, filtering all based on your existing database.

Over the last few years though I've relied heavily on code generation for Go projects. Code generation is basically the only way to conserve type-safe code in Go. But it's similarly popular in more powerful languages like Java.

However none of the existing projects give you much flexibility or provide you with enough templates to be useful.

DBCore

DBCore is written in F# and can be distributed as a static binary on all systems .NET now supports (read: not just Windows!).

Reading from MySQL or PostgreSQL is supported but I'd like to see that extended to include SQLite, Oracle, and MS SQL at least.

As mentioned, currently DBCore only provides a Go REST API template. That only solves half the problem of building an application though. And while there are some projects that can generate an admin CRUD interface for you, I want to see that more tightly integrated into DBCore. So I'll be introducing a new template for a browser application as well. For each table in the database it will generate a page showing paginated entries and allow you to create, update, and delete.

Finally, while the tool only currently has a concept of "browser" and "api" templates, the project should be able to accept any kind of template and generate any text based on any database schema.

New blog post, background and goals for dbcorehttps://t.co/XW9gUCtvr0

— Phil Eaton (@phil_eaton) June 7, 2020

GTID-based replication makes managing replication topology easy: just CHANGE MASTER to any node and voilà. It doesn’t always work, but for the most part it does. That’s great, but it can hide a serious problem: missing writes. Even when MySQL GTID-based replication says, “OK, sure!”, which is most of the time, you should double check it.

I hated writing documentation before working on features. But after a while I realized I couldn't communicate well enough, even with folks I had a good connection with. It took me a number of mistaken deliveries to get the message.

Sketches and mockups

Designers solve this by producing low-fidelity sketches early on in the process, iterating on feedback to produce a high-fidelity mockup. I solve this by producing short RFC (request for comment) documents. This isn't an original idea, but I see it so rarely I wanted to share.

Now as soon as I begin thinking about a technical or organizational change, I write an RFC. My RFCs are typically a page or two long and typically take me 30-60 minutes for a good first draft. I make clear in the title that it is a proposal or draft. This allows me to make crazy suggestions without upsetting folks; a draft can be easily thrown away.

RFC process

My RFCs include three key sections:

1. What I think the problem is
2. Pros/cons of all the solutions I considered
3. Which solution I'm planning to go with if no one responds to the RFC

After I write the first draft I circulate it among a small group of peers I respect, my boss, etc. I request feedback at leisure and I check in every few days with a reminder. If no one responds after a while and there is little concern, I typically move forward with the proposed solution.

In addition to clarifying intent up front, this removes the need to schedule a meeting to discuss a problem. Discussion and decisions can be held asynchronously. I only schedule a meeting if there is disagreement that is unable to be resolved in writing.

After incorporating feedback, I either throw away the RFC and move on or feel reasonably confident about the proposal. I send it out to a wider group of relevant participants. Final meetings are held as needed.

The other option

In contrast, synchronous-first and undocumented proposals make some sense when you've got a small team in the same timezone with a similar schedule. Otherwise, you repeatedly reschedule meetings to accommodate everyone. You spend your first few meetings simply coming to understand and agree on the problem.

Spending 30-60 minutes to draft a proposal is almost always easier. It makes the decision-making process faster and produces more accurate results.

Spending 30-60 minutes to draft a technical (or organizational) proposal is almost always easier for discussion and action than just scheduling a meeting. Or "my asynchronous-first manifesto"https://t.co/gm4SUzBD2W

— Phil Eaton (@phil_eaton) May 16, 2020