11–20 of 199 posts
Disclaimer: I work on MongoDB Stitch This looks really cool and an improvement on Prisma! I particularly like the much less bloated schema experience (and the builder) along with the easy addition of actions. We've been working on something similar but it's great to see improvements in the UX of the space.
(And a way that doesn't require writing rollbacks, which sometimes aren't even possible anyway).
I often miss graphql features when working with rest APIs. But switching over seems very much not worth it when no one in the organisation knows graphql. I feel like graphql would be much easier to adopt of it just sticked to rest conventions as much as possible. Like have the query language be pure JSON. It should even be possible to design it so that you could make drop in replacements for most of existing rest API…
GraphQL is much easier to pickup and get productive than most people think, most of the times all you have to do is writing resolvers (functions) instead of http handlers (functions) On the client side is the same, following any getting started guide can explain 90% of what you need to know in a single day
I'm curious if anyone here has compared Postgraphile to Hasura? My personal difficulty in implementing these is that there aren't good source control and code organization tools for SQL and managing rollbacks and rollforwards in a sane way. (And a way that doesn't require writing rollbacks, which sometimes aren't even possible anyway).
Their migration tool is really nice; reminds me of Rails but better as you can write raw SQL.
https://github.com/hasura/graphql-engine/tree/master/scripts...
While I like and enjoy many aspects of code generation such as this or Prisma, In real world scenario it just doesn’t feel right. Imagine a very simple scenario, you want to add some validation based on business requirements, in order to do that you have to have a server with custom endpoints or a custom graphql server (thus copy most of what hasura generates) to implement your own validation The only situation in wh…
Often times that’s not needed if you actually use the full power of PG. CHECK constraints go a long way, and where they don‘t go, PG/PSQL goes pretty much a long way. For internal or prototypical use cases, that can be totally sufficient, however you‘re right that you‘ll eventually want good error messages, observability and much more other custom logic. What I‘m still searching for is something that works like Hasur…
Both Hasura and Postgraphile also support schema stitching from what I know, so you should be able to extend it that way also (more complicated obviously)
Earlier quoted context omitted.
GraphQL is much easier to pickup and get productive than most people think, most of the times all you have to do is writing resolvers (functions) instead of http handlers (functions) On the client side is the same, following any getting started guide can explain 90% of what you need to know in a single day
Client side GraphQL is harder than REST, though I wouldn’t define it hard in general. Whereas with REST one only needs to update the data model for the response, GraphQL also requires that the request itself is also updated. It gets more complex if the client wants to take advantage of hashed queries and now there’s all this work needed to upload the queries to some backend service. This is from my own experience — I…
Hasura is a game-changer. I'm never writing CRUD backend apps again by hand. Combine Hasura (automatic GraphQL on top of PostgreSQL) with React Admin (low code CRUD apps) and you can build an entire back office admin suite or form app (API endpoints and admin front end) in a matter of hours. This adaptor connects react-admin with Hasura: https://github.com/Steams/ra-data-hasura-graphql Here's a reference application…
While I like and enjoy many aspects of code generation such as this or Prisma, In real world scenario it just doesn’t feel right. Imagine a very simple scenario, you want to add some validation based on business requirements, in order to do that you have to have a server with custom endpoints or a custom graphql server (thus copy most of what hasura generates) to implement your own validation The only situation in wh…
Writes (mutations) are delegated to a REST endpoint, the GraphQL mutation response can be synchronously (blocking mutation) or asynchronously consumed (mutation + subscription).
I'm curious if anyone here has compared Postgraphile to Hasura? My personal difficulty in implementing these is that there aren't good source control and code organization tools for SQL and managing rollbacks and rollforwards in a sane way. (And a way that doesn't require writing rollbacks, which sometimes aren't even possible anyway).
https://hasura.io/docs/1.0/graphql/manual/migrations/index.h... Their migration tool is really nice; reminds me of Rails but better as you can write raw SQL. https://github.com/hasura/graphql-engine/tree/master/scripts...
While I like and enjoy many aspects of code generation such as this or Prisma, In real world scenario it just doesn’t feel right. Imagine a very simple scenario, you want to add some validation based on business requirements, in order to do that you have to have a server with custom endpoints or a custom graphql server (thus copy most of what hasura generates) to implement your own validation The only situation in wh…
On that last bit, we recently added actions: https://hasura.io/blog/introducing-actions/ Writes (mutations) are delegated to a REST endpoint, the GraphQL mutation response can be synchronously (blocking mutation) or asynchronously consumed (mutation + subscription).
Will give it a try, thanks