4 ms·

I've been working on GraphQL services since 2015. I worked on the design of the precursor to postgraphile; it was called postgraphql. Hadn't heard of Hasura bef

I've been working on GraphQL services since 2015. I worked on the design of the precursor to postgraphile; it was called postgraphql. Hadn't heard of Hasura before today, but it looks interesting. The primary complaints I hear from others about GraphQL are observability and the learning curve for devs who are new to it. I think these projects add a lot of value with tools like the GraphQL playground (similar to GraphiQL but better), middleware extensibility for observation/analytics, their documentation, and most importantly the starter/boilerplate projects. IMO, the preferred option today is Prisma. They have a non-production-ready v2 that is available for testing. But even v1 is good for an enterprise product; and they're working on migration/codemod to get onto v2 when it's ready. But the other big piece of the puzzle is deciding on a GraphQL client. It seems like most choose Apollo + Redux, but Relay is, without a doubt in my mind, the better library/framework for consuming GraphQL in the frontend. Facebook designed React, Relay, and GraphQL to work together really nicely. Relay takes some re-learning to think about frontend data dependencies and caching, but it's really well designed. I think GraphQL on its own has value as a centralized contract between frontend and backend services, and is a nice query and mutation language; but without Relay I don't think you get the full benefits of all the hard work that goes into the GraphQL service design. And teams/organizations that end up with Apollo/Redux designs suffer from complexities around cache management that Relay does a better job of reducing.

awb 7y ago
Curious if you were active on the precursor to postgraphile why you feel Prisma is a better option. It's been my experience as well, but would love to hear what the deciding factors were for you.
- rojobuffalo 7y ago
  Postgraphile is more open-ended and advanced, which could be better for some cases. I really like it and enjoy writing the PostgreSQL directly. Prisma compresses the domain a little more than Postgraphile, which means its a little simpler. The Prisma datamodel very closely mirrors the GraphQL schema. It has just a bare minimum variance to allow different data types (and maybe something else I'm forgetting). I think the generated GraphQL for the database client ends up being simpler and easier to debug; but that's just my feeling about it. The Prisma database admin tool at `host:port/_admin` is nice; and compliments the GraphQL Playground really well. Prisma develops GraphQL Playground as an open-source project, inspired by GraphiQL which comes out-of-the-box with graphql-server.
brillout 7y ago
Curious to know what you think of the React + RPC (e.g. https://github.com/reframejs/wildcard-api https://github.com/reframejs/wildcard-api) + PostgreSQL stack in comparison to React + Relay + GraphQL + PostgreSQL? RPC tightly couples frontend and backend. Decoupling is usually only needed for (very) large applications; while getting there you migrate from RPC to GraphQL.
- rojobuffalo 7y ago
  It looks like a nice library. It might be good as a learning tool. I'm not sure what kind of use-case I would want it for, maybe a small game? It looks similar to how I've done smaller/demo/mock-up APIs for frontend apps. I like the simplicity. I think if I was going to be deploying a real database (PostgreSQL), I'd want to do things with authorization and network configuration; at which point I'd be dealing with enough stuff around the user profile that I'd want my preferred query and mutation design (GraphQL + Relay). If at any point you're going to be fetching data containing long lists, I'd also prefer to be working with GraphQL and Relay because the design is well thought-out for doing filtering, pagination, and caching. Decoupling is good any time you want to allow different parts to change independently. Migrating architectures can take a significant amount of effort, but it just depends what you want to accomplish.
  - brillout 7y ago
    One way to think about Wildcard (and RPC in general) is that it allows you to directly use SQL queries to retrieve and mutate data for your frontend. That said, if you prefer using Relay + GraphQL over writing SQL queries, then Wildcard (and RPC) may not be the right tool for you. Although I'd worry about the complexity of your stack. Unnecessary complex stacks tend to be an evil time sink in the long run. Simplicity is key. RPC + PotgreSQL is fundamentally simpler than Relay + GraphQL + Hasura + PotgreSQL. The thing is that you need GraphQL only when you need to expose your data to third parties. GraphQL = generic API = thid-party devS. For consuming your database from your own frontend, you don't need GraphQL and RPC is enough and simpler. > Decoupling is good any time you want to allow different parts to change independently With Wildcard(/RPC) you deploy frontend and backend at the same time but you develop both independently. Migration is easy when you create a GraphQL API in parallel to your existing RPC API and progressively transition from your RPC API to your newly created GraphQL API. That said, chances are high that GraphQL will never be needed; only very large companies need GraphQL (the organization is so large that exposing an API to the whole organization is almost like exposing an API to the whole world). Basically devS of very large companies ~= third-party devS and you then need a generic API such as GraphQL.

awb 7y ago

Curious if you were active on the precursor to postgraphile why you feel Prisma is a better option. It's been my experience as well, but would love to hear what the deciding factors were for you.

rojobuffalo 7y ago
Postgraphile is more open-ended and advanced, which could be better for some cases. I really like it and enjoy writing the PostgreSQL directly. Prisma compresses the domain a little more than Postgraphile, which means its a little simpler. The Prisma datamodel very closely mirrors the GraphQL schema. It has just a bare minimum variance to allow different data types (and maybe something else I'm forgetting). I think the generated GraphQL for the database client ends up being simpler and easier to debug; but that's just my feeling about it. The Prisma database admin tool at `host:port/_admin` is nice; and compliments the GraphQL Playground really well. Prisma develops GraphQL Playground as an open-source project, inspired by GraphiQL which comes out-of-the-box with graphql-server.

brillout 7y ago

Curious to know what you think of the React + RPC (e.g. https://github.com/reframejs/wildcard-api https://github.com/reframejs/wildcard-api) + PostgreSQL stack in comparison to React + Relay + GraphQL + PostgreSQL? RPC tightly couples frontend and backend. Decoupling is usually only needed for (very) large applications; while getting there you migrate from RPC to GraphQL.

rojobuffalo 7y ago
It looks like a nice library. It might be good as a learning tool. I'm not sure what kind of use-case I would want it for, maybe a small game? It looks similar to how I've done smaller/demo/mock-up APIs for frontend apps. I like the simplicity. I think if I was going to be deploying a real database (PostgreSQL), I'd want to do things with authorization and network configuration; at which point I'd be dealing with enough stuff around the user profile that I'd want my preferred query and mutation design (GraphQL + Relay). If at any point you're going to be fetching data containing long lists, I'd also prefer to be working with GraphQL and Relay because the design is well thought-out for doing filtering, pagination, and caching. Decoupling is good any time you want to allow different parts to change independently. Migrating architectures can take a significant amount of effort, but it just depends what you want to accomplish.
- brillout 7y ago
  One way to think about Wildcard (and RPC in general) is that it allows you to directly use SQL queries to retrieve and mutate data for your frontend. That said, if you prefer using Relay + GraphQL over writing SQL queries, then Wildcard (and RPC) may not be the right tool for you. Although I'd worry about the complexity of your stack. Unnecessary complex stacks tend to be an evil time sink in the long run. Simplicity is key. RPC + PotgreSQL is fundamentally simpler than Relay + GraphQL + Hasura + PotgreSQL. The thing is that you need GraphQL only when you need to expose your data to third parties. GraphQL = generic API = thid-party devS. For consuming your database from your own frontend, you don't need GraphQL and RPC is enough and simpler. > Decoupling is good any time you want to allow different parts to change independently With Wildcard(/RPC) you deploy frontend and backend at the same time but you develop both independently. Migration is easy when you create a GraphQL API in parallel to your existing RPC API and progressively transition from your RPC API to your newly created GraphQL API. That said, chances are high that GraphQL will never be needed; only very large companies need GraphQL (the organization is so large that exposing an API to the whole organization is almost like exposing an API to the whole world). Basically devS of very large companies ~= third-party devS and you then need a generic API such as GraphQL.