https://www.prisma.io/ logo
Join Slack
Powered by
Also, would it be correct to assume that if I want...
# prisma-whats-new
s
Also, would it be correct to assume that if I wanted to have virtual fields, ie: fields I want to have available in the API but not tracked in the database as a column, ie: 
fullname
which would be computed from 
firstname
and 
lastname
, that I would need to write that type in two locations? Both in 
datamodel.graphql
and 
schema.graphql
? From the examples it looks like types that aren't defined in 
schema.graphql
are automatically merged from 
prisma.graphql
.
a
You would include those fields only in your schema.graphql and add a resolver for them
So Prisma doesn't know about them
The only caveat is that instead of importing your Prisma type in schema.graphql, you would have to copy it and add your field(s)
s
yeah that's what I figured, and would like to find a solution to avoid needing to do that
there should be a single source of truth for type definitions. the way it works now opens up an easy vector for bugs to crop up as things get out of synch
a
Currently, there is none. We are investigating how we can make the 
extend
syntax working, so you would put an 
extend type MyType { newField: String }
in your schema.graphql, instead of copying 
MyType
s
gotcha
👍🏻 1
still think it could be solved using a directive
unless I'm misunderstanding how the SDL is being parsed to create the database schema
a
I think there's a bigger benefit in keeping the two completely separate. Adding fields to your backend Prisma schema and then telling it using a directive to ignore them, then importing that type and adding your own resolvers for the missing fields is also error prone
👍 1
That would be a single source of truth for the schema, but then you would get a schema that has fields in it that don't work
And as the Prisma endpoint is a working GraphQL endpoint on its own, that would not work
s
I see
didn't realize Prisma itself was an endpoint, I assumed under the hood there was just an abstraction on the node server
a
No, Prisma is just a standalone full GraphQL endpoint
s
alright, well that makes some sense then
a
If you run 
graphql playground
, you'll get a playground with two separate endpoints (app and database), and you can run queries against both.
s
right, I did notice that
🕵🏻 1
however I still think you could define things in one place. Given that 
prisma.graphql
is generated from 
datamodel.graphql
, those virtual fields could just be used in the generated schema used by the node server. They don't need to be used by Prisma at all, they can just be skipped
a
Yes, but you import your types from prisma.graphql
And when those fields would be ignored by prisma, they wouldn't be in there...
Also, that idea only works when you have a single Prisma binding. But your server could contain more than one binding (to other endpoints).
s
right, so, what's the difference then between 
prisma.graphql
and 
sceham.graphql
if in the end they get merged together anyways? as far as I understand it, the first one is just automatically generated from Prisma's schema, hence why you shouldn't edit that file directly.
a
schema.graphql
is generally a subset of 
prisma.graphql
that you actually want to expose in your server, plus any extras you want to expose as well
s
by the way, just trying to help hash out a solution to the problem since the other option is currently blocked
a
Much appreciated.
However, I would want to stay as closely as possible to the graphql spec. So that leaves us with little other possibilities than either copy or extend.
s
right, so, for example if I write a query in 
schema.graphql
and don't provide a resolver for it, the server throws an error on startup. Couldn't the same be true of those virtual fields, brought over from 
prisma.graphql
?
a
Yes, with the difference being that you can't fix that on the Prisma side. So you would have a Prisma GraphQL endpoint that throws an error if you query certain fields, without being able to know which ones (directives are not part of the graphiql/playground documentation).
Also, I actually think the copying is more explicit than using 
extend
, because then you would end up with half of your type in one file, and half in the other. So I agree with you that having that in one place is better, but you really need to see that Prisma endpoint as being completely separate from your own yoga server.
s
okay, so then if I'm understanding you correctly, then 
prisma.graphql
is literally the schema exposed to me in 
graphql-playground
under 
database
, and if I were to change that file, then that schema would change? Cuz I'm under the impression that the generated file is only used by the node server to help generate the 
app
schema
given that the Prisma endpoint should be running on a docker cluster already after I run the deploy script, changing that file shouldn't change the schema it exposes at all
a
prisma.graphql is updated when you do 
prisma deploy
based on datamodel.graphql
It's the result of the introspection query
Against the Prisma endpoint
s
right, so if I manually made changes to 
prisma.graphql
, that wouldn't actually change the schema on the Prisma endpoint
a
No it wouldn't
But it would be overwritten on the next deploy
s
right, okay
so then follow my logic here, if 
prisma.graphql
is generated from the introspection query, then theoretically it could be merged with those virtual fields we discussed earlier. That way the Prisma endpoint literally would not have those virtual fields in it's schema. But in the generated file we'll be using in our node server, we'll have those fields available to us, which we'll need to write resolvers for
a
And in which step would that merge happen?
s
during the generation of 
prisma.graphql
a
You can run 
graphql get-schema
at any time, and that would overwrite prisma.graphql again
Also, prisma.graphql is used by 
prisma-binding
to create the info object for example, that depends on the field names. So if you start putting fields in there that are unknown to the actual endpoint, all of that will start failing too.
s
alright, what about this: instead of merging the introspection query with the virtual fields, generate two files instead?
a
I really don't think this is a viable solution. Also, I'm afraid I have to go now, but if you come up with a nice solution, please feel free to create an issue in the 
prisma-binding
repo so we can continue and share our thoughts there.
s
alright, will do
a
Thanks!
2 Views
Open in Slack
PreviousNext
Powered by