Project stewardship.

[hsyed]

@atrniv @pyros2097 Great work on this project. It's very different from the other 3 GraphQL libraries (as well as the reference JS implementation). For my purposes I think it is the most suitable base to work off. I am working on a massively multi-tenant project and need to design a GraphQL engine that can manage hundreds of schemas and alter them at runtime.

@paralin is doing some interesting work with Magellan. I will need to add features like that to the work I am doing as well. I don't want to fork and maintain an internal flavour of GraphQL -- as I realistically wouldn't be able to open source it

The other 3 GraphQL projects don't have a mechanism for us to contribute realistically (correct me if I am wrong @paralin).

I am hoping @atrniv @pyros2097 you guys can spend some resources to make it possible for us to contribute back, get parity with the spec and steward extensions which would allow us to build more advanced GraphQL engines.

[unreadable]

I agree, hoping that repository will become more active

[paralin]

I will have mechanisms to contribute more once the codebase for Magellan is more stable. I also already basically could add a api interface to replicate what the other libraries can do without real-time fairly easily.

Right now I'm mostly focusing on redesigning parts of Magellan to be more efficient, with optimizations and algorithms to reduce the amount of network traffic by batching data in the result messages. Once that work is complete I'll be moving the project towards production ready status.

[atrniv]

@hsyed , thank you. I can see how you could use our library to create a graphql engine with dynamic schemas, I actually designed it initially with that as a potential use case. We wanted to create a way for our users to extend our platform API.

Till now, we have primarily been using this internally for our own production use, and so far we haven't faced too many limitations from the graphql spec which was initially implemented. But I feel now we are approaching a point where it will be worth updating the implementation.

I've open sourced a few repos before but found it very difficult to maintain as time passes, especially if I later stop using the repo internally at our company. Hence I didn't even bother putting up a README file initially as a test to see if we actually created something valuable that would get people to take the trouble to understand the codebase before over-committing my effort to project. It's good to see that it passed the test.

I also think it is a good idea to create a formal mechanism for contributing back to the project, do you guys have any ideas on how we could best go about this ? @paralin , @krypton97 , @hsyed, @pyros2097 ?

[pyrossh]

Yeah. I guess we need to get this revamped to the latest spec. But then that would require the main person @atrniv who implemented the initial spec to make a review of all the places we need to change since he would know what changes that need to be made.
I guess this is also important from a standpoint that the new Relay Modern depends on the latest features from the spec and we can't use it without those features. Also the hacks we do with __typename might not be needed anymore.
I think we should start out by listing all the new things that need to be implemented for the new spec and put that in the issues list with a detailed description on what needs to be done and some of us can take that as a task and complete it little by little instead of 1 person (@atrniv) doing all the work that way more people can learn and contribute to it and we can have more maintainers like we did with the graphql-go project before.
Also it would be good if there was some documentation as to how this implementation works or is built since it would be easier for us to understand it. As there are features like parallel resolution which many users might not know about. And also we also need to take into consideration as to what improvements we can make to the current implementation in terms of performance. (lexer, parser, executor)
I've also created a framework based on this library which uses structs to implement the graphql schema and makes it easier to code without too much type conversion happening. You can check it out here
https://github.com/pyros2097/golem.

[pyrossh]

And also I'm looking into rust these days and this Graphql implementation in Rust https://github.com/mhallin/juniper is similar to golem in its design