https://www.prisma.io/ logo
Join Slack
Powered by
It seems that a lot of `schema.graphql`-setups are...
# prisma-whats-new
n
It seems that a lot of 
schema.graphql
-setups are leaking data through cyclic references. These can become complex to manage (
me
➡️ 
bookings
➡️ 
places
➡️ 
bookings
(of other user) ) https://github.com/graphcool/graphql-server-example/issues/109 Is there a best practice on that?
m
yeah I had this issue so I had to re-define types on the public api. i.e. I would redefine 
places
to remove references to 
bookings
. The only way to access bookings would be through 
me
or directly on 
bookings
n
It appears like the public facing API must be a set of unidirected graphs or trees instead of graphs containing cyclic references.
Like i define several entry points (tree roots) into the API, but i never get back to ancestor nodes.
But if i need to access a relation bidirectional, i.e. authors 
posts
and the 
author
of a post, i would need to define the same model twice.
m
I guess it depends on your data structure. I have large graphs with cyclic references but I ring-fence so only people with the correct permissions can access them
n
What do you mean by 'ring-fence'?
m
where there is potential data leakeage, I have re-defined the types in the public api by removing the leaky relationships. my large graphs contain maybe 15 connected types but I only have to redefine one or two types
n
Ok, thank you for the advice max!😀
m
regarding your 
posts
and the 
author
question. you could have a public definition of 
author
which people can query. Then the author can edit and view their info on 
me
.
np 🙂
w
I'm confused how the data leaks. If you have business logic/permissions in place that says "Only the owner of a booking can retrieve a booking", no matter how many levels of indirection a booking is accessed through that rule should prevent unauthorized access.
m
I didn't quite follow the second part of your statement. What do you mean?
w
No matter whether a booking is accessed via 
me
➡️ 
bookings
or 
me
➡️ 
bookings
➡️ 
places
➡️ 
bookings
, if there is business logic that checks on a per-booking level 
is this user authorized to view this booking
, then there will be no data leak
m
yes agreed with that use case where if the user fetches a 
place
and the 
bookings
on that node. you can check if they have access to those bookings.
that's one way of doing it. Else you could redefine the 
place
in the public facing graphql api to stop users from accessing 
bookings
on the 
place
node
n
As max said its often easier to define the business logic on 
me
than on a specific 
booking
, as you normally specify sub-resolvers for a single booking (like 
id
, 
bookee
etc.) , and you want to avoid to run an authorization task on every resolution of one of these sub-fields.Especially if you get a lot of 
bookings
. A nice helper i found today is https://github.com/maticzav/graphql-shield
👍 1
3 Views
Open in Slack
PreviousNext
Powered by