Anyone know if there is a plan to officially support graphql/prisma subscriptions? I know prisma2 doesn’t officially support subscriptions yet.
2 Likes
Hi @john We are working closely with the Prisma team. And subscriptions are on their radar. However, we don’t know anything about timing for subscriptions support in Prisma2. Looks like the best place to follow is this Issue:
1 Like
@thedavid are you sure you guys want to double-down on Prisma2? We’ve built a few apps with Prisma but are tired of their pivots and missing features. There are basic features people been waiting on for years (like increment, PostGIS, scalar search). Prisma doesn’t even support case-insensitive queries!
If you started with the first version of their product (Graphcool) this will be the fourth time you’ll need to refactor your code because they pivoted their model. Prisma promises things will get better, but those promises have now continued for years.
Here’s what a tech founder friend of mine has to say about it:
Prisma… and it’s the biggest fucking piece of shit💩… like, the worst piece of infrastructure we’ve ever worked with, every developer we’ve worked with (5+) hated it, and our lead developer in the end outright boycotted
half a dozen basic features core to our product missing, some with no viable workaround
terrible documentation too
so many basic things still missing, and totally ignored by the devs
and weird bugs that require messy workarounds
our devs say they’ll veto any new project using Prisma at this point xD
Why not build for a backend like Hasura or FaunaDB? I hate to see ReadwoodJS stillborn because you bet on the wrong horse.
@maxhodges I’m sorry you’ve had a bad experience in the past with Prisma. We have chosen Prisma 2 specifically for developer ergonomics and their ambitious roadmap (plus migrations and other really nice things). I don’t have a crystal ball and can’t predict the future, but we are currently well aligned with Prisma on what we both want for its future.
As @guledali mentions, I do indeed have a small investment in Prisma, as I’m a believer in what they’re doing. I made the investment after we chose Prisma to be integrated into Redwood. Through this investment I hopefully will also have a bit more influence in making sure Prisma and Redwood play nice together! At the same time, if Redwood and Prisma grow apart, then my first priority is to make sure that Redwood does what is right for Redwood (not for my pocketbook).
As for the other options you mentioned, I’m not a fan of auto-generated full GraphQL APIs from a DB schema (a la Hasura). For long term maintainability, it’s important to handcraft your API to suit the needs of the client. Experience tells me that exposing too much of the DB implementation to the frontend is an anti-pattern. Regarding FaunaDB, we intend to support it via Prisma 2 (it’s on their roadmap). In fact, Fauna may be the ultimate DB for Redwood given its serverless focus and edge characteristics. But right now Fauna is too hard to use. They seem to be heavily focused on DX and I’m hoping that will lead to a bright future where Fauna is the best choice for Redwood.
Hopefully these explanations are helpful. I don’t believe that choosing Prisma 2 will result in Redwood being “stillborn”. Quite the opposite has been indicated from the feedback we’ve gotten so far. Have you had a chance to go through the Redwood Tutorial yet? I think that’s a nice indication of the DX we’re shooting for when it comes to Prisma 2. And we will endeavor to get the features out that people need. Being open source is a huge advantage for something like the Prisma 2 Client and Migrate. We can help from the outside to make it all happen!
9 Likes
I have been using Prisma for a few years now, and totally love prisma for what they have been doing. Out of the box - redwood is tightly integrated with Prisma and netlify. Though, I hope redwood in the future would allow for simple enough integrations with others like Hasura and for deployments outside netlify.
@Jaikant We will definitely offer deployment targets other than Netlify, and make it possible for users to create their own custom deployment strategies if they like. Netlify is just the easiest way to get started and ensures we meet the edge-ready goal that underpins Redwood.
Swapping out Prisma will probably be harder, in that we’ll have a lot of tooling optimized to make workflows super easy with it. That said, Redwood isn’t so tightly coupled that it will be impossible to use other storage backends, but it might be a while until we can make it first class to do so.
2 Likes
Just saw Redwood talk on Twitter, checked it out - and now I’m really excited! 
I’ve been sketching on a similar tool just for myself, but now I might have a reason to ditch that and contribute here instead 
@maxhodges I share the frustration working with Prisma. Hearing of Prisma 2 I got excited and gave it a second go last summer and again in January. I got many red flags from working with the product, seeing how they (didn’t) responded to users on slack, how they dealt with previous customers and as you say, pivots the core product again and again and still lack important features, and it’s slow. Like for three days I’ve been wanting to test Redwood and the first thing to break in the cli init command is an underlying prisma thing that probably has had a breaking change (though it’s understandable now that they swap 1 with 2 (issue exist in github)). Anyways, knowing Prisma’s history of so-so attempts to deliver makes me feel really stupid if I’m being burned a third time. That said, users like me giving it multiple chances says a lot about the need for a product like Prisma.
@mojombo As for Hasura, I have to add a few good things. 1) They use remote schema stitching to make a unified graphql endpoint, and you can add business logic before and after that - giving complete control of how the API will work and what will be exposed (only if you need to). Hasura is a compiler for making optimized queries between postgres and graphql with convenient features on top of that (I heard the creator define it that way). I’d say it follows the “convention with sensible defaults and configuration” principle that I just invented. Well, it’s only postgres but I prefer that over Prisma that cater to more than they can chew. 2) Hasura has impressed to over-deliver since birth- I have gotten much confidence from seeing how the product progresses and how they answer users and improve the product. But Hasura UI is the only way to create initial models as far as I know (which is fine, it’s just not code). You have more types and speed is superior.
2 Likes
Thank you for adding your thoughts here @turbotobias
This specifically caught my eye:
Outside of stretching generators to their limit (e.g. relations support), we don’t know of any other current issues with Prisma in Redwood at this time. Could you help point me in the right direction so I can make sure we understand and diagnose further (if needed)?
Appreciate the help in advance!
@thedavid No problem, thank you. Yes, here is the issue: https://github.com/redwoodjs/redwood/issues/404 and matches the exact steps I’ve taken.
The error
$ yarn rw dev
...
yarn run v1.21.1
$ '/Users/tobias/web/test-redwood/node_modules/.bin/rw' dev
✖ Generating the Prisma client...
→ info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Command failed with exit code 1: yarn prisma2 generate
Error: Cannot call write after a stream was destroyed
error Command failed with exit code 1.
$ '/Users/tobias/web/test-redwood/node_modules/.bin/prisma2' generate
Versions
$ node -v
v13.7.0
$ yarn -v
1.21.1
Let me know if you need anything else
1 Like
Ah, got it and working on it. If you have a chance, could you go through the steps I outline in my reply and add your results in the Issue comments? Understood either way. Thanks again!
Done 
Glad to help. Let me know what more I can do
1 Like
One more thing: the choice of React seems at odds with your goals. Prisma dumbs down the database. It simplifies things by removing a lot of features, power, and control. That makes it appealing to developers who find RDBMS to be intimidating and scary. Yet React is not for the faint of heart.
In a survey of over 20K developers in 163 countries, React ranks as dramatically harder to learn than Vue. The combination of React and Prisma seems inconsistent with your goals.It’s like putting an unnecessarily complex CLI on a water cooler. I don’t think React completely sucks or anything, but most find it challenging, cumbersome, hard to master, and it can feel a bit irrational at times. If people can master React, they can probably handle the unbridled power of a backend like Hasura. If you want to lower the learning curve and offer a great developer experience, then Prisma plus Vue seems like a more rational combination.
1 Like
Note: Vue3’s right around the corner and does offer a more functional style that may address my complaint.
I started with Vue and now I use React. I disagree. While Vue’s easier to get started with, I found the familiar gripe to be true: doing more advanced things in Vue (e.g. renderless components) is way less intuitive than in React.
In React, especially now with hooks, it’s really Just-Javascript™.
If there’s going to be a framework war, it should probably be in another thread. I actually used Hasura too–I was trying to spin something up with Nuxt + Hasura. The problems were almost never just this-tech-vs-that-tech. The problem was the one Redwood’s trying to address: integration. All I seemed to be doing was scratching my head trying to configure stuff.
2 Likes
What do you disagree with? I don’t think we are in disagreement. I wrote, “most people”. The fact that you have a minority opinion isn’t in disagreement. It’s just one anecdotal opinion compared with a survey of more than 20K developers, which includes some people in your camp.
Sorry for the confusion–I disagree with this statement.
@maxhodges I found your graph and conclusions quite surprising, so I dug up the source, and I will counter with another graph from that website:
WOW, look at how React crushes Vue on every metric of the advantages! Also surprising, right? It’s because both of these graphs are useless. They are graphing the number of responses for each question (not percentages), and the number of responses for React happen to be > 2x the number of responses for Vue. These graphs are absolutely meaningless, and it’s astonishingly ingenuous to use them as the basis of any argument. Here are the other graphs from the website that are much less surprising:
According to these graphs (which I have not checked against the real source data, and have very little faith in, as the author of these graphs has shown little understanding of how graphs work), developer happiness for both systems is extremely high. This matches much better with my sense of reality. Both are awesome. Both have advantages. Both have drawbacks.
If you’d like to have a legitimate argument about the merits of React vs Vue, or any other component of Redwood, I will be happy to do so in another thread, but I do not appreciate your aggressive approach on this thread, especially when supported by deceptive graphs. It’s possible that Redwood isn’t the right framework for you. That’s ok. If, however, you’d like to be constructive in how Redwood evolves, we welcome you, but your attacks here are not welcome.
6 Likes
ok sure, I get it. In a culture, people relate to each other to the extent that they think the same thoughts and share the same beliefs. I don’t share those ideas, so I’m not appreciated. That’s the nature of cultures; they insulate themselves from new ideas by killing them off.
For the record, I have nothing to gain personally from sharing any of my opinions here. It’s just that my team built multiple apps with Prisma over the past two years, and I’m very unhappy with the lack of many basic features and lack of support for their yet-another-abandoned product. I’m a Prisma detractor for real, painful, costly reasons.
I didn’t make those graphs, i just grabbed them. It was lazy of me. Sorry. But Vue is nearly universally accepted to have a lower learning curve. You can get the raw data from Sasha Greif if you really want it. But I think it was never really a matter of evidence. You’re betting on a promise. You have skin in the game–you’re backing a project that doesn’t quite exist yet from a team that has a track record for abandoning half-baked ideas year-after-year. That’s good. You have strong reasons to make it a success no matter what I or anyone else has to say about it.
I’ll bugger off. Good luck with Redwood!
For the record I thought your last response was civil, and I know you’re barely talking to me at this point, but I can’t help but respond to this at least:
This is unfair to all of us.
Plenty of people here have suggested other technologies. And the core team’s explanations as to why things are this way and aren’t that way have been detailed and honest. @mojombo’s even said (on the JS party podcast I believe?) that he’d be willing to champion making technologies if Redwood needs them.
Here’s a question: why are we all here? Is it because we all think React’s great? Probably not–there’s other communities for that. The only answer that seems convincing to me (and I’m hardly being original–again, really just pulling from that one JS party podcast) is that we’re all here because we at least agree on one thing: today’s JS is not well integrated. And as far as learning curves go, that’s a pretty big one. Nothing about that’s insulating, unless you think the JS landscape would be better off with more entropy.
I’d say something about skin in the game, Taleb (I’m a fan), betting-on-promises vs planning, teleology, and definite optimism, etc., but then we’d have to start the next thread in the #uncategorized category.
2 Likes
This how Twitter we know today looked like when it was first launched at Odeo.
@maxhodges Prisma might or might not be a perfect choice for Redwoodjs but does it really matter. Redwoodjs is all about simplifying building modern web applications with react & graphql and there will be some issues, bugs, fixes and improvements along the way and the team will iterate and ship a better software.
I know for sure that Redwoodjs is going to improve as Twitter has improved over the years.
1 Like