HN Explorer

Ask HN: Entire API and DB generator from model definition

2 points by dpix ↗ HN
I've recently got back into some backend development after being more front end focused for sometime. At the current company I am at they are quite invested in using JSONAPI spec (which I actually think is great) for their microservice APIs. I've realised that a lot of these APIs simply become REST interfaces over the database with resources mapping 1:1 with the db models.

Our current process for building these out is to build a swagger definition with a mock service backend in js to unblock upstream clients like web and mobile. From there we go an implement the real API in python/flask with postgres.

It got me thinking that probably 80-90% of all the code written for the real API is boilerplate setting up models, db migrations, routes, controllers, authentication etc.

I am imagining that a fair bit of this could be automated, all you really need is a modal definition, and you could generate all of the above, abstracting all that away from the engineer. Providing hooks for inserts and updates would allow for custom business logic to slot in, and would be all the real code engineers would need to write.

What else am I missing that backend developers would want from a framework (or managed service) like this?

5 comments

[ 4.5 ms ] story [ 25.3 ms ] thread
xq3000
I would say that’s a valid insight and most Line Of business (LOB) apps can (and really should) be produced that way.

However, this approach usually doesn’t work for more “system” level products.

Check out Model-Driven Architecture [1]. Most likely you’ll be able to configure an MDA toolchain to generate the code you want

[1] MDA https://en.wikipedia.org/wiki/Model-driven_architecture

dpix
Thanks for the link!

What do you mean by "system" level products?

I would envision this would make sense for microservice style APIs, not so much for client/product facing interfaces like an API tied to a web front end

xq3000
I just meant something with a lower level of programming than business apps.

Usually, the frameworks themselves, “servers,” “engines,” and “drivers” would not be easy to generate with the MDA approach. I imagine, apps and games with highly customized UI/UX would not be a good fit either.

MDA is for “boring” business apps where you would want all your screens look the same unified way. That’s where MDA shines, cuts down coding and QA effort, and allows producing massive products with many hundreds of tables and screens.

dpix
Agreed, I see this as a good fit for micro service APIs where the consumers are just other parts of a larger system. APIs for front end or consumer facing applications would likely not fit this model so well