Prisma as query engine on Graphcool-Framework?

[steve]

@sorenbs - Thanks for the clarification in https://github.com/graphcool/prisma/issues/1629 on the differences between Graphcool-Framework and Prisma.

@sorenbs @nilan - Can you please provide a priority level for changing the Graphcool Framework to use Prisma as the query engine.?

I know graphcool is evolving quickly and it can be challenging for early adopters (myself included) to keep up with the rapid proliferation of tooling/services/re-branding etc…

Some of us may be looking for a one size fits all solution, others, all the necessary building blocks for maximum flexibility.

One pain point for those who invested time (significantly on my part) in Graphcool-Framework is that we cannot immediately reap the benefits (specifically features like cascading deletes and interfaces) of Prisma/Graphcool 1.0 that were much anticipated and assumed to be coming to Graphcool-Framework. Instead, once 1.0 was reaching completion, it was announced that in order to use the features you either have to:

A. Migrate to Prisma and abandon framework (non-trivial)
B. Keep using Framework and wait until framework supports Prisma, which may or may not be a priority atm for graphcool

Without Graphcool’s hard work on all of these tools we wouldn’t be having these conversations, so thank you for that and considering this constructive feedback

I own a start-up and choose try to choose my tech wisely, and with Graphcool I see a company that we can “grow with”… so we will continue (attempt) to keep pace with you guys.

Best,
Steve

[jingle]

Same thoughts here. I think graphcool has hit a sweet spot with a cloud service that autogenerates a graph API for developers AND gives you the flexibility of adding your own serverless functions. There’s not much comparable competition in this graphql area at this point AFAIK. I would try to keep the momentum going if I were Graphcool.
I’m a developer and not a server specialist or DBA. and I’m tired of having to manage app servers, db servers, scalability, security etc. Besides, I want to sleep at night with peace of mind, and go on Holidays without having to check server stats on my mobile. As my business grows I want a dev team good at programming (without server distractions).
Given the rapid growth of Graphql, my guess is that a LOT of developer teams are going to ditch virtual servers for cloud services based on graphql.

[steve]

For those looking for a thorough explanation on the differences between Graphcool Framework and Prisma see @nilan’s post here: Graphcool Framework and Prisma.

[sorenbs]

Thank you for the thoughtful question Steve!

At the moment our focus is two-fold:

• Increase stability of Graphcool Cloud (hosted framework)
• Greatly expand capabilities of Prisma (API features and connectors to more databases)

It will be a while before we prioritise backporting Prisma features into Graphcool Framework.

The technical design of Prisma Cloud is quite different from Graphcool Cloud in that every customer will be running on dedicated hardware. This change allows us to move much faster in terms of adding new features because we don’t have to be quite as careful about ensuring that one service can not impact the performance of another.

Prisma is still very young, but over the next few months we will see a lot of the existing framework functionality finding its way into prisma through libraries that can be used with graphql-yoga.

There is also a very interesting discussion going on about providing a more integrated hosting experience for Prisma in this thread: Prisma as a service? We are unlikely to provide something like this in the short term, but I find the idea very appealing.

I hope that helps you better understand the way we think about Graphcool Framework and Prisma

[sedubois]

Thanks @sorenbs. After a hiatus of one year it looks like I am finally ready to get back into Graphcool (just waiting for the PostgresQL connector), and I needed to have a feeling of where things are headed to choose between graphcool-framework and prisma, so your last comment was very helpful.

Nevertheless, I feel concerned that by using Prisma I wouldn’t be supporting Graphcool’s business. AFAIK Graphcool cloud based on graphcool-framework is Graphcool’s only source of income. Where do you plan to make money in the mid-term future, as you just suggested that in the short term you neither plan to retrofit Prisma into Graphcool nor deliver a “Prisma Cloud”?

I.e., what should your users choose if they want to both invest in development and support Graphcool?

Thanks a lot for all your efforts and keep up the good work.

[sorenbs]

Our clear recommendation is to choose Prisma when feasible.

This is where new features are currently being developed, and I believe our initial launch of Prisma Cloud will be quite compelling for many developers.

I appreciate you thinking about our financial wellbeing. We are a well funded company and like other open source companies before us, our current focus is on getting the core technology right.

Hope that explains our position!

[jhalborg]

I’m very much in the same boat as @steve , and would also like to commend him for the way he put his criticism.

@sorenbs : “Our clear recommendation is to choose Prisma when feasible” - This does seem to be the overall arching theme when browsing slack/forums, but what if we’re in a situation where that isn’t feasible? Me, and as far as I can tell also others, are concerned that GCF will either stagnate in development, or even worse, do a Facebook Parse-like exit. We’re using GCF in production for our app, and I would really like some official comment/assurance that this will not happen, and that the fairly large and growing amount of issues/FR’s on graphcool-framework will also be worked on.

I do appreciate the advantages of Prisma, and think it’s really awesome tech! But I also think a lot of developers who look to graphcool do so for the fastest way to mock up/prototype a backend, and perhaps also drive it into production, myself included, and here the more opinionated Graphcool Framework is a much better fit (assuming you don’t need the more granular control that an applayer + Prisma DB layer provides).

Thanks

[jhalborg]

Maybe @nilan can be of help?

[jhalborg]

@sorenbs @nilan - Friendly ping The TL;DR goes something like this:

For projects that are already reliant on GCF, and where it is not feasible to switch, what’s our outlook for maintenance and features?