Hacker News Reader

Comment by lsorber | Hacker News Reader

Anyone from the GraphQL camp care to weigh in against this argument?

If your endpoints are backed 100% by a db, then you can get by with the postgrest approach.

However GraphQL resolvers can do much more beyond a simple DB query. E.g. you can call other services and combine their reponses. Or calculate the n-th digit of Pi. Or whatever you want to do.

The DB can do much more than simple queries, you can use stored procedures for any custom business logic, you can even use PL/Python in them.

See https://postgrest.org/en/v5.0/api.html#stored-procedures for more details.

I know, but stored procedures are a PITA in general. Last time I’ve checked there was no widespread standard way of version control for stored procedures, other than DROP PROCEDURE followed by CREATE PROCEDURE, which makes blue/green deloyment impossible/awkward.

You can treat SQL code as any other code and version your schema with git. Migrations can be handled with https://sqitch.org, and you can also reduce some of the work with https://www.apgdiff.com that will generate CREATE OR REPLACE function statements for you.

Also have to mention that when using PostgREST we encourage you to decouple your data schema(where your tables are) from your api schema(only views, stored procedures, computed columns), that way you can version your schemas(having "v1" schema, "v2", etc) and prevent breaking changes.

Reply on news.ycombinator.com