Can I know the roadmap for this library? Is it going to be actively maintained? Or should I go for https://github.com/graphql-go/graphql instead?
This would be useful but I think it will remain a community effort. I suggest better organizing the issues (applying labels, etc.) so we know what we can work on to contribute to this library.
@dvic It is just a general question on the direction this library is heading. I am not sure what label I should put for this
@yxchng I was referring to the current open issues, not this issue :)
Hey, great question and apologies for the lack of activity as of late. I'm trying to sort some things out that will allow me to spend a more consistent amount of time on this project.
I'm going to commit to getting a draft of a roadmap out within the next 24 hours. Have you seen any other projects with a good roadmap? Is there a preferred format?
Or should I go for https://github.com/graphql-go/graphql instead?
I wouldn't recommend using github.com/graphql-go/graphql at this time. Last I looked, it's not very idiomatic for Go and makes some strange design decisions (i.e. fields resolve in serial, rather than in parallel).
If you're trying to get started using this library, I'd recommend taking a look at one of the community examples listed in the README. I've created one at github.com/tonyghita/graphql-go-example, and others have contributed their own approaches to different usecases as well.
@tonyghita
I'm more interested in how stable and reliable of this library. Is it production ready. what importannt features are you going to add (e.g subscription, codegen)
I find grafafna's way of managing roadmap is easy to track:
https://github.com/grafana/grafana/blob/master/ROADMAP.md
I think it will also be useful to have a digest of change log like this,
https://github.com/grafana/grafana/blob/master/CHANGELOG.md
It's used in production, but I do expect the API to change over time. I would consider this a v0.
That being said, I'd like to follow the Go package version proposal so any breaking changes would be included in a different path.
No guarantees are offered about the packages in internal. I'm hoping to bring this library up to the working draft specification, and in doing so will solidify those interfaces with the goal of eventually exporting them out of internal.
Update: I wasn't able to get to writing down the roadmap this weekend but I'm going to try and open a PR with RFC on the roadmap tonight.
Looking forward to seeing the roadmap. My company would be interested in recurring donations to help continue the development 鉂わ笍
Any news of treating resolvers like http.Handler?
Sorry for the delay. Let's try out using GitHub Projects for this repository's roadmap. I've created a first draft here: https://github.com/graph-gophers/graphql-go/projects/1.
@maxbeatty that's very generous! I fully intend to ramp up development on this project very soon.
@pindamonhangaba I'm not yet able to wrap my head around how that would work within the context of the current implementation. Feel free to open a PR if you are able to show an example.
Hope this helps clear up the status of this project!
Most helpful comment
Hey, great question and apologies for the lack of activity as of late. I'm trying to sort some things out that will allow me to spend a more consistent amount of time on this project.
I'm going to commit to getting a draft of a roadmap out within the next 24 hours. Have you seen any other projects with a good roadmap? Is there a preferred format?
I wouldn't recommend using
github.com/graphql-go/graphqlat this time. Last I looked, it's not very idiomatic for Go and makes some strange design decisions (i.e. fields resolve in serial, rather than in parallel).If you're trying to get started using this library, I'd recommend taking a look at one of the community examples listed in the README. I've created one at github.com/tonyghita/graphql-go-example, and others have contributed their own approaches to different usecases as well.