undefined | Better HN

0 pointsecf5y ago0 comments

I recently started a side project on top of Postgraphile and I had to end up scrapping it in favor of something I was more familiar with.

The biggest problem is that unless the main language you’re familiar with is PL/pgSQL, you’ll eventually run into the roadblock that is having everything reside in the DB.

In my case, I simply could not figure out how to use the Users table without having the password returned in all queries. I could turn off the automatically generated queries that Postgraphile made, but at that point why bother with it?

Other problems are that there isn’t a mature and well established method of maintaining development, staging, and production database schemas on projects with more than one developer.

Graphile makes https://github.com/graphile/migrate, however, it seems incredibly brittle and is built on a workflow that will absolutely break production if it is slightly deviated from.

I really liked using it! I just hope some of these developer ergonomics issues could be better handled.

0 comments

lukeramsden5y ago

> In my case, I simply could not figure out how to use the Users table without having the password returned in all queries

The recommended way of doing this is to store anything you don't want public in a separate table with a one-to-one relationship, and then controlling access to that table through computed columns and such (https://www.graphile.org/postgraphile/postgresql-schema-desi...)

What I can't recommend enough to people starting with Postgraphile is to check out graphile-starter, and especially it's first migration: https://github.com/graphile/starter/blob/main/%40app/db/migr...

That really helped me to understand better how to structure my schema, as separation of concerns within a model by using different tables is not something that is necessary when doing a regular application-in-front-of-datastore type app.

> Other problems are that there isn’t a mature and well established method of maintaining development, staging, and production database schemas on projects with more than one developer.

Yes, I don't have to grapple with this issue so I don't really have much to say about this. Graphile-migrate works great for me, but I can see how it could be an issue for larger projects, although I would think that database migrations are simply tricky on their own, regardless of Postgraphile.

ecfOP5y ago

You’re completely right about the starter and I feel if I had discovered it first instead of trying to roll my own migration system with Knex and stuff, I would have stuck with Postgraphile.

But instead of rebasing my project with the starter I decided to go back to what I was comfortable with and do a Rails gql api.

I’ll definitely be trying it out in the future though! I felt so incredibly productive with rolling stuff out before auth became a concern.

lukeramsden5y ago

Yes it's been incredibly quick for me to iterate and build my current project. You are still right about migrations though, I'm not sure how that would work in a bigger team with feature PRs etc.

brycelarkin5y ago

Also, you’d want to put the passwords/secrets table in a separate schema from the one you’re exposing postgraphile to

j / k navigate · click thread line to collapse

0 pointsecf5y ago0 comments

I recently started a side project on top of Postgraphile and I had to end up scrapping it in favor of something I was more familiar with.

The biggest problem is that unless the main language you’re familiar with is PL/pgSQL, you’ll eventually run into the roadblock that is having everything reside in the DB.

Other problems are that there isn’t a mature and well established method of maintaining development, staging, and production database schemas on projects with more than one developer.

Graphile makes https://github.com/graphile/migrate, however, it seems incredibly brittle and is built on a workflow that will absolutely break production if it is slightly deviated from.

I really liked using it! I just hope some of these developer ergonomics issues could be better handled.

0 comments

lukeramsden5y ago

> In my case, I simply could not figure out how to use the Users table without having the password returned in all queries

> Other problems are that there isn’t a mature and well established method of maintaining development, staging, and production database schemas on projects with more than one developer.

ecfOP5y ago

You’re completely right about the starter and I feel if I had discovered it first instead of trying to roll my own migration system with Knex and stuff, I would have stuck with Postgraphile.

But instead of rebasing my project with the starter I decided to go back to what I was comfortable with and do a Rails gql api.

I’ll definitely be trying it out in the future though! I felt so incredibly productive with rolling stuff out before auth became a concern.

lukeramsden5y ago

Yes it's been incredibly quick for me to iterate and build my current project. You are still right about migrations though, I'm not sure how that would work in a bigger team with feature PRs etc.

brycelarkin5y ago

Also, you’d want to put the passwords/secrets table in a separate schema from the one you’re exposing postgraphile to

j / k navigate · click thread line to collapse