3 ms·

To what extent does this headache go away if autogenerating graphql from a relational db, using tools like Postgraphile or Hasura? I never considered making my

To what extent does this headache go away if autogenerating graphql from a relational db, using tools like Postgraphile or Hasura? I never considered making my "own" graphql service but those tools sure make it look easy to create a nice API controller through db migrations.

sebmellen 4y ago
We have had a wonderful experience with https://prisma.io https://prisma.io
- o_m 4y ago
  Prisma only queries your own database. A GraphQL API could talk to many services and give the consumer one endpoint which all of this can be queried.
  - sebmellen 4y ago
    About 90% of our GraphQL API passes through Prisma. We have a master API that talks to many different microservices to process data and so-on, but all the data ultimately ends up residing in our Postgres DB. One of the nice things about Prisma is that it gives you a very declarative way to manage your data, and encourages using your DB as your "single source of truth". Querying everything through one API (which relays requests to other microservices, if necessary) and having one Postgres DB which acts as the "endpoint" for all of our data is a very clean model. For edge cases, it's also possible to write custom resolvers. Prisma doesn't prohibit that.
    - alisonatwork 4y ago
      Philosophically, is it really a "microservice" if it doesn't have its own database? In my opinion, if multiple services are ultimately all connecting to and storing their data in the same database, then you haven't really gained very much, since one misbehaving client can still take down everyone else's service. The point of microservices was always sold to me as "every team owns their own stack", and specifically if one team's stack goes down, everyone else can cheerfully continue. (Or less cheerfully, if the team whose stack went down was identity or user service.)
- claytonjy 4y ago
  Do you worry about over-coupling when using Prisma? I'm hesitant to let front-end control the schema in any scenario where they're not the only users of that DB. Works great until it doesn't and can be a pain to migrate control to a backend/API team.
  - RedShift1 4y ago
    But that's true for any solution. This goes back to "avoid db server specific SQL", you gain the portability advantage but you're willingly giving up advanced features the db server has. How far do you want to take this to be "independent"?
    - claytonjy 4y ago
      I'm not concerned with independence from the database _implementation_ but independence of the database schema from any one consumer. This is one of the more interesting things about tools like Hasura/Postgres/Postgraphile in my eyes, they encourage you to separate frontends from the backend early on. That might be one team to start, but you can divide labor and add more services without rearchitecting like you would if the database was controlled by ORM from a single front end.
  - sebmellen 4y ago
    Our Prisma schema resides in our "backend" (Prisma essentially governs our master API). So I'm not sure why you're concerned that the front-end might control the schema. The nicest thing about Prisma is that it is a declarative single-source-of-truth for our data models. Everything resides in one schema, all changes to database models and all migrations run through Prisma, and, best of all, strong types are inherently built in. The team is also building useful middleware like field-level encryption; all of this together makes Prisma a very complete package. Of course, there is a price for this convenience — we sacrifice some higher-level DB-side features. But Prisma is such a competent tool that we don't miss them much.

sebmellen 4y ago

We have had a wonderful experience with https://prisma.io https://prisma.io

o_m 4y ago
Prisma only queries your own database. A GraphQL API could talk to many services and give the consumer one endpoint which all of this can be queried.
- sebmellen 4y ago
  About 90% of our GraphQL API passes through Prisma. We have a master API that talks to many different microservices to process data and so-on, but all the data ultimately ends up residing in our Postgres DB. One of the nice things about Prisma is that it gives you a very declarative way to manage your data, and encourages using your DB as your "single source of truth". Querying everything through one API (which relays requests to other microservices, if necessary) and having one Postgres DB which acts as the "endpoint" for all of our data is a very clean model. For edge cases, it's also possible to write custom resolvers. Prisma doesn't prohibit that.
  - alisonatwork 4y ago
    Philosophically, is it really a "microservice" if it doesn't have its own database? In my opinion, if multiple services are ultimately all connecting to and storing their data in the same database, then you haven't really gained very much, since one misbehaving client can still take down everyone else's service. The point of microservices was always sold to me as "every team owns their own stack", and specifically if one team's stack goes down, everyone else can cheerfully continue. (Or less cheerfully, if the team whose stack went down was identity or user service.)
claytonjy 4y ago
Do you worry about over-coupling when using Prisma? I'm hesitant to let front-end control the schema in any scenario where they're not the only users of that DB. Works great until it doesn't and can be a pain to migrate control to a backend/API team.
- RedShift1 4y ago
  But that's true for any solution. This goes back to "avoid db server specific SQL", you gain the portability advantage but you're willingly giving up advanced features the db server has. How far do you want to take this to be "independent"?
  - claytonjy 4y ago
    I'm not concerned with independence from the database _implementation_ but independence of the database schema from any one consumer. This is one of the more interesting things about tools like Hasura/Postgres/Postgraphile in my eyes, they encourage you to separate frontends from the backend early on. That might be one team to start, but you can divide labor and add more services without rearchitecting like you would if the database was controlled by ORM from a single front end.
- sebmellen 4y ago
  Our Prisma schema resides in our "backend" (Prisma essentially governs our master API). So I'm not sure why you're concerned that the front-end might control the schema. The nicest thing about Prisma is that it is a declarative single-source-of-truth for our data models. Everything resides in one schema, all changes to database models and all migrations run through Prisma, and, best of all, strong types are inherently built in. The team is also building useful middleware like field-level encryption; all of this together makes Prisma a very complete package. Of course, there is a price for this convenience — we sacrifice some higher-level DB-side features. But Prisma is such a competent tool that we don't miss them much.