- cut earlier this week
- final version of the spec
- updated index page for site with list of versions
- subscriptions, SDL, validation fixes
- Lee wants to cut ref impl really soon
- next major version should be spec compliant
- thanks to Ivan for doing a lot of work
- GH milestones + tasks -> 2 tasks left
- Release cut tomorrow at GraphQL-Europe
- schema validation rules came with SDL
- before only verbal rules
- this rule "at least one object must implement each interface", was added after the fact
- incorporated into graphql-js
- pulling it in, caused things to break
- Michael: might break schema stitching
- value vs. cost -> revert that rule change + discussion
- RFC for that change now
- original scenario: return field with interface that is not implemented (only null valid)
- non-nullable would be invalid schema
- similar validation rule for fragments
- remote interfaces by stitched schema
- "how does stitching actually work"
- validate before or only after ?
- "you can stitch full schemas or individual types or valid schemas" - it's a bit open
- do these rules exist for other things like enums/unions too?
- no usage rules
- probably have a separate discussion on that topic?
- Oleg: Sangria has also additional types
- that caused issues
- so now you can configure it if they are exposed
- by default not
- cleaner docs with the validation rule?
- Michael: graphqlint vs. hard rule?
- code quality checks instead?
- optional validation tool in graphql-tools for these additional rules
- MH: Warning vs. Error
- LB lint should have some opinion
- validation rule is stronger
- currently validation rules also contain "lint" like things
- doesn't like warnings
- IG: strong validation rules -> put pressure on tools
- GraphQL-JS:
- validation after construction (separate at first execution)
- at execution time: valid query and also valid schema
- GraphQL-JS:
- James B: you can't see interfaces through introspection?
- Matt: SDL is different than raw introspection queries ???
- JS: Helper libraries for common types (URL, Email, … )
- also separate validation rules in those helpers
- those libs should also use the regular schema validation rules
- Michael:
- executable schema
- bag of connected types/common types -> different validation rules?
- introspection schema is also bag of types
- distinction on use-cases ?
- LB tools don't differentiate between use-cases
- Oleg: syntax rules vs. validation rules
- also with schema extension of types etc. with directives
- move one field syntax rule to validation
- semantic vs. syntactic
- LB: we made the syntax rule to allow zero fields
- have a document that parses but is invalid
- we should always start with the most strict grammar and later loosen the grammar
- Action Items
- reasonable discussion continue
- other unconnected pieces of the schema (e.g. enums)
- stitching ?
- Oleg: relaxing validation rules for directives
- at the moment we only allow one directive with the same name on the same place/field
- you can work around it a bit with fragments
- asked original author of the validation if it is ok to change or remove this rule
- shouldn't be a problem at FB (used a hashmap for directive-names)
- motivation: type/schema extension "add partial schemas several times"
- compose resolution logic
- LB: no order of directives in spec, its up to the author
- Oleg: no order for input fields
- LB: many tools use directives as/in hashmaps
- make sure to to disallow ambiguous queries
- suggestion: rewrite the rules to apply only to directives in the spec
- otherwise you have to write your own validation rules
- MH: in our use-cases multiple directives would actually be harmful
- languages have annotations and also stuck with single instances and added arrays of input-objects inside instead
- JS: encountered both scenarios - uniqueness / vs. multiple uses (for better DSL)
- JS: perhaps separate @skip/@include from spec and ship as separate tool
- IG: how do you support popular tools and their directives and validation rules
- MH: Meta directives?
- LB: suggestion add sth to the grammar for the directive definition like "allow multiples"
- Oleg to write the spect test
- clear language that we don't regress on skip/include
- see thread comments from Jan
- Grammar extensions
- Multiple RFC (remove rule, additional syntax rule, meta directives) + IG with use-cases
- TG: slides - lack of input unions
- Lack of input unions leads to either runtime server validation or many similar Mutation fields each with varying input signatures.
- clients doesn't know if input signature is valid
- Main blocker: Difficulty disambiguating between input unions
- Current. Tagged Unions
- is not type-checked b/c fields are optional not required no check that you provide each field exactly once
- Proposed: new type inputUnion with __inputname in payload similar to __typename in union type
- backwards compatible, opt-in
- __inputName could be valid for any payload
- original motivation: lack of overloading
- LB doesn't like __inputName
- currently all inputs can be represented as raw data
- are there other solutions that were tried?
- not really?
- current proposal is similar to unions
- one usecase: scalar or object types (e.g. generic filtering inputs) -> we should support that
- JS: would map great to TypeScript declarations
- Steve: also the generic/scalar usecases
- how would it work with nested inputs?
- TG you would have to pass it for any of the input types, some way to specify each input
- LB: suggestion treat it similar to TS unions, try types in order
- TG likes that
- Oleg: has the same issue with abstract types, he sees this as error prone to use order
- LB: do it as part of schema validation, check for potential abiguity
- Oleg: semantically different types even if they have the same data
- LB: Flow -> any type can supply an actual string , additional discriminator
- LB does it really matter if there is ambiguity ? he doesn't see it as problem
- Ivan: tagged union
- JS: really likes the discriminating
- TG to iterate over the use-cases with concrete data to decide on ambiuguity
- LB wills stay spec editor
- will continued to contribute to graphql-js
- Ivan contributes a lot
- Matt: FB was iterating a lot internally on things that the oss community doesn't need, or would be incompatible
- still want to build on top of current spec
- he will continue to pull in latest spec releases
- fix breaking changes internally vs. handling
- LB Jan Joerges should join these WG sessions
- he designed FB servers
- Matt point person for client + tooling
- Jan for server related things
- JS: lot of the industry is shaping around this
- need some security
- originally a lot of FB people were involved
- now more outside community
- future? foundation / independent group ?
- how will FB be able to contribute / run in the future ?
- LB: not all people want consistent contributions of FB
- want to see different kinds of contributions
- FB open sourcing GraphQL -> setting a ship out to sail
- now GraphQL has been open as long as not before
- also a reason to start the working groups
- no surprise that there is now more contribution from the outside
- JS: many decisions have been owned / blocked by FB
- had to chase many people on FB to get things in
- LB: future changes should be tactical
- foundation vs. no foundation -> slow moving process, little value
- WG is social commitment, is a "foundation",
- other foundations involved legal commitments, money, …
- like JS -> third party ECMA
- JS: if there is movement it should not be blocked by FB
- LB: we should actively talk about that problem and solve it
- OSS team, bring people in, allow permissions on repos (commit, PR)
- Matt: for example graphql-js Ivan is a trusted committer/contributor
- we can pull them in fairly quickly
- LB: some projects are not as active as graphql-js (graphiql, language service, …)
- Nick: is there a model that we want to emulate?
- JS: not enough thinking on it
- FB owns a lot of these things, wants to fix the blocking
- open to conversation about model + contributions
- LB: add active contributors
- Johannes to identify stalled projects
- then we can add active contributors
- LB: Daniel W. and LB built Defer into client Relay for FB's internal Batch API as a compile target
- not very compelling, very challenging
- challenge was integrating it into the client frameworks, lots of effort
- pursuing it from the angle of the relay team was not enough
- look for example that show spromising
- will not come from FB / the relay project
- JS: we're now 2 years in the future
- community thinks FB is working on this
- please share the findings
- LB will ask Daniel
- Matt: my team is continuing to experiment with these directives
- has still not figured out a compelling answer
- doesn't expect answer out of FB
- perhaps a specific answer for the concrete infrastructure, but don't hold your breath
- findings would have implementation details that are very specific
- LB: Jan + Adam at the GraphQL server are really interested in this
- LB: a public post would be great on this
- MH: large data volumes
- LB: the boundaries have to be decided by the client, b/c each flush causes a rende
- Oleg: Brad implemented at Atlassian Deferred and Stream we would love to hear
- Ivan: This also includes normalization
- LB: server side normalization is still interesting
- you have to add additional validation rules for determining duplicates
- JS: aliased objects make it harder to decide if two paths are the same or not
- Ivan: Falcor -> look there
- Ivan: _id field for a globally unique ID -> also affects normalization
- IG: connected to FB + OSS discussion
- current patents can be switched to MIT but need FB legal department
- LB: from what I learned from the move to MIT -> move on a case by case basis
- Matt could help to flag these 3 projects to the OSS team/legal team
- Matt doesn't expects changes any time soon
- LB: logo license -> should be CC license
- code license on spec was wrong -> content license
- IG biggest problem is point of contact in this issue, the WG is kinda the point of contact
- it would be beneficial to have a clearer message around FB + OSS / licenses
- LB Joel from the OSS team has been tremendously helpful
- LB to bring logo license to attention
- Matt to flag the three projects to OSS/Legal at FB
- JS/IG: set up a plan with concrete topics, open an issue for Joel to take on for internal advocacy
- Send Joel Marcy a big present
- JS: a list of things that are currently not possible
- for a next version of GraphQL
- currently GraphQL is tied to (mobile) application
- a lot is happening in the infrastructure (grpc, nbor, …) which
- LB: graphql are not bound to JSON or a transport
- there are streaming serialization techniques
- there could be a server that (CaptnProto) requires streamed upside-down
- for services to service communication
- JS: lots of infrastructure tools support GRPC and different serializers (thrift, protobuf etc)
- there could be misconceptions that mistreats GraphQL
- LB: if you could go back and what you would change is an interesting consideration (good keynote)
- none of them tackled transport
- GraphQLs solve API boundaries for clients
- hope that at some point there will be something better than graphql
- take ideas from graphql but apply them to new domains
- best of both worlds
- JS: how would it look like if yo could break it up into
- typesystem, resolvers, ….
- LB: the spec should be a trailing indicator
- people should be able to build stuff
- Neo4j started with some graphql like features internally but then used graphql as an optional API
- Rapid API Inno -> tries to solve api space / weird fork
- Tooling is important and breaks if you move outside the spec
- LB Neo is using directives and graphcool too
- JS: composing schema, importing namespaces, are parts of thrift etc.
- but we are observing and
- Schema gets composed into one place / file and then it's locked
- LB if we had specced things like that back then it would have been wrong, as we didn't have the experience in those areas at FB
- Oleg: there different ways
- we need a language independent way
- directives are big thing
- JS: what would be good for the community is to see the boundaries
- initially graphql + relay were perceived as the same thing
- that there is schema vs. validation vs. query execution
- distinct concepts
- Matt: withing FB we now started to figured out the depth graph of GraphQL
- we tried to use a lot of the proposals (like graphql-config etc)
- none of those worked in our case
- would recommend against formalizing too much on the execution
- Oleg: offer alternatives and discussions
- show leadership
Oleg: when a lot of people are not in the same room it is hard to indicate that you want to contribute
- Ivan: Node.js has a system to solve that as well