Greetings, As a first time user of Graphcool, I must say reading the docs, and website this framework appeared to be promising and exactly what my team needed. I would like to share my observation of this platform. This is strictly my opinion and i'm sure this post will ruffle some feathers, however I believe, in giving critical feedback in hopes to evolve a such a promising platform. I discovered this project after leaving a department meeting by which we discussed plans to move to a graphql framework. After doing some preliminary research I discovered graphcool. Looking at the specs of the project it appeared to accomplish majority of the things we were looking for. With that said, after about a week of reading through docs, issues, and forums I have come to this conclusion. If I were to analyize and or score the Graphcool framework here are the immediate things that stand out to me: [Issues] (primarily windows) - Outdated / Invalid Docs - Lack of response to common questions / concerns regarding the new implementation and migration flow - Unstable release planning do to numerous breaking changes (literally ran a command one day, and the next day the command was missing, with no mention in the docs of the new command) - High community push to migrate to an unstable release. (it's great to get people on the new release, however pushing the vast majority of your community to the unstable release is a sure way to turn serious developers away) - No clear path of future direction (directly relating to constantly changing roadmap of set milestone) - Lack of testing in multi-platform environments. Graphcool@next works when using docker for mac, but is absolutely useless when trying to run a local cluster on Docker Toolbox for Windows. Both follow under the statement "Use Docker" per the docs. - Lack of documentation on how to stand up a dedicated docker cluster, and push to that cluster - Unexpected behavior with authentication loop when trying to deploy to local cluster - Intermittent message when spinning up docker a local cluster on windows "Waiting for Graphcool to initialize. This can take several minutes..." well this message has been here for several hours ? what gives. - Most Importantly : prominent prompt in production environment to convert project to @beta, and states this cannot be reversed. Due to the current state of @next several users are left with less than ideal working environments of their existing project. Countless numbers of development hours lost. [Suggestions] - Discuss a milestone set it in place, and form an iteration plan to accomplish said milestone. @vscode is a great example of this. Monthly iterations with minimal adjustments after the iteration is locked. This allows community devs to have a clear direction of what needs to be done, and where they can help. - Rather than pushing the entire community to try out the @next features, and implementing dialog - Test in multi-platform environments, or invite a distinct list of users from each environment to test new features prior to annoncing to the community to migrate. - The term "Migrate" indicates that the suggested release is ready to use. Use it lightly when making annoncements on the production platform. Unless it is truly ready for migration , that includes all stated supported platforms. This entire statement would be completely useless had there not been such a great push to move to @next. I understand @next is in beta and is subject to change, but I would say the annoncements to move to @next was extremely premature. I know some would say if you don't like the platform make it better. Let me be clear, I absolutely believe Graphcool has the potential to be a leading platform, and would be more than happy to contribute to it's development. I will explore these options with the core contributors in an effort to learn the development workflow and see where I can pitch in.

As an active community member, I have seen many people fall prey to the eagerness of wanting to be on the front-line of all the beta features, and if you're there indeed, you will experience most of the issues you have described. A lot of major features are currently in flux, making the day to day experience... challenging at times. Taking one step back however, and going to back to using what has been officially released as stable, the experience is totally different in my opinion. For example, it took a very long time for the resolver functions to move out of beta (literally months), and when they finally did, the feature was stable. And before the new Framework Preview was launched, there was already weeks of closed user testing going on (I know, because I was a part of that test group). As you mention: This entire statement would be completely useless had there not been such a great push to move to @next. I don't see that push to move to @next, unless people are in need of features that are part of that Preview, but always with a disclaimer. And yes, even with the current stable version, I have seen some minor regression issues over the past week from new changes being introduced, but none of them were breaking, and all of them were dealt with efficiently. If you look back, and take away all of the @next stuff from the equation, would you have had a different experience?

Dear @rwatts3, thank you so much for your open and constructive feedback. You raise many valid points. Let me share some perspectives I have on the topics you touched on. * First of all, the Framework Preview introduces a completely new approach of working with Graphcool services, powered by a service definition that fully lives in the file system. We designed this workflow based on the feedback we heard from the community (see for example https://github.com/graphcool/graphcool/issues/213). * Second, we are currently pioneering the deployment of a GraphQL server in a single docker image, that comes batteries included: the image contains a localfaas (local Function as a Service), a local subscription service (using WebSockets) and an in-memory MySQL DB. Together, these two points enable a much better development workflow. This is also reinforced by the feedback we have been and are receiving. You might not realize, but especially the docker setup is a huge change for the Framework. * Third, we are taking part in the efforts of the GraphQL community to design setups surrounding GraphQL API Gateways (for example, https://dev-blog.apollodata.com/graphql-tools-2-0-with-schema-stitching-8944064904a5 and https://github.com/graphcool/graphcool/tree/master/examples/gateway-custom-schema). We are exploring this topic as we believe it offers a lot of potential, and much is still to learn about it, and new best practices based on this will emerge. In sum, a lot is currently in flux. We are quickly iterating and evolving the three areas I mentioned.

@agartha You have made very valid points in your response. Please note I stated I was coming to the platform as a first time user. I believe I signed up some time ago but never truly used the platform. I went through the docs first to get reacquainted with the platform. I'm just stating as a first time true user of the platform my impression based on the @next push was that this is where you should start. I can't recall exactly where , whether it was the docs or the issues board, but I read a statement from a graphcool staff saying if you're starting out definitely start with the @next tag, That gave me the impression that what I would be bringing my team through on the current stable version would be obsolete. I completely agree with going with the more stable route. The last thing I want to do is waist time, trying to implement a beta into production. Even though I would happily contribute to the development of a beta. My statement merely focuses on the misconception that @next was where we should start.