4 ms·
Anyone from the GraphQL camp care to weigh in against this argument?
by lsorber 8y ago
Anyone from the GraphQL camp care to weigh in against this argument?
- tzahola 8y agoIf 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.
- steve-chavez 8y agoThe 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 https://postgrest.org/en/v5.0/api.html#stored-procedures for more details.
- tzahola 8y agoI 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.
- steve-chavez 8y agoYou can treat SQL code as any other code and version your schema with git. Migrations can be handled with https://sqitch.org https://sqitch.org, and you can also reduce some of the work with https://www.apgdiff.com 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.