The prisma-binding to SDL-first guide is missing really crucial info

[omar-dulaimi]

Hello,

While going through this page https://www.prisma.io/docs/guides/upgrade-guides/upgrade-from-prisma-1/upgrading-prisma-binding-to-sdl-first
I had a few questions that nobody is answering on the Slack channel, here they are:

1- The first step requires that I download the full graphql schema from the graphql server.
The confusion here is that this guide assumes that we have gone through multiple steps prior to that, like fixing schema incompatibilities. But if that step has already been done then there would be no running graphql server, so how exactly should we get the updated graphql schema?

2- The last step (section 4.2) says this:

You can also delete any remaining .js files, the schema.graphql and prisma.graphql files.

If I delete the schema.graphql file, then how would the server work?

const server = new GraphQLServer({
  typeDefs: 'src/schema.graphql',      // see this line ???
  resolvers,
  context: req => ({
    ...req,
    prisma: new PrismaClient()
  }),

I tried deleting it, but the grapqhl server won't run in reality, and I don't think it should be removed otherwise I'm missing something here.

3- If generated schema and application schema have been combined into one, then this means all operations supported will be exposed. Which introduces a lot of security issues that we never had to deal with. but like this we're forced to. What should we do in this case?

4- After the upgrade is done, what is the recomeneded workflow?
what are the required steps to add a new feature?
Are we stuck with editing a 24k lines long file?

[nikolasburk]

Hey @omar-dulaimi, thanks a lot for raising these points! I'll try to address them as good as possible but I'd also like to offer you to jump on a call to discuss this in person 🙂 I'll reach out to you in a DM on Slack to coordinate this in case you're interested!

1- The first step requires that I download the full graphql schema from the graphql server.
The confusion here is that this guide assumes that we have gone through multiple steps prior to that, like fixing schema incompatibilities. But if that step has already been done then there would be no running graphql server, so how exactly should we get the updated graphql schema?

Hmm, did you already shut down the GraphQL server that you had with Prisma 1? What's needed here indeed is a GraphQL schema of your previous GraphQL server so that the same API can be replicated with Prisma 2.

If I delete the schema.graphql file, then how would the server work?

Ha, thanks for catching this! I think this indeed a false instruction that wrongfully made it into this guide! I just removed it via this PR.

If generated schema and application schema have been combined into one, then this means all operations supported will be exposed. Which introduces a lot of security issues that we never had to deal with. but like this we're forced to. What should we do in this case?

I'm not sure I can follow... can you elaborate what exactly you mean and maybe give an example? If you're worried about authorization, then a library like graphql-shield might be a good idea to include. However, if you didn't use it in your setup before I don't think it will be necessary now.

4- After the upgrade is done, what is the recomeneded workflow?

Again I'm not fully sure what you mean, maybe you can elaborate? Generally, a workflow to add a feature would be:

1. adjust Prisma data model
2. adjust GraphQL schema definition
3. implement GraphQL resolvers functions

I hope this helps already, but as I said I'll reach out to you on Slack so that we can jump on a call and hopefully clarify these questions! 🙏

[omar-dulaimi]

Hello @nikolasburk, thank you for taking the time to answer these questions.

Hmm, did you already shut down the GraphQL server that you had with Prisma 1? What's needed here indeed is a GraphQL schema of your previous GraphQL server so that the same API can be replicated with Prisma 2.

• No we haven't yet. I did download that schema, but I don't get how a Prisma 1 schema that had a lot of incompatibilities could be used to work as a Prisma 2 graphql server schema. I mean after fixing the database structure, a lot of parts of this old schema should be changed, right?

I'm not sure I can follow... can you elaborate what exactly you mean and maybe give an example? If you're worried about authorization, then a library like graphql-shield might be a good idea to include. However, if you didn't use it in your setup before I don't think it will be necessary now.

Okay. So basically the prisma 1 generated schemas has all possible queries/mutations a datamodel can provide, correct?
In the application schema what we did was expose just a limited number of queries and mutations, and as a result, you don't see them from the playground(intended). But using the entire schema like the article suggests means that all operations will be visible through the playground(We want to keep them hidden).
For example, all "many" mutations are hidden whether it was create/update/delete. And a lot of "items"Connection queries are also hidden.
For authorization, we do use graphql-shield to set rules on some queries/mutations that are exposed only.

Again I'm not fully sure what you mean, maybe you can elaborate? Generally, a workflow to add a feature would be:

adjust Prisma data model
adjust GraphQL schema definition
implement GraphQL resolvers functions

What I meant by that question was, that the graphql schema being currently at 24k lines and expected to grow greatly in the near future, I was thinking that maintaining such a file would be hell. I know it's not your problem as you have shifted your focus away from graphql servers, but I only suggest that you mention how to deal with this method running a graphql server; like maintaining it and if that approach is really the right approach. I don't think big projects will rely on it, am I right?

As I imagine, this approach isn't practical, and I would love to hear your feedback about evolving the schema with new features.

[nikolasburk]

No we haven't yet. I did download that schema, but I don't get how a Prisma 1 schema that had a lot of incompatibilities could be used to work as a Prisma 2 graphql server schema. I mean after fixing the database structure, a lot of parts of this old schema should be changed, right?

This is hard to say without knowing more about your project unfortunately.

Generally, because the GraphQL layer and the Prisma layer are independent from each other, you can implement the same application schema that you used with Prisma 1 with Prisma 2 as well.

However, since a lot of your Prisma 1 GraphQL queries are using forwardTo (as I understood from a previous message), this indeed will end up with a lot of boilerplate. But it is possible!

So basically the prisma 1 generated schemas has all possible queries/mutations a datamodel can provide, correct?

Yes!

In the application schema what we did was expose just a limited number of queries and mutations, and as a result, you don't see them from the playground(intended).

Understood!

But using the entire schema like the article suggests means that all operations will be visible through the playground(We want to keep them hidden).

Ok, here's the misunderstanding! You're not supposed to download the Prisma GraphQL schema at this point, but the application schema. This is what you need because that's what's being exposed to your client applications. If you have the application schema, you can re-implement the same resolvers you had with prisma-binding.

As I imagine, this approach isn't practical, and I would love to hear your feedback about evolving the schema with new features.

Ah ok. So, as you mentioned this is indeed not directly Prisma-related but more a question of building and maintaining the GraphQL layer on top of it and it really comes down to your individual needs and preferences.

One approach I think would be to split the application schema into several files and then merge them together when you create the GraphQLSchema instance. This article on the Apollo blog gives a great overview for best practices how this can be done: Modularizing your GraphQL schema code. Alternatively you can also use tools like graphql-import or potentially even Apollo Federation which I think would be able to solve similar problems as well.

[omar-dulaimi]

Ok, here's the misunderstanding! You're not supposed to download the Prisma GraphQL schema at this point, but the application schema. This is what you need because that's what's being exposed to your client applications. If you have the application schema, you can re-implement the same resolvers you had with prisma-binding.

I'm lost now honestly. The article says that we have to download the full schema, and that is the purpose of the download button in the playground:

With Prisma 2, there's no prisma.graphql file any more that you could import from. Therefore, you have to spell out all the types of your GraphQL schema directly inside your schema.graphql file.

The easiest way to do so is by downloading the full GraphQL schema from the GraphQL Playground. To do so, open the SCHEMA tab and click the DOWNLOAD button in the top-right corner, then select SDL.

Then it's not really just the application schema, it won't work without the types imports.

[nikolasburk]

I'm lost now honestly. The article says that we have to download the full schema, and that is the purpose of the download button in the playground:

In this case, "full schema" means: application schema where the imported types are already part of the schema as opposed to before where the application schema imported the types from the Prisma GraphQL schema. Does that make more sense?

Basically this is the schema before with graphql-import:

And this is the "full schema" without using graphql-import that you have to use with Prisma 2:

[omar-dulaimi]

@nikolasburk Yes, it does make sense. The only issue that I still can't find any solutions for is how to regenerate graphql schema to fix the breaking changes to relations. Is that possible?

[shahbaazdev]

hey @nikolasburk when i upgrading the prisma1 to prisma2 as given ref. i have geeting lot of error like type does not exported from index.d.ts but it's. and i was see some solution like import {Prisma} becuse everything under the prisma. but after i do there are lot of type does not found.

[shahbaazdev]

i'm totally stuck because prisma1 generate prisma.ts file in generated folder and all related info in them., is there any soln. of that
please acknowledge me. Thank you

[omar-dulaimi]

@shahbaaz207
Nikolas will be back in October. I think you should join this slack channel to help https://join.slack.com/share/zt-tufpj5va-GPCen4uJaLqSeqZpRmjPog

[shahbaazdev]

okey

[ankur-arch]

Hey @omar-dulaimi 👋 thanks for opening this issue! I'm aware that it has been around for a while but we're only now getting to a major cleanup of the docs repo, so apologies for the delay. I'm closing this issue as there hasn't been much activity for this issue, but please feel free to open other issues in the future if you notice anything that can be improved in the Prisma docs 🙏.