Don't expose GraphQL Playground

[nikolasburk]

As discussed in this Slack conversation, it is currently possible to access a GraphQL Playground that exposes a CRUD GraphQL API when using Prisma. To do so, you need to enable the info log level in the PrismaClient instructor and navigate your browser to the URL that's printed like this:

prisma:info  Started http server on 127.0.0.1:37157

On tools like Codesandbox this open port is also recognized, and offered to users by default to open a browser with that:

Since GraphQL is an implementation detail of Prisma 2.0, I believe we should not expose the GraphQL Playground.

[mavilein]

Internal Note: the playground route should be dependant on an env var. We will add this env var to our local .envrc

[ansarizafar]

Why not just add authorization and expose graphql endpoint like https://github.com/genie-team/graphql-genie/tree/master/plugins/authentication

[peteralbert]

Both, the playground and the GraphQL access to the DB is really useful to us - as it allows us to build tooling on top of GraphQL instead of SQL! For instance, in Prisma 1 when seeding the database, we have an elaborate set of scripts that creates all entries via GQL - and uses the created UIDs to link the created items. Changing this to SQL is possible - but would remove a huge advantage of Prisma!

Alternatively, would it be possible to expose the Prisma Studio access? I.e. Prisma Studio send the queries and mutations (in TS instead of GQL) via WebSockets to the server, executes them and returns the result. If it would be possible to do the same manually via a REST endpoint, this would allow the above functionality, too...

[homoky]

Yes, GraphQL Playground is really great. Studio is not powerful enough in some cases.

[Fonz001]

In Prisma 1, the playground was my place-2-be... I never used SQL directly. I'd be in favor of having this exposed.

I also noticed that the whole Prisma concept is slightly harder to explain now that Prisma is no longer a separate GraphQL server:

"An (almost complete) ORM system that works very well with GraphQL"

vs.

"A GraphQL server over your database"

I hope this helps!

[sorenbs]

@ansarizafar @peteralbert @homoky @Fonz001 and others interested in using the GraphQL Playground,

It is important to understand that Prisma2 does not provide a GraphQL server. Instead, what you are seeing is an internal implementation detail that currently looks very much like GraphQL. It is not actually compliant GraphQL and it will most certainly change in the future to be even less GraphQL compliant.
The right way to think about this is as the internal wire protocol between the query engine and Prisma Client.

What we will do now: keep the modified GraphQL playground, but hide it by default. You will have to set an environment variable to access it.

What you should do now: you can keep using at as before, but please understand that it will break in small unexpected ways in the future because it is an undocumented implementation detail. The following are suggestions for how you could deal with various use cases where you might currently be relying on the modified GraphQL Playground:

Replacing the undocumented GraphQL Playground

Powerful data access: If you are using the GraphQL playground because Prisma Studio is not powerful enough for you, you should open feature requests. We intend for Studio to be a very flexible and powerful data management UI, and we would appreciate your suggestions.

Automatically generate data mutations: If you are relying on the GraphQL endpoint to programmatically generate a lot of mutations to create data, either for seeding a database or fulfil some complex workflow, you should adopt Prisma Client. Prisma Client is a type-safe data access library that has been designed to simplify tasks like this. If you are not using JavaScript/TypeScript or Go, then you should reconsider if Prisma is the right tool for you.

Building a GraphQL API: If you are using the internal and undocumented Prisma 2 GraphQL endpoint to build a GraphQL API, then you should really strongly consider to change direction. This is unsupported and will not be a happy journey for you. Instead you should investigate Nexus, which represents the culmination of 4 years of our experience building database-backed GraphQL APIs

I hope this helps shed some light on our decision.

[pimeys]

Talked with Dom and we agreed I'll do the ticket.

[pimeys]

Merged to master