Saeris
02/03/2018, 3:52 AMfullname
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
.agartha
02/03/2018, 3:55 AMagartha
02/03/2018, 3:55 AMagartha
02/03/2018, 3:56 AMSaeris
02/03/2018, 3:57 AMSaeris
02/03/2018, 3:58 AMagartha
02/03/2018, 3:58 AMextend
syntax working, so you would put an extend type MyType { newField: String }
in your schema.graphql, instead of copying MyType
agartha
02/03/2018, 3:59 AMSaeris
02/03/2018, 3:59 AMSaeris
02/03/2018, 4:00 AMSaeris
02/03/2018, 4:00 AMagartha
02/03/2018, 4:02 AMagartha
02/03/2018, 4:02 AMagartha
02/03/2018, 4:03 AMSaeris
02/03/2018, 4:03 AMSaeris
02/03/2018, 4:04 AMagartha
02/03/2018, 4:04 AMSaeris
02/03/2018, 4:05 AMagartha
02/03/2018, 4:05 AMgraphql playground
, you'll get a playground with two separate endpoints (app and database), and you can run queries against both.Saeris
02/03/2018, 4:05 AMSaeris
02/03/2018, 4:08 AMprisma.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 skippedagartha
02/03/2018, 4:09 AMagartha
02/03/2018, 4:09 AMagartha
02/03/2018, 4:11 AMSaeris
02/03/2018, 4:11 AMprisma.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.agartha
02/03/2018, 4:12 AMschema.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 wellSaeris
02/03/2018, 4:12 AMagartha
02/03/2018, 4:12 AMagartha
02/03/2018, 4:14 AMSaeris
02/03/2018, 4:14 AMschema.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
?agartha
02/03/2018, 4:16 AMagartha
02/03/2018, 4:17 AMextend
, 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.Saeris
02/03/2018, 4:19 AMprisma.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
schemaSaeris
02/03/2018, 4:21 AMagartha
02/03/2018, 4:21 AMprisma deploy
based on datamodel.graphqlagartha
02/03/2018, 4:21 AMagartha
02/03/2018, 4:21 AMSaeris
02/03/2018, 4:22 AMprisma.graphql
, that wouldn't actually change the schema on the Prisma endpointagartha
02/03/2018, 4:22 AMagartha
02/03/2018, 4:22 AMSaeris
02/03/2018, 4:22 AMSaeris
02/03/2018, 4:24 AMprisma.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 foragartha
02/03/2018, 4:25 AMSaeris
02/03/2018, 4:25 AMprisma.graphql
agartha
02/03/2018, 4:25 AMgraphql get-schema
at any time, and that would overwrite prisma.graphql againagartha
02/03/2018, 4:27 AMprisma-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.Saeris
02/03/2018, 4:28 AMagartha
02/03/2018, 4:30 AMprisma-binding
repo so we can continue and share our thoughts there.Saeris
02/03/2018, 4:30 AMagartha
02/03/2018, 4:30 AM