calebmer
commented
7 years ago When I first saw this issue I left it alone because I wanted to give other people a chance to comment, but that meant I just ended up forgetting about it 😣
I don’t have much experience with a Rails or Django which might make me a little less qualified to answer, but I at least want to get the discussion going. The largest frameworks I’ve worked with in my career extensively are Wordpress and Meteor 😊
I’m going to go on some tangents on some of the more interesting bits I see in your question.
Mostly I'm interested in hearing about others' experiences with moving away from a framework like Rails or Django, to a Postgres/PostGraphQL approach.
Again, not a lot of experience here, but I’ll share my process anyway. I jumped onto the Postgres forever bandwagon pretty early with PostgREST. At that time I was migrating a client project from Meteor to a standard REST API and Node.js setup. I gained a lot of time by adopting PostgREST instead of writing my own REST API, but I ended up loosing some of that time by bikeshedding and contributing back to PostgREST (which I do not regret!).
What’s really interesting to me about open source approaches like PostgREST and PostGraphQL is that they effectively allow you to avoid building out an API and defer that task to other “team members” where those team members are distributed and open source contributors. Of course the same can be said about a Rails or Django, but the interpersonal relationships that evolve from a growing project make are way more personal and valuable providing your project with a team of experts that you don’t have to pay, but you still know closely 😊
So for me one of the cool thing about the Postg* suite is really the community in a way I don’t think the large communities of a Rails or Django could provide.
I’d love to hear @benjie’s thoughts on this.
I also want to cc @begriffs and @ruslantalpa who I worked with on PostgREST who may have some good comments on this topic.
How was it not having an ORM on the backend?
In my opinion, SQL, and specifically Postgres’s flavor of SQL is the most powerful ORM you could have 😄
There are no limitations, there are no unnecessary abstractions, there is no missing documentation or engrained community knowledge, there is just the raw expressive power of SQL and in some cases pl/pgSQL.
To be fair, I’ve never really worked with a good ORM besides brushing up against knex and sequelize in my contracting travels. At this point (probably as a result of working with PostgREST/PostGraphQL) I much prefer just writing SQL queries directly. I’ve even adapted one of the modules in PostGraphQL into its own npm package to allow myself to use raw SQL efficiently outside of PostGraphQL. See pg-sql.
What were the pain points?
Auth and in general extension of database logic are two pain points that definitely need to be worked on. PostGraphQL is amazing at all things CRUD, and if you have basic ACL needs then PostGraphQL tools is amazing at that too. Once your auth gets really complicated, or you need to make some requests against an external API, then things start to get a little difficult.
However, there is no reason why these things should be difficult! PostGraphQL specifically is written in JavaScript and as a result of that is theoretically incredibly flexible and extensible. The current codebase was even written with the intention of being flexible and extensible (see “My vision for the future of PostGraphQL”). There is no reason why we shouldn’t be totally extensible.
My hunch is, though, that when people hit a problem where they need some extensibility from PostGraphQL they chock it up to a limitation of the platform instead of looking to expose some internal hooks that already exist.
So the main pain points are that a lot of potential is locked up in the minds of core contributors and so it’s hard to know where to start when you need to extend your API.
I do want to add, however, that I think you can go a very long way with PostGraphQL as it is today. You could probably build an early Facebook, Twitter, AirBnB, and so on with PostGraphQL (getting it to scale would require some work, but we have some excellent PRs open aiming to do just that: https://github.com/calebmer/postgraphql/pull/342).
Were there any resources you found particularly useful?
Whenever you need something search in Google: “Postgres x” and the documentation should be the first result with a super in-depth explanation of everything you need to know.
If you want to be a real master then read the entire Postgres documentation. It may take you two weekends, but I promise it won’t be a boring read. There is a lot of really good stuff in there (I haven’t done it myself, but I’ve definitely thought about it multiple times). This isn’t my idea, this is an idea from Nick Gauthier, founder of MeetSpace, in episode 214 of the Giant Robots Smashing Into Other Giant Robots podcast (It might actually be episode 217 or episode 215, I can’t remember. All three episodes are very good though).
I'm not sure how to deal with in Postgres like project structure
Check out this issue for some ideas: https://github.com/calebmer/postgraphql/issues/235. @valorize shares his really cool approach here: https://github.com/calebmer/postgraphql/issues/235#issuecomment-283927883
I personally really like Sqitch, but there’s a lot of manual stuff that goes into that.
Project structure for large Postgres databases is an excellent space to build a successful open source project (I think). PostGraphQL users would definitely appreciate such a project 😊
benjie
shayneoneill
The vast majority of my web development experience thus far has been through Django, where I've become used to the highly opinionated nature of it. Our main stack has been Django, the excellent Django REST framework, Postgres, and React / React Native on the frontend.
I'm very interested in GraphQL, and I'd love to give it a try, but as I go through the tutorial (which is excellent btw) I'm realizing that transitioning to a Postgres + PostGraphQL backend is going to be harder than I realized. There's just a lot of things that I automatically get from a big framework that I'm not sure how to deal with in Postgres like project structure, data migrations, versioning, form validation, verification emails, etc.
Mostly I'm interested in hearing about others' experiences with moving away from a framework like Rails or Django, to a Postgres/PostGraphQL approach. Aside from obvious advantages gained on the frontend by using GraphQL, how was it not having an ORM on the backend? What were the pain points? Were there any resources you found particularly useful?
I realize this is pretty specific, but any discussion on this topic would be great to see 😄