You do not need to use React or Node or anything else specifically with Prisma (which is written in Java, I think). Because you get so much out of the box with GraphQL, and then Prisma takes that to a whole new level, it’s easy to see any graphql endpoint like Prisma as a ‘server’ substitute. But it’s best to think about Prisma as a ‘thin wrapper’ for your data service. For simple, non production cases, you could definitely get away with connecting right to the endpoint from your client—it will work. But, apart from the potential security issues, if you were to go this route, you’d be missing sooooo much of the GraphQL goodness that running an actual server in front of Prisma would allow you to do. For instance, are you familiar with schema stitching? It’s where you use one GraphQL server/schema to tie together disparate sources of data for a seamless client experience. It’s life altering. And, btw, if you set up GraphQL-yoga or Apollo Server in front Prisma you are already doing schema stitching. There is absolutely no reason why you couldn’t have 10 Prismas behind your server. Or maybe you want to return some relevant other data (like, weather, github information, reverse geocodjng, etc), you could do all of that right along side your calls to Prisma. Your client would never know. It’s beautiful. But It needn’t be that complex. I run my GraphQL ‘server’ on AWS Lambda. Apart from not supporting subscriptions, it’s nearly the same experience with no cost for idle time. Happy to talk further to help talk through getting you set up if you’d like.