Possible topics to work on

[emilebosch]

Lets discuss some possible ideas to work on here

[Willianvdv]

• Local performance metrics
  For us, it would be handy to have some form of performance chart per query. We've already built a PoC that shows you the number of queries per resolver, but this required some (serious) TLC to make it useable. Some form of regression specs for performance would also be interesting to know, so if we change something the CI can generate some report about performance loss (or gain).

• Lint everything!
  Instead of writing documentation we love to write linters. It's a great tool to help you with consistent schema design. We could write/open source some of the linters we're using and figure out what linters companies like Shopify/Github/Zendesk use for GraphQL.

• Test best practices and test tooling.
  We've started by testing every resolver, but we've slowly pivoted to writing snapshot tests that interact with our GraphQL schema. These kinds of test catch the most bugs for us and are pretty easy to write. I'd like to create "official" support for snapshot testing.

• Query prediction
  Basically #732, I'd like to have a mechanism that helps us fetch data efficiently.

[Willianvdv]

Mhew, I kinda like one big list and pitch them if there's interest at the hack day

[emilebosch]

Better output for queries in rails log/logger
We need better logging in the rails console/log. Right now everything is a big big string and messy, i'd love to see more clarity in colors or any other format. Some ideas:

• Metrics per resolver
• Indented just like a graphql query / or should be another flattend display?
• Coloroured parameters?

[rmosolgo]

For me, I want to make support my first priority: making sure folks have what they need to keep their projects moving forward and helping those projects reach a stable, maintainable state. For example, reviewing code which will be added to graphql-ruby, or making sure that external projects are supported through well-tested extension points.

As for projects, the ones above all sound great, here are few ideas from my head (some similar to above):

• Fine-grained instrumentation for all steps of GraphQL execution

  Not only resolve function performance, but also parsing, validation and analysis. I'd like to build something that could work with ActiveSupport::Notifications so that existing metrics systems can benefit. This might put graphql-pro's "monitoring" feature out of business, but that's ok with me -- it would be better to have something more directly integrated & open-source.

• Bug-tracker add-ons

  At my old job, we used Bugsnag, some folks use other systems. It would be nice to add integrations for these platforms so that bugs show up with lots of metadata.

• Test tooling

  👍 for @Willianvdv 's comment above. I have two ideas in this area, but I haven't tried them out, so I don't know if they are good or not:

  • Snapshot testing, as described above

  • Isolated execution

    This is a bit crazy, but what if you could do this:

    # Get a Ruby object 
    user = create(:user) 
    # Write a _fragment_ only 
    query = <<-GRAPHQL 
    fragment on User {
      fullName
    }
    GRAPHQL 
    # evaluate the fragment on the object: 
    result = MySchema.execute_fragment(query, user, context: ctx)

    I think this would reduce boilerplate of writing a whole query, and it would give you a way to test individual types in the schema. But ... I haven't tried it yet 😆

• Linters

  👍 for above, that's all :) We have some in GitHub that could be extracted with some work.

• Query planning

  👍 again, this will be tricky, so maybe we can plan the interface beforehand!

• Finish subscriptions

  I'm really happy with the progress here: feat(Subscriptions) add subscriptions rmosolgo/graphql-ruby#672 but it still needs a bit of work before merging. Besides supporting others, I will probably spend my day on that!

• Other big-picture issues

  Here's a list of very involved things that I dream of doing some day 😬

  • Opinionated cursor-based pagination framework: separate cursor generation from data fetching; separate the page data from the GraphQL type (so that you could skip Relay types if you don't need them, like GraphCool's "simple pagination" vs "Relay pagination")
  • Stream-friendly execution: instead of .execute being one, big blocking function, create a tree of execution nodes that evaluate themselves as needed. For a GraphQL API, there is no difference; but for graphql-client, this is a huge win, since the response can begin while the data is being fetched. Also, this infrastructure would support @stream and @defer
  • Implement @export. I think the implementation is easy; the hard part is implementing the validation! (So that values can only be @export-ed to variables with matching types)
  • Implement @live. Once subscriptions are implemented, we could provide this for people whose use case supports it. Updates could be sent in the same manner as subscription updates.
  • Oh, of course, redoing graphql-ruby's DSL.
  • Adding header-level search results to http://graphql-ruby.org. Right now, search results open to the right URL, but not the right section of the page.

  Happy to talk more about those in case anyone is interested, just thought I'd share!

I'm looking forward to it!!

[emilebosch]

• Fine-grained instrumentation for all steps of GraphQL execution

Woop 🙌 Thanks for considering donating/opensourcing pro's monitoring or implementing metrics.

• Test tooling

Sounds super awesome. How would such a think look like in combination with a mutation? Most of the time i test mutations and the influence of them on the API?

@rmosolgo Thans for replying! Awesome, I also got triggered by:

like GraphCool's "simple pagination" vs "Relay pagination")

It seems that lot of innovation is also happening outside of the ruby domain, which is an inspiration for us rubyists too. I was thinking of making a list of "cool things happening outside of ruby-land" to see if we should adopt some things, or maybe provide answers to questions we might have .

[rmosolgo]

"cool things happening outside of ruby-land"

👍 💰 !!

[Willianvdv]

I'd also have some more accessible tasks. Some ideas:

• Clean up the graphql-ruby.org webpage.
  • Beginner friendly getting started
    • With Rails
  • Design in general
• Extend the demo app so we use all features that the gem offers. Great to reference to if folks have questions.
• Have a demo app with Relay. Including pagination, mutations etc.
  • Would be nice to use Rails 5's webpacker functionality and Relay Modern.
• Add a how-to-ask-a-question template, we've received a lot of questions that need too much communication to get an understanding of the issue. We can motivate issue filers to add backtraces, a test app, a regression spec, etc.
• Make a list of common mistakes/questions:
  • Rails autoloader
  • Conventions, where to put types, mutations etc
• How to deal with your security, aka how not to leak all of your private data.
• Tune the search on graphql-ruby.org.
  • it would be nice to link to search results
  • personally, I'm a big fan of Algolia maybe it would be a nice replacement for the homebrew solution?

[rmosolgo]

I love those "more accessible" tasks, that's a great thing to think about too

[rmosolgo]

a proper demo app would be amazing

[Willianvdv]

I'm wondering if we could make linters based on the generated GraphQL definition? This way it can also be used by other implementation and you can lint schemas from others 😆 . But I guess creating cops will be a smarter move since most projects already use RuboCop and I don't know how much work building GraphQL definition validators is.

[cjoudrey]

re: Schema Linter -- I've started this GraphQL Schema Linter that has a bunch of rules inspired by the GitHub and Shopify codebase. I'd love help on it if anyone is interested by this.

Apollo also open sourced an ESLint plugin for GraphQL queries here: https://github.com/apollographql/eslint-plugin-graphql.

[rmosolgo]

I added a label for this and opened a few more issues for the topics mentioned here:

https://github.com/rmosolgo/graphql-ruby/issues?utf8=%E2%9C%93&q=label%3A%22hack%20day%20topic%22%20

Please open an issue or let me know if I missed anything!