feat(postgraphql): Provide mechanism to add data to resolver context #601
Conversation
benjie
force-pushed
the
additionalGraphqlContext
branch
from
88880a5
to
cbed122
Compare
|
Changed the head to |
|
Thanks again for this, I'm now using it in one of my projects 👍 |
|
No problem, we're actually moving slowly away from postgraphile now, turns out our simple little back end is turning into a horrible Goliath. But i use it for my projects now 👍 it does so much so fast |
|
I'd be interested to hear more about this if you've time to jot down some rough thoughts in an email. Are you moving from logic in the database, or keeping that and moving to a simpler custom GraphQL schema? Have you considered using PostGraphQL behind another GraphQL schema generated with something like graphql-weaver? |
|
Yeah we've got the postgraphile running against our postgres instance, and using apollo-tools to join that with a hand written schema + resolvers for other fields we want more control over. We're losing some more of that now as we're actually making a complex DB structure that has a recursion in it, which means graphql can't really handle it as there's no concept of infinite depth recursion (understandably). So we're going custom for that too. TBH our team wasn't comfortable putting too much logic into the DB, so that's where we break with philosophy and limit what we achieve with postgraphile, so it's not a limitation in postgraphile, just limits we placed on it ourselves 👍 |
|
Yeah; as you say the indefinite recursion is a limitation of GraphQL itself... You could potentially work around that by using a recursive CTE and generating a I think there's a lot of resistance about putting logic in the database just because it's not been the way that we're used to building things in web-dev, but with todays microservices/etc putting all the business logic in the most central location makes a lot of sense as it effectively prevents anything from bypassing it or corrupting the data. I heard someone the other day say "only using a ORDBMS to store data is like only using a car to store petrol" - I feel there's an amount of truth to that, but if you're using constraints, foreign keys, indexes, triggers and views you're still reaping a lot of the benefits even if you don't use it for access control, business logic, computed columns, etc. |
|
I think we're looking at the JSON solution so you still obtain the graph through graphql, but requesting a certain field just returns a JSON blob. We'd been toying with putting the JSON in the db too, but that didn't sit well either. This is all very much in flux though! Thanks for the CTE link, i'm still learning postgres, that will definitely come in handy when I want this data back... RE: the resistance to moving logic to the DB, one simple problem we have is the competence of the team, we're all JS devs and postgres although simple, is still not something we feel confident to do anything complicated with yet. We also had some discussion around the microservices idea, we'll be a monolith for the foreseeable future, but when splitting to micro services we would probably never have two services hitting the same DB, so there'd be no sharing there. Not sure if you have a use-case in mind where you'd have that? |
Postgres' JSONB handling is pretty 👌 but no doubt you've factored that in when evaluating it.
That's fair enough - generally a good idea to make things in technologies where you already know the caveats!
The sharing of Postgres between multiple microservices? Might be for example if a job worker needs to access the same database as the web clients (to see the tasks they have queued); or if there's additional gateways into the same data (e.g. an SMTP or chat gateway) that requires similar permissions checks - having these go through the existing web API could be a performance bottleneck and would also add to latency. That said, there's a lot more scaling options this way so it definitely makes sense in some contexts! As with everything, it depends on the needs of your stack. |
…raphile#601) * feat(postgraphql): provide mechanism to add data to resolver context * Convert additional context method to a promise and conform to naming convention * Combine destructuring
Add an optional parameter called
additionalGraphqlContextFromRequestto the options object supplied to the postgraphile middleware hereThis should be provided an async function which resolves to an object. It will be called upon graphql requests, and provided the incoming request object. The resultant object is then applied to the context passed to all graphql resolvers.
This will allow us to add extra information from the request into the graphql resolver context, which when writing custom plugins will be useful for instances such as personalisation or auth flows outside of postgres.
Cheers for the library, think it's awesome.