Is prisma studio on the roadmap?

Is prisma studio on the roadmap?

Right now, given a saved-and-upped model, it can be run in Redwood Apps by 1) navigating to the prisma directory, 2) copying the .env.defaults from the app’s root directory to a file named .env, and 3) running yarn prisma studio --experimental. Altogether:

$ cd /api/prisma/                    # 1
$ cp ../../.env.defaults .env        # 2
$ yarn prisma studio --experimental  # 3

This isn’t always without errors for me yet (there’s a stray UserExample model), but it’s a convenient way to just see the data.


This is a good question! I wasn’t aware they had updated Prisma Studio for Prisma 2 also!

@thedavid @rob - what do you guys think about having this run as a part of yarn rw dev? My initial intuition is that we’re duplicating a little bit here, (since you can (and should be?) query(ing) data in the GraphQL playground,) but I could maybe see the ability to push a button and add new records as being useful.

Ahhh I didn’t realize they had added this. Yes, we want to provide that as another endpoint like the GraphQL playground that devs can access. We talked about actually appending a litttttllleeee widget to like the bottom right corner of your rendered pages (can disable if you want) that gives you quick access to these other tools running on other ports.

We should be able to test that out by adding a job to packages/cli/src/commands/dev.js!


@sam Thanks! I should definitely use the GraphQL playground more; I often forget it’s there (@rob maybe that widget would help for that?).

I think I don’t use it too much since I see it as being more geared for testing your api which I just haven’t had to do lately.

There’s definitely some duplication between prisma studio and scaffolds. I think what brought prisma studio to my attention was that a schema I was mocking had a self-relation, and scaffolds weren’t generating the sdl + resolvers + components, etc. for that out of the box.

@rob I tried to get it working by adding the following job to the file you mentioned:

ide: {
  name: 'ide',
  command: `cd ${path.join(
  )} && yarn prisma studio --experimental`,
  prefixColor: 'green',

(Prisma calls studio a modern database IDE so I went with ide.) It kind of works; I get the following output, and a new window opens at port 5555:

01:33:53 web | ℹ 「wds」: Project is running at http://localhost:8910/
01:33:53 web | ℹ 「wds」: webpack output is served from /
01:33:53 web | ℹ 「wds」: Content not from webpack is served from /home/dominic/projects/redwood/redwood-app/web
01:33:53 web | ℹ 「wds」: 404s will fallback to /index.html
01:33:54 api | Listening on http://localhost:8911
01:33:54 api | Watching /home/dominic/projects/redwood/redwood-app/api
01:33:54 api | 
01:33:54 api | Now serving
01:33:54 api | 
01:33:54 api | ► http://localhost:8911/graphql/
01:33:54 ide | Studio started at http://localhost:5555
01:33:55  db | 
01:33:55  db | Watching... /home/dominic/projects/redwood/redwood-app/api/prisma/schema.prisma
01:33:55  db | 
01:33:55  db | ✔ Generated Prisma Client to ./../node_modules/@prisma/client in 86ms
01:33:55  db | 

But then I get a long error message that basically says it’s trying to do this and can’t:

01:33:59 ide | Error in request:  {
01:34:03 ide | } { query: 'prisma.userExample.count()' }

Some thoughts:

  • I think you can’t really make good use of prisma studio until you run the save and up commands, so it doesn’t seem to make sense for it to open a new window. And that’d probably get annoying anyways.
  • Should it be at port 8911 then? Like http://localhost:8911/ide/? In that case it’d have to be a service right?

Prisma has an issue where you HAVE to have at least one model defined in schema.prisma or their generate command blows up. So we put that UserExample in there so we can start the generate --watch command as part of yarn rw dev and not have any errors. But now that conflicts with Studio, UGH.

As a hacky workaround you could do some kind of grep to look for UserExample and NOT start Studio if it’s found?

I’ll bring this up in our weekly meeting on Tuesday and see if there’s a cleaner solution for working around it.

I’m guessing you wouldn’t be able to run it on port 8911 as a completely different service is already bound to that port. 8912 would be nice, but can you pick what port it opens on? And yes, ideally it would NOT open a browser window on start.

Studio would be great for quick access to all your tables, whereas we think scaffolds are are a stepping stone to building out your own pages. They act as functional placeholders until you get around to either tweaking them a bit to fit your needs or replace them one by one. Since they’re regular components built to /web they’ll be accessible in your production app whereas I don’t imagine Studio being able to run in a serverless context.

Yes you can pick the port with --port, and even specify the schema with --schema. But there’s no --open flag, and as long as I’m looking at the right file (StudioCommand.ts) it looks like we’re locked-in to that feature.

They also discussed open in this issue, saying:

If you want to get fancy, it could use to automatically open the URL in the default browser as well (as this command is explicitly about using Studio, so this matches the user’s expectation).

And I kinda got the grep hack working, but I think the error might be a little more nuanced. E.g. if I change UserExample to Post the error just becomes:

14:23:36 ide | Error in request:  {
14:23:36 ide | } { query: '' }

But it disappears when I save and up the model. Is there anyway to check for that?

Caching also has something to do it, because even after I change UserExample to Post and save and up that, I get an prisma.UserExample.count() error.

I threw up a draft PR just to share the changes I’m making: