Greetings, As a first time user of Graphcool, I m...
# prisma-whats-new
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.
👍 3
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 * 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, and 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.
However, we have not sticked to our usual standard of providing a stable experience and uptodate documentation, and I acknowledge the extend of frustration and confusion this is causing. I see it every day on Github, Slack and in the Forum, and try to alleviate it as much as possible. Other issues you mentioned: * multi-environment docker/lack of response: Sorry for not responding earlier to the issues you've raised in the Forum and Github - indeed, we have not tested many workflows for the docker setup on windows yet. We'll do that later this week, and the insights you shared are super helpful for that. Once we have more to say here, I'll get back to the issues you created. * lack of docker documentation: as I said above, the docker setup is brand new. There's definitely a lack of documentation that we're looking to improve on soon, maybe this helps: * prominent prompt in production environment to convert project to @beta, and states this cannot be reversed: do you mean the "Upgrade Project" button in the Console? I am not quite sure what you are critizing here. The button exists because many developers want to upgrade their project to the new Framework Preview. And the disclaimer is there to tell them that this is not reversible. Furthermore, I have to strongly agree with @agartha here. We've made it a point to mention the context surrounding the Framework Preview (it's called Preview after all) whenever it's being brought up.
Suggestions you mentioned: * milestone workflow: we are currently following a weekly milestone cycle, in light of the quick iterations I mentioned above this is working better right now. I expect us to stabilize and increase the period of the release cycles roughly a month from now. Then we'll also introduce a formal roadmap process. You can follow along releases, and will be able to follow along the roadmap, here: * feature testing: I agree. we've have great success with previous previews (such as permission query preview, resolver preview, multi-region preview). this is what we're looking to replicate with the Framework Preview. As mentioned above, we're looking into multi-environment docker later this week and I'll make sure to keep a close feedback loop to you, as I'm sure you have a lot of insights to share regarding Docker/Windows. Finally, regarding your last point, we're very much looking to help everyone who wants to contribute. We'll have more information about this soon, but feel free to reach out to me before. A final notes on "logistics", I'd like to keep broader discussions like this in the Forum instead of Slack. This discussion is very productive and important, and I'd like as many people as possible to chime in. Unfortunately, discussions on Slack tend to get buried very quickly.
(needed to split it up into 3 messages, too... 😄 )
@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.
💪🏻 1
👍🏻 1
Thank you for clearing up those concerns and truly looking at the suggestions. I think it's important to state that the issues I raised were certainly responded and handled in a diligent manner. I should have been more clear in my observations, I was more so referring to similar questions or issues I came across where other developers were experiencing a problem, and there didn't seem to be a plan of action to resolve or acknowledge those problems. Ultimately I found that at least one or two of the issues I posted were already posted prior, but I was not able to find a solution or official statement on the previous issue. With that said I completely understand the direction for Docker. I would like to propose this. I am an experienced Docker user, I have given a presentation at a major conference on Docker as well as pioneered many workflows, and systems to adopt the docker workflow. As you can see from the suggestions I proposed regarding the host port issue and potential solutions along with the port issue. I would really like to assist in this movement of the Preview and help with solutions to some of the pain points revolving Docker. As i'm sure your team has discovered Docker is an amazing solution but I found it comes with a steep learning curve especially when migrating to docker from an existing platform or Devops workflow. You've already addressed my suggestion regarding the workflow and areas where community developers can assist. All in all as stated before my initial observation or introduction to the framework lead me to believe that we should be starting with @next, and that's why I put the disclaimer "This entire statement would be useless had there not been such a great push to move to @next". If i were to revise that statement I'd focus my point around a first time user's impression of where to start. My comments about breaking changes where collected from feedback or issues posted in the chat of existing users struggling with their existing workflow having migrated to the @next or @beta implementation.