Comment by eatonphil | Hacker News Reader

Comment by eatonphil | Hacker News Reader

I've got a similar project that reads your db schema and generates a Go REST API and a TypeScript/React web interface. (The code-generation is language agnostic so at some point I'd like to add at least a Java REST API as well.) It supports PostgreSQL, MySQL, and SQLite.

Unlike PostgREST/Hasura and some other dynamic tools you can "eject" at this point if you'd like and continue on development without the generator in a language you already know. But I'm working on exposing Lua-based hooks you could carry across whatever backend language you choose to generate and avoid the need to eject.

It has builtin support for paginated bulk GET requests with filtering, sorting, limiting. Built-in support for bcrypt-password authentication and optional SQL filters specified in configuration for authorization of particular endpoints based on session and request metadata.

Still very much a work in progress but the goal is to push the envelope on application boilerplate.

Screenshots are of the example/notes project in the repo.

https://www.dbcore.org/

https://github.com/eatonphil/dbcore

I feel like projects like this work for simple stuff but as soon as you need analytics/insights or actual business logic, you almost always need to just "roll your own" API. Am I wrong? Do other people feel this way? Can anybody think of a few projects they've worked on that would be too complex/a ton of work to make work with these kind of simple template generators?

Long-term maintainability is definitely my concern. I don't see projects like this so much as products themselves (maybe I'm myopic) but as core infrastructure. I don't want to ever write the boilerplate again, but I should be able to extend it maintainably over time (hence ejecting or Lua hooks).

My goal in building this is to allow myself to more rapidly prototype real, complex applications. It's not there yet but I've got such an application in mind, building toward support for it as I'm developing this.

I think on average you're right. As the project grows, these generators lose some of their initial value and speed.

If I were to use something like this, it'd be for rapid development initially for prototyping purposes. Then I'd transition to something more bespoke as needed.

If you know all your requirements up front, then starting bespoke from the beginning may be the better route.

Postgraphile allows you to write plugins to arbitrarily extend (GraphQL) schema and wrap resolvers, which is useful for things like interfacing with external APIs etc. It works just fine for me at my current project.

DreamFactory is basically a paid service for this sort of thing. They support something like 20 types of databases (among many other data sources). They have a lot of features that make the exposed api be good enough long-term. https://www.dreamfactory.com

It seems like when working with generators, the trick is to have the right boundaries between generated code, points where you can extend the generated code, and the API through which you use the generated code. If successful, you should never feel the need to hand edit the generated code itself, and you shouldn't need to worry too much about re-running the generator breaking things or stomping on your code.

>> you shouldn't need to worry too much about re-running the generator breaking things or stomping on your code.

Can't agree more! There are code parsers which give out a DOM and then code can be manipulated. But is a bit of work. We are trying this concept in our framework.

The sweet spot for things like this is for them to generate the sort of code you'd want anyway, in a way which allows you to selectively replace bits where you need additional business logic or UI customisation.

Rails' generators are a pretty good starting point here, if a little bit more verbose than I'd like. They're great for getting the boilerplatey bits off the ground, and focusing on the bits that are unique to what you're doing.

I’m using Prisma right now and they allow you to manually expose your fields, and they allow you to “resolve” any field as you see fit. If you want to run the original function, you can provide “originalResolve” and call it later. I think Prisma has a great (albeit in progress) way of doing what you’re saying.

It also integrates with graphql-codegen so you can generate code for apollo/others

With postgrest you can add stored procedures as rest rpc calls, and you can always roll a microservice for more advanced stuff. In practice these sorts of auto-api tools make a good starting point as long as they support your authentication and authorization needs.

What I like about postgREST is you’re leveraging a mature system for authorization (postgresql roles) rather than rolling your own outside the database and introducing a ton of code and vulnerabilities.

Not every application needs roles though, but it definitely feels like the saner approach if you do.

Also a nice side effect, depending on the team, is a significant performance boost as your forced to go deep in database land instead of leaky ORM abstractions.

Ya, I have very few tables in my db that can be updated directly without needing to pass the data through some business logic, trigger notifications, etc

Used PostgRest once. We had a project with datasets for sale where all the data was stored in a database and didn't need any updates or transactions. Postgrest was easy to create a self-contained API.

https://github.com/PostgREST/postgrest

This is not dis-similar to what Strapi.io does, although I don't think they realize that's a big selling point from their marketing materials.

With strapi you configure your DB and get code generated in JS that supports a standard CRUD REST API. If you want to add business logic, you can override any particular endpoint you want. Their docs even come with the default implementation for easy copy/paste.

I would love to see research in this space continue, I think it's the future of bringing non-technical people into the product development process (if you can understand building a workflow with Excel/Google Sheets/Airtable, you can understand building an API). I'm excited to check out your project.

My thoughts exactly as I’ve been exploring strapi for a recent project.

The UI allows for build out the schema, and has all the CRUD interfaces pre-built and the CRUD api endpoints.

But then the code is still all there and you can add additional controllers actions, model hooks and services.

I haven’t run into any hard limitations yet, been very impressed.

In case anyone else is wondering what's doing the templating in this project, it's Scriban.

https://github.com/lunet-io/scriban

A port of Ruby's liquid templates to .NET, yep.

Reply on news.ycombinator.com