https://www.prisma.io/ logo
Join Slack
Powered by
Hello all. Just trying out graph.cool for the firs...
# prisma-whats-new
j
Hello all. Just trying out graph.cool for the first time, and am running into a bit of a wall. First off.. Are interfaces supported? I see the Interfaces (coming soon) tab, but I don't know if this is just a UI for interfaces... If interfaces are not supported, how are folks pulling off more complex scenarios such as multiples types of users... 
User -> Provider | Customer
?
a
@jpdesigndev Not supported yet, and we don't 🙂
d
@jpdesigndev I'm new to graphcool and backend design in general and have been thinking about the same problem (different types of users)
I didn't realize the use of 
interfaces
would solve this issue and the way I've thought to implement it on my own is to have each User have a different 'role'
So each 
User
type has a 
role
field that are different strings (e.g. user, moderator, admin, etc)
@agartha any thoughts/suggestions on this?
s
@dk0r This is totally a valid approach. Even when we do add support for Interfaces (and more importantly, relations to interfaces) there are still scenarios where your suggested approach would be better. You should consider using an enum instead of strings though 🙂
👍 1
a
Yes @dk0r, I strongly believe we need Interfaces 🙂
d
thanks @sorenbs @agartha. Is this our single source of truth for definitions and the like? http://facebook.github.io/graphql/
s
That is the GraphQL specification and the ultimate source of truth. I certainly recommend skimming through it 🙂 We also have this more accessible article providing an overview of the Schema Definition Language https://www.graph.cool/docs/faq/graphql-sdl-schema-definition-language-kr84dktnp0/
d
Thanks. I'll assume there could be variations between the spec and graphcool's implementations then
s
Graphcool is fully GraphQL spec compliant. Sometimes we move ahead of the specification, as was the case when we introduced subscriptions and the Schema Definition Language before they were in the official spec. So far we have been able to align with the spec as it catches up in a way that is backwards compatible.
a
@dk0r This is also a very good source: http://graphql.org/learn/
d
Thanks @agartha --that gives a little more context and should be helpful
a
@sorenbs The permission queries are ahead of spec, the added directives are in line with spec, but custom built, and the spec leaves a looooot of room for interpretation (example: ordering, filtering etc. The spec only describes that fields can have arguments, the implementation is not in the spec). So the spec will only get you so far...
Most of the 'hidden magic' is definitely great, and offers a lot of added value over a vanilla graphql server, but the spec will not tell you about any of it. Like the way input types are generated based on 'system' fields (which is an unknown concept in the spec), which queries are generated based on the type definitions and relations, all that stuff. The queries that are invented to support the permission system (which is a separate graphql schema under the hood) for example, are 100% according to spec, but the implementation is very specific to the use case (determining permissions).
And like all 'black box' systems, reference documentation is very important, and I have to admit, Graphcool has done a very very decent job with that!
🍾
d
@agartha any idea why sorenbs suggested using 
enums
over 
strings
for the 
role
field I will be assigning to my 
User
types?
I've read that performance is better on enums compared to strings but haven't understood much else
a
Enums define the possible values, so it has built-in validation
🙏 1
j
@agartha thank you 🤔
@dk0r sure... I'm referring to something a bit different here. Not user roles/abilities. For example, an Appointment type would have a Provider field and a Customer field, both of which are users. The fields available to those users would be different though. Sorry if I misunderstood you.
The user is a Customer on this Appointment, which does not mean this user is a "Customer" role necessarily. This is where I would use Interfaces. Not for roles/permission (I don't think I would at least, although I'm not certain)
a
You don't need interface for that. In fact, if the fields visible are different, you need the opposite. Both 'Customer' and 'Provider' fields are of type User. You would create two read permission queries, one with the fields for Customers, one with the fields for Provider, and in those queries you would check SomeAppointmentExists(consumer: $user_id) or (provider: $user_id). (sorry, pseudo code, can't check the actual syntax, but you get the idea)
Open in Slack
PreviousNext
Powered by