Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Format documents with 'prettier' #174

Merged
merged 5 commits into from Jun 14, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 12 additions & 0 deletions .gitignore
Expand Up @@ -59,3 +59,15 @@ typings/

# Visual Studio project specific, machine local files
.vs/

# Standard ignores from wg-template
*.swp
*~
.*.haste_cache.*
.DS_Store
npm-debug.log
/build
/public
/gh-pages
yarn.lock
package-lock.json
4 changes: 4 additions & 0 deletions .prettierignore
@@ -0,0 +1,4 @@
# PRs to Working Group documents should be minimal effort - no need to force formatting compliance
/working-group/
# To maintain the expressiveness of the original poster, we do not auto-format RFCs
/rfcs/
133 changes: 74 additions & 59 deletions INTERESTED_DEVELOPERS.md
@@ -1,73 +1,88 @@
# Interested Developers

## Want to get involved?
## Want to get involved?

If you're interested in this spec and helping contribute to it, you can get involved with the following steps:
If you're interested in this spec and helping contribute to it, you can get
involved with the following steps:

1. Read the [Roadmap](ROADMAP.md) which outlines the planned development of this spec.
2. See [Agendas](working-group/agendas) for upcoming meetings of the GraphQL-over-HTTP working group. Given our world-wide span over many timezones, we are doing an experiment of attempting to advance the spec with fewer meetings and more asynchronous communication. During this experiment, please reach out over slack and github.
1. Read the [Roadmap](ROADMAP.md) which outlines the planned development of this
spec.
2. See [Agendas](working-group/agendas) for upcoming meetings of the
GraphQL-over-HTTP working group. Given our world-wide span over many
timezones, we are doing an experiment of attempting to advance the spec with
fewer meetings and more asynchronous communication. During this experiment,
please reach out over slack and github.
3. Add yourself to `List of Developers` below.
4. Find our working group on the [GraphQL Foundation slack community](https://slack.graphql.org) in the [graphql-over-http channel](https://graphql.slack.com/archives/CRTKLUZRT).
4. Find our working group on the
[GraphQL Foundation slack community](https://slack.graphql.org) in the
[graphql-over-http channel](https://graphql.slack.com/archives/CRTKLUZRT).

## List of Developers

This list helps us keep track people that are interested in taking decisions of the specification of GraphQL over HTTP.
This list helps us keep track people that are interested in taking decisions of
the specification of GraphQL over HTTP.

If you want to be listed here, open a PR with your information, just order yourself by username.
If you want to be listed here, open a PR with your information, just order
yourself by username.

- @abernix
- Company/Project/Repo: https://github.com/apollographql/apollo-server,
https://github.com/apollographql/apollo-client
- Reason: Interested in client/server spec
- @balshor
- Company/Project/Repo: https://github.com/linkedin
- Reason: Interested in a common HTTP spec
- @benjie
- Company/Project/Repo: https://github.com/graphql/graphiql,
https://github.com/graphile/postgraphile
- Reason: Interested in a common HTTP spec
- @deinok
- Company/Project/Repo: https://github.com/graphql-dotnet/graphql-client
- Reason: Interested in client/server on C# stack
- @enisdenjo
- Company/Project/Repo: https://github.com/domonda,
https://github.com/bhidapa, https://github.com/enisdenjo/graphql-ws
- Reason: Interested in a common subscriptions spec
- @erikwittern
- Company/Project/Repo: https://github.com/graphql/libgraphqlparser,
https://github.com/IBM/openapi-to-graphql
- Reason: Interested in client/server in JavaScript/C++
- @ghmcadams
- Company/Project/Repo: https://github.com/ghmcadams
- Reason: Interested in a common HTTP spec
- @jaydenseric
- Company/Project/Repo:
https://github.com/jaydenseric/graphql-multipart-request-spec
- Reason: Interested in multipart request spec
- @maraisr
- Company/Project/Repo: https://github.com/maraisr/meros
- Reason: Interested in common incremental delivery spec
- @michaelstaib
- Company/Project/Repo: https://github.com/ChilliCream/hotchocolate
- Reason: Interested in client/server in JavaScript/C++/C#
- @mike-marcacci
- Company/Project/Repo: https://github.com/boltline
- Reason: Interested in client/server spec
- @mmatsa
- Company/Project/Repo: https://github.com/graphql/libgraphqlparser
- Reason: Interested in client/server in C++
- @sjparsons
- Company/Project/Repo: PayPal & Braintree https://github.com/sjparsons
- Reason: Interested in common spec
- @spawnia
- Company/Project/Repo: https://github.com/nuwave/lighthouse
- Reason: Interested in client/server in PHP
- @sungam3r
- Company/Project/Repo: https://github.com/graphql-dotnet/server
- Reason: Interested in client/server spec
- @glennblock
- Company/Project/Report: https://github.com/microsoft
- Reason: Interested in a common HTTP spec, and in adoption of emerging HTTP
standards like HTTP SEARCH
- @hemanth
- Company/Project/Repo: PayPal https://github.com/hemanth
- Reason: Interested in a common HTTP spec and common subscriptions spec.

* @abernix
* Company/Project/Repo: https://github.com/apollographql/apollo-server, https://github.com/apollographql/apollo-client
* Reason: Interested in client/server spec
* @balshor
* Company/Project/Repo: https://github.com/linkedin
* Reason: Interested in a common HTTP spec
* @benjie
* Company/Project/Repo: https://github.com/graphql/graphiql, https://github.com/graphile/postgraphile
* Reason: Interested in a common HTTP spec
* @deinok
* Company/Project/Repo: https://github.com/graphql-dotnet/graphql-client
* Reason: Interested in client/server on C# stack
* @enisdenjo
* Company/Project/Repo: https://github.com/domonda, https://github.com/bhidapa, https://github.com/enisdenjo/graphql-ws
* Reason: Interested in a common subscriptions spec
* @erikwittern
* Company/Project/Repo: https://github.com/graphql/libgraphqlparser, https://github.com/IBM/openapi-to-graphql
* Reason: Interested in client/server in JavaScript/C++
* @ghmcadams
* Company/Project/Repo: https://github.com/ghmcadams
* Reason: Interested in a common HTTP spec
* @jaydenseric
* Company/Project/Repo: https://github.com/jaydenseric/graphql-multipart-request-spec
* Reason: Interested in multipart request spec
* @maraisr
* Company/Project/Repo: https://github.com/maraisr/meros
* Reason: Interested in common incremental delivery spec
* @michaelstaib
* Company/Project/Repo: https://github.com/ChilliCream/hotchocolate
* Reason: Interested in client/server in JavaScript/C++/C#
* @mike-marcacci
* Company/Project/Repo: https://github.com/boltline
* Reason: Interested in client/server spec
* @mmatsa
* Company/Project/Repo: https://github.com/graphql/libgraphqlparser
* Reason: Interested in client/server in C++
* @sjparsons
* Company/Project/Repo: PayPal & Braintree https://github.com/sjparsons
* Reason: Interested in common spec
* @spawnia
* Company/Project/Repo: https://github.com/nuwave/lighthouse
* Reason: Interested in client/server in PHP
* @sungam3r
* Company/Project/Repo: https://github.com/graphql-dotnet/server
* Reason: Interested in client/server spec
* @glennblock
* Company/Project/Report: https://github.com/microsoft
* Reason: Interested in a common HTTP spec, and in adoption of emerging HTTP standards like HTTP SEARCH
* @hemanth
* Company/Project/Repo: PayPal https://github.com/hemanth
* Reason: Interested in a common HTTP spec and common subscriptions spec.

### CC Helper

`@abernix @balshor @benjie @deinok @erikwittern @jaydenseric @michaelstaib @mike-marcacci @mmatsa @sjparsons @spawnia @sungam3r @enisdenjo`
66 changes: 48 additions & 18 deletions README.md
@@ -1,42 +1,72 @@
> **Stage 0: Preliminary**
>
> This spec is in a preliminary stage of active development, and can change a lot before reaching `Draft` stage. For more information, please see the [Roadmap](ROADMAP.md) or [how to get involved](INTERESTED_DEVELOPERS.md).
>
> You can find our community in the [graphql-over-http channel](https://discord.com/channels/625400653321076807/863141924126588958) on the [GraphQL Foundation Discord](https://discord.graphql.org).
> This spec is in a preliminary stage of active development, and can change a
> lot before reaching `Draft` stage. For more information, please see the
> [Roadmap](ROADMAP.md) or [how to get involved](INTERESTED_DEVELOPERS.md).
>
> You can find our community in the
> [graphql-over-http channel](https://discord.com/channels/625400653321076807/863141924126588958)
> on the [GraphQL Foundation Discord](https://discord.graphql.org).

---

# GraphQL over HTTP

**Introduction**

HTTP is the most common choice as the client-server protocol when using GraphQL because of its ubiquity.
However the [GraphQL specification](https://graphql.github.io/graphql-spec/) deliberately does not specify the transport layer.
HTTP is the most common choice as the client-server protocol when using GraphQL
because of its ubiquity. However the
[GraphQL specification](https://graphql.github.io/graphql-spec/) deliberately
does not specify the transport layer.

The closest thing to an official specification is the article [Serving over HTTP](https://graphql.org/learn/serving-over-http/).
Leading implementations on both client and server have mostly upheld those best practices and thus established
a de-facto standard that is commonly used throughout the ecosystem.
The closest thing to an official specification is the article
[Serving over HTTP](https://graphql.org/learn/serving-over-http/). Leading
implementations on both client and server have mostly upheld those best
practices and thus established a de-facto standard that is commonly used
throughout the ecosystem.

This specification is intended to fill this gap by specifying how GraphQL should be served over HTTP.
The main intention of this specification is to provide interoperability between different client libraries, tools
and server implementations.
This specification is intended to fill this gap by specifying how GraphQL should
be served over HTTP. The main intention of this specification is to provide
interoperability between different client libraries, tools and server
implementations.

**Spec Location**

The GraphQL over HTTP specification is edited in the [spec-md markdown file](./spec/GraphQLOverHTTP.md).
The GraphQL over HTTP specification is edited in the
[spec-md markdown file](./spec/GraphQLOverHTTP.md).

In the future, we plan that you would be able to view the generated form of the specification as well.
In the future, we plan that you would be able to view the generated form of the
specification as well.

### Contributing to this repo

This repository is managed by EasyCLA. Project participants must sign the free ([GraphQL Specification Membership agreement](https://preview-spec-membership.graphql.org) before making a contribution. You only need to do this one time, and it can be signed by [individual contributors](https://individual-spec-membership.graphql.org/) or their [employers](https://corporate-spec-membership.graphql.org/).
This repository is managed by EasyCLA. Project participants must sign the free
([GraphQL Specification Membership agreement](https://preview-spec-membership.graphql.org)
before making a contribution. You only need to do this one time, and it can be
signed by
[individual contributors](https://individual-spec-membership.graphql.org/) or
their [employers](https://corporate-spec-membership.graphql.org/).

To initiate the signature process please open a PR against this repo. The EasyCLA bot will block the merge if we still need a membership agreement from you.
To initiate the signature process please open a PR against this repo. The
EasyCLA bot will block the merge if we still need a membership agreement from
you.

You can find [detailed information here](https://github.com/graphql/graphql-wg/tree/main/membership). If you have issues, please email [operations@graphql.org](mailto:operations@graphql.org).
You can find
[detailed information here](https://github.com/graphql/graphql-wg/tree/main/membership).
If you have issues, please email
[operations@graphql.org](mailto:operations@graphql.org).

If your company benefits from GraphQL and you would like to provide essential financial support for the systems and people that power our community, please also consider membership in the [GraphQL Foundation](https://foundation.graphql.org/join).
If your company benefits from GraphQL and you would like to provide essential
financial support for the systems and people that power our community, please
also consider membership in the
[GraphQL Foundation](https://foundation.graphql.org/join).

---

Copyright Joint Development Foundation Projects, LLC, GraphQL Series.<br>
[graphql.org](https://graphql.org) | [Spec](https://spec.graphql.org) | [GitHub](https://github.com/graphql/graphql-over-http) | [GraphQL Foundation](https://foundation.graphql.org) | [Code of Conduct](https://code-of-conduct.graphql.org) | [Discord](https://discord.com/channels/625400653321076807/863141924126588958) | [Store](https://store.graphql.org)
[graphql.org](https://graphql.org) | [Spec](https://spec.graphql.org) |
[GitHub](https://github.com/graphql/graphql-over-http) |
[GraphQL Foundation](https://foundation.graphql.org) |
[Code of Conduct](https://code-of-conduct.graphql.org) |
[Discord](https://discord.com/channels/625400653321076807/863141924126588958) |
[Store](https://store.graphql.org)
61 changes: 38 additions & 23 deletions ROADMAP.md
Expand Up @@ -2,20 +2,24 @@

## Mission

_Provide a specification that allows GraphQL clients and servers with different implementations and technology stacks to interact freely over HTTP if both client and server are compliant._
_Provide a specification that allows GraphQL clients and servers with different
implementations and technology stacks to interact freely over HTTP if both
client and server are compliant._

## Guiding principles

- Development is based on use cases
- Strive for backwards-compatible progress
- Servers supporting later versions of this spec should support clients using earlier versions of this spec.
- Servers supporting later versions of this spec should support clients using
earlier versions of this spec.

## Version 1.0

After significant meetings, the Working Group has come to consensus that a first version of this spec should
introduce some key changes over the prior existing uses of GraphQL over HTTP.
This first version _might_ also codify existing prior common usages of GraphQL over HTTP.
In layout and structure version 1.0 should lay a foundation for future development and standardization.
After significant meetings, the Working Group has come to consensus that a first
version of this spec should introduce some key changes over the prior existing
uses of GraphQL over HTTP. This first version _might_ also codify existing prior
common usages of GraphQL over HTTP. In layout and structure version 1.0 should
lay a foundation for future development and standardization.

### Scope

Expand All @@ -28,7 +32,8 @@ In layout and structure version 1.0 should lay a foundation for future developme
### Actions

- Move to the GraphQL Foundation
- Set of running examples of ~5 of the most popular servers/clients with a standard, minimal GraphQL schema
- Set of running examples of ~5 of the most popular servers/clients with a
standard, minimal GraphQL schema
- Test suite to automate testing of GraphQL servers compliance with the spec
- Can be applied to examples of popular server or public GraphQL APIs
- Results of popular libraries and APIs compliance with current spec
Expand All @@ -43,42 +48,52 @@ Future versions of the spec may include these concepts:

- Caching
- Batching
- Versioning mechanism for servers/clients to communicate what versions they support
- Modularity - A way to communicate what features (and possibly versions) of the HTTP spec are supported by a server
- Versioning mechanism for servers/clients to communicate what versions they
support
- Modularity - A way to communicate what features (and possibly versions) of the
HTTP spec are supported by a server
- Persisted queries
- Multipart requests (file uploads)
- Submit MIME type application/graphql+json to IANA
- New HTTP SEARCH method and how it could be used https://tools.ietf.org/html/draft-snell-search-method-01
- New HTTP SEARCH method and how it could be used
https://tools.ietf.org/html/draft-snell-search-method-01

## Stages

The process of writing this specification may proceed according this rough outline of stages.
We are currently in the *Preliminary Stage*.
The process of writing this specification may proceed according this rough
outline of stages. We are currently in the _Preliminary Stage_.

### Stage 0: Preliminary

In the *Preliminary Stage*, things may change rapidly and no one should count on any particular
detail remaining the same.
In the _Preliminary Stage_, things may change rapidly and no one should count on
any particular detail remaining the same.

- If a PR has no requests for changes for 2 weeks then it should be merged by one of the maintainers
- If anyone has an objection later, they just open a PR to make the change and it goes through the same process
- If a PR has no requests for changes for 2 weeks then it should be merged by
one of the maintainers
- If anyone has an objection later, they just open a PR to make the change and
it goes through the same process
- Optional: When there is lots of consensus but not 100% full consensus then:
- We might merge the consensus-view and debate modifying it in parallel
- Anyone can extract the non-controversial part and make a separate PR
- We might merge the consensus-view and debate modifying it in parallel
- Anyone can extract the non-controversial part and make a separate PR

When the spec seems stable enough, the working group would promote it to *Proposal Stage*.
When the spec seems stable enough, the working group would promote it to
_Proposal Stage_.

### Stage 1: Proposal

In the *Proposal Stage*, things can still change but it is reasonable to start implementations.
In the _Proposal Stage_, things can still change but it is reasonable to start
implementations.

- Before release of the spec, in "Draft" stage, we have to review the spec and review all open PRs
- Before release of the spec, in "Draft" stage, we have to review the spec and
review all open PRs
- Every merge to master would need strong consensus
- Only changes that address concerns
- Implementers could start trying things

After the spec and open PRs are reviewed and there is strong consensus, the working group would promote it to *Draft Stage*.
After the spec and open PRs are reviewed and there is strong consensus, the
working group would promote it to _Draft Stage_.

### Stage 2: Draft

This corresponds to the general [GraphQL Draft Stage](https://github.com/graphql/graphql-spec/blob/master/CONTRIBUTING.md#stage-2-draft)
This corresponds to the general
[GraphQL Draft Stage](https://github.com/graphql/graphql-spec/blob/master/CONTRIBUTING.md#stage-2-draft)
16 changes: 16 additions & 0 deletions cspell.yml
@@ -0,0 +1,16 @@
language: en-US
ignoreRegExpList:
# Posessives
- /[a-z]{2,}'s/
words:
# Terms of art
- endianness
- interoperation
- monospace
- openwebfoundation
- parallelization
- structs
- subselection
# Software
- ical
# Fictional characters / examples