Your previous job sounds interesting, @max! (and kind of top secret ) . I think you have definetely enough experience to make sophisticated decisions regarding your webstack.
However i can absolutely relate to you, and have very similar feelings and thougts regarding our current tech stack.
The thing is: We are very dependent on the development and speed + decisions of the graph cool team. I mean you guys are absolutely great, and i admire your work. Without you these discussions would not be possible at all.
But the thing is we want run in production.
A little analogy: If a car producer is building a prototype, they call it prototype and drive it on test courses. In software we call this stage beta.
Since 1.0, we’re past beta, and it was solely Graphcools decision to set this milestone, stating:
Yes you can drive our car (prisma) in public traffic, and it will have the basic features we expect it to have (like steering and airbags).
We do not expect it to have any extraordinary features (like autonomous driving, to keep the analogy). But:
- it should be usable with a normal database or a DBaaS like RDS (
- it of course can have bugs beyond beta, but not bugs like i can’t delete things.
- Things like the memory issue (you cited above), should not happen.
- Things that worked in framework, do not work in Prisma anymore. I could even bring Prisma into a state
that was unrecoverable via redeploy and i had to nuke the cluster. (Filed an issue)
Now you can say: “If you run Prisma, you’re on the forefront of GraphQL”, you’re on the bleeding edge of web development in the world" - you should expect this - i must state again, that it was decided we’re no longer in beta. If something has the beta-label we of course expect this.
We had, like you @meep a more traditional framework in use before (Flask not Django, but very similar). Now we’re building a Next.js app and hosting on Netlify, so we already leverage the “hottest stuff”.
In my opinion there is however no way back to REST after GraphQL. As someone also working on the frontend (where my users are!), i must say that it’s a 10x-speed-up, zero-to-one technology, that i would never give up.
Also writing universal apps completely in React, instead of sprinkling React across a traditional template language like Django’s or Flask is not an option neither.
So basically we have three to four options:
Use a a buggy and problematic version of Prisma. Fully trust and rely on Graphcool that they will fix it ASAP. Be like water my friend, in the meantime, and just work around any upcoming issues. I do not know Scala, nor does anyone of my team so we cannot write PRs. (which i would do otherwise). I think this isn’t an option for you neither.
Use AWS AppSync instead. Make your own picture, regarding that. For us it’s not an option. I just love Graphcool and i love their OSS approach.
Write your own GraphQL server. We were thinking about writing our own implementation using Elixir and Absinthe. Personally i’m really not a fan of: Everybody build actually the same stuff, solves the same problems, re- and -reinvents the wheel. We would be solving the same problems that GC is trying to solve - without the community. Then, rather learn Scala, fork Prisma and do PRs.
Use graphcool framework. It has missing features. The API is worse. You have far less control, then you would have with a working version of Prisma. But it is running in production (Cars: driving in public traffic, without major accidents).
For us it’s always: Stability first, features last. So currently after really trying to move to Prisma for a week or so, i’m really in fond of option 4 - until all implementations stabilize and i’m able to make a more sophisticated decision.
I kind of feel far more safe with the framework regarding a production app. I do not want to appear arrogant, but i’m not sure what standards other people have here for their production apps. You come from cryptography, so i assume you will have similar standards. I mean people are running production apps on a framework that cannot delete things.
A word to @nilan and the team: Please do not take this to harsh, and understand us as users. We really want you to succeed with us and our apps. We from Bluepick, and i think absolutely love and value your product, your dedication, skillset and courage to build THE GraphQL database interface. I’m really betting on it. Still, if a good friend asked me, i would never recommend it to be used in production, as of 2. February. 2018, and recommend the framework instead.