Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Octo – Generate a serverless API from an SQL query

octoproject.github.io

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Show HN: Octo – Generate a serverless API from an SQL query

#51

Post by eatonphil »

jdc wrote: post #50
eatonphil wrote: post #9

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 i…

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.

Re: Show HN: Octo – Generate a serverless API from an SQL query

#52

Post by awb »

lukeramsden wrote: post #29
awb wrote: post #22

Earlier quoted context omitted.

I tied this "no backend" approach but ended up writing all of my business logic in the DB schema instead of in the app, which seemed to defeat the purpose.

Well if your application has business logic at all you're going to have to write business logic at some point, and I personally like the idea of keeping as much of it co-located with the data - it makes your schema the SSOT for your data structure and it's constraints and transformations. The complication is as always external services, like sending email, validating IAP receipts, things like that. For that I liked t…

Agreed, I really liked having everything so close and tightly coupled with the DB. The integrations and business logic were the part I had to build traditionally and at that point it wasn't much more to query the DB from the backend rather than trying to learn how to script inside Postgres.

Re: Show HN: Octo – Generate a serverless API from an SQL query

#53

Post by RileyJames »

henryfjordan wrote: post #47
eatonphil wrote: post #9

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 i…

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 t…

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.

Re: Show HN: Octo – Generate a serverless API from an SQL query

#54

Post by jjeaff »

MuffinFlavored wrote: post #17
eatonphil wrote: post #9

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 i…

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?

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

Re: Show HN: Octo – Generate a serverless API from an SQL query

#55

Post by hn_throwaway_99 »

I fear that all of these "expose your DB as an API" tools like this, Postgraphile, Hasura, etc. are going to set up folks for a world of hurt down the road. Tightly coupling your end clients to your database schema can make it extremely difficult, if not impossible, to refactor your DB in you need to (which is highly likely).

Re: Show HN: Octo – Generate a serverless API from an SQL query

#57

Post by brycelarkin »

hn_throwaway_99 wrote: post #55

I fear that all of these "expose your DB as an API" tools like this, Postgraphile, Hasura, etc. are going to set up folks for a world of hurt down the road. Tightly coupling your end clients to your database schema can make it extremely difficult, if not impossible, to refactor your DB in you need to (which is highly likely).

I’m building a project using one of those tools. I imagine that difficulty refactoring your database is more a problem of bad schema design than the tool. If you normalize and abstract out the implementation details into Views, I can’t see how refactoring would be difficult. Haven’t built anything at scale with Postgraphile/Harusa, so just wondering if I’m missing anything here.

Re: Show HN: Octo – Generate a serverless API from an SQL query

#58

Post by brycelarkin »

lukeramsden wrote: post #36
ecf wrote: post #34

Earlier quoted context omitted.

I recently started a side project on top of Postgraphile and I had to end up scrapping it in favor of something I was more familiar with. The biggest problem is that unless the main language you’re familiar with is PL/pgSQL, you’ll eventually run into the roadblock that is having everything reside in the DB. In my case, I simply could not figure out how to use the Users table without having the password returned in a…

> In my case, I simply could not figure out how to use the Users table without having the password returned in all queries The recommended way of doing this is to store anything you don't want public in a separate table with a one-to-one relationship, and then controlling access to that table through computed columns and such ( https://www.graphile.org/postgraphile/postgresql-schema-desi... ) What I can't recommend e…

Also, you’d want to put the passwords/secrets table in a separate schema from the one you’re exposing postgraphile to

Re: Show HN: Octo – Generate a serverless API from an SQL query

#59

Post by manigandham »

MuffinFlavored wrote: post #17
eatonphil wrote: post #9

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 i…

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?

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

Re: Show HN: Octo – Generate a serverless API from an SQL query

#60

Post by TylerE »

hn_throwaway_99 wrote: post #55

I fear that all of these "expose your DB as an API" tools like this, Postgraphile, Hasura, etc. are going to set up folks for a world of hurt down the road. Tightly coupling your end clients to your database schema can make it extremely difficult, if not impossible, to refactor your DB in you need to (which is highly likely).

Views make it trivial to decouple what a query returns from the underlying schema
Post reply on HN