Skip to content

Latest commit

 

History

History
227 lines (198 loc) · 19.7 KB

2019-12-05.md

File metadata and controls

227 lines (198 loc) · 19.7 KB

GraphQL WG Meeting Notes for 2019/12/05

Agenda

Action Items (from this meeting)

  • [Lee] Go through all previous meeting’s action items and translate them into GitHub issues
    • Having a draft plan for 2020 release
    • Some to do with the website
  • [Antoine] Put together an RFC concerning name spaces.
  • [Vince] Bronze, Silver, Gold evaluation of criteria
  • [Vince] Tie guiding principles to the solution criteria
  • [Champions] Folks should volunteer to champion the various proposals
  • [Michael] Document empty object types in a PR to keep the discussion going
  • [Lee] Ask the JS Foundation how they set up funding.
  • [Benjie and Stephen and Alan (or anyone else)] Help Ivan with the blogpost

Review previous meeting's action items and check progress on those

5m, Lee

  • Currently open action items
  • [ACTION: Lee] Go through all previous meeting’s action items and translate them into GitHub issues
    • Having a draft plan for 2020 release
    • Some to do with the website
  • Ivan: suggest adding "help wanted" tag to action item issues in GitHub to encourage others to contribute
  • Lee: I completely agree

Custom Scalar Specification URIs

20m, Evan and Andi

Context

Notes

  • Evan: Last meeting, we talked about the custom scalar spec. Since then, we’ve put together a PR. There are only a few things left to talk about.
  • Evan: RFC currently proposes a new standard and it is a breaking change
  • Adding "@specified(by: ...)" directive - is anyone aware of a schema this might break?
  • Antoine: maybe we can add to the spec that when people add directives they should use a namespace to guarantee that new spec additions will not break existing schemas
  • Lee: I like that.
  • Evan: I also like the idea of adding namespaces. We could potentially throw together a separate RFC.
  • Evan: It can be a non-normative note in the spec
  • Lee: Doesn’t need to be a formal RFC. Just searching for some best practice wisdom from the crowd.
  • [ACTION: Antoine] Put together an RFC concerning name spaces.
  • Evan: How do people feel about the RFC? Should we move to stage 2?
  • Evan: I don't speak JavaScript, so I cannot contribute an implementation to graphql-js
  • Ivan: Just file an issue
  • Ivan: Just providing a link just narrows down but the implementation can still be different.
  • Lee: I like pointing to an IETF RFC because it makes it clear it doesn't need to be a GraphQL specific standard. I don't think many people subset the spec, they just use the whole spec?
  • Evan: Andy would probably disagree with that idea.
  • Lee: Part of the reason why I like pointing to the RFC is that it can lead to discussion
  • Matt: [asked about the change from inline spec to directive]
  • Lee: The introspection change didn’t change when you change it from an inline parameter to a directive, right?
  • Evan: correct (though I may have tweaked the field name)
  • Lee: I think what will happen is there will be a handful of popular tools that will advocate what they want, Apollo for example. As long as they prefer specific specs, that will incentivize people to use them.
  • Ivan: last time we discussed this, we agreed that graphql-js as the reference implementation should include a few new scalars such as DateTime (even though they're not specified as required in the GraphQL spec)
  • Evan: That’s a great question. I’d like to handle that separately and for now and not accept any scalars like that into graphql-js. What kind of scalars that GraphiQL support is something we should consider.
  • Ivan: for reference implementation it just be for @specified(by:...) itself without any scalars included
  • Evan: Absolutely
  • Lee: I think it would be reasonable for graphql-js examples to mirror the ones in the spec. Let’s wait a bit before introducing an out-of-the box DateTime scalar to avoid the can of worms that comes with it. It is clear that we need to come to a consensus on one DateTime spec at some point but we won't block this RFC advancing stages for this
  • Lee: Having a working implemetation is a requirement for stage 2
  • Lee: We can move onto stage 2 outside of working group meetings
  • Lee: normally we require an implementation to make sure that everything has been thought about and actually works (rather than just working theoretically); in this case it's a simple addition so should just work, but it's good to have an implementation anyway
  • Matt: I can help with the Javascript

Input Union RFC

20m, Vince

Context

Notes

  • Vince: Lots of work in the last week, started doing evaluations of the various criteria and solutions (color-coded system). Our goal was to let anything in and then evaluate it.
  • Vince: Added 2 new criteria to push things along, they have to do with backwards compatibility. If we make any changes in the SDL, we want them to be compatible with previous parsing. Same thing with the introspection result. Don’t want to break existing tooling like GraphiQL.
  • Vince: They have not been evaluated but I’m hoping people can give their opinions.
  • Vince: we've looked at what potential SDL might look like for the various solutions, but we haven't looked at the introspection changes
  • Lee: This is awesome, dramatic improvement. Especially the crosswise exalution which makes it much easier to read.
  • Stephen: Yeah, I also agree that there is significant improvement.
  • Stephen: One thing that is immediately apparent to me is how do we know what criteria is prioritized?
  • Vince: I have also thought about this and using the results of the evaluations can help us understand what are the “musts”, the most important criteria that we need to maintain
  • Lee: I like Stephen’s idea of stack ranking the criteria. How we decide that stack ranking is another huge problem and I don’t want to waste time on that. We should consider a more coarse ranking, like Vince’s “musts”, but a little more fine-grained, changing the language a bit.
  • Vince: There are gold, silver, and bronze medal emojis that we can use to convey the criteria priority.
  • Vince: We need some terms to go along with those medals.
  • Stephen: We could go mathematical and assign a point system using the medals.
  • Ivan: One thing I’m worried about is currently, we don’t need consensus on anything and to use the ranking system, we need consensus.
  • Lee: I agree. I like the gold, silver, and bronze medal emoji idea. Just adding something so we can move quickly in regards to information gathering. Prioritize speedy evaluation.
  • Vince: I’m happy with just going with the medal emojis for now
  • Benjie: Some criteria like performance is a feature is hard to evaluate right now
  • Lee: We can do back of the napkin calculations, Big-0 complexity analysis. We can encourage people to build demo runs and test extreme cases.
  • Vince: I would probably evaluate the performance as a bronze
  • Evan:
  • Benjie:
  • Lee: I want to us to zoom into the appropriate resolution of what that criteria mean. Because we’re looking at this in the worst case, they will all have reasonable performance. We should be able to see to have what is the best and worst performance but look at it from the right perspective. We expect all of them to have acceptable performance. It's a guiding principle, but it's likely that all of these are well within the realm of reasonable for these examples.
  • Vince: Next step, establishing the gold/silver/bronze medal standard
  • Vince: then evaluate all criteria.
  • Vince: then enter "Decision mode" after all that is done
  • Can we talk about what a decision mode will look like when we get there?
  • Lee: One is we can decide which of the proposed solutions is best and in one fell swoop, pick one and move onto RFC. The other way is a weakest link strategy and try to narrow it down that way.
  • Lee: Looking at the criteria right now, I think both solutions will be tricky because everything has good coverage but we knew this going in.
  • Lee: If we can't agree on which one is the best, hopefully we can agree on which one is the least-best and narrow that one out.
  • Vince: The weakest link strategy seems the least controversial
  • Lee: People can decide to champion certain solutions and that will facilitate more fulfilling debates
  • Vince: I like that idea
  • Lee: It’s really easy to put names to ideas and then become focused on the names rather than the ideas. I think we just need to be cognizant of that.
  • Ivan: I have another idea. I would also like to hear how other people/company will use a particular solution to solve a real-world issue.
  • Vince: I think this is still along with the champion idea
  • Ivan: I am just saying that we can also consider emphasize real-world issues as well. For example, I care a lot about developer experience and I’m not sure if just weighing against these criteria will be able to capture that.
  • Lee: I agree, I think we shouldn’t forget that developer experience is important, not just server usage. Just listing more examples is good.
  • Vince: Should we just consider making developer experience a criteria?
  • Lee: Not necessarily. Like Ivan said, developer experience and convenience is difficult to evaluate.
  • Vince: I ask people to help evaluate some lingering solutions. One other thought is there’s one solution (oneOf/oneField directive) and I wonder if it has value on its own aside from this. Input union but also this directive provides value in other situations. How do people feel about this one solution?
  • Michael: Do you mean the oneOf/oneField directive?
  • Vince: Yes. I can see it being useful in a variety of cases.
  • Lee: I see this as a possible path.
  • Benjie: One of the other uses of oneOf is for arguments - for example finding a user by id, email or username, instead of offering three different fields, we could use the oneOf to allow us to provide only one
  • [ACTION: Vince] Bronze, Silver, Gold evaluation of criteria
  • [ACTION: Vince] Tie guiding principles to the solution criteria
  • [ACTION: champions] Folks should volunteer to champion the various proposals
  • Greg Kesler:

Make root query operation type optional

15m, Victor

Context

Notes

  • Victor: I think there is a use-case for mutation-only or subscription-only services
    • Current proposal would effectively create a stub for introspection
  • Michael: We at Hot Chocolate, we already allow that. If no Query type is specified, then we create a Query type that just does an introspection query.
    • Implementations should be straightforward
  • Lee: That is the variant if the type is empty?
  • Michael: That is if we do not define a Query type. At Hot Chocolate, you just specify a Mutation type.
  • Benjie: My only hesitation - you are then naming the Query instead of allowing a custom name for Query type - other than that I think it's a solid solution
  • Michael: Those are just nuances of how you want to do it. But in the schema stitching scenario that we have in mind, if there is no Query type, then we are not really stitching it in.
  • Lee: Is that currently a valid introspection result? Or if you try to print out an SDL?
  • Michael: I see what you are going to. When we print the SDL, we omit the Query type. We haven’t noticed any tooling that has issue with this. GraphiQL works fine.
  • Lee: The suggestion is that the introspection shows that there’s a Query type but the SDL would not print the Query type.
  • Michael: Yeah, that’s how we have implemented it.
  • Lee: I see. I think it is a little confusing: “does it have a Query type or not?” but I can see how it works.
  • Michael: The introspection fields on the Query type, you also wouldn’t print those in the SDL, and if you don’t plan on printing those, then there’s no reason to print and empty Query type. So that’s why we went down that road.
  • Michael: We have modifiers like “internal fields”.
  • Lee: I don’t know if your solution is generalizable. Either we have no type but you can still technically write a query but it can only include metafields, but that might be tricky for some tools, or we allow empty fields.
  • Michael: <Something about comparing a user’s point of view vs an execution engine’s point of view>
  • Victor: You can’t see these things in the introspection query but then you either have to hide the type or allow defining empty object types. If you don’t define a Query type, you’ll get one but it’s not really there. Maybe just restricting it to the empty Query type is good/conservative change, rather than jumping allowing any arbitrary empty objects types.
  • Victor: Just raising the restriction for the root Query type would be a way forward.
  • Michael: It is allowed syntactically (defining empty object types) but it needs to be extended with fields.
  • Lee: I think there are two paths here and they have different implications/problems. 1) revisit the RFC that you closed earlier about supporting empty object types, changing the grammar to allow empty selections and empty objects types. 2) Allow there to be no Query type. Might be strange but it might make sense in some use cases like these micro GraphQL endpoints you pointed out.
  • Need to look through the spec, and fiddle with some implementation to figure out if we did this, what would it mean to implement an introspection query (a query of meta fields) against a schema with no Query type.
  • Victor: That makes sense. I think that is a reasonable analysis of the situation. To be fair (the one driving this), I just brought up this problem because I thought it was interesting. I can’t hide my bias towards the first suggestion.
  • Lee: Ultimately, you’re the champion so you can decide which solution to pursue.
  • [ACTION: Michael] Document this feature in a PR to keep the discussion going

Crowd-funding GraphiQL

5m, Benjie

Context

Notes

  • Benjie: Working hard on GraphiQL… Struggling to keep up as a group. Trying to bring along other maintainers but what we want to do is to enable greater functionality. Playgrounds, integration with VS Code and Vim, we want to make it extensible… But we are struggling with human resources to do that.
  • Benjie: I’ve been speaking to Chris with the Linux Foundation about crowd funding
  • Benjie: Just wanted to let people be aware of that
  • Lee: Are you thinking of from the current set of maintainers, just setting up official contracts so that they spend a certain number of hours working on GraphiQL? Or hiring new people?
  • Benjie: I was thinking more like how Open Collective operates, there’s a group the can decide to fund someone to complete a certain task.
  • Benjie: It does not need to be just maintainers, it could be open to people in the community
  • Lee: So Open Collective works more like a bounty program, right?
  • Benjie: Yeah, I think so.
  • Lee: One thing I’d like to talk to you (Benjie) about moving funds from the GraphQL foundation.
  • Benjie: Yeah, that sounds great! I think also just encouraging people to help out on GraphiQL is great.
  • Lee: What are some easier ways to contribute to those pools? Maybe just setting up Open Collective or setting up GitHub sponsors.
  • Ivan: Set up under Linux Foundation or Kubernetes Foundation or Open Collective and reuse the experience. We need to ask Chris.
  • Lee: I know the JS Foundation has something set up too. I will ask them as well.
  • [ACTION: Lee] Ask the JS Foundation how they set up funding.

General Discussion, Wrap-up

  • Benjie: Victor, you mentioned previously about schema introspection enhancements, the ability to customize the introspection. Is there anyone championing this right now?
  • Victor: I saw that Ivan made a presentation about something similar. I have not personally done anything more in that area.
  • Ivan: This is very important on my list.
  • Michael: We use 2-stage introspection in all of our tools now. We had a problem with schema stitching and 2-stage introspection works really well.
  • Benjie: So no one is working concretely on introspection enhancements right now. I’m still interested to see how 2-stage introspection will enable introspection enhancements.
  • Lee: I think we can be working on both in parallel. Benjie, feel free to look into them to get the discussion started.
  • Ivan: Another thing, Chris reached out to me if I wanted to write a blogpost after every working group to summarize. I will create a draft and I would like to ask someone here to review it.
  • [ACTION: Benjie and Stephen and Alan (or anyone else)] Help Ivan with the blogpost