I've been using graphcool (0.1) for quite some time, on a paid plan.
I feel so lost with so many changes lately, graphcool 1.0, now prisma, first it was a baas, then open sourced, then only a graphql database, etc.<p>My question are
(and I totally thank you guys for the great tool you created)<p>#1 how will you profit from it?
I need to make sure we invest in a tool that will be supported.<p>#2, how do I migrate? I understand that now I have to take care of a lot more than before, but the information available ain't clear, instead of saying "Hey, we no longer will create everything for you, make sure you learn how to tie graphql-yoga + bindings+ prisma" you were saying "We will focus on graphql database" which led us wonder what it meant.<p>I think your decision to focus on the hard problem is the right one, it just that our relation as users/customers of graphcool has changed and that wasn't very well explained.<p>keep the great work!
These DB -> API tools show promise, until you want to do something outside the CRUD box like upload images or process payments.<p>Also, I've found it much harder to modify functionality because now your business logic is embedded in your DB which is harder to version than backend code.<p>In any event, if you want a GraphQL/DB API and don't want to pay for graph.cool, there's a great similar tool called PostGraphile: <a href="https://www.graphile.org/" rel="nofollow">https://www.graphile.org/</a>
Graphcool is awesome. I think you guys made the right choice moving to a code-first, open-source platform.<p>Obviously you still need to make money. Besides hosting and automatic backups, how will you monetize? What are your plans for Graphcool Enterprise on-premise?
Huge fan and user of Graphcool the BaaS! My question concerns permissions.<p>I thought Graphcool did a phenomenal job of permission/authorization. The tutorials seem to kick authentication to the application layer. That seems appropriate.<p>I think one of GraphQL's pain points is lack of a permissions pattern. It's typically hand rolled at the field / resolver level, leaving a lot of messy code. Will permissions be a part of Prisma and, if so, is there a road map for how granular they can be?
I tried to use graph.cool as my first graphql project, everything was a breeze, except:<p>* I couldn't for the life of me find out how to implement user auth.
* The json fields are sooo small, it's a huge no-go for developers (like me) who are used to postgres's amazing json support.<p>I ended up just using neelance's Go lib and postgres.
I tried to deploy this the other day and got stuck waiting in it's wizard to create a bunch of docker containers. (which I waited 30 minutes then gave up)<p>I'd like it more if it was just a standalone server and not a bunch of "magic" scripts to standup/deploy.
How looks great!
After looking about the BaaS, Framework, and now Prisma, I don’t really have a question about the relation between them.
I feel that it just a “wrapper” or something else, because it combine with the binding and yoga package, so it’s not really clear what is the role played by Prisma inside this ecosystem?
(but soon i will look at it very closely)