What is the current path folks are taking for getting an admin dashboard up and running? Coming from Django world, I miss having a “recommended” path to a CRUD admin panel, and so far I haven’t figured out the best option for getting something similar in React+Prisma world.
Ideal features:
Offers an easy solution for all CRUD operations on all Prisma schema models
Can be hosted remotely (not just a local devserver)
Supports authentication
One option is to use the Redwood scaffold generators, but from the documentation and discussions in this community, it sounds like scaffolds aren’t currently meant for long term / production use. Is that still the case, or are there plans to make scaffolds “production worthy”? I just discovered that the Redwood service generators support the --crud option so I wouldn’t have to manually create all of the necessary queries/mutations, but again I’m not sure if this is only meant for bootstrapping a project before moving on to something more serious.
There’s also Prisma Studio, but it’s an experimental feature so I haven’t looked very closely at this.
Another option is something like react-admin. I’ve put a decent amount of effort into getting this approach working. It seems possible, but there’s a lot of work required to get the backend generating the necessary CRUD queries and mutations, and getting it to play nicely with many-to-many relations. I have it working well for the read operations, but I haven’t figured out how to get many-to-many create/update to work yet (other than just directly creating/updating rows in the join-table). React-admin was originally built for REST APIs, so getting GraphQL support working requires customizing it with some pretty peripheral 3rd-party packages, which makes it feel like I’m working against the intent of the project.
I also recently found pal.js which has its own Prisma Admin. This looks promising since it’s built intentionally for GraphQL and Prisma. It also looks like it supports an SDL-first approach, so maybe it would play nicely with generated Redwood services. The documentation is spotty though, and I haven’t figured out how to get it to integrate with an existing backend like Redwood creates. I feel like if I spend more time with this one it could be a good option, but I’m not sure about adding another CLI tool like Pal.js on top of Redwood.
So that’s all I’ve got so far. What are other folks using to approximate something like the Django Admin?
As for the HTML + CSS, most of us are falling in with TailwindCSS and the new TailwindUI. Between running generators and dropping in HTML + CSS, the workflow is becoming
Anyone else have thoughts/success stories here? Maybe @danny?
Thanks @thedavid – great to hear re: scaffolds! I remember reading a while back that scaffolds were thought of as kind of a “brochure” feature, but that developers would probably replace them as they became more familiar with the framework. I know there was a comment by @rob to that effect in this thread, and I thought I remembered reading similar views elsewhere. But now I see that thread was almost 6 months ago, which leaves a lot of time for things to change! (How has it been that long already?!)
It’s been a few months since I’ve done a comprehensive read of the docs and tutorial, and it looks like a lot has changed. I’ll catch up on all the updates, and see if it looks like using the built-in scaffolds on a route behind a login will do the job!
Hi Bennet! Yeah, 6 months feels like about 3 years. A lot has happened with much more to come.
The generators have taken on a life of their own, as well as the CLI experience. And Auth+RBAC is working really well.
For a basic Admin setup, check out what Rob did in the Example Blog repo. It’s behind Netlify Identity Auth.
Lastly, how cool would it be to have one Scaffold generator run take multiple models in and create one, inclusive Admin page?!? You should totally build that
Lastly, how cool would it be to have one Scaffold generator run take multiple models in and create one, inclusive Admin page?!?
This would be great. It would enable reduction of a lot of duplicate code too. It would be nice if things like the ModelForm, Detail table, timeTag, etc were all centralized and reused across the different scaffolded components.
I’m still looking into the available options. One thing to consider is permissions. A proper admin site requires a lot of API endpoints that might be risky to have in the actual app API. Trying to split the endpoints into ones that are needed for the app vs ones that are only needed for the admin seems dangerous. One alternative would be to run the admin site as a completely separate project. That would make permissioning way easier, but would require duplicating the schema and migrations which sounds like a headache of a different sort.
Security by structure is always most awesome, but you don’t necessarily need to split everything to achieve good security. Look into how individual queries and mutations can be secured with the Auth package (I believe the Tutorial shows this. If not check out the Auth doc and the example site for RBAC/Auth.)
^^ @dthyresson how have your experiments with GraphQL shield been going?
On the Admin dashboard I think the key word often forgotten is “dashboard”.
Do admins edit the rows and columns in a database table? Or do they solve problems given concise, readily available information and analysis?
If I am doing support, I’d want a view of the user profile, their last transactions, they issues their raised before, some of the last tracked events they did, how long they have been a customer, how active they are, etc.
That’s hard to “scaffold”.
But I digress.
@thedavid my graphql exploration is going well – it’s just like everything auth … how do you keep track of all the rules and keep them consistent. That is, if you protect the graphql how/do you protect the service the same way? Or do you at all? But sometimes it is used by a function and needs auth and maybe sometimes it doesn’t.
In my case, I started with the scaffold generators early on and have been customising as I need. Because of these changes, when I need a new CRUD section now, it’s faster if I clone from my existing admin sections (So yes, a little bit of manual work, but fair enough while you figure out the best setup for your requirements).
I used TailwindUI for the front-end and basically implemented global components for search, pagination and form elements.
Now, this is definitely not in the same level of maturity of Django admin where you only need to worry about setting up the models correctly. But at the same time, it took me only a day to write all this structure manually, which I can now quickly replicate.
As you can see, I only implemented basic auth to identify general admin users. I haven’t played with role protection yet, but this is coming next in my list.
An update on this, and replies to all of you who have chimed in (thank you!):
First, to reply to @dthyresson’s comment about a dashboard: my intent is to have something very similar to the Django Admin. So maybe calling it a “dashboard” was not the right term… I really do need something that lets a trusted non-developer create/read/update/delete the data in the database in an easy way. If any of my projects get any traction, then a proper “dashboard” with metrics etc will be a future need, but that’s not what I’m trying to achieve now.
After a few hours of using it, Forest Admin seems excellent. It was easy to set up locally, and looks like it should be customizable enough to do what I need initially. I do need to test deployment to production, but the docs on that seem solid. I think by using this, I can restrict my GraphQL API to only the endpoints/services I need for my app, while avoiding the need to add the remaining CRUD endpoints and the associated admin permissions maintenance. Thank you @peterp for the suggestion!
@betocmn Thank you for describing your setup. How do you distinguish between service actions that require admin permissions, and ones that simply require row-level access? E.g. an admin should be able to delete any data, a user should be able to delete only their own data, and an anonymous user shouldn’t be able to hit a delete endpoint at all. When using the Redwood scaffolded services for both the app and the admin, it seems like these sorts of decisions and permissions-checking would need to be figured out for each query and mutation resolver. That’s why I had started down the path of making a completely separate admin app that exposed all of the CRUD operations, where I could just put the whole API behind an admin login (this is what react-admin recommends). But then I’d need to sync the schema and migrations between the app and the admin projects, which felt messy too…
@Ahmed The Prisma Admin from Pal.js looks like the most polished and full-featured in-house option that I could find. Thank you for all of the effort this must have taken! I think Forest Admin will do what I want for now and let me get back to working on the app itself, but I haven’t used it enough to find out where the walls are. It seems likely there will be a point where I will want more customizability, and Prisma Admin / Pal.js looks like it will offer that. What do you see as the best way to integrate Prisma Admin with Redwood?
@bennett I didn’t used Redwood.js before so I can explain how my admin work and you can think with me how we do this in Redwood.js then I can make some customization in my admin to work with your integrations
with 
