The future of this library
michaeldgraham opened this issue · 4 comments
I believe now is the appropriate time for me to post this. I really do apologize if our perspectives disagree; I know this may be stressful for some. It may help to know that I have waited over 6 months; this is planned and intentional.
I worked for Neo4j on this library starting August 2018, kept on a part-time contract. I have been the only person at Neo4j working on this library. I went to them because I wanted to do everything I have done. But I did not do it for Neo4j, I did it for myself and for us. Neo4j, to me, seems to be most (but not only) interested in motivations and directions oriented toward the Neo4j company and its growth. And I don't blame them, really. I was blessed to be paid to work on this for so long.
I am effectively the author of this library, but it has never been in my control. We are now many months into waiting on anything to be done about all the issues that have been created since or before January. I knew around January that the library was about to be paralyzed and ignored. I see you all posting issues and PRs, and I love you for it.
With the state of management issues within tech these days, you may or may not agree with my intended actions. But explaining the history thoroughly, and somehow without bias, is certainly not the point of this issue.
This is: I will progressively update my fork of this library with bug fixes, feature implementations, possibly refactors that allow for extensibility, various experiments, etc. It is objectively clear now, and perhaps surprisingly, that Neo4j has no intention of supporting this library from now to any length of time. But I do. I am still sincerely interested in working on these resources and will likely continue to be. But I have recently quit working for Neo4j.
If this issue is deleted, then I will repost it. If I am blocked from doing so, I will make a new account and repost it. There is a higher level of abstraction that this integration could be built upon which would allow for vastly increased customization of how GraphQL gets translated to Cypher - I may also work on that and welcome anyone to join me. It's too bad the GraphQL team never communicated with me during the past year, because I could of shared it with them. Maybe @johnymontana should have let them know I exist.
This library should be maintained until such a time that the majority of users actually report that they can migrate to @neo4j/graphql in a sufficient way. If anyone at Neo4j wants to publicly debate about that conclusion, then I will be right here in this post. Beyond that, I will continue to maintain it because it is a resource that I care very much about and personally intend to use until such a time that I can migrate to @neo4j/graphql.
I will update my fork in about a month with a variety of bug fixes and improvements.
@johnymontana I hope you don't delete this. <3
@michaeldgraham thank you for the message and I fully support you as a community member!
My suggestion though, is that instead of updating this library you fork @neo4j/graphql and work on fixing the small handful of regressions. Then work on new features like subscriptions.
The main regressions are missing relationship properties and being able to inject $cypherParams into a query outside of a JWT. Otherwise the new library is superior in many ways and migrating isn't too hard. I've also noticed the code is cleaner and TypeScript is more intuitive to work with.
I think your work would be more valuable supporting the official project rather than maintaining legacy code.
Hi @michaeldgraham I am super eager to help maintain and bug fix, theres a lot of nice feature in here :)
Thanks, @michaeldgraham for your work on this library. It's been a great validation of using GraphQL with Neo4j. Of course anyone can maintain a fork of this library, but Neo4j will continue to invest in GraphQL + Neo4j through the official open-source @neo4j/graphql library and users will benefit from ongoing development work there. Contributions are welcome there as well.
We are interested in ensuring users are able to migrate to the official library. Here are some resources showing what's involved in migrating:
If you have any blockers to migrating please open an issue in the @neo4j/graphql repo so we can make sure these blockers are identified and addressed.