diff --git a/.prettierignore b/.prettierignore
index 896ab5f8f4..4e8fcdd095 100644
--- a/.prettierignore
+++ b/.prettierignore
@@ -1,6 +1,5 @@
public/
pnpm-lock.yaml
-*.mdx
!src/pages/blog/2024-04-11-announcing-new-graphql-website/index.mdx
!src/pages/blog/2024-08-15-graphql-local-initiative.mdx
*.jpg
diff --git a/src/app/conf/2023/faq/faq.mdx b/src/app/conf/2023/faq/faq.mdx
index 6f952dafdb..569a0b410a 100644
--- a/src/app/conf/2023/faq/faq.mdx
+++ b/src/app/conf/2023/faq/faq.mdx
@@ -1,109 +1,114 @@
# GraphQLConf FAQ
-<div className="mt-6 grid grid-cols-2 gap-x-4">{toc.map(({value, id}) => <a key={id} href={`#${id}`}>{value}</a>)}</div>
+<div className="mt-6 grid grid-cols-2 gap-x-4">
+ {toc.map(({ value, id }) => (
+ <a key={id} href={`#${id}`}>
+ {value}
+ </a>
+ ))}
+</div>
## Contact Us [#contact]
-Answers to many common questions are readily available on this event’s
-website. If you cannot find the answer to your question, you are welcome
-to contact us by emailing graphql_events@linuxfoundation.org.
+Answers to many common questions are readily available on this event’s website.
+If you cannot find the answer to your question, you are welcome to contact us by
+emailing graphql_events@linuxfoundation.org.
## Confidentiality
-We never sell attendee lists or contact information, nor do we authorize
-others to do so. If you receive an email claiming to sell an attendee
-list for a Linux Foundation event, please forward it to events@linuxfoundation.org.
+We never sell attendee lists or contact information, nor do we authorize others
+to do so. If you receive an email claiming to sell an attendee list for a Linux
+Foundation event, please forward it to events@linuxfoundation.org.
## Code of Conduct [#codeofconduct]
-The GraphQL Foundation and the Linux Foundation are dedicated to
-providing a harassment-free experience for participants at all of our
-events, whether they are held in person or virtually. GraphQLConf is a
-working conference intended for professional networking and
-collaboration within the open source community. It exists to encourage
-the open exchange of ideas and expression and requires an environment
-that recognizes the inherent worth of every person and group. While at
-GraphQLConf or related ancillary or social events, any participants,
-including members, speakers, attendees, volunteers, sponsors,
-exhibitors, booth staff and anyone else, should not engage in
-harassment in any form.
-
-This Code of Conduct may be revised at any time by The GraphQL
-Foundation or The Linux Foundation and the terms are non-negotiable.
-Your registration for or attendance at GraphQL, whether in person or
-virtually, indicates your agreement to abide by this policy and its
-terms.
-
-Please read the full [Code of Conduct](https://events.linuxfoundation.org/about/code-of-conduct) for the complete policy and terms.
+The GraphQL Foundation and the Linux Foundation are dedicated to providing a
+harassment-free experience for participants at all of our events, whether they
+are held in person or virtually. GraphQLConf is a working conference intended
+for professional networking and collaboration within the open source community.
+It exists to encourage the open exchange of ideas and expression and requires an
+environment that recognizes the inherent worth of every person and group. While
+at GraphQLConf or related ancillary or social events, any participants,
+including members, speakers, attendees, volunteers, sponsors, exhibitors, booth
+staff and anyone else, should not engage in harassment in any form.
+
+This Code of Conduct may be revised at any time by The GraphQL Foundation or The
+Linux Foundation and the terms are non-negotiable. Your registration for or
+attendance at GraphQL, whether in person or virtually, indicates your agreement
+to abide by this policy and its terms.
+
+Please read the full
+[Code of Conduct](https://events.linuxfoundation.org/about/code-of-conduct) for
+the complete policy and terms.
## Diversity & Inclusion [#dni]
Education and collaboration are vital to the future of the open source
-ecosystem, and it is imperative to us that everyone in the community
-that wants to participate feels welcome to do so regardless of gender,
-gender identity, sexual orientation, disability, race, ethnicity, age,
-religion or economic status. Our [code of conduct](#codeofconduct) outlines our expectations
-for all those who participate in our community, as well as the
-consequences for unacceptable behavior.
-
-We offer diversity and need based
-scholarships and have considered a broad
-range of both onsite resources and
-emergency resources as well as a
-health & safety policy.
-
-If you have ideas on how we can create a more inclusive event, please
-do not hesitate to let us know. Contact Emily Ruf, Senior Event
-Manager, at eruf@linuxfoundation.org.
+ecosystem, and it is imperative to us that everyone in the community that wants
+to participate feels welcome to do so regardless of gender, gender identity,
+sexual orientation, disability, race, ethnicity, age, religion or economic
+status. Our [code of conduct](#codeofconduct) outlines our expectations for all
+those who participate in our community, as well as the consequences for
+unacceptable behavior.
+
+We offer diversity and need based scholarships and have considered a broad range
+of both onsite resources and emergency resources as well as a health & safety
+policy.
+
+If you have ideas on how we can create a more inclusive event, please do not
+hesitate to let us know. Contact Emily Ruf, Senior Event Manager, at
+eruf@linuxfoundation.org.
## CHAOSS D&I Event Badge [#chaoss-event-badge]
-Awarded to events in the open source community that fosters healthy
-D&I practices. [Learn More](https://chaoss.community/diversity-and-inclusion-badging).
+Awarded to events in the open source community that fosters healthy D&I
+practices.
+[Learn More](https://chaoss.community/diversity-and-inclusion-badging).
## Invoices & Certificates of Attendance [#invoices]
### Registration Invoices
-Invoice receipts are downloadable from the confirmation email you
-received after registering under the Payment Receipt Information
-section. If the downloadable invoice receipt does not meet your needs
-or you need to have your confirmation email resent, please submit your
-request [here](https://docs.google.com/forms/d/1uxCqF-ieG9QmpU8tl3HqgatHLY9FWhRs7KLpyhZA5KI/edit).
-Please include any additional customization you need for your
-invoice receipt in the request.
+Invoice receipts are downloadable from the confirmation email you received after
+registering under the Payment Receipt Information section. If the downloadable
+invoice receipt does not meet your needs or you need to have your confirmation
+email resent, please submit your request
+[here](https://docs.google.com/forms/d/1uxCqF-ieG9QmpU8tl3HqgatHLY9FWhRs7KLpyhZA5KI/edit).
+Please include any additional customization you need for your invoice receipt in
+the request.
### Certificates of Attendance
-To request a Certificate of Attendance, please submit a request [here](https://docs.google.com/forms/d/1RpI8h6AGK2rCl3aIlyEY0D6fU3tsZ5yr1Ba6c3h6p9Y/edit).
+To request a Certificate of Attendance, please submit a request
+[here](https://docs.google.com/forms/d/1RpI8h6AGK2rCl3aIlyEY0D6fU3tsZ5yr1Ba6c3h6p9Y/edit).
**Please note:** We verify attendance through the registration system, and
-Certificate of Attendance letters are sent out after the event is
-completed.
+Certificate of Attendance letters are sent out after the event is completed.
## Refund Policy
### Cancellations
-If you must cancel for any reason, please [sign back into your registration](https://cvent.me/4zbxz9), click the “Register/Modify” button and select “Unregister.” If you
-need further assistance, email registration@linuxfoundation.org.
+If you must cancel for any reason, please
+[sign back into your registration](https://cvent.me/4zbxz9), click the
+“Register/Modify” button and select “Unregister.” If you need further
+assistance, email registration@linuxfoundation.org.
-Refunds will only be issued for cancellations received two weeks prior
-to the event start date, including bulk ticket request refunds, and
-will appear as a credit on the card’s statement 7 – 10 business days
-after cancellation. Due to the ongoing pandemic, individual refund
-requests due to COVID-19 positive tests will be honored up until the
-start date of the event, and must be accompanied by a photo of a
-positive COVID-19 test.
+Refunds will only be issued for cancellations received two weeks prior to the
+event start date, including bulk ticket request refunds, and will appear as a
+credit on the card’s statement 7 – 10 business days after cancellation. Due to
+the ongoing pandemic, individual refund requests due to COVID-19 positive tests
+will be honored up until the start date of the event, and must be accompanied by
+a photo of a positive COVID-19 test.
-**Please note:** Refunds can only be issued on the card the original
-payment was made.
+**Please note:** Refunds can only be issued on the card the original payment was
+made.
### Substitutions
-If you are unable to attend, you may substitute another attendee in
-lieu of cancellation. To substitute an attendee, [sign back into your registration](https://cvent.me/4zbxz9)
-, click the “Register/Modify”, and select “Transfer Registration” on
-your confirmation page.
+If you are unable to attend, you may substitute another attendee in lieu of
+cancellation. To substitute an attendee,
+[sign back into your registration](https://cvent.me/4zbxz9) , click the
+“Register/Modify”, and select “Transfer Registration” on your confirmation page.
diff --git a/src/app/conf/2024/faq/faq.mdx b/src/app/conf/2024/faq/faq.mdx
index e8c5adee33..be4e2423fd 100644
--- a/src/app/conf/2024/faq/faq.mdx
+++ b/src/app/conf/2024/faq/faq.mdx
@@ -1,190 +1,194 @@
# GraphQLConf FAQ
-<div className="mt-6 grid grid-cols-2 gap-x-4">{toc.map(({value, id}) => <a key={id} href={`#${id}`}>{value}</a>)}</div>
+<div className="mt-6 grid grid-cols-2 gap-x-4">
+ {toc.map(({ value, id }) => (
+ <a key={id} href={`#${id}`}>
+ {value}
+ </a>
+ ))}
+</div>
## Contact Us [#contact]
-Answers to many common questions are readily available on this event’s
-website. If you cannot find the answer to your question, you are welcome
-to contact us by emailing graphql_events@linuxfoundation.org.
+Answers to many common questions are readily available on this event’s website.
+If you cannot find the answer to your question, you are welcome to contact us by
+emailing graphql_events@linuxfoundation.org.
## Confidentiality
-We never sell attendee lists or contact information, nor do we authorize
-others to do so. If you receive an email claiming to sell an attendee
-list for a Linux Foundation event, please forward it to events@linuxfoundation.org.
+We never sell attendee lists or contact information, nor do we authorize others
+to do so. If you receive an email claiming to sell an attendee list for a Linux
+Foundation event, please forward it to events@linuxfoundation.org.
## Code of Conduct [#codeofconduct]
-The GraphQL Foundation and the Linux Foundation are dedicated to
-providing a harassment-free experience for participants at all of our
-events, whether they are held in person or virtually. GraphQLConf is a
-working conference intended for professional networking and
-collaboration within the open source community. It exists to encourage
-the open exchange of ideas and expression and requires an environment
-that recognizes the inherent worth of every person and group. While at
-GraphQLConf or related ancillary or social events, any participants,
-including members, speakers, attendees, volunteers, sponsors,
-exhibitors, booth staff and anyone else, should not engage in
-harassment in any form.
-
-This Code of Conduct may be revised at any time by The GraphQL
-Foundation or The Linux Foundation and the terms are non-negotiable.
-Your registration for or attendance at GraphQL, whether in person or
-virtually, indicates your agreement to abide by this policy and its
-terms.
-
-Please read the full [Code of Conduct](https://events.linuxfoundation.org/about/code-of-conduct) for the complete policy and terms.
+The GraphQL Foundation and the Linux Foundation are dedicated to providing a
+harassment-free experience for participants at all of our events, whether they
+are held in person or virtually. GraphQLConf is a working conference intended
+for professional networking and collaboration within the open source community.
+It exists to encourage the open exchange of ideas and expression and requires an
+environment that recognizes the inherent worth of every person and group. While
+at GraphQLConf or related ancillary or social events, any participants,
+including members, speakers, attendees, volunteers, sponsors, exhibitors, booth
+staff and anyone else, should not engage in harassment in any form.
+
+This Code of Conduct may be revised at any time by The GraphQL Foundation or The
+Linux Foundation and the terms are non-negotiable. Your registration for or
+attendance at GraphQL, whether in person or virtually, indicates your agreement
+to abide by this policy and its terms.
+
+Please read the full
+[Code of Conduct](https://events.linuxfoundation.org/about/code-of-conduct) for
+the complete policy and terms.
## Diversity & Inclusion [#dni]
Education and collaboration are vital to the future of the open source
-ecosystem, and it is imperative to us that everyone in the community
-that wants to participate feels welcome to do so regardless of gender,
-gender identity, sexual orientation, disability, race, ethnicity, age,
-religion or economic status. Our [code of conduct](#codeofconduct) outlines our expectations
-for all those who participate in our community, as well as the
-consequences for unacceptable behavior.
-
-We offer diversity and have considered a broad
-range of both [onsite resources](#onsite-resources) and
+ecosystem, and it is imperative to us that everyone in the community that wants
+to participate feels welcome to do so regardless of gender, gender identity,
+sexual orientation, disability, race, ethnicity, age, religion or economic
+status. Our [code of conduct](#codeofconduct) outlines our expectations for all
+those who participate in our community, as well as the consequences for
+unacceptable behavior.
+
+We offer diversity and have considered a broad range of both
+[onsite resources](#onsite-resources) and
[emergency resources](#emergency-resources) as well as a
[health & safety](#health-and-safety) policy.
-If you have ideas on how we can create a more inclusive event, please
-do not hesitate to let us know. Contact Emily Ruf, Event Director, at eruf@linuxfoundation.org.
+If you have ideas on how we can create a more inclusive event, please do not
+hesitate to let us know. Contact Emily Ruf, Event Director, at
+eruf@linuxfoundation.org.
## Health & Safety [#health-and-safety]
_Updated March 27, 2024_
-_Our community’s well-being is extremely important to us, and
-creating a safe, worry-free event is our top priority. We will
-adjust our health and safety protocols as needed while updating this
-page with information about plans for our attendees onsite. We
-continue to look to local municipality guidelines to make the best
-and most informed decisions around onsite safety and requirements.
-**All in-person attendance requirements are subject to change based on local guidelines.**_
-
-{/*
-
-{<h3>Health Measures</h3>}
-
-{<h4>COVID-19</h4>}
-
-Masks are recommended, but not required, to attend this event. There
-are no vaccine or testing requirements to attend this event. These are
-both subject to change based on local municipality requirements and
-any changes in COVID-19.
-
-We encourage high-risk individuals, and those with family or
-colleagues who are at a higher risk of getting COVID-19, to consider
-wearing a high-quality mask recommended by health agencies. We also
-ask that you respect those around you who choose to wear a mask. A
-limited number of masks will be available upon request at Registration
-onsite.
-
-{<h4>Vaccines</h4>}
-
-We encourage flu shots, COVID-19 vaccination and boosters to reduce
-the threat of illness.
-
-*/}
+_Our community’s well-being is extremely important to us, and creating a safe,
+worry-free event is our top priority. We will adjust our health and safety
+protocols as needed while updating this page with information about plans for
+our attendees onsite. We continue to look to local municipality guidelines to
+make the best and most informed decisions around onsite safety and requirements.
+**All in-person attendance requirements are subject to change based on local
+guidelines.**_
{<h3>Onsite Personal Protection</h3>}
-- If you feel ill while at the event, please take a COVID-19 self-test and isolate as needed.
+- If you feel ill while at the event, please take a COVID-19 self-test and
+ isolate as needed.
- Hand sanitizing stations will be available throughout the event venue.
- A limited supply of face masks will be available upon request at Registration.
- We respectfully remind all attendees, speakers, sponsors, and staff to:
- - Stay home if you experience any cold or flu-like symptoms.
- - Wash your hands for at least 20 seconds.
- - Stay healthy! Engage in responsible health practices such as avoiding touching eyes/nose/mouth with unwashed hands.
-- We’ll be providing a wearable indicator that shows your comfort
- level with social distancing. While it's optional to wear, we highly
- encourage participants to use it.
+ - Stay home if you experience any cold or flu-like symptoms.
+ - Wash your hands for at least 20 seconds.
+ - Stay healthy! Engage in responsible health practices such as avoiding
+ touching eyes/nose/mouth with unwashed hands.
+- We’ll be providing a wearable indicator that shows your comfort level with
+ social distancing. While it's optional to wear, we highly encourage
+ participants to use it.
{<h3>Food Allergies</h3>}
-The Linux Foundation believes it’s essential to prioritize the safety
-and well-being of all attendees, including those with food allergies.
+The Linux Foundation believes it’s essential to prioritize the safety and
+well-being of all attendees, including those with food allergies.
-- We aim to provide a variety of choices to cater to various needs such as vegetarian, vegan, gluten-free, dairy-free, and nut-free.
-- All food items will be clearly labeled at the event, indicating the ingredients used and any potential allergens present.
+- We aim to provide a variety of choices to cater to various needs such as
+ vegetarian, vegan, gluten-free, dairy-free, and nut-free.
+- All food items will be clearly labeled at the event, indicating the
+ ingredients used and any potential allergens present.
-If you have a food allergy we need to be aware of, please email us at graphql_events@linuxfoundation.org.
+If you have a food allergy we need to be aware of, please email us at
+graphql_events@linuxfoundation.org.
{<h3>Safety Resources & Tips</h3>}
-Attendee safety is our top priority. Always exercise common sense and
-good judgment when traveling.
+Attendee safety is our top priority. Always exercise common sense and good
+judgment when traveling.
{<h4>General Safety</h4>}
- When walking around the city, remember to take off your conference badge.
-- Safety in numbers: Exploring the city can be safer when done with a friend or colleague.
+- Safety in numbers: Exploring the city can be safer when done with a friend or
+ colleague.
- Walk with purpose and stick to well-lit areas and on main streets.
- If alone after dark, use a ride service such as Lyft, Uber or a taxi.
- Save the address and phone number of where you’re staying in your phone.
- Be aware of your surroundings and keep your eyes up and not on your phone.
- If something doesn’t feel right, walk into a business/hotel for help.
- Be careful and alert when using a cash machine.
-- Carry your purse or wallet safely. Purses should be closed and held in front of your body. Wallets should be carried in a front pants pocket or in an interior jacket pocket.
+- Carry your purse or wallet safely. Purses should be closed and held in front
+ of your body. Wallets should be carried in a front pants pocket or in an
+ interior jacket pocket.
{<h4>When Visiting Any Venue:</h4>}
- Know where you are; the venue name, street address or cross street.
-- Take a moment to identify at least two exit routes from any building or event and emergency exit signs.
-- If an alarm sounds, evacuate immediately. Follow directions from First Responders and venue staff.
-- Do not carry any unnecessary valuables with you, or leave personal items unattended.
-- Do not leave drinks unattended, or accept open drinks or food products from strangers.
+- Take a moment to identify at least two exit routes from any building or event
+ and emergency exit signs.
+- If an alarm sounds, evacuate immediately. Follow directions from First
+ Responders and venue staff.
+- Do not carry any unnecessary valuables with you, or leave personal items
+ unattended.
+- Do not leave drinks unattended, or accept open drinks or food products from
+ strangers.
{<h4>Emergency Evacuations</h4>}
-- In the event of an emergency evacuation, make your way quickly and calmly to an emergency exit. Be aware of any hazards or dangers around you and proceed to a safe area.
+- In the event of an emergency evacuation, make your way quickly and calmly to
+ an emergency exit. Be aware of any hazards or dangers around you and proceed
+ to a safe area.
- Follow the advice of venue staff, security personnel and First Responders.
-- Do not put yourself in danger by stopping to collect belongings unless directed by First Responders.
+- Do not put yourself in danger by stopping to collect belongings unless
+ directed by First Responders.
{<h4>Weapon Policy</h4>}
-The Linux Foundation does not allow firearms or other weapons,
-regardless of whether they are permitted or not, or whether they are
-concealed or not, to be brought into our events. By registering for
-the event, you are agreeing that you understand this policy and will
-not bring a firearm or other weapons into the event.
+The Linux Foundation does not allow firearms or other weapons, regardless of
+whether they are permitted or not, or whether they are concealed or not, to be
+brought into our events. By registering for the event, you are agreeing that you
+understand this policy and will not bring a firearm or other weapons into the
+event.
## Invoices & Certificates of Attendance [#invoices]
{<h3>Registration Invoices</h3>}
-Invoice receipts are downloadable from the confirmation email you
-received after registering under the Payment Receipt Information
-section. If the downloadable invoice receipt does not meet your needs
-or you need to have your confirmation email resent, please submit your
-request [here](https://docs.google.com/forms/d/1uxCqF-ieG9QmpU8tl3HqgatHLY9FWhRs7KLpyhZA5KI/edit).
-Please include any additional customization you need for your
-invoice receipt in the request.
+Invoice receipts are downloadable from the confirmation email you received after
+registering under the Payment Receipt Information section. If the downloadable
+invoice receipt does not meet your needs or you need to have your confirmation
+email resent, please submit your request
+[here](https://docs.google.com/forms/d/1uxCqF-ieG9QmpU8tl3HqgatHLY9FWhRs7KLpyhZA5KI/edit).
+Please include any additional customization you need for your invoice receipt in
+the request.
{<h3>Certificates of Attendance</h3>}
-To request a Certificate of Attendance, please submit a request [here](https://docs.google.com/forms/d/1RpI8h6AGK2rCl3aIlyEY0D6fU3tsZ5yr1Ba6c3h6p9Y/edit).
+To request a Certificate of Attendance, please submit a request
+[here](https://docs.google.com/forms/d/1RpI8h6AGK2rCl3aIlyEY0D6fU3tsZ5yr1Ba6c3h6p9Y/edit).
**Please note:** We verify attendance through the registration system, and
-Certificate of Attendance letters are sent out after the event is
-completed.
-
+Certificate of Attendance letters are sent out after the event is completed.
## Refund Policy
{<h3>Cancellations</h3>}
-If you must cancel for any reason, please click the Unregister button above. If you need further assistance, email registration@linuxfoundation.org.
+If you must cancel for any reason, please click the Unregister button above. If
+you need further assistance, email registration@linuxfoundation.org.
-Refunds will only be issued for cancellations received two weeks prior to the event start date (including bulk ticket request refunds, co-located events, and add-ons), and will appear as a credit on the card’s statement 7 - 10 business days after cancellation. Individual refund requests for late cancellations due to sickness or emergency will be considered on a case by case basis - contact us at registration@linuxfoundation.org.
+Refunds will only be issued for cancellations received two weeks prior to the
+event start date (including bulk ticket request refunds, co-located events, and
+add-ons), and will appear as a credit on the card’s statement 7 - 10 business
+days after cancellation. Individual refund requests for late cancellations due
+to sickness or emergency will be considered on a case by case basis - contact us
+at registration@linuxfoundation.org.
-**Please note:** Refunds can only be issued on the card the original payment was made.
+**Please note:** Refunds can only be issued on the card the original payment was
+made.
{<h3>Substitutions</h3>}
-If you are unable to attend, you may substitute another attendee in lieu of cancellation. To substitute an attendee, select the Transfer Registration button above. You will be required to provide the attendee's first name, last name, and email address for the registration.
-
+If you are unable to attend, you may substitute another attendee in lieu of
+cancellation. To substitute an attendee, select the Transfer Registration button
+above. You will be required to provide the attendee's first name, last name, and
+email address for the registration.
diff --git a/src/app/conf/2024/partner/index.mdx b/src/app/conf/2024/partner/index.mdx
index 41556176e6..23c88d5a8b 100644
--- a/src/app/conf/2024/partner/index.mdx
+++ b/src/app/conf/2024/partner/index.mdx
@@ -2,27 +2,45 @@ import { Button } from "@/app/conf/_components/button"
## Sponsor GraphQLConf 2024 [#sponsor]
-<div className="flex flex-row justfiy-center">
- <Button target="_blank" href="https://events.linuxfoundation.org/sponsor-GraphQLConf-24" className="!text-white !block">Sponsorship Details</Button>
- <Button href="mailto:graphqlconf@graphql.org?subject=Sponsorships" className="!text-white !block ml-3.5">Contact Us</Button>
+<div className="justfiy-center flex flex-row">
+ <Button
+ target="_blank"
+ href="https://events.linuxfoundation.org/sponsor-GraphQLConf-24"
+ className="!block !text-white"
+ >
+ Sponsorship Details
+ </Button>
+ <Button
+ href="mailto:graphqlconf@graphql.org?subject=Sponsorships"
+ className="ml-3.5 !block !text-white"
+ >
+ Contact Us
+ </Button>
</div>
-Contact us at graphqlconf@graphql.org to reserve your sponsorship, ask questions or talk about different options.
+Contact us at graphqlconf@graphql.org to reserve your sponsorship, ask questions
+or talk about different options.
-GraphQLConf is the official GraphQL conference hosted by the GraphQL Foundation. It is a premier event by the community for the community to promote education, adoption, and advancement of GraphQL.
+GraphQLConf is the official GraphQL conference hosted by the GraphQL Foundation.
+It is a premier event by the community for the community to promote education,
+adoption, and advancement of GraphQL.
Help make this event one to remember by becoming a sponsor.
-GraphQLConf will attract members of the GraphQL community from around the world. Developers, users, architects, and technology leaders from multiple industries will gather in San Francisco to meet, collaborate and build. GraphQLConf 2024 is the flagship event in the GraphQL Foundation’s official event series.
-
-Investing in GraphQLConf provides the opportunity to build awareness and loyalty with leaders and decision makers in organizations across the GraphQL and open source community.
+GraphQLConf will attract members of the GraphQL community from around the world.
+Developers, users, architects, and technology leaders from multiple industries
+will gather in San Francisco to meet, collaborate and build. GraphQLConf 2024 is
+the flagship event in the GraphQL Foundation’s official event series.
+Investing in GraphQLConf provides the opportunity to build awareness and loyalty
+with leaders and decision makers in organizations across the GraphQL and open
+source community.
## Partner with GraphQLConf [#program]
-We are pleased to offer a Media and Community Partner Program for
-our upcoming GraphQLConf 2024. Our program is designed to provide
-benefits to media and community partners, while also ensuring that
-our conference is promoted in a positive and appropriate way.
+We are pleased to offer a Media and Community Partner Program for our upcoming
+GraphQLConf 2024. Our program is designed to provide benefits to media and
+community partners, while also ensuring that our conference is promoted in a
+positive and appropriate way.
{/* prettier-ignore */}
<div className="flex flex-wrap gap-2">
@@ -70,29 +88,31 @@ As a community partner, you will receive the following benefits:
## Obligations for Media and Community Partners [#obligation]
-In exchange for these benefits, media and community partners are
-expected to fulfill the following obligations:
+In exchange for these benefits, media and community partners are expected to
+fulfill the following obligations:
- Promote the conference through your own media channels or community network
-- Include the conference logo and website URL in any promotional materials related to the conference
-- Follow conference media and social media guidelines, including not publishing or sharing any defamatory or inappropriate content related to the conference or its attendees
+- Include the conference logo and website URL in any promotional materials
+ related to the conference
+- Follow conference media and social media guidelines, including not publishing
+ or sharing any defamatory or inappropriate content related to the conference
+ or its attendees
- Attend the conference and actively engage with attendees and other partners
- Provide feedback and suggestions for improvement of future conferences
## How to Apply [#apply]
-To apply to become a media or community partner, please fill out the
-application form. Applications will be reviewed on a rolling basis,
-and all applicants will be notified of their status within two weeks
-of submitting their application.
+To apply to become a media or community partner, please fill out the application
+form. Applications will be reviewed on a rolling basis, and all applicants will
+be notified of their status within two weeks of submitting their application.
-Thank you for your interest in partnering with us for GraphQLConf 2024. We look forward to working with you to make our
-conference a success!
+Thank you for your interest in partnering with us for GraphQLConf 2024. We look
+forward to working with you to make our conference a success!
-{/*
<Button
className="!text-white"
href="mailto:graphqlconf@graphql.org"
target="_blank"
->Fill out the application form</Button>
-*/}
+>
+ Fill out the application form
+</Button>
diff --git a/src/app/conf/2024/speak/index.mdx b/src/app/conf/2024/speak/index.mdx
index 1bb6b63712..4679ec2989 100644
--- a/src/app/conf/2024/speak/index.mdx
+++ b/src/app/conf/2024/speak/index.mdx
@@ -4,11 +4,13 @@ import { Button } from "@/app/conf/_components/button"
**September 10-12, 2024 | San Francisco, CA**
-Putting on an amazing conference depends on great content, which is where you come in! Join
-other GraphQL leaders and community members as a presenter by submitting to our Call for
-Proposals (CFP) and sharing your experience across a wide range of topics.
+Putting on an amazing conference depends on great content, which is where you
+come in! Join other GraphQL leaders and community members as a presenter by
+submitting to our Call for Proposals (CFP) and sharing your experience across a
+wide range of topics.
-For any questions regarding the CFP process, please email cfp@linuxfoundation.org.
+For any questions regarding the CFP process, please email
+cfp@linuxfoundation.org.
export const isExpired = new Date() > new Date("2024/05/22 12:00")
@@ -20,10 +22,12 @@ export const isExpired = new Date() > new Date("2024/05/22 12:00")
{isExpired ? "CFP Closed" : "Submit a Proposal"}
</Button>
-> Please be aware that the Linux Foundation will now be utilizing Sessionize for CFP
-> submissions. Sessionize is a cloud-based event content management software designed to be
-> intuitive and user-friendly. If you need guidance, please review [how to submit your session for
-> an event](https://sessionize.com/playbook/submit-your-session-for-an-event) to see step-by-step instructions and helpful screenshots.
+> Please be aware that the Linux Foundation will now be utilizing Sessionize for
+> CFP submissions. Sessionize is a cloud-based event content management software
+> designed to be intuitive and user-friendly. If you need guidance, please
+> review
+> [how to submit your session for an event](https://sessionize.com/playbook/submit-your-session-for-an-event)
+> to see step-by-step instructions and helpful screenshots.
Click through the tabs on this page to access the information.
@@ -45,92 +49,128 @@ Click through the tabs on this page to access the information.
## Suggested Topics
-{<h3>GraphQL Spec</h3>}
-Latest and greatest developments in the GraphQL specification, reference implementation, and related
-official specifications such as GraphQL-over-HTTP specification.
+{<h3>GraphQL Spec</h3>} Latest and greatest developments in the GraphQL
+specification, reference implementation, and related official specifications
+such as GraphQL-over-HTTP specification.
-{<h3>GraphQL in Production</h3>}
-Best practices, real world use cases, spectacular success, spectacular failures, and lessons
-learned from production deployments of GraphQL.
+{<h3>GraphQL in Production</h3>} Best practices, real world use cases,
+spectacular success, spectacular failures, and lessons learned from production
+deployments of GraphQL.
-{<h3>GraphQL Security</h3>}
-Authentication/authorization, security testing, threat models, GraphQL and OWASP Top 10,
-exploit analysis and retrospective, full-lifecycle security considerations.
+{<h3>GraphQL Security</h3>} Authentication/authorization, security testing,
+threat models, GraphQL and OWASP Top 10, exploit analysis and retrospective,
+full-lifecycle security considerations.
-{<h3>GraphQL Clients</h3>}
-Client development (web, mobile, and beyond) with GraphQL, frontend frameworks, GraphQL
-IDEs.
+{<h3>GraphQL Clients</h3>} Client development (web, mobile, and beyond) with
+GraphQL, frontend frameworks, GraphQL IDEs.
-{<h3>Backend</h3>}
-GraphQL server implementations, data sources for GraphQL resolvers, alternative execution strategies,
-and related backend development concerns.
+{<h3>Backend</h3>} GraphQL server implementations, data sources for GraphQL
+resolvers, alternative execution strategies, and related backend development
+concerns.
-{<h3>Scaling</h3>}
-Everything related to scaling GraphQL: testing, automation, performance, social/organizational
-considerations.
+{<h3>Scaling</h3>} Everything related to scaling GraphQL: testing, automation,
+performance, social/organizational considerations.
-{<h3>GraphQL Academia</h3>}
-Research papers or studies in academia that involve GraphQL.
+{<h3>GraphQL Academia</h3>} Research papers or studies in academia that involve
+GraphQL.
-{<h3>Emerging Community Trends</h3>}
-What’s happening at the vanguard of GraphQL adoption that will help define the future of
-GraphQL usage in the community.
+{<h3>Emerging Community Trends</h3>} What’s happening at the vanguard of GraphQL
+adoption that will help define the future of GraphQL usage in the community.
-{<h3>API Platform</h3>}
-Integration with platform providers/frameworks, serverless, mesh architectures, AI/ML.
+{<h3>API Platform</h3>} Integration with platform providers/frameworks,
+serverless, mesh architectures, AI/ML.
-{<h3>Federation and Composite Schemas</h3>}
-Building a schema from multiple smaller schemas: technologies, experiences, specifications, best
-practices, things to avoid.
+{<h3>Federation and Composite Schemas</h3>} Building a schema from multiple
+smaller schemas: technologies, experiences, specifications, best practices,
+things to avoid.
-{<h3>Developer Experience</h3>}
-The latest and greatest developments in GraphiQL and other GraphQL IDEs, frontend and backend tooling,
-editor integrations, AI assistance and more.
+{<h3>Developer Experience</h3>} The latest and greatest developments in GraphiQL
+and other GraphQL IDEs, frontend and backend tooling, editor integrations, AI
+assistance and more.
-{<h3>Defies Categorization</h3>}
-Have a talk idea that doesn’t fit inside the topics above? Challenge accepted! Wow us with your
-awesome talk submission and we’ll work with you to fit it into our track structure.
+{<h3>Defies Categorization</h3>} Have a talk idea that doesn’t fit inside the
+topics above? Challenge accepted! Wow us with your awesome talk submission and
+we’ll work with you to fit it into our track structure.
## Submission Types
-- **Session Presentation:** Typically 30-40 minutes in length, 1-2 speakers presenting on a topic
-- **Panel Discussion:** Typically 30-40 minutes in length, 3-4 speakers presenting on a topic
+- **Session Presentation:** Typically 30-40 minutes in length, 1-2 speakers
+ presenting on a topic
+- **Panel Discussion:** Typically 30-40 minutes in length, 3-4 speakers
+ presenting on a topic
- **Birds of a Feather:** Typically 45 minutes to 1 hour in length
- **Lightning Talk:** Typically 5-10 minutes in length
- **Workshop:** Typically 1-2 hours in length
## Important Notes
-- All speakers are required to adhere to our [Code of Conduct](/conf/2024/faq/#codeofconduct). We also highly recommend that speakers take our online [Inclusive Speaker Orientation Course](https://training.linuxfoundation.org/linux-courses/open-source-compliance-courses/inclusive-speaker-orientation).
-- Panel submissions must include the names of all participants in the initial submission to be considered. In an effort to promote speaker diversity, The Linux Foundation does not accept submissions with all-male panels, and speakers must not all be from the same company.
-- Complimentary Passes For Speakers – One complimentary pass for the event will be provided for each accepted speaker.
-- Avoid sales or marketing pitches and discussing unlicensed or potentially closed-source technologies when preparing your proposal; these talks are almost always rejected due to the fact that they take away from the integrity of our events, and are rarely well-received by conference attendees.
-- You are allowed to be listed as a speaker on a maximum of two proposals submitted to the CFP, regardless of the format. If you are listed on more than two, we will contact you to remove yourself from any additional proposals.
-- You may only be selected to speak on one panel and one non-panel session per event.
+- All speakers are required to adhere to our
+ [Code of Conduct](/conf/2024/faq/#codeofconduct). We also highly recommend
+ that speakers take our online
+ [Inclusive Speaker Orientation Course](https://training.linuxfoundation.org/linux-courses/open-source-compliance-courses/inclusive-speaker-orientation).
+- Panel submissions must include the names of all participants in the initial
+ submission to be considered. In an effort to promote speaker diversity, The
+ Linux Foundation does not accept submissions with all-male panels, and
+ speakers must not all be from the same company.
+- Complimentary Passes For Speakers – One complimentary pass for the event will
+ be provided for each accepted speaker.
+- Avoid sales or marketing pitches and discussing unlicensed or potentially
+ closed-source technologies when preparing your proposal; these talks are
+ almost always rejected due to the fact that they take away from the integrity
+ of our events, and are rarely well-received by conference attendees.
+- You are allowed to be listed as a speaker on a maximum of two proposals
+ submitted to the CFP, regardless of the format. If you are listed on more than
+ two, we will contact you to remove yourself from any additional proposals.
+- You may only be selected to speak on one panel and one non-panel session per
+ event.
- All accepted speakers are required to submit their slides prior to the event.
## Prepare to Submit
-While it is not our intention to provide you with strict instructions on how to prepare your proposal, we hope you will take a moment to review the following guidelines that we have put together to help you prepare the best submission possible. To get started, here are three things that you should consider before submitting your proposal:
+While it is not our intention to provide you with strict instructions on how to
+prepare your proposal, we hope you will take a moment to review the following
+guidelines that we have put together to help you prepare the best submission
+possible. To get started, here are three things that you should consider before
+submitting your proposal:
1. What are you hoping to get from your presentation?
1. What do you expect the audience to gain from your presentation?
1. How will your presentation help better the ecosystem?
-There are plenty of ways to give a presentation about projects and technologies without focusing on company-specific efforts. Remember the things to consider that we mentioned above when writing your proposal and think of ways to make it interesting for attendees while still letting you share your experiences, educate the community about an issue, or generate interest in a project.
+There are plenty of ways to give a presentation about projects and technologies
+without focusing on company-specific efforts. Remember the things to consider
+that we mentioned above when writing your proposal and think of ways to make it
+interesting for attendees while still letting you share your experiences,
+educate the community about an issue, or generate interest in a project.
{<h3>Writing Your Proposal</h3>}
-Your abstract title will be the main point of reference for attendees to decide if they want to attend your talk, so choose it carefully. The title should accurately reflect the content of your talk. Speakers are required to adhere to our [Code of Conduct](https://events.linuxfoundation.org/about/code-of-conduct). We also highly recommend that speakers take our online [Inclusive Speaker Orientation Course](https://training.linuxfoundation.org/linux-courses/open-source-compliance-courses/inclusive-speaker-orientation).
+Your abstract title will be the main point of reference for attendees to decide
+if they want to attend your talk, so choose it carefully. The title should
+accurately reflect the content of your talk. Speakers are required to adhere to
+our [Code of Conduct](https://events.linuxfoundation.org/about/code-of-conduct).
+We also highly recommend that speakers take our online
+[Inclusive Speaker Orientation Course](https://training.linuxfoundation.org/linux-courses/open-source-compliance-courses/inclusive-speaker-orientation).
{<h3>How to Give a Great Talk</h3>}
-We want to make sure submitters receive resources to help put together a great submission and if accepted, give the best presentation possible. To help with this, we recommend viewing seasoned speaker Dawn Foster’s in-depth talk: [Getting Over Your Imposter Syndrome to Become a Conference Speaker – Dawn Foster, VMware](https://youtu.be/2I5fYBLCfUA).
+We want to make sure submitters receive resources to help put together a great
+submission and if accepted, give the best presentation possible. To help with
+this, we recommend viewing seasoned speaker Dawn Foster’s in-depth talk:
+[Getting Over Your Imposter Syndrome to Become a Conference Speaker – Dawn Foster, VMware](https://youtu.be/2I5fYBLCfUA).
{<h3>Have More Questions? First Time Submitting? Don’t Feel Intimidated</h3>}
-Linux Foundation events are an excellent way to get to know the community and share your ideas and the work that you are doing and we strongly encourage first-time speakers to submit talks for our events. In the instance that you aren’t sure about your abstract, [reach out to us](mailto:cfp@linuxfoundation.org) and we will be more than happy to work with you on your proposal.
+Linux Foundation events are an excellent way to get to know the community and
+share your ideas and the work that you are doing and we strongly encourage
+first-time speakers to submit talks for our events. In the instance that you
+aren’t sure about your abstract,
+[reach out to us](mailto:cfp@linuxfoundation.org) and we will be more than happy
+to work with you on your proposal.
## Code of Conduct
-The Linux Foundation is dedicated to providing a harassment-free experience for participants at all of our events. We encourage all submitters to review our complete [Code of Conduct](https://events.linuxfoundation.org/about/code-of-conduct).
+The Linux Foundation is dedicated to providing a harassment-free experience for
+participants at all of our events. We encourage all submitters to review our
+complete
+[Code of Conduct](https://events.linuxfoundation.org/about/code-of-conduct).
diff --git a/src/pages/blog.mdx b/src/pages/blog.mdx
index df349e7b40..e48c5ed59e 100644
--- a/src/pages/blog.mdx
+++ b/src/pages/blog.mdx
@@ -7,10 +7,10 @@ import { clsx } from "clsx"
export default function Blog() {
const { asPath } = useRouter()
- const items = getPagesUnderRoute("/blog").flatMap(item => item.children || item)
- const blogs = items.sort(
- (a, b) => b.frontMatter.date - a.frontMatter.date,
+ const items = getPagesUnderRoute("/blog").flatMap(
+ item => item.children || item
)
+ const blogs = items.sort((a, b) => b.frontMatter.date - a.frontMatter.date)
const currentTag = asPath.startsWith("/blog")
? ""
: asPath.replace("/tags/", "").replace(/\/$/, "")
@@ -24,7 +24,7 @@ export default function Blog() {
}, {})
//
const tagList = (
- <div className="flex gap-3 md:gap-5 mt-6 flex-wrap roboto-mono">
+ <div className="roboto-mono mt-6 flex flex-wrap gap-3 md:gap-5">
{Object.entries(tags)
.sort((a, b) => b[1] - a[1])
.map(([tag, count]) => (
@@ -32,7 +32,7 @@ export default function Blog() {
key={tag}
href={currentTag === tag ? "/blog" : `/tags/${tag}`}
data-active={currentTag === tag ? "" : undefined}
- className={clsx("tag [&[data-active]]:bg-primary capitalize")}
+ className={clsx("tag capitalize [&[data-active]]:bg-primary")}
>
{tag.replaceAll("-", " ")} ({count})
</NextLink>
@@ -49,39 +49,39 @@ export default function Blog() {
href={page.route}
className="flex flex-col"
>
- <div className="gap-2 flex mb-7">
+ <div className="mb-7 flex gap-2">
{page.frontMatter.tags.map(tag => (
<Tag key={tag}>{tag.replaceAll("-", " ")}</Tag>
))}
</div>
- <div className="font-extrabold text-xl md:text-3xl text-balance">
+ <div className="text-balance text-xl font-extrabold md:text-3xl">
{page.frontMatter.title}
</div>
- <div className="opacity-50 text-sm my-7 flex gap-2">
+ <div className="my-7 flex gap-2 text-sm opacity-50">
<time dateTime={page.frontMatter.date.toISOString()}>
{page.frontMatter.date.toLocaleDateString("en", {
month: "long",
day: "numeric",
- year: "numeric",
+ year: "numeric"
})}
</time>
<span className="border-r border-gray-500" />
<span>by {page.frontMatter.byline}</span>
</div>
- <span className="text-primary block font-bold mt-auto">
+ <span className="mt-auto block font-bold text-primary">
Read more →
</span>
</Card>
- ),
+ )
)
return (
<>
- <div className="py-10 md:py-20 container">
- <h1 className="text-4xl md:text-7xl font-extrabold mb-10">Blog</h1>
+ <div className="container py-10 md:py-20">
+ <h1 className="mb-10 text-4xl font-extrabold md:text-7xl">Blog</h1>
<h3 className="text-2xl font-bold">Categories</h3>
{tagList}
</div>
- <div className="container grid md:grid-cols-2 gap-7 pb-10">
+ <div className="container grid gap-7 pb-10 md:grid-cols-2">
{blogList}
</div>
</>
diff --git a/src/pages/blog/2015-09-14-graphql.mdx b/src/pages/blog/2015-09-14-graphql.mdx
index 97cd48527c..1f9cfa5b45 100644
--- a/src/pages/blog/2015-09-14-graphql.mdx
+++ b/src/pages/blog/2015-09-14-graphql.mdx
@@ -5,21 +5,46 @@ date: 2015-09-14
byline: "Lee Byron"
---
-When we built Facebook's mobile applications, we needed a data-fetching API powerful enough to describe all of Facebook, yet simple and easy to learn so product developers can focus on building things quickly. We developed GraphQL three years ago to fill this need. Today it powers hundreds of billions of API calls a day. This year we've begun the process of open-sourcing GraphQL by drafting a specification, releasing a reference implementation, and forming a community around it here at [graphql.org](/).
+When we built Facebook's mobile applications, we needed a data-fetching API
+powerful enough to describe all of Facebook, yet simple and easy to learn so
+product developers can focus on building things quickly. We developed GraphQL
+three years ago to fill this need. Today it powers hundreds of billions of API
+calls a day. This year we've begun the process of open-sourcing GraphQL by
+drafting a specification, releasing a reference implementation, and forming a
+community around it here at [graphql.org](/).
## Why GraphQL?
-Back in 2012, we began an effort to rebuild Facebook's native mobile applications.
-
-At the time, our iOS and Android apps were thin wrappers around views of our mobile website. While this brought us close to a platonic ideal of the "write one, run anywhere" mobile application, in practice it pushed our mobile-webview apps beyond their limits. As Facebook's mobile apps became more complex, they suffered poor performance and frequently crashed.
-
-As we transitioned to natively implemented models and views, we found ourselves for the first time needing an API data version of News Feed — which up until that point had only been delivered as HTML. We evaluated our options for delivering News Feed data to our mobile apps, including RESTful server resources and FQL tables (Facebook's SQL-like API). We were frustrated with the differences between the data we wanted to use in our apps and the server queries they required. We don't think of data in terms of resource URLs, secondary keys, or join tables; we think about it in terms of a graph of objects and the models we ultimately use in our apps like NSObjects or JSON.
-
-There was also a considerable amount of code to write on both the server to prepare the data and on the client to parse it. This frustration inspired a few of us to start the project that ultimately became GraphQL. GraphQL was our opportunity to rethink mobile app data-fetching from the perspective of product designers and developers. It moved the focus of development to the client apps, where designers and developers spend their time and attention.
+Back in 2012, we began an effort to rebuild Facebook's native mobile
+applications.
+
+At the time, our iOS and Android apps were thin wrappers around views of our
+mobile website. While this brought us close to a platonic ideal of the "write
+one, run anywhere" mobile application, in practice it pushed our mobile-webview
+apps beyond their limits. As Facebook's mobile apps became more complex, they
+suffered poor performance and frequently crashed.
+
+As we transitioned to natively implemented models and views, we found ourselves
+for the first time needing an API data version of News Feed — which up until
+that point had only been delivered as HTML. We evaluated our options for
+delivering News Feed data to our mobile apps, including RESTful server resources
+and FQL tables (Facebook's SQL-like API). We were frustrated with the
+differences between the data we wanted to use in our apps and the server queries
+they required. We don't think of data in terms of resource URLs, secondary keys,
+or join tables; we think about it in terms of a graph of objects and the models
+we ultimately use in our apps like NSObjects or JSON.
+
+There was also a considerable amount of code to write on both the server to
+prepare the data and on the client to parse it. This frustration inspired a few
+of us to start the project that ultimately became GraphQL. GraphQL was our
+opportunity to rethink mobile app data-fetching from the perspective of product
+designers and developers. It moved the focus of development to the client apps,
+where designers and developers spend their time and attention.
## What is GraphQL?
-A GraphQL query is a string that is sent to a server to be interpreted and fulfilled, which then returns JSON back to the client.
+A GraphQL query is a string that is sent to a server to be interpreted and
+fulfilled, which then returns JSON back to the client.
```graphql
# { "graphiql": true, "schema": "Users" }
@@ -44,15 +69,40 @@ A GraphQL query is a string that is sent to a server to be interpreted and fulfi
}
```
-**Defines a data shape:** The first thing you'll notice is that GraphQL queries mirror their response. This makes it easy to predict the shape of the data returned from a query, as well as to write a query if you know the data your app needs. More important, this makes GraphQL really easy to learn and use. GraphQL is unapologetically driven by the data requirements of products and of the designers and developers who build them.
-
-**Hierarchical:** Another important aspect of GraphQL is its hierarchical nature. GraphQL naturally follows relationships between objects, where a RESTful service may require multiple round-trips (resource-intensive on mobile networks) or a complex join statement in SQL. This data hierarchy pairs well with graph-structured data stores and ultimately with the hierarchical user interfaces it's used within.
-
-**Strongly typed:** Each level of a GraphQL query corresponds to a particular type, and each type describes a set of available fields. Similar to SQL, this allows GraphQL to provide descriptive error messages before executing a query. It also plays well with the strongly typed native environments of Obj-C and Java.
-
-**Protocol, not storage:** Each GraphQL field on the server is backed by a function - code linking to your application layer. While we were building GraphQL to support News Feed, we already had a sophisticated feed ranking and storage model, along with existing databases and business logic. GraphQL had to leverage all this existing work to be useful, and so does not dictate or provide any backing storage. Instead, GraphQL takes advantage of your existing code by exposing your application layer, not your storage layer.
-
-**Introspective:** A GraphQL server can be queried for the types it supports. This creates a powerful platform for tools and client software to build atop this information like code generation in statically typed languages, our application framework, Relay, or IDEs like GraphiQL (pictured below). GraphiQL helps developers learn and explore an API quickly without grepping the codebase or wrangling with cURL.
+**Defines a data shape:** The first thing you'll notice is that GraphQL queries
+mirror their response. This makes it easy to predict the shape of the data
+returned from a query, as well as to write a query if you know the data your app
+needs. More important, this makes GraphQL really easy to learn and use. GraphQL
+is unapologetically driven by the data requirements of products and of the
+designers and developers who build them.
+
+**Hierarchical:** Another important aspect of GraphQL is its hierarchical
+nature. GraphQL naturally follows relationships between objects, where a RESTful
+service may require multiple round-trips (resource-intensive on mobile networks)
+or a complex join statement in SQL. This data hierarchy pairs well with
+graph-structured data stores and ultimately with the hierarchical user
+interfaces it's used within.
+
+**Strongly typed:** Each level of a GraphQL query corresponds to a particular
+type, and each type describes a set of available fields. Similar to SQL, this
+allows GraphQL to provide descriptive error messages before executing a query.
+It also plays well with the strongly typed native environments of Obj-C and
+Java.
+
+**Protocol, not storage:** Each GraphQL field on the server is backed by a
+function - code linking to your application layer. While we were building
+GraphQL to support News Feed, we already had a sophisticated feed ranking and
+storage model, along with existing databases and business logic. GraphQL had to
+leverage all this existing work to be useful, and so does not dictate or provide
+any backing storage. Instead, GraphQL takes advantage of your existing code by
+exposing your application layer, not your storage layer.
+
+**Introspective:** A GraphQL server can be queried for the types it supports.
+This creates a powerful platform for tools and client software to build atop
+this information like code generation in statically typed languages, our
+application framework, Relay, or IDEs like GraphiQL (pictured below). GraphiQL
+helps developers learn and explore an API quickly without grepping the codebase
+or wrangling with cURL.
```graphql
# { "graphiql": true, "schema": "Users" }
@@ -69,15 +119,53 @@ A GraphQL query is a string that is sent to a server to be interpreted and fulfi
}
```
-**Version free:** The shape of the returned data is determined entirely by the client's query, so servers become simpler and easy to generalize. When you're adding new product features, additional fields can be added to the server, leaving existing clients unaffected. When you're sunsetting older features, the corresponding server fields can be deprecated but continue to function. This gradual, backward-compatible process removes the need for an incrementing version number. We still support three years of released Facebook applications on a single version of our GraphQL API.
-
-With GraphQL, we were able to build full-featured native News Feed on iOS in 2012, and on Android shortly after. Since then, GraphQL has become the primary way we build our mobile apps and the servers that power them. More than three years later, GraphQL powers almost all data-fetching in our mobile applications, serving millions of requests per second from nearly 1,000 shipped application versions.
-
-When we built GraphQL in 2012 we had no idea how important it would become to how we build things at Facebook and didn't anticipate its value beyond Facebook. However, earlier this year we announced Relay, our application framework for the web and React Native built atop GraphQL. The community excitement for Relay inspired us to revisit GraphQL to evaluate every detail, make improvements, fix inconsistencies, and write a specification describing GraphQL and how it works.
-
-Two months ago, we [made our progress public](https://youtube.com/watch?v=WQLzZf34FJ8) and released a working draft of the [GraphQL spec](https://spec.graphql.org) and a reference implementation: [GraphQL.js](https://github.com/graphql/graphql-js). Since then, a community has started to form around GraphQL, and versions of the GraphQL runtime are being [built in many languages](https://github.com/chentsulin/awesome-graphql), including Go, Ruby, Scala, Java, .Net, and Python. We've also begun to share some of the tools we use internally, like [GraphiQL](https://github.com/graphql/graphiql), an in-browser IDE, documentation browser, and query runner. GraphQL has also seen production usage outside Facebook, in a project for the [_Financial Times_](https://youtube.com/watch?v=S0s935RKKB4) by consultancy [Red Badger](http://red-badger.com).
-
-“GraphQL makes orchestrating data fetching so much simpler, and it pretty much functions as a perfect isolation point between the front end and the back end”
-— Viktor Charypar, software engineer at Red Badger
-
-While GraphQL is an established part of building products at Facebook, its use beyond Facebook is just beginning. Try out [GraphiQL](http://graphql-swapi.parseapp.com/graphiql) and help provide feedback on our [specification](https://github.com/facebook/graphql). We think GraphQL can greatly simplify data needs for both client product developers and server-side engineers, regardless of what languages you're using in either environment, and we're excited to continue to improve GraphQL, help a community grow around it, and see what we can build together.
+**Version free:** The shape of the returned data is determined entirely by the
+client's query, so servers become simpler and easy to generalize. When you're
+adding new product features, additional fields can be added to the server,
+leaving existing clients unaffected. When you're sunsetting older features, the
+corresponding server fields can be deprecated but continue to function. This
+gradual, backward-compatible process removes the need for an incrementing
+version number. We still support three years of released Facebook applications
+on a single version of our GraphQL API.
+
+With GraphQL, we were able to build full-featured native News Feed on iOS in
+2012, and on Android shortly after. Since then, GraphQL has become the primary
+way we build our mobile apps and the servers that power them. More than three
+years later, GraphQL powers almost all data-fetching in our mobile applications,
+serving millions of requests per second from nearly 1,000 shipped application
+versions.
+
+When we built GraphQL in 2012 we had no idea how important it would become to
+how we build things at Facebook and didn't anticipate its value beyond Facebook.
+However, earlier this year we announced Relay, our application framework for the
+web and React Native built atop GraphQL. The community excitement for Relay
+inspired us to revisit GraphQL to evaluate every detail, make improvements, fix
+inconsistencies, and write a specification describing GraphQL and how it works.
+
+Two months ago, we
+[made our progress public](https://youtube.com/watch?v=WQLzZf34FJ8) and released
+a working draft of the [GraphQL spec](https://spec.graphql.org) and a reference
+implementation: [GraphQL.js](https://github.com/graphql/graphql-js). Since then,
+a community has started to form around GraphQL, and versions of the GraphQL
+runtime are being
+[built in many languages](https://github.com/chentsulin/awesome-graphql),
+including Go, Ruby, Scala, Java, .Net, and Python. We've also begun to share
+some of the tools we use internally, like
+[GraphiQL](https://github.com/graphql/graphiql), an in-browser IDE,
+documentation browser, and query runner. GraphQL has also seen production usage
+outside Facebook, in a project for the
+[_Financial Times_](https://youtube.com/watch?v=S0s935RKKB4) by consultancy
+[Red Badger](http://red-badger.com).
+
+“GraphQL makes orchestrating data fetching so much simpler, and it pretty much
+functions as a perfect isolation point between the front end and the back end” —
+Viktor Charypar, software engineer at Red Badger
+
+While GraphQL is an established part of building products at Facebook, its use
+beyond Facebook is just beginning. Try out
+[GraphiQL](http://graphql-swapi.parseapp.com/graphiql) and help provide feedback
+on our [specification](https://github.com/facebook/graphql). We think GraphQL
+can greatly simplify data needs for both client product developers and
+server-side engineers, regardless of what languages you're using in either
+environment, and we're excited to continue to improve GraphQL, help a community
+grow around it, and see what we can build together.
diff --git a/src/pages/blog/2015-10-16-subscriptions.mdx b/src/pages/blog/2015-10-16-subscriptions.mdx
index 5a0318ebd7..f37cbff8e2 100644
--- a/src/pages/blog/2015-10-16-subscriptions.mdx
+++ b/src/pages/blog/2015-10-16-subscriptions.mdx
@@ -5,39 +5,67 @@ date: 2015-10-16
byline: Dan Schafer and Laney Kuenzel
---
-When we announced and open-sourced GraphQL and Relay this year, we described how they can be used to perform reads with queries, and to perform writes with mutations. However, oftentimes clients want to get pushed updates from the server when data they care about changes. To support that, we’ve introduced a third operation into the GraphQL specification: subscription.
+When we announced and open-sourced GraphQL and Relay this year, we described how
+they can be used to perform reads with queries, and to perform writes with
+mutations. However, oftentimes clients want to get pushed updates from the
+server when data they care about changes. To support that, we’ve introduced a
+third operation into the GraphQL specification: subscription.
## Event-based subscriptions
-The approach that we’ve taken to subscriptions parallels that of mutations; just as the list of mutations that the server supports describes all of the actions that a client can take, the list of subscriptions that the server supports describes all of the events that it can subscribe to. Just as a client can tell the server what data to refetch after it performs a mutation with a GraphQL selection, the client can tell the server what data it wants to be pushed with the subscription with a GraphQL selection.
+The approach that we’ve taken to subscriptions parallels that of mutations; just
+as the list of mutations that the server supports describes all of the actions
+that a client can take, the list of subscriptions that the server supports
+describes all of the events that it can subscribe to. Just as a client can tell
+the server what data to refetch after it performs a mutation with a GraphQL
+selection, the client can tell the server what data it wants to be pushed with
+the subscription with a GraphQL selection.
-For example, in the Facebook schema, we have a mutation field named `storyLike`, that clients can use to like a post. The client might want to refetch the like count, as well as the like sentence (“Dan and 3 others like this”. We do this translation on the server because of the complexity of that translation in various languages). To do so, they would issue the following mutation:
+For example, in the Facebook schema, we have a mutation field named `storyLike`,
+that clients can use to like a post. The client might want to refetch the like
+count, as well as the like sentence (“Dan and 3 others like this”. We do this
+translation on the server because of the complexity of that translation in
+various languages). To do so, they would issue the following mutation:
```graphql
mutation StoryLikeMutation($input: StoryLikeInput) {
storyLike(input: $input) {
story {
- likers { count }
- likeSentence { text }
+ likers {
+ count
+ }
+ likeSentence {
+ text
+ }
}
}
}
```
-But when you’re looking at a post, you also want to get pushed an update whenever someone else likes the post! That’s where subscriptions come in; the Facebook schema has a subscription field named `storyLikeSubscribe` that allows the client to get pushed data anytime someone likes or unlikes that story! The client would create a subscription like this:
+But when you’re looking at a post, you also want to get pushed an update
+whenever someone else likes the post! That’s where subscriptions come in; the
+Facebook schema has a subscription field named `storyLikeSubscribe` that allows
+the client to get pushed data anytime someone likes or unlikes that story! The
+client would create a subscription like this:
```graphql
subscription StoryLikeSubscription($input: StoryLikeSubscribeInput) {
storyLikeSubscribe(input: $input) {
story {
- likers { count }
- likeSentence { text }
+ likers {
+ count
+ }
+ likeSentence {
+ text
+ }
}
}
}
```
-The client would then send this subscription to the server, along with the value for the `$input` variable, which would contain information like the story ID to which we are subscribing:
+The client would then send this subscription to the server, along with the value
+for the `$input` variable, which would contain information like the story ID to
+which we are subscribing:
```graphql
input StoryLikeSubscribeInput {
@@ -46,21 +74,33 @@ input StoryLikeSubscribeInput {
}
```
-At Facebook, we send this query to the server at build time to generate a unique ID for it, then subscribe to a special MQTT topic with the subscription ID in it, but many different subscription mechanisms could be used here.
+At Facebook, we send this query to the server at build time to generate a unique
+ID for it, then subscribe to a special MQTT topic with the subscription ID in
+it, but many different subscription mechanisms could be used here.
-On the server, we then trigger this subscription every time someone likes a post. If all of our clients were using GraphQL, we could put this hook in the GraphQL mutation; since we have non-GraphQL clients as well, we put the hook in a layer below the GraphQL mutation to ensure it always fires.
+On the server, we then trigger this subscription every time someone likes a
+post. If all of our clients were using GraphQL, we could put this hook in the
+GraphQL mutation; since we have non-GraphQL clients as well, we put the hook in
+a layer below the GraphQL mutation to ensure it always fires.
## Why not Live Queries?
-Notably, this approach requires the client to subscribe to events that it cares about. Another approach is to have the client subscribe to a query, and ask for updates every time the result of that query changes. Why didn’t we take that approach?
+Notably, this approach requires the client to subscribe to events that it cares
+about. Another approach is to have the client subscribe to a query, and ask for
+updates every time the result of that query changes. Why didn’t we take that
+approach?
Let’s look back at the data we wanted to refetch for the story:
```graphql
fragment StoryLikeData on Story {
story {
- likers { count }
- likeSentence { text }
+ likers {
+ count
+ }
+ likeSentence {
+ text
+ }
}
}
```
@@ -69,20 +109,49 @@ What events could trigger that a change to the data fetched in that fragment?
- Someone likes the post.
- Someone unlikes the post.
-- Someone who had liked the post deactivates their account (changes the like count down one, changes the like sentence to decrement the translated count).
-- Someone who had liked the post reactivates their account (changes the like count up one, changes the like sentence to increment the translated count).
-- Someone who had liked the post blocks you (cannot show them in the like sentence).
-- Someone who had liked the post changes their name (need to update the text of the like sentence).
-- Our internal ranking model for the ordering of names in the like sentence updates, and we should be listing a different person first (want to update the text of the like sentence).
-
-And that’s just the tip of the iceberg in terms of events; each of those events also becomes tricky when there are thousands of people subscribed, and millions of people who liked the post. Implementing live queries for this set of data proved to be immensely complicated.
-
-When building event-based subscriptions, the problem of determining what should trigger an event is easy, since the event defines that explicitly. It also proved fairly straight-forward to implement atop existing message queue systems. For live queries, though, this appeared much harder. The value of our fields is determined by the result of their resolve function, and figuring out all of the things that could alter the result of that function was difficult. We could in theory have polled on the server to implement this, but that had efficiency and timeliness issues. Based on this, we decided to invest in the event-based subscription approach.
+- Someone who had liked the post deactivates their account (changes the like
+ count down one, changes the like sentence to decrement the translated count).
+- Someone who had liked the post reactivates their account (changes the like
+ count up one, changes the like sentence to increment the translated count).
+- Someone who had liked the post blocks you (cannot show them in the like
+ sentence).
+- Someone who had liked the post changes their name (need to update the text of
+ the like sentence).
+- Our internal ranking model for the ordering of names in the like sentence
+ updates, and we should be listing a different person first (want to update the
+ text of the like sentence).
+
+And that’s just the tip of the iceberg in terms of events; each of those events
+also becomes tricky when there are thousands of people subscribed, and millions
+of people who liked the post. Implementing live queries for this set of data
+proved to be immensely complicated.
+
+When building event-based subscriptions, the problem of determining what should
+trigger an event is easy, since the event defines that explicitly. It also
+proved fairly straight-forward to implement atop existing message queue systems.
+For live queries, though, this appeared much harder. The value of our fields is
+determined by the result of their resolve function, and figuring out all of the
+things that could alter the result of that function was difficult. We could in
+theory have polled on the server to implement this, but that had efficiency and
+timeliness issues. Based on this, we decided to invest in the event-based
+subscription approach.
## What’s next?
-We’re actively building out the event-based subscription approach described above. We’ve built out live liking and commenting features on our iOS and Android apps using that approach, and are continuing to flesh out its functionality and API. While its current implementation at Facebook is coupled to Facebook’s infrastructure, we’re certainly looking forward to open sourcing our progress here as soon as we can.
-
-Because our backend and schema don’t offer easy support for live queries, we don’t have any plans to develop them at Facebook. At the same time, it’s clear that there are backends and schemas for which live queries are feasible, and that they offer a lot of value in those situations. The discussion in the community on this topic has been fantastic, and we’re excited to see what kind of live query proposals emerge from it!
-
-Subscriptions create a ton of possibilities for creating truly dynamic applications. We’re excited to continue developing GraphQL and Relay with the help of the community to enable these possibilities.
+We’re actively building out the event-based subscription approach described
+above. We’ve built out live liking and commenting features on our iOS and
+Android apps using that approach, and are continuing to flesh out its
+functionality and API. While its current implementation at Facebook is coupled
+to Facebook’s infrastructure, we’re certainly looking forward to open sourcing
+our progress here as soon as we can.
+
+Because our backend and schema don’t offer easy support for live queries, we
+don’t have any plans to develop them at Facebook. At the same time, it’s clear
+that there are backends and schemas for which live queries are feasible, and
+that they offer a lot of value in those situations. The discussion in the
+community on this topic has been fantastic, and we’re excited to see what kind
+of live query proposals emerge from it!
+
+Subscriptions create a ton of possibilities for creating truly dynamic
+applications. We’re excited to continue developing GraphQL and Relay with the
+help of the community to enable these possibilities.
diff --git a/src/pages/blog/2016-04-19-mocking.mdx b/src/pages/blog/2016-04-19-mocking.mdx
index f77a19880b..2801432c57 100644
--- a/src/pages/blog/2016-04-19-mocking.mdx
+++ b/src/pages/blog/2016-04-19-mocking.mdx
@@ -6,40 +6,86 @@ byline: "Jonas Helfer"
guestBio: engineer at Meteor working on Apollo
---
-Do you think mocking your backend is always a tedious task? If you do, reading this post might change your mind…
-
-Mocking is the practice of creating a fake version of a component, so that you can develop and test other parts of your application independently. Mocking your backend is a great way to quickly build a prototype of your frontend, and it lets you test your frontend without starting up any servers. API mocking is so useful that a [quick Google search](https://www.google.com/?ion=1&espv=2#q=mock+rest+api) will turn up dozens of expensive products and services that promise to help you.
-
-Sadly, I think none of the solutions out there make it as easy as it should be. As it turns out, that’s because they’ve been trying to do it with the wrong technology!
-
-> Editor’s note : The concepts in this post are accurate, but some the code samples don’t demonstrate new usage patterns. After reading, consult the [graphql-tools docs](http://dev.apollodata.com/tools/graphql-tools/mocking.html) to see how to use mocking today.
+Do you think mocking your backend is always a tedious task? If you do, reading
+this post might change your mind…
+
+Mocking is the practice of creating a fake version of a component, so that you
+can develop and test other parts of your application independently. Mocking your
+backend is a great way to quickly build a prototype of your frontend, and it
+lets you test your frontend without starting up any servers. API mocking is so
+useful that a
+[quick Google search](https://www.google.com/?ion=1&espv=2#q=mock+rest+api) will
+turn up dozens of expensive products and services that promise to help you.
+
+Sadly, I think none of the solutions out there make it as easy as it should be.
+As it turns out, that’s because they’ve been trying to do it with the wrong
+technology!
+
+> Editor’s note : The concepts in this post are accurate, but some the code
+> samples don’t demonstrate new usage patterns. After reading, consult the
+> [graphql-tools docs](http://dev.apollodata.com/tools/graphql-tools/mocking.html)
+> to see how to use mocking today.
## Why mock?
Mocking the data a backend would return is very useful for two main reasons:
-1. It lets you start developing a frontend feature when you don’t have a working backend for it yet. This is critical for projects where the frontend and backend components are often developed in parallel.
-2. It lets you run tests locally without connecting to a real backend, which is much faster and safer. As your codebase grows and your app becomes more complex, starting up all of the server infrastructure just to run some tests isn’t feasible.
+1. It lets you start developing a frontend feature when you don’t have a working
+ backend for it yet. This is critical for projects where the frontend and
+ backend components are often developed in parallel.
+2. It lets you run tests locally without connecting to a real backend, which is
+ much faster and safer. As your codebase grows and your app becomes more
+ complex, starting up all of the server infrastructure just to run some tests
+ isn’t feasible.
-If mocking your backend API has such clear benefits, why doesn’t everyone do it? I think it's because mocking often seems like too much trouble to be worth it.
+If mocking your backend API has such clear benefits, why doesn’t everyone do it?
+I think it's because mocking often seems like too much trouble to be worth it.
## Why is mocking backends hard?
-Let’s say your backend is some REST API that is called over HTTP from the browser. You have someone working on the backend, and someone else working on the frontend. The backend code actually determines the shape of the data returned for each REST endpoint, but mocking has to be done in the frontend code. That means the mocking code will break every time the backend changes, unless both are changed at the same time. What’s worse, if you’re doing your frontend testing against a mock backend that is not up to date with your backend, your tests may pass, but your actual frontend won’t work.
-
-Rather than having to keep more dependencies up to date, the easy option is to just not mock the REST API, or have the backend be in charge of mocking itself, just so it’s all in one place. That may be easier, but it will also slow you down.
-
-The other reason I often hear for why people don’t mock the backend in their project is because it takes time to set up: first you have to include extra logic in your data fetching layer that lets you turn mocking on and off, and second you have to actually describe what that mock data should look like. For any non-trivial API that requires a lot of tedious work.
-
-Both of these reasons for why mocking backends is hard are actually due to the same underlying reason: there is no standard REST API description in machine-consumable format and contains all the information necessary for mocking and can be used by both the backend and the frontend. There are some API description standards, like Swagger, but they don’t contain all of the information you need, and can be cumbersome to write and maintain. Unless you want to pay for a service or a product — and maybe even then — mocking is a lot of work.
-
-Actually, I should say mocking used to be a lot of work, because a new technology is changing the way we think of APIs: GraphQL.
+Let’s say your backend is some REST API that is called over HTTP from the
+browser. You have someone working on the backend, and someone else working on
+the frontend. The backend code actually determines the shape of the data
+returned for each REST endpoint, but mocking has to be done in the frontend
+code. That means the mocking code will break every time the backend changes,
+unless both are changed at the same time. What’s worse, if you’re doing your
+frontend testing against a mock backend that is not up to date with your
+backend, your tests may pass, but your actual frontend won’t work.
+
+Rather than having to keep more dependencies up to date, the easy option is to
+just not mock the REST API, or have the backend be in charge of mocking itself,
+just so it’s all in one place. That may be easier, but it will also slow you
+down.
+
+The other reason I often hear for why people don’t mock the backend in their
+project is because it takes time to set up: first you have to include extra
+logic in your data fetching layer that lets you turn mocking on and off, and
+second you have to actually describe what that mock data should look like. For
+any non-trivial API that requires a lot of tedious work.
+
+Both of these reasons for why mocking backends is hard are actually due to the
+same underlying reason: there is no standard REST API description in
+machine-consumable format and contains all the information necessary for mocking
+and can be used by both the backend and the frontend. There are some API
+description standards, like Swagger, but they don’t contain all of the
+information you need, and can be cumbersome to write and maintain. Unless you
+want to pay for a service or a product — and maybe even then — mocking is a lot
+of work.
+
+Actually, I should say mocking used to be a lot of work, because a new
+technology is changing the way we think of APIs: GraphQL.
## Mocking is easy with a type system!
-GraphQL makes mocking easy, because every GraphQL backend comes with a static type system. The types can be shared between your backend and your frontend, and they contain all of the information necessary to make mocking incredibly fast and convenient. With GraphQL, there is no excuse to not mock your backend for development or testing.
+GraphQL makes mocking easy, because every GraphQL backend comes with a static
+type system. The types can be shared between your backend and your frontend, and
+they contain all of the information necessary to make mocking incredibly fast
+and convenient. With GraphQL, there is no excuse to not mock your backend for
+development or testing.
-Here’s how easy it is to create a mocked backend that will accept any valid GraphQL query with the GraphQL mocking tool we are building as part of our new [GraphQL server toolkit](https://github.com/apollostack/graphql-tools):
+Here’s how easy it is to create a mocked backend that will accept any valid
+GraphQL query with the GraphQL mocking tool we are building as part of our new
+[GraphQL server toolkit](https://github.com/apollostack/graphql-tools):
```js
// > npm install graphql-tools
@@ -65,17 +111,34 @@ myMockServer.query(`{
// }
```
-Every GraphQL server needs a schema, so it’s not extra code you need to write just for mocking. And the query is the one your component already uses for fetching data, so that’s also not code you write just for mocking. Not counting the import statement, it only took us one line of code to mock the entire backend!
+Every GraphQL server needs a schema, so it’s not extra code you need to write
+just for mocking. And the query is the one your component already uses for
+fetching data, so that’s also not code you write just for mocking. Not counting
+the import statement, it only took us one line of code to mock the entire
+backend!
-Put that in contrast to most REST APIs out there, where mocking means parsing a URL and returning data in a custom shape for each endpoint. It takes dozens of lines to mock a single endpoint that returns some realistic-looking data. With GraphQL, the shape is encoded in the query, and together with the schema we have enough information to mock the server with a single line of code.
+Put that in contrast to most REST APIs out there, where mocking means parsing a
+URL and returning data in a custom shape for each endpoint. It takes dozens of
+lines to mock a single endpoint that returns some realistic-looking data. With
+GraphQL, the shape is encoded in the query, and together with the schema we have
+enough information to mock the server with a single line of code.
-Did I mention that this one line is all you need to return mock data for any valid GraphQL query you could send? Not just some valid query, any valid query! Pretty cool, right?
+Did I mention that this one line is all you need to return mock data for any
+valid GraphQL query you could send? Not just some valid query, any valid query!
+Pretty cool, right?
## Customizing mock data
-In the example above, the mock server will return completely random IDs and strings every time you query it. When you’ve just started building your app and only want to see what your UI code looks like in different states, that’s probably good enough, but as you start to fine-tune your layout, or want to use the mock server to test your component’s logic, you’ll probably need more realistic data.
+In the example above, the mock server will return completely random IDs and
+strings every time you query it. When you’ve just started building your app and
+only want to see what your UI code looks like in different states, that’s
+probably good enough, but as you start to fine-tune your layout, or want to use
+the mock server to test your component’s logic, you’ll probably need more
+realistic data.
-Luckily, this takes only a little more effort: customization of mock data is really where the Apollo mocking tool shines, because it lets you customize virtually everything about the mock data that it returns.
+Luckily, this takes only a little more effort: customization of mock data is
+really where the Apollo mocking tool shines, because it lets you customize
+virtually everything about the mock data that it returns.
It lets you do all of the following and more:
@@ -84,14 +147,14 @@ It lets you do all of the following and more:
mockServer(schema, {
Int: () => 6,
Float: () => 22.1,
- String: () => 'Hello'
+ String: () => "Hello"
})
// customize mocking per field in the schema (i.e. for Person.name and Person.age)
mockServer(schema, {
Person: () => ({
name: casual.name,
- age: () => casual.integer(0,120)
+ age: () => casual.integer(0, 120)
})
})
@@ -99,7 +162,7 @@ mockServer(schema, {
mockServer(schema, {
Person: () => ({
// a list of length between 2 and 6
- friends: () => new MockList([2,6]),
+ friends: () => new MockList([2, 6]),
// a list of three lists of two items: [[1, 1], [2, 2], [3, 3]]
listOfLists: () => new MockList(3, () => new MockList(2))
})
@@ -116,11 +179,21 @@ mockServer(schema, {
// You can also disable mocking for specific fields, pass through to the backend, etc.
```
-For each type and each field you can provide a function that will be called on to generate mock data. Mock functions on fields have precedence over mock functions on types, but they work together really nicely: The field mock functions only need to describe the properties of the objects that matter to them, type mock functions will fill in the rest.
+For each type and each field you can provide a function that will be called on
+to generate mock data. Mock functions on fields have precedence over mock
+functions on types, but they work together really nicely: The field mock
+functions only need to describe the properties of the objects that matter to
+them, type mock functions will fill in the rest.
-The mock functions are actually just GraphQL resolve functions in disguise. What that means is that your mocking can do anything that you could do inside a GraphQL resolve function. If you wanted, you could write your entire backend with it. I’m not saying you should, but you could.
+The mock functions are actually just GraphQL resolve functions in disguise. What
+that means is that your mocking can do anything that you could do inside a
+GraphQL resolve function. If you wanted, you could write your entire backend
+with it. I’m not saying you should, but you could.
-I think the real power of this tool is that while it allows almost arbitrarily complex customization, you can get started really quickly and increase the sophistication of your mocks in tiny steps whenever you need it. Each step is so simple that it will feel like a breeze.
+I think the real power of this tool is that while it allows almost arbitrarily
+complex customization, you can get started really quickly and increase the
+sophistication of your mocks in tiny steps whenever you need it. Each step is so
+simple that it will feel like a breeze.
But enough talking, here’s a complete example:
@@ -163,14 +236,14 @@ const schema = `
// will be used to resolve the field if the query requests it.
const server = mockServer(schema, {
RootQuery: () => ({
- user: (o, { id }) => ({ id }),
+ user: (o, { id }) => ({ id })
}),
List: () => ({
name: () => casual.word,
- tasks: () => new MockList(4, (o, { completed }) => ({ completed })),
+ tasks: () => new MockList(4, (o, { completed }) => ({ completed }))
}),
Task: () => ({ text: casual.words(10) }),
- User: () => ({ name: casual.name }),
+ User: () => ({ name: casual.name })
})
mockServer.query(`
@@ -199,12 +272,21 @@ query tasksForUser{
## Live demo + try it yourself
-To see the example in action and see what output it generates, head over to the [live demo](https://launchpad.graphql.com/98lq7vz8r) try running some queries!
+To see the example in action and see what output it generates, head over to the
+[live demo](https://launchpad.graphql.com/98lq7vz8r) try running some queries!
-If you want to fiddle around with the example, just click the "Download" button in the Launchpad UI. If you’re curious about how it works or want to see what other tools we’re building for GraphQL, then head over to [apollostack/graphql-tools](https://github.com/apollostack/graphql-tools).
+If you want to fiddle around with the example, just click the "Download" button
+in the Launchpad UI. If you’re curious about how it works or want to see what
+other tools we’re building for GraphQL, then head over to
+[apollostack/graphql-tools](https://github.com/apollostack/graphql-tools).
-Pretty cool, right? All of that becomes possible by using a type system. And that’s only just the beginning — we‘re working on bridging the gap between mocking and the real thing so that your mock server can gradually turn into your real server as you add more functionality to it.
+Pretty cool, right? All of that becomes possible by using a type system. And
+that’s only just the beginning — we‘re working on bridging the gap between
+mocking and the real thing so that your mock server can gradually turn into your
+real server as you add more functionality to it.
---
-_This post was originally published on [the Apollo Blog](https://medium.com/apollo-stack). We publish one or two posts every week, about the stuff we’re working on and thinking about._
+_This post was originally published on
+[the Apollo Blog](https://medium.com/apollo-stack). We publish one or two posts
+every week, about the stuff we’re working on and thinking about._
diff --git a/src/pages/blog/2016-05-02-rest-api-graphql-wrapper.mdx b/src/pages/blog/2016-05-02-rest-api-graphql-wrapper.mdx
index 19c11fd5c9..f5c754d428 100644
--- a/src/pages/blog/2016-05-02-rest-api-graphql-wrapper.mdx
+++ b/src/pages/blog/2016-05-02-rest-api-graphql-wrapper.mdx
@@ -5,19 +5,33 @@ date: 2016-05-05
byline: "Steven Luscher"
---
-Time and time again I hear the same aspiration from front-end web and mobile developers: they're eager to reap the developer efficiency gains offered by new technologies like Relay and GraphQL, but they have years of momentum behind their existing REST API. Without data that clearly demonstrates the benefits of switching, they find it hard to justify an additional investment in GraphQL infrastructure.
+Time and time again I hear the same aspiration from front-end web and mobile
+developers: they're eager to reap the developer efficiency gains offered by new
+technologies like Relay and GraphQL, but they have years of momentum behind
+their existing REST API. Without data that clearly demonstrates the benefits of
+switching, they find it hard to justify an additional investment in GraphQL
+infrastructure.
-In this post I will outline a rapid, low-investment method that you can use to stand up a GraphQL endpoint atop an existing REST API, using JavaScript alone. No backend developers will be harmed during the making of this blog post.
+In this post I will outline a rapid, low-investment method that you can use to
+stand up a GraphQL endpoint atop an existing REST API, using JavaScript alone.
+No backend developers will be harmed during the making of this blog post.
## A client-side REST wrapper
-We're going to create a _GraphQL schema_ – a type system that describes your universe of data – that wraps calls to your existing REST API. This schema will receive and resolve GraphQL queries all on the client side. This architecture features some inherent performance flaws, but is fast to implement and requires no server changes.
+We're going to create a _GraphQL schema_ – a type system that describes your
+universe of data – that wraps calls to your existing REST API. This schema will
+receive and resolve GraphQL queries all on the client side. This architecture
+features some inherent performance flaws, but is fast to implement and requires
+no server changes.
-Imagine a REST API that exposes a `/people/` endpoint through which you can browse `Person` models and their associated friends.
+Imagine a REST API that exposes a `/people/` endpoint through which you can
+browse `Person` models and their associated friends.
![A REST API that exposes an index of people][rest-api-people]
-We will build a GraphQL schema that models people and their attributes (like `first_name` and `email`) as well as their association to other people through friendships.
+We will build a GraphQL schema that models people and their attributes (like
+`first_name` and `email`) as well as their association to other people through
+friendships.
### Installation
@@ -29,35 +43,36 @@ npm i graphql
### Building the GraphQL Schema
-Ultimately we will want to export a `GraphQLSchema` that we can use to resolve queries.
+Ultimately we will want to export a `GraphQLSchema` that we can use to resolve
+queries.
```js
import { GraphQLSchema } from "graphql"
export default new GraphQLSchema({
- query: QueryType,
+ query: QueryType
})
```
-At the root of all GraphQL schemas is a type called `query` whose definition we provide, and have specified here as `QueryType`. Let's build `QueryType` now – a type on which we will define all the possible things one might want to fetch.
+At the root of all GraphQL schemas is a type called `query` whose definition we
+provide, and have specified here as `QueryType`. Let's build `QueryType` now – a
+type on which we will define all the possible things one might want to fetch.
-To replicate all of the functionality of our REST API, let's expose two fields on `QueryType`:
+To replicate all of the functionality of our REST API, let's expose two fields
+on `QueryType`:
- an `allPeople` field – analogous to `/people/`
- a `person(id: String)` field – analogous to `/people/{ID}/`
-Each field will consist of a return type, optional argument definitions, and a JavaScript method that resolves the data being queried for.
+Each field will consist of a return type, optional argument definitions, and a
+JavaScript method that resolves the data being queried for.
```js
-import {
- GraphQLList,
- GraphQLObjectType,
- GraphQLString,
-} from 'graphql';
+import { GraphQLList, GraphQLObjectType, GraphQLString } from "graphql"
const QueryType = new GraphQLObjectType({
- name: 'Query',
- description: 'The root of all... queries',
+ name: "Query",
+ description: "The root of all... queries",
fields: () => ({
allPeople: {
type: new GraphQLList(PersonType),
@@ -66,49 +81,57 @@ const QueryType = new GraphQLObjectType({
person: {
type: PersonType,
args: {
- id: { type: GraphQLString },
+ id: { type: GraphQLString }
},
resolve: (root, args) => {} // Fetch the person with ID `args.id`,
- },
- }),
-});
+ }
+ })
+})
```
-Let's leave the resolvers as a sketch for now, and move on to defining `PersonType`.
+Let's leave the resolvers as a sketch for now, and move on to defining
+`PersonType`.
```js
-import {
- GraphQLList,
- GraphQLObjectType,
- GraphQLString,
-} from 'graphql';
+import { GraphQLList, GraphQLObjectType, GraphQLString } from "graphql"
const PersonType = new GraphQLObjectType({
- name: 'Person',
- description: 'Somebody that you used to know',
+ name: "Person",
+ description: "Somebody that you used to know",
fields: () => ({
firstName: {
type: GraphQLString,
- resolve: person => person.first_name,
+ resolve: person => person.first_name
},
lastName: {
type: GraphQLString,
- resolve: person => person.last_name,
+ resolve: person => person.last_name
},
- email: {type: GraphQLString},
- id: {type: GraphQLString},
- username: {type: GraphQLString},
+ email: { type: GraphQLString },
+ id: { type: GraphQLString },
+ username: { type: GraphQLString },
friends: {
type: new GraphQLList(PersonType),
resolve: person => {} // Fetch the friends with the URLs `person.friends`,
- },
- }),
-});
+ }
+ })
+})
```
-Note two things about the definition of `PersonType`. Firstly, we have not supplied a resolver for `email`, `id`, or `username`. The default resolver simply accesses the property of the `person` object that has the same name as the field. This works everywhere except where the property names do not match the field name (eg. the field `firstName` does not match the `first_name` property of the response object from the REST API) or where accessing the property would not yield the object that we want (eg. we want a list of person objects for the `friends` field, not a list of URLs).
-
-Now, let's write resolvers that fetch people from the REST API. Because we need to load from the network, we won't be able to return a value right away. Luckily for us, `resolve()` can return either a value or a `Promise` for a value. We're going to take advantage of this to fire off an HTTP request to the REST API that eventually resolves to a JavaScript object that conforms to `PersonType`.
+Note two things about the definition of `PersonType`. Firstly, we have not
+supplied a resolver for `email`, `id`, or `username`. The default resolver
+simply accesses the property of the `person` object that has the same name as
+the field. This works everywhere except where the property names do not match
+the field name (eg. the field `firstName` does not match the `first_name`
+property of the response object from the REST API) or where accessing the
+property would not yield the object that we want (eg. we want a list of person
+objects for the `friends` field, not a list of URLs).
+
+Now, let's write resolvers that fetch people from the REST API. Because we need
+to load from the network, we won't be able to return a value right away. Luckily
+for us, `resolve()` can return either a value or a `Promise` for a value. We're
+going to take advantage of this to fire off an HTTP request to the REST API that
+eventually resolves to a JavaScript object that conforms to `PersonType`.
And here we have it – a complete first-pass at the schema:
@@ -117,21 +140,21 @@ import {
GraphQLList,
GraphQLObjectType,
GraphQLSchema,
- GraphQLString,
-} from 'graphql';
+ GraphQLString
+} from "graphql"
-const BASE_URL = 'https://myapp.com/';
+const BASE_URL = "https://myapp.com/"
function fetchResponseByURL(relativeURL) {
- return fetch(`${BASE_URL}${relativeURL}`).then(res => res.json());
+ return fetch(`${BASE_URL}${relativeURL}`).then(res => res.json())
}
function fetchPeople() {
- return fetchResponseByURL('/people/').then(json => json.people);
+ return fetchResponseByURL("/people/").then(json => json.people)
}
function fetchPersonByURL(relativeURL) {
- return fetchResponseByURL(relativeURL).then(json => json.person);
+ return fetchResponseByURL(relativeURL).then(json => json.person)
}
const PersonType = new GraphQLObjectType({
@@ -140,71 +163,90 @@ const PersonType = new GraphQLObjectType({
/* ... */
friends: {
type: new GraphQLList(PersonType),
- resolve: person => person.friends.map(fetchPersonByURL),
- },
- }),
-});
+ resolve: person => person.friends.map(fetchPersonByURL)
+ }
+ })
+})
const QueryType = new GraphQLObjectType({
/* ... */
fields: () => ({
allPeople: {
type: new GraphQLList(PersonType),
- resolve: fetchPeople,
+ resolve: fetchPeople
},
person: {
type: PersonType,
args: {
- id: { type: GraphQLString },
+ id: { type: GraphQLString }
},
- resolve: (root, args) => fetchPersonByURL(`/people/${args.id}/`),
- },
- }),
-});
+ resolve: (root, args) => fetchPersonByURL(`/people/${args.id}/`)
+ }
+ })
+})
export default new GraphQLSchema({
- query: QueryType,
-});
+ query: QueryType
+})
```
### Using a client-side schema with Relay
-Normally, Relay will send its GraphQL queries to a server over HTTP. We can inject [@taion](https://github.com/taion/)'s custom `relay-local-schema` network layer to resolve queries using the schema we just built. Put this code wherever it's guaranteed to be executed before you mount your Relay app.
+Normally, Relay will send its GraphQL queries to a server over HTTP. We can
+inject [@taion](https://github.com/taion/)'s custom `relay-local-schema` network
+layer to resolve queries using the schema we just built. Put this code wherever
+it's guaranteed to be executed before you mount your Relay app.
```sh npm2yarn
npm i relay-local-schema
```
```js
-import RelayLocalSchema from 'relay-local-schema';
+import RelayLocalSchema from "relay-local-schema"
-import schema from './schema';
+import schema from "./schema"
-Relay.injectNetworkLayer(
- new RelayLocalSchema.NetworkLayer({ schema })
-);
+Relay.injectNetworkLayer(new RelayLocalSchema.NetworkLayer({ schema }))
```
-And that's that. Relay will send all of its queries to your custom client-resident schema, which will in turn resolve them by making calls to your existing REST API.
+And that's that. Relay will send all of its queries to your custom
+client-resident schema, which will in turn resolve them by making calls to your
+existing REST API.
## A server-side REST wrapper
-The client-side REST API wrapper demonstrated above should help you get up and running quickly so that you can try out a Relay version of your app (or part of your app).
+The client-side REST API wrapper demonstrated above should help you get up and
+running quickly so that you can try out a Relay version of your app (or part of
+your app).
-However, as we mentioned before, this architecture features some inherent performance flaws because of how GraphQL is still calling your underlying REST API which can be very network intensive. A good next step is to move the schema from the client side to the server side to minimize latency on the network and to give you more power to cache responses.
+However, as we mentioned before, this architecture features some inherent
+performance flaws because of how GraphQL is still calling your underlying REST
+API which can be very network intensive. A good next step is to move the schema
+from the client side to the server side to minimize latency on the network and
+to give you more power to cache responses.
-Take the next 10 minutes to watch me build a server side version of the GraphQL wrapper above using Node and Express.
+Take the next 10 minutes to watch me build a server side version of the GraphQL
+wrapper above using Node and Express.
-<iframe className="aspect-video w-full"
- src="https://youtube.com/embed/UBGzsb2UkeY?autoplay=0&origin=http://graphql.org&start=900" />
+<iframe
+ className="aspect-video w-full"
+ src="https://youtube.com/embed/UBGzsb2UkeY?autoplay=0&origin=http://graphql.org&start=900"
+/>
## Bonus round: A truly Relay compliant schema
-The schema we developed above will work for Relay up until a certain point – the point at which you ask Relay to refetch data for records you've already downloaded. Relay's refetching subsystem relies on your GraphQL schema exposing a special field that can fetch any entity in your data universe by GUID. We call this the _node interface_.
+The schema we developed above will work for Relay up until a certain point – the
+point at which you ask Relay to refetch data for records you've already
+downloaded. Relay's refetching subsystem relies on your GraphQL schema exposing
+a special field that can fetch any entity in your data universe by GUID. We call
+this the _node interface_.
-To expose a node interface requires that you do two things: offer a `node(id: String!)` field at the root of the query, and switch all of your ids over to GUIDs (globally-unique ids).
+To expose a node interface requires that you do two things: offer a
+`node(id: String!)` field at the root of the query, and switch all of your ids
+over to GUIDs (globally-unique ids).
-The `graphql-relay` package contains some helper functions to make this easy to do.
+The `graphql-relay` package contains some helper functions to make this easy to
+do.
```sh npm2yarn
npm i graphql-relay
@@ -212,7 +254,8 @@ npm i graphql-relay
#### Global ids
-First, let's change the `id` field of `PersonType` into a GUID. To do this, we'll use the `globalIdField` helper from `graphql-relay`.
+First, let's change the `id` field of `PersonType` into a GUID. To do this,
+we'll use the `globalIdField` helper from `graphql-relay`.
```js
import { globalIdField } from "graphql-relay"
@@ -227,11 +270,15 @@ const PersonType = new GraphQLObjectType({
})
```
-Behind the scenes `globalIdField` returns a field definition that resolves `id` to a `GraphQLString` by hashing together the typename `'Person'` and the id returned by the REST API. We can later use `fromGlobalId` to convert the result of this field back into `'Person'` and the REST API's id.
+Behind the scenes `globalIdField` returns a field definition that resolves `id`
+to a `GraphQLString` by hashing together the typename `'Person'` and the id
+returned by the REST API. We can later use `fromGlobalId` to convert the result
+of this field back into `'Person'` and the REST API's id.
#### The node field
-Another set of helpers from `graphql-relay` will give us a hand developing the node field. Your job is to supply the helper two functions:
+Another set of helpers from `graphql-relay` will give us a hand developing the
+node field. Your job is to supply the helper two functions:
- One function that can resolve an object given a GUID.
- One function that can resolve a typename given an object.
@@ -254,96 +301,94 @@ const { nodeInterface, nodeField } = nodeDefinitions(
)
```
-The object-to-typename resolver above is no marvel of engineering, but you get the idea.
+The object-to-typename resolver above is no marvel of engineering, but you get
+the idea.
-Next, we simply need to add the `nodeInterface` and the `nodeField` to our schema. A complete example follows:
+Next, we simply need to add the `nodeInterface` and the `nodeField` to our
+schema. A complete example follows:
```js {27-39,54,61,72}
import {
GraphQLList,
GraphQLObjectType,
GraphQLSchema,
- GraphQLString,
-} from 'graphql';
-import {
- fromGlobalId,
- globalIdField,
- nodeDefinitions,
-} from 'graphql-relay';
+ GraphQLString
+} from "graphql"
+import { fromGlobalId, globalIdField, nodeDefinitions } from "graphql-relay"
-const BASE_URL = 'https://myapp.com/';
+const BASE_URL = "https://myapp.com/"
function fetchResponseByURL(relativeURL) {
- return fetch(`${BASE_URL}${relativeURL}`).then(res => res.json());
+ return fetch(`${BASE_URL}${relativeURL}`).then(res => res.json())
}
function fetchPeople() {
- return fetchResponseByURL('/people/').then(json => json.people);
+ return fetchResponseByURL("/people/").then(json => json.people)
}
function fetchPersonByURL(relativeURL) {
- return fetchResponseByURL(relativeURL).then(json => json.person);
+ return fetchResponseByURL(relativeURL).then(json => json.person)
}
const { nodeInterface, nodeField } = nodeDefinitions(
globalId => {
- const { type, id } = fromGlobalId(globalId);
- if (type === 'Person') {
- return fetchPersonByURL(`/people/${id}/`);
+ const { type, id } = fromGlobalId(globalId)
+ if (type === "Person") {
+ return fetchPersonByURL(`/people/${id}/`)
}
},
object => {
- if (object.hasOwnProperty('username')) {
- return 'Person';
+ if (object.hasOwnProperty("username")) {
+ return "Person"
}
- },
-);
+ }
+)
const PersonType = new GraphQLObjectType({
- name: 'Person',
- description: 'Somebody that you used to know',
+ name: "Person",
+ description: "Somebody that you used to know",
fields: () => ({
firstName: {
type: GraphQLString,
- resolve: person => person.first_name,
+ resolve: person => person.first_name
},
lastName: {
type: GraphQLString,
- resolve: person => person.last_name,
+ resolve: person => person.last_name
},
- email: {type: GraphQLString},
- id: globalIdField('Person'),
- username: {type: GraphQLString},
+ email: { type: GraphQLString },
+ id: globalIdField("Person"),
+ username: { type: GraphQLString },
friends: {
type: new GraphQLList(PersonType),
- resolve: person => person.friends.map(fetchPersonByURL),
- },
+ resolve: person => person.friends.map(fetchPersonByURL)
+ }
}),
- interfaces: [ nodeInterface ],
-});
+ interfaces: [nodeInterface]
+})
const QueryType = new GraphQLObjectType({
- name: 'Query',
- description: 'The root of all... queries',
+ name: "Query",
+ description: "The root of all... queries",
fields: () => ({
allPeople: {
type: new GraphQLList(PersonType),
- resolve: fetchPeople,
+ resolve: fetchPeople
},
node: nodeField,
person: {
type: PersonType,
args: {
- id: { type: GraphQLString },
+ id: { type: GraphQLString }
},
- resolve: (root, args) => fetchPersonByURL(`/people/${args.id}/`),
+ resolve: (root, args) => fetchPersonByURL(`/people/${args.id}/`)
}
})
-});
+})
export default new GraphQLSchema({
query: QueryType
-});
+})
```
## Taming pathological queries
@@ -367,11 +412,13 @@ query {
}
```
-The schema we created above will generate multiple round trips to the REST API for the same data.
+The schema we created above will generate multiple round trips to the REST API
+for the same data.
![Duplicate queries to the REST API][pathological-query]
-This is obviously something we would like to avoid! At the very least, we need a way to cache the result of these requests.
+This is obviously something we would like to avoid! At the very least, we need a
+way to cache the result of these requests.
We created a library called DataLoader to help tame these sorts of queries.
@@ -379,11 +426,15 @@ We created a library called DataLoader to help tame these sorts of queries.
npm i dataloader
```
-As a special note, make sure that your runtime offers native or polyfilled versions of `Promise` and `Map`. Read more [at the DataLoader site](https://github.com/facebook/dataloader#getting-started).
+As a special note, make sure that your runtime offers native or polyfilled
+versions of `Promise` and `Map`. Read more
+[at the DataLoader site](https://github.com/facebook/dataloader#getting-started).
#### Creating a data loader
-To create a `DataLoader` you supply a method that can resolve a list of objects given a list of keys. In our example, the keys are URLs at which we access our REST API.
+To create a `DataLoader` you supply a method that can resolve a list of objects
+given a list of keys. In our example, the keys are URLs at which we access our
+REST API.
```js
const personLoader = new DataLoader(urls =>
@@ -391,61 +442,60 @@ const personLoader = new DataLoader(urls =>
)
```
-If this data loader sees a key more than once in its lifetime, it will return a memoized (cached) version of the response.
+If this data loader sees a key more than once in its lifetime, it will return a
+memoized (cached) version of the response.
#### Loading data
-We can make use of the `load()` and `loadMany()` methods on `personLoader` to load URLs without fear of hitting the REST API more than once per URL. A complete example follows:
+We can make use of the `load()` and `loadMany()` methods on `personLoader` to
+load URLs without fear of hitting the REST API more than once per URL. A
+complete example follows:
```js {36,63,83}
-import DataLoader from 'dataloader';
+import DataLoader from "dataloader"
import {
GraphQLList,
GraphQLObjectType,
GraphQLSchema,
- GraphQLString,
-} from 'graphql';
-import {
- fromGlobalId,
- globalIdField,
- nodeDefinitions,
-} from 'graphql-relay';
+ GraphQLString
+} from "graphql"
+import { fromGlobalId, globalIdField, nodeDefinitions } from "graphql-relay"
-const BASE_URL = 'https://myapp.com/';
+const BASE_URL = "https://myapp.com/"
function fetchResponseByURL(relativeURL) {
- return fetch(`${BASE_URL}${relativeURL}`).then(res => res.json());
+ return fetch(`${BASE_URL}${relativeURL}`).then(res => res.json())
}
function fetchPeople() {
- return fetchResponseByURL('/people/').then(json => json.people);
+ return fetchResponseByURL("/people/").then(json => json.people)
}
function fetchPersonByURL(relativeURL) {
- return fetchResponseByURL(relativeURL).then(json => json.person);
+ return fetchResponseByURL(relativeURL).then(json => json.person)
}
-const personLoader = new DataLoader(
- urls => Promise.all(urls.map(fetchPersonByURL))
-);
+const personLoader = new DataLoader(urls =>
+ Promise.all(urls.map(fetchPersonByURL))
+)
const { nodeInterface, nodeField } = nodeDefinitions(
globalId => {
- const {type, id} = fromGlobalId(globalId);
- if (type === 'Person') {
- return personLoader.load(`/people/${id}/`);
+ const { type, id } = fromGlobalId(globalId)
+ if (type === "Person") {
+ return personLoader.load(`/people/${id}/`)
}
},
object => {
- if (object.hasOwnProperty('username')) {
- return 'Person';
+ if (object.hasOwnProperty("username")) {
+ return "Person"
}
- },
-);
+ }
+)
const PersonType = new GraphQLObjectType({
- name: 'Person',
- description: 'Somebody that you used to know',
+ name: "Person",
+ description: "Somebody that you used to know",
fields: () => ({
firstName: {
type: GraphQLString,
@@ -455,20 +505,20 @@ const PersonType = new GraphQLObjectType({
type: GraphQLString,
resolve: person => person.last_name
},
- email: {type: GraphQLString},
- id: globalIdField('Person'),
- username: {type: GraphQLString},
+ email: { type: GraphQLString },
+ id: globalIdField("Person"),
+ username: { type: GraphQLString },
friends: {
type: new GraphQLList(PersonType),
resolve: person => personLoader.loadMany(person.friends)
}
}),
interfaces: [nodeInterface]
-});
+})
const QueryType = new GraphQLObjectType({
- name: 'Query',
- description: 'The root of all... queries',
+ name: "Query",
+ description: "The root of all... queries",
fields: () => ({
allPeople: {
type: new GraphQLList(PersonType),
@@ -483,27 +533,43 @@ const QueryType = new GraphQLObjectType({
resolve: (root, args) => personLoader.load(`/people/${args.id}/`)
}
})
-});
+})
export default new GraphQLSchema({
query: QueryType
-});
+})
```
-Now, our pathological query produces the following nicely de-duped set of requests to the REST API:
+Now, our pathological query produces the following nicely de-duped set of
+requests to the REST API:
![De-duped queries to the REST API][dataloader-query]
### Query planning and beyond
-Consider that your REST API might already offer configuration offers that let you eagerly load associations. Maybe to load a person and all of their direct friends you might hit the URL `/people/1/?include_friends`. To take advantage of this in your GraphQL schema you will need the ability to develop a resolution plan based on the structure of the query itself (eg. whether the `friends` field is part of the query or not).
+Consider that your REST API might already offer configuration offers that let
+you eagerly load associations. Maybe to load a person and all of their direct
+friends you might hit the URL `/people/1/?include_friends`. To take advantage of
+this in your GraphQL schema you will need the ability to develop a resolution
+plan based on the structure of the query itself (eg. whether the `friends` field
+is part of the query or not).
-For those interested in the current thinking around advanced resolution strategies, keep an eye on [pull request #304](https://github.com/graphql/graphql-js/pull/304).
+For those interested in the current thinking around advanced resolution
+strategies, keep an eye on
+[pull request #304](https://github.com/graphql/graphql-js/pull/304).
## Thanks for reading
-I hope that this demonstration has torn down some of the barriers between you and a functional GraphQL endpoint, and has inspired you to experiment with GraphQL and Relay on an existing project.
-
-[rest-api-people]: /img/blog/20160502-rest-api-graphql-wrapper/rest-api-people.png "A REST API that exposes an index of people"
-[pathological-query]: /img/blog/20160502-rest-api-graphql-wrapper/pathological-query.png "Duplicate queries to the REST API"
-[dataloader-query]: /img/blog/20160502-rest-api-graphql-wrapper/dataloader-query.png "De-duped queries to the REST API"
+I hope that this demonstration has torn down some of the barriers between you
+and a functional GraphQL endpoint, and has inspired you to experiment with
+GraphQL and Relay on an existing project.
+
+[rest-api-people]:
+ /img/blog/20160502-rest-api-graphql-wrapper/rest-api-people.png
+ "A REST API that exposes an index of people"
+[pathological-query]:
+ /img/blog/20160502-rest-api-graphql-wrapper/pathological-query.png
+ "Duplicate queries to the REST API"
+[dataloader-query]:
+ /img/blog/20160502-rest-api-graphql-wrapper/dataloader-query.png
+ "De-duped queries to the REST API"
diff --git a/src/pages/blog/2016-09-14-production-ready.mdx b/src/pages/blog/2016-09-14-production-ready.mdx
index ee5142455d..352537f19e 100644
--- a/src/pages/blog/2016-09-14-production-ready.mdx
+++ b/src/pages/blog/2016-09-14-production-ready.mdx
@@ -5,18 +5,45 @@ date: 2016-09-14
byline: "Lee Byron"
---
-After over a year of being open sourced we're bringing GraphQL out of "technical preview" and relaunching [graphql.org](/).
-
-For us at Facebook, GraphQL isn't a new technology. GraphQL has been delivering data to mobile News Feed since 2012. Since then it's expanded to support the majority of the Facebook mobile product and evolved in the process.
-
-Early last year when we first [spoke publicly about GraphQL](https://youtube.com/watch?v=9sc8Pyc51uU) we received overwhelming demand to share more about this technology. That sparked an internal project to revisit GraphQL, make improvements, draft a specification, produce a reference implementation you could use to try it out, and build new versions of some of our favorite tools, like [GraphiQL](https://github.com/graphql/graphiql). We moved quickly, and released parts that were ready along the way.
-
-Part of Facebook's open source philosophy is that we want to only open source what is ready for production. While it's true that we had been using GraphQL in production at Facebook for years, we knew that these newly released pieces had yet to be proven. We expected feedback. So we carefully released GraphQL as a "technical preview."
-
-Exactly one year ago, we published graphql.org, with a [formal announcement](/blog/graphql-a-query-language) that GraphQL was open source and ready to be "technically previewed". Since then, we've seen GraphQL implemented [in many languages](/code), and successfully adopted by other companies. That includes today's exciting announcement of the [GitHub GraphQL API](http://githubengineering.com/the-github-graphql-api), the first major public API to use GraphQL.
-
-In recognition of the fact that GraphQL is now being used in production by many companies, we're excited to remove the "technical preview" moniker. GraphQL is production ready.
-
-We've also revamped this website, [graphql.org](/), with clearer and more relevant content in response to some the most common questions we've received over the last year.
-
-We think GraphQL can greatly simplify data needs for both client product developers and server-side engineers, regardless of what languages you're using in either environment, and we're excited to continue to improve GraphQL, support the already growing community, and see what we can build together.
+After over a year of being open sourced we're bringing GraphQL out of "technical
+preview" and relaunching [graphql.org](/).
+
+For us at Facebook, GraphQL isn't a new technology. GraphQL has been delivering
+data to mobile News Feed since 2012. Since then it's expanded to support the
+majority of the Facebook mobile product and evolved in the process.
+
+Early last year when we first
+[spoke publicly about GraphQL](https://youtube.com/watch?v=9sc8Pyc51uU) we
+received overwhelming demand to share more about this technology. That sparked
+an internal project to revisit GraphQL, make improvements, draft a
+specification, produce a reference implementation you could use to try it out,
+and build new versions of some of our favorite tools, like
+[GraphiQL](https://github.com/graphql/graphiql). We moved quickly, and released
+parts that were ready along the way.
+
+Part of Facebook's open source philosophy is that we want to only open source
+what is ready for production. While it's true that we had been using GraphQL in
+production at Facebook for years, we knew that these newly released pieces had
+yet to be proven. We expected feedback. So we carefully released GraphQL as a
+"technical preview."
+
+Exactly one year ago, we published graphql.org, with a
+[formal announcement](/blog/graphql-a-query-language) that GraphQL was open
+source and ready to be "technically previewed". Since then, we've seen GraphQL
+implemented [in many languages](/code), and successfully adopted by other
+companies. That includes today's exciting announcement of the
+[GitHub GraphQL API](http://githubengineering.com/the-github-graphql-api), the
+first major public API to use GraphQL.
+
+In recognition of the fact that GraphQL is now being used in production by many
+companies, we're excited to remove the "technical preview" moniker. GraphQL is
+production ready.
+
+We've also revamped this website, [graphql.org](/), with clearer and more
+relevant content in response to some the most common questions we've received
+over the last year.
+
+We think GraphQL can greatly simplify data needs for both client product
+developers and server-side engineers, regardless of what languages you're using
+in either environment, and we're excited to continue to improve GraphQL, support
+the already growing community, and see what we can build together.
diff --git a/src/pages/blog/2017-11-08-programmable-web.mdx b/src/pages/blog/2017-11-08-programmable-web.mdx
index b69c3213a3..c956ce2a8f 100644
--- a/src/pages/blog/2017-11-08-programmable-web.mdx
+++ b/src/pages/blog/2017-11-08-programmable-web.mdx
@@ -5,6 +5,15 @@ date: 2017-11-08
byline: ProgrammableWeb
---
-GraphQL will now have its own foundation: the [GraphQL Foundation](/foundation). Although GraphQL was initially incubated by Facebook, GraphQL is now utilized heavily by a diverse set of companies including major tech giants (e.g. Twitter, Airbnb, Shopify, etc.). Accordingly, it makes sense that the data query language move to a neutral, open source home. Like many open source projects, the GraphQL Foundation will be hosted by the Linux Foundation. Linux will implement an open governance model similar to many collaborations overseen by Linux. The exact details of the model, and future plans continue to be a work in progress. The current founding members include Airbnb, Apollo, Coursera, Elementl, Facebook, GitHub, Hasura, Prisma, Shopify and Twitter.
+GraphQL will now have its own foundation: the [GraphQL Foundation](/foundation).
+Although GraphQL was initially incubated by Facebook, GraphQL is now utilized
+heavily by a diverse set of companies including major tech giants (e.g. Twitter,
+Airbnb, Shopify, etc.). Accordingly, it makes sense that the data query language
+move to a neutral, open source home. Like many open source projects, the GraphQL
+Foundation will be hosted by the Linux Foundation. Linux will implement an open
+governance model similar to many collaborations overseen by Linux. The exact
+details of the model, and future plans continue to be a work in progress. The
+current founding members include Airbnb, Apollo, Coursera, Elementl, Facebook,
+GitHub, Hasura, Prisma, Shopify and Twitter.
[Read More](https://programmableweb.com/news/graphql-moving-to-neutral-open-source-foundation/brief/2018/11/08)
diff --git a/src/pages/blog/2018-11-06-eweek.mdx b/src/pages/blog/2018-11-06-eweek.mdx
index 7f6163a131..4e8066d883 100644
--- a/src/pages/blog/2018-11-06-eweek.mdx
+++ b/src/pages/blog/2018-11-06-eweek.mdx
@@ -1,10 +1,20 @@
---
-title: "eWeek: GraphQL API Specification Moving Forward with Independent Foundation"
+title:
+ "eWeek: GraphQL API Specification Moving Forward with Independent Foundation"
tags: ["in-the-news"]
date: 2018-11-06
byline: eweek
---
-The Linux Foundation announced on Nov. 6 that it is forming a new foundation to support the open source GraphQL specification, which enables a new generation of APIs. For nearly two decades, REST (Representational State Transfer) has been one of the primary approaches for enabling APIs that help to connect and extend applications and web services. REST however has multiple limitations, which is where GraphQL steps into the picture, finding wide adoption by large web properties. GraphQL was created in 2012 by Facebook and became open source in 2015. The move to create a new vendor-neutral independent foundation under the Linux Foundation will serve to help further advance the development of GraphQL.
+The Linux Foundation announced on Nov. 6 that it is forming a new foundation to
+support the open source GraphQL specification, which enables a new generation of
+APIs. For nearly two decades, REST (Representational State Transfer) has been
+one of the primary approaches for enabling APIs that help to connect and extend
+applications and web services. REST however has multiple limitations, which is
+where GraphQL steps into the picture, finding wide adoption by large web
+properties. GraphQL was created in 2012 by Facebook and became open source
+in 2015. The move to create a new vendor-neutral independent foundation under
+the Linux Foundation will serve to help further advance the development of
+GraphQL.
[Read more](https://eweek.com/development/graphql-api-specification-moving-forward-with-independent-foundation)
diff --git a/src/pages/blog/2018-11-06-infoworld.mdx b/src/pages/blog/2018-11-06-infoworld.mdx
index 8c9f0ad5c6..c767d98b55 100644
--- a/src/pages/blog/2018-11-06-infoworld.mdx
+++ b/src/pages/blog/2018-11-06-infoworld.mdx
@@ -5,8 +5,13 @@ date: 2018-11-06
byline: InfoWorld
---
-The Linux Foundation plans to host a foundation to support the GraphQL API project, with the intent of growing a neutral ecosystem for the technology.
+The Linux Foundation plans to host a foundation to support the GraphQL API
+project, with the intent of growing a neutral ecosystem for the technology.
-GraphQL is a specification for building APIs. It is intended to make cross-platform and mobile development simpler. Providing an alternative to REST, GraphQL lets developers use a strongly typed query language to define requests and responses, letting an application specify what it needs from an API. GraphQL enables access to multiple data sources through a single request.
+GraphQL is a specification for building APIs. It is intended to make
+cross-platform and mobile development simpler. Providing an alternative to REST,
+GraphQL lets developers use a strongly typed query language to define requests
+and responses, letting an application specify what it needs from an API. GraphQL
+enables access to multiple data sources through a single request.
[Read more](https://infoworld.com/article/3318255/apis/graphql-gets-its-own-foundation.html)
diff --git a/src/pages/blog/2018-11-06-linux-foundation-graphql.mdx b/src/pages/blog/2018-11-06-linux-foundation-graphql.mdx
index 73238cbdb0..64489dd3c6 100644
--- a/src/pages/blog/2018-11-06-linux-foundation-graphql.mdx
+++ b/src/pages/blog/2018-11-06-linux-foundation-graphql.mdx
@@ -1,46 +1,145 @@
---
-title: "The Linux Foundation Announces Intent to Form New Foundation to Support GraphQL"
+title:
+ "The Linux Foundation Announces Intent to Form New Foundation to Support
+ GraphQL"
tags: ["announcements"]
date: 2018-11-06
byline: GraphQL Foundation
---
-[The Linux Foundation](https://linuxfoundation.org), the nonprofit organization enabling mass innovation through open source, announces a broad coalition of industry leaders and users have joined forces to create a new open source foundation for the [GraphQL](/) project, which will be dedicated to growing and sustaining a neutral GraphQL ecosystem. Hosted under the Linux Foundation, the [GraphQL Foundation](https://gql.foundation)'s mission will be to enable widespread adoption and help accelerate development of GraphQL and the surrounding ecosystem.
-
-> “As one of GraphQL’s co-creators, I’ve been amazed and proud to see it grow in adoption since its open sourcing. Through the formation of the GraphQL Foundation, I hope to see GraphQL become industry standard by encouraging contributions from a broader group and creating a shared investment in vendor-neutral events, documentation, tools, and support,” said Lee Byron, co-creator of GraphQL.
-
-GraphQL is a next-generation API technology developed internally by Facebook in 2012 before being publicly [open sourced in 2015](https://code.fb.com/core-data/graphql-a-data-query-language/). As application development shifts towards microservices architectures with an emphasis on flexibility and speed to market, tools like GraphQL are redefining API design and client-server interaction to improve the developer experience, increasing developer productivity and minimizing amounts of data transferred. GraphQL makes cross-platform and mobile development simpler with availability in multiple programming languages, allowing developers to create seamless user experiences for their customers.
-
-GraphQL is being used in production by a [variety of high scale companies](https://graphql.org/users/) such as Airbnb, Atlassian, Audi, CNBC, GitHub, Major League Soccer, Netflix, Shopify, The New York Times, Twitter, Pinterest and Yelp. GraphQL also [powers hundreds of billions of API calls a day at Facebook](https://code.fb.com/core-data/graphql-a-data-query-language/).
-
-> “We are thrilled to welcome the GraphQL Foundation into the Linux Foundation. This advancement is important because it allows for long-term support and accelerated growth of this essential and groundbreaking technology that is changing the approach to API design for cloud-connected applications in any language,” said Jim Zemlin, Executive Director, the Linux Foundation.
-
-Unlike REST-based APIs, which take advantage of HTTP and existing protocols, GraphQL APIs provide developers with the flexibility to query the exact data they need from a diverse set of cloud data sources, with less code, greater performance and security, and a faster development cycle. Not only does this enable developers to rapidly build top quality apps, it also helps them achieve consistency and feature parity across multiple platforms such as web, iOS, Android, and embedded and IoT applications.
-
-The GraphQL Foundation will have an open governance model that encourages participation and technical contribution and will provide a framework for long-term stewardship by an ecosystem invested in GraphQL’s success.
-
-> “At Facebook, our mission is to give people the power to build community and bring the world closer together. We believe open source projects and the communities built around them help accelerate the pace of innovation and bring many minds to bear to solve large-scale challenges. GraphQL is one such project and community and the GraphQL Foundation will help ensure GraphQL continues to solve the real data fetching challenges that developers will face in building the products of tomorrow,” said Killian Murphy, Director, Facebook Open Source.
-
-> “GraphQL has redefined how developers work with APIs and client-server interactions. We look forward to working with the diverse GraphQL community from end users like Facebook to a diverse ecosystem of vendors to become an independent foundation, draft their governance and continue to foster the growth and adoption of GraphQL,” said Chris Aniszczyk, Vice President of Developer Relations, the Linux Foundation.
+[The Linux Foundation](https://linuxfoundation.org), the nonprofit organization
+enabling mass innovation through open source, announces a broad coalition of
+industry leaders and users have joined forces to create a new open source
+foundation for the [GraphQL](/) project, which will be dedicated to growing and
+sustaining a neutral GraphQL ecosystem. Hosted under the Linux Foundation, the
+[GraphQL Foundation](https://gql.foundation)'s mission will be to enable
+widespread adoption and help accelerate development of GraphQL and the
+surrounding ecosystem.
+
+> “As one of GraphQL’s co-creators, I’ve been amazed and proud to see it grow in
+> adoption since its open sourcing. Through the formation of the GraphQL
+> Foundation, I hope to see GraphQL become industry standard by encouraging
+> contributions from a broader group and creating a shared investment in
+> vendor-neutral events, documentation, tools, and support,” said Lee Byron,
+> co-creator of GraphQL.
+
+GraphQL is a next-generation API technology developed internally by Facebook in
+2012 before being publicly
+[open sourced in 2015](https://code.fb.com/core-data/graphql-a-data-query-language/).
+As application development shifts towards microservices architectures with an
+emphasis on flexibility and speed to market, tools like GraphQL are redefining
+API design and client-server interaction to improve the developer experience,
+increasing developer productivity and minimizing amounts of data transferred.
+GraphQL makes cross-platform and mobile development simpler with availability in
+multiple programming languages, allowing developers to create seamless user
+experiences for their customers.
+
+GraphQL is being used in production by a
+[variety of high scale companies](https://graphql.org/users/) such as Airbnb,
+Atlassian, Audi, CNBC, GitHub, Major League Soccer, Netflix, Shopify, The New
+York Times, Twitter, Pinterest and Yelp. GraphQL also
+[powers hundreds of billions of API calls a day at Facebook](https://code.fb.com/core-data/graphql-a-data-query-language/).
+
+> “We are thrilled to welcome the GraphQL Foundation into the Linux Foundation.
+> This advancement is important because it allows for long-term support and
+> accelerated growth of this essential and groundbreaking technology that is
+> changing the approach to API design for cloud-connected applications in any
+> language,” said Jim Zemlin, Executive Director, the Linux Foundation.
+
+Unlike REST-based APIs, which take advantage of HTTP and existing protocols,
+GraphQL APIs provide developers with the flexibility to query the exact data
+they need from a diverse set of cloud data sources, with less code, greater
+performance and security, and a faster development cycle. Not only does this
+enable developers to rapidly build top quality apps, it also helps them achieve
+consistency and feature parity across multiple platforms such as web, iOS,
+Android, and embedded and IoT applications.
+
+The GraphQL Foundation will have an open governance model that encourages
+participation and technical contribution and will provide a framework for
+long-term stewardship by an ecosystem invested in GraphQL’s success.
+
+> “At Facebook, our mission is to give people the power to build community and
+> bring the world closer together. We believe open source projects and the
+> communities built around them help accelerate the pace of innovation and bring
+> many minds to bear to solve large-scale challenges. GraphQL is one such
+> project and community and the GraphQL Foundation will help ensure GraphQL
+> continues to solve the real data fetching challenges that developers will face
+> in building the products of tomorrow,” said Killian Murphy, Director, Facebook
+> Open Source.
+
+> “GraphQL has redefined how developers work with APIs and client-server
+> interactions. We look forward to working with the diverse GraphQL community
+> from end users like Facebook to a diverse ecosystem of vendors to become an
+> independent foundation, draft their governance and continue to foster the
+> growth and adoption of GraphQL,” said Chris Aniszczyk, Vice President of
+> Developer Relations, the Linux Foundation.
## Supporting Quotes
-> “Airbnb is making a massive investment in GraphQL, putting it at the center of our API strategy across both our product and internal tools. We are excited to see the Foundation play a key role in cultivating the community around GraphQL and continue to evolve GraphQL as a technology, paving the way for continued innovation of Airbnb’s API.” — Adam Neary, Tech Lead, Airbnb
-
-> “Given GraphQL’s centrality in the modern app development stack, the foundation we’re announcing today is not just necessary, but overdue. As the creators of Apollo, the most widely used implementation of GraphQL, we’re looking forward to working together with the Linux Foundation to define appropriate governance processes for this critical Internet standard.” – Geoff Schmidt, co-founder and CEO of Apollo GraphQL
-
-> “GraphQL, and the strong ecosystem behind it, is leading to a fundamental change in how we build products, and it helps bring together teams and organizations of every size. At Coursera, GraphQL assists us in understanding the massive breadth of our APIs and helps us create transformative educational experiences for everyone, everywhere. We’re excited to see the impact of the GraphQL Foundation in making both the technology and the community stronger.” – Jon Wong, Staff Software Engineer, Coursera
-
-> “GraphQL has come a long way since its creation in 2012. It’s been an honor seeing the technology grow from a prototype, to powering Facebook’s core applications, to an open source technology on the way to becoming a ubiquitous standard across the entire industry. The GraphQL Foundation is an exciting step forward. This new governance model is a major milestone in that maturation process that will ensure a neutral venue and structure for the entire community to drive the technology forward.” – Nick Schrock, Founder, Elementl, GraphQL Co-Creator
-
-> “We created GraphQL at Facebook six years ago to help us build high-performance mobile experiences, so to see it grow and gain broad industry adoption has been amazing. Since Facebook open-sourced GraphQL in 2015, the community has grown to include developers around the world, newly-founded startups, and well-established companies. The creation of the GraphQL Foundation is a new chapter that will create a governance structure we believe will empower the community and provide GraphQL long-term technical success. I’m excited to see its continued growth under the Foundation’s guidance.” – Dan Schafer, Facebook Software Engineer, GraphQL Co-Creator
-
-> “GraphQL has proven to be a valuable, extensible tool for GitHub, our customers, and our integrators over the past two years. The GraphQL Foundation embodies openness, transparency, and community — all of which we believe in at GitHub.” – Kyle Daigle, Director, Ecosystem Engineering, GitHub
-
-> “This is a very welcome announcement, and we believe that this is a necessary step. The GraphQL community has grown rapidly over the last few years, and has reached the point where transparent, neutral governance policies are necessary for future growth. At Hasura, we look forward to helping the Foundation in its work.” – Tanmai Gopal, CEO, Hasura
-
-> “GraphQL has become one of the most important technologies in the modern application development stack and sees rapid adoption by developers and companies across all industries. At Prisma, we’re very excited to support the GraphQL Foundation to enable a healthy community and sustain the continuous development of GraphQL.” – Johannes Schickling, Founder and CEO, Prisma
-
-> “At Shopify, GraphQL powers our core APIs and all our mobile and web clients. We strongly believe in open development and look to the Foundation to help expand the community and nurture its evolution.” – Jean-Michel Lemieux, SVP Engineering, Shopify
-
-> “GraphQL is gaining tremendous adoption as one of the best protocols for remote retrieval of large object graphs. At Twitter, we are looking forward to what’s to come in the GraphQL ecosystem and are very excited to support the GraphQL Foundation.” – Anna Sulkina Sr. Engineering Manager, Core Services Group, Twitter
+> “Airbnb is making a massive investment in GraphQL, putting it at the center of
+> our API strategy across both our product and internal tools. We are excited to
+> see the Foundation play a key role in cultivating the community around GraphQL
+> and continue to evolve GraphQL as a technology, paving the way for continued
+> innovation of Airbnb’s API.” — Adam Neary, Tech Lead, Airbnb
+
+> “Given GraphQL’s centrality in the modern app development stack, the
+> foundation we’re announcing today is not just necessary, but overdue. As the
+> creators of Apollo, the most widely used implementation of GraphQL, we’re
+> looking forward to working together with the Linux Foundation to define
+> appropriate governance processes for this critical Internet standard.” – Geoff
+> Schmidt, co-founder and CEO of Apollo GraphQL
+
+> “GraphQL, and the strong ecosystem behind it, is leading to a fundamental
+> change in how we build products, and it helps bring together teams and
+> organizations of every size. At Coursera, GraphQL assists us in understanding
+> the massive breadth of our APIs and helps us create transformative educational
+> experiences for everyone, everywhere. We’re excited to see the impact of the
+> GraphQL Foundation in making both the technology and the community stronger.”
+> – Jon Wong, Staff Software Engineer, Coursera
+
+> “GraphQL has come a long way since its creation in 2012. It’s been an honor
+> seeing the technology grow from a prototype, to powering Facebook’s core
+> applications, to an open source technology on the way to becoming a ubiquitous
+> standard across the entire industry. The GraphQL Foundation is an exciting
+> step forward. This new governance model is a major milestone in that
+> maturation process that will ensure a neutral venue and structure for the
+> entire community to drive the technology forward.” – Nick Schrock, Founder,
+> Elementl, GraphQL Co-Creator
+
+> “We created GraphQL at Facebook six years ago to help us build
+> high-performance mobile experiences, so to see it grow and gain broad industry
+> adoption has been amazing. Since Facebook open-sourced GraphQL in 2015, the
+> community has grown to include developers around the world, newly-founded
+> startups, and well-established companies. The creation of the GraphQL
+> Foundation is a new chapter that will create a governance structure we believe
+> will empower the community and provide GraphQL long-term technical success.
+> I’m excited to see its continued growth under the Foundation’s guidance.” –
+> Dan Schafer, Facebook Software Engineer, GraphQL Co-Creator
+
+> “GraphQL has proven to be a valuable, extensible tool for GitHub, our
+> customers, and our integrators over the past two years. The GraphQL Foundation
+> embodies openness, transparency, and community — all of which we believe in at
+> GitHub.” – Kyle Daigle, Director, Ecosystem Engineering, GitHub
+
+> “This is a very welcome announcement, and we believe that this is a necessary
+> step. The GraphQL community has grown rapidly over the last few years, and has
+> reached the point where transparent, neutral governance policies are necessary
+> for future growth. At Hasura, we look forward to helping the Foundation in its
+> work.” – Tanmai Gopal, CEO, Hasura
+
+> “GraphQL has become one of the most important technologies in the modern
+> application development stack and sees rapid adoption by developers and
+> companies across all industries. At Prisma, we’re very excited to support the
+> GraphQL Foundation to enable a healthy community and sustain the continuous
+> development of GraphQL.” – Johannes Schickling, Founder and CEO, Prisma
+
+> “At Shopify, GraphQL powers our core APIs and all our mobile and web clients.
+> We strongly believe in open development and look to the Foundation to help
+> expand the community and nurture its evolution.” – Jean-Michel Lemieux, SVP
+> Engineering, Shopify
+
+> “GraphQL is gaining tremendous adoption as one of the best protocols for
+> remote retrieval of large object graphs. At Twitter, we are looking forward to
+> what’s to come in the GraphQL ecosystem and are very excited to support the
+> GraphQL Foundation.” – Anna Sulkina Sr. Engineering Manager, Core Services
+> Group, Twitter
diff --git a/src/pages/blog/2018-11-07-datanami.mdx b/src/pages/blog/2018-11-07-datanami.mdx
index db9ad42d17..e261d8275c 100644
--- a/src/pages/blog/2018-11-07-datanami.mdx
+++ b/src/pages/blog/2018-11-07-datanami.mdx
@@ -5,6 +5,10 @@ date: 2018-11-07
byline: Datanami
---
-Don’t look now but a new language called GraphQL is emerging that could radically simplify how developers use APIs to get data into applications, and potentially provide a graph-like alternative to procedural REST. The company behind the open source software, Apollo, today announced the GraphQL Platform to standardize access to the new technology.
+Don’t look now but a new language called GraphQL is emerging that could
+radically simplify how developers use APIs to get data into applications, and
+potentially provide a graph-like alternative to procedural REST. The company
+behind the open source software, Apollo, today announced the GraphQL Platform to
+standardize access to the new technology.
[Read more](https://www.datanami.com/2018/11/07/will-graphql-become-a-standard-for-the-new-data-economy/)
diff --git a/src/pages/blog/2018-11-07-sd-times.mdx b/src/pages/blog/2018-11-07-sd-times.mdx
index f3a59a85b7..1b70cebee2 100644
--- a/src/pages/blog/2018-11-07-sd-times.mdx
+++ b/src/pages/blog/2018-11-07-sd-times.mdx
@@ -1,12 +1,17 @@
---
-title: "SD Times: The Linux Foundation announces plans to form GraphQL foundation"
+title:
+ "SD Times: The Linux Foundation announces plans to form GraphQL foundation"
tags: ["in-the-news"]
date: 2018-11-07
byline: SD Times
---
-In an effort to grow and sustain the GraphQL ecosystem, The Linux Foundation has announced plans to launch a new open-source foundation for it. GraphQL is an [API](https://sdtimes.com/tag/apis/) technology that was initially developed by Facebook.
+In an effort to grow and sustain the GraphQL ecosystem, The Linux Foundation has
+announced plans to launch a new open-source foundation for it. GraphQL is an
+[API](https://sdtimes.com/tag/apis/) technology that was initially developed by
+Facebook.
-The GraphQL Foundation will be a collaborative effort between industry leaders and users.
+The GraphQL Foundation will be a collaborative effort between industry leaders
+and users.
[Read more](https://sdtimes.com/api/the-linux-foundation-announces-plans-to-form-graphql-foundation/)
diff --git a/src/pages/blog/2018-11-07-the-register.mdx b/src/pages/blog/2018-11-07-the-register.mdx
index 7f871a8840..a44c592d6d 100644
--- a/src/pages/blog/2018-11-07-the-register.mdx
+++ b/src/pages/blog/2018-11-07-the-register.mdx
@@ -1,10 +1,14 @@
---
-title: "The Register: Facebook’s open-source license drama-zone GraphQL gets swanky digs in Linux mansion"
+title:
+ "The Register: Facebook’s open-source license drama-zone GraphQL gets swanky
+ digs in Linux mansion"
tags: ["in-the-news"]
date: 2018-11-07
byline: The Register
---
-GraphQL, a query language for APIs that was on the verge of being shunned last year over software license concerns, has bounced back and landed in the arms of the Linux Foundation.
+GraphQL, a query language for APIs that was on the verge of being shunned last
+year over software license concerns, has bounced back and landed in the arms of
+the Linux Foundation.
[Read more](https://www.theregister.co.uk/2018/11/07/graphql_on_linux/)
diff --git a/src/pages/blog/2018-11-12-channel-futures.mdx b/src/pages/blog/2018-11-12-channel-futures.mdx
index 81fb238de6..feef6ca58e 100644
--- a/src/pages/blog/2018-11-12-channel-futures.mdx
+++ b/src/pages/blog/2018-11-12-channel-futures.mdx
@@ -1,12 +1,22 @@
---
-title: "Channel Futures: GraphQL API Query Language Growing, Gets Own Support Foundation"
+title:
+ "Channel Futures: GraphQL API Query Language Growing, Gets Own Support
+ Foundation"
tags: ["in-the-news"]
date: 2018-11-12
byline: Channel Futures
---
-The growing popularity and use of the open-source GraphQL API language by software developers has inspired the creation of a [GraphQL Foundation](https://www.linuxfoundation.org/press-release/2018/11/intent_to_form_graphql/) to promote the technology and help it accelerate its development and footprint in future code.
+The growing popularity and use of the open-source GraphQL API language by
+software developers has inspired the creation of a
+[GraphQL Foundation](https://www.linuxfoundation.org/press-release/2018/11/intent_to_form_graphql/)
+to promote the technology and help it accelerate its development and footprint
+in future code.
-The new organization, hosted by the non-profit [Linux Foundation](http://www.linuxfoundation.org/), is made up of a wide range of companies and users that are interested in growing and nurturing the GraphQL API project, which Facebook originally developed internally. After several years of development, Facebook released the code for GraphQL as an opn-source project.
+The new organization, hosted by the non-profit
+[Linux Foundation](http://www.linuxfoundation.org/), is made up of a wide range
+of companies and users that are interested in growing and nurturing the GraphQL
+API project, which Facebook originally developed internally. After several years
+of development, Facebook released the code for GraphQL as an opn-source project.
[Read more](https://www.channelfutures.com/open-source/graphql-api-query-language-growing-gets-own-support-foundation)
diff --git a/src/pages/blog/2019-03-12-joint-development-foundation.mdx b/src/pages/blog/2019-03-12-joint-development-foundation.mdx
index aa92468005..b827f8bfc9 100644
--- a/src/pages/blog/2019-03-12-joint-development-foundation.mdx
+++ b/src/pages/blog/2019-03-12-joint-development-foundation.mdx
@@ -1,58 +1,201 @@
---
-title: The GraphQL Foundation Announces Collaboration with the Joint Development Foundation to Drive Open Source and Open Standards
+title:
+ The GraphQL Foundation Announces Collaboration with the Joint Development
+ Foundation to Drive Open Source and Open Standards
tags: ["announcements"]
date: 2019-03-12
byline: GraphQL Foundation
---
-The [GraphQL Foundation](/foundation/), a neutral home for the GraphQL community to accelerate development of the surrounding ecosystem, today announces it is collaborating with the Joint Development Foundation (JDF), [which recently joined the Linux Foundation to drive adoption of open source and standards](https://www.linuxfoundation.org/press-release/2018/12/jdf-joins-lf-family/), to continue developing the [GraphQL specification](https://github.com/facebook/graphql/).
-
-GraphQL Foundation encourages contributions, stewardship, and a shared investment from a broad group in vendor-neutral events, documentation, tools, and support for the data query language. The following companies Apollo, AWS, Butterfly Network, Dgraph Labs, Facebook, Gatsby, GraphZen, Hasura, IBM, Intuit, Neo4j, Novvum, Pipefy, Salsify, Solo.io and Thicit are joining as members to advance GraphQL as an industry specification for designing more effective APIs.
-
-GraphQL powers hundreds of billions of API calls a day at Facebook, which developed the technology in 2012 and played an integral role in helping GraphQL [join the Linux Foundation last year](https://www.linuxfoundation.org/press-release/2018/11/intent_to_form_graphql/). Today, virtually every major programming language offers GraphQL support through a variety of open source software libraries.
-
-GraphQL is the first Linux Foundation project to benefit from the JDF and Linux Foundation collaboration, which provides open source projects with a swift path to standardization for open specifications. Developers will have an open GraphQL specification and open source software implementations available for designing conformant APIs.
-
-“We are excited to formally welcome new members and to work closely with them to build out and support a global GraphQL ecosystem. We’re pleased that the GraphQL specification will continue to evolve through the JDF and Linux Foundation partnership. With an easier and faster way to create and advance standards, developers can concentrate on creating applications that make a bigger impact on communities around the world,” said Lee Byron, co-creator of GraphQL.
-
-GraphQL is important for API development as it allows nested objects in a single API request that traditionally would require multiple API requests. The [GraphQL specification](https://github.com/facebook/graphql/), [GraphQL.js](https://github.com/graphql/graphql-js) reference implementation, [DataLoader](https://github.com/facebook/dataloader) library, and [GraphiQL](https://github.com/graphql/graphiql) developer tool are technical projects supported by the GraphQL Foundation. As application development shifts toward microservices architectures with an emphasis on flexibility and speed to market, tools like GraphQL are redefining API design and client-server interaction to improve the developer experience, increasing developer productivity and minimizing amounts of data transferred. GraphQL makes cross-platform and mobile development simpler with availability in multiple programming languages that are consistent and feature parity across multiple platforms such as web, iOS, Android, and embedded and IoT applications.
-
-[The Linux Foundation](https://www.linuxfoundation.org/) and the [Facebook Open Source](https://opensource.facebook.com/) team leveraged the JDF’s proven framework to create a lightweight governance structure for specifications — allowing communities to quickly spin-up neutral collaborations.
-
-“We’re thrilled to see GraphQL and the Joint Development Foundation join forces and get to work so quickly to advance open standards,” said Jim Zemlin, executive director of the Linux Foundation. “Working with the JDF, the GraphQL community is able to leverage turnkey infrastructure to create and manage open standards more quickly and nimbly than ever before. This allows developers to continue to break barriers and modernize application development.”
-
-“We are very pleased to have worked closely with the Linux Foundation in creating this novel approach to specification-based collaborations,” said Michael Cheng from the Facebook Open Source team. “By offering open source communities a streamlined path to standardization and nurturing open source implementations, this strategic alignment benefits GraphQL developers, corporate contributors and end users who need both outcomes to succeed.”
-
-“We look forward to working closely with the GraphQL Foundation and we expect many other Linux Foundation projects to work with us this year to accelerate specifications and standards development to advance their mission and drive the creation of innovative technology, ” said David Rudin, president of the Joint Development Foundation.
+The [GraphQL Foundation](/foundation/), a neutral home for the GraphQL community
+to accelerate development of the surrounding ecosystem, today announces it is
+collaborating with the Joint Development Foundation (JDF),
+[which recently joined the Linux Foundation to drive adoption of open source and standards](https://www.linuxfoundation.org/press-release/2018/12/jdf-joins-lf-family/),
+to continue developing the
+[GraphQL specification](https://github.com/facebook/graphql/).
+
+GraphQL Foundation encourages contributions, stewardship, and a shared
+investment from a broad group in vendor-neutral events, documentation, tools,
+and support for the data query language. The following companies Apollo, AWS,
+Butterfly Network, Dgraph Labs, Facebook, Gatsby, GraphZen, Hasura, IBM, Intuit,
+Neo4j, Novvum, Pipefy, Salsify, Solo.io and Thicit are joining as members to
+advance GraphQL as an industry specification for designing more effective APIs.
+
+GraphQL powers hundreds of billions of API calls a day at Facebook, which
+developed the technology in 2012 and played an integral role in helping GraphQL
+[join the Linux Foundation last year](https://www.linuxfoundation.org/press-release/2018/11/intent_to_form_graphql/).
+Today, virtually every major programming language offers GraphQL support through
+a variety of open source software libraries.
+
+GraphQL is the first Linux Foundation project to benefit from the JDF and Linux
+Foundation collaboration, which provides open source projects with a swift path
+to standardization for open specifications. Developers will have an open GraphQL
+specification and open source software implementations available for designing
+conformant APIs.
+
+“We are excited to formally welcome new members and to work closely with them to
+build out and support a global GraphQL ecosystem. We’re pleased that the GraphQL
+specification will continue to evolve through the JDF and Linux Foundation
+partnership. With an easier and faster way to create and advance standards,
+developers can concentrate on creating applications that make a bigger impact on
+communities around the world,” said Lee Byron, co-creator of GraphQL.
+
+GraphQL is important for API development as it allows nested objects in a single
+API request that traditionally would require multiple API requests. The
+[GraphQL specification](https://github.com/facebook/graphql/),
+[GraphQL.js](https://github.com/graphql/graphql-js) reference implementation,
+[DataLoader](https://github.com/facebook/dataloader) library, and
+[GraphiQL](https://github.com/graphql/graphiql) developer tool are technical
+projects supported by the GraphQL Foundation. As application development shifts
+toward microservices architectures with an emphasis on flexibility and speed to
+market, tools like GraphQL are redefining API design and client-server
+interaction to improve the developer experience, increasing developer
+productivity and minimizing amounts of data transferred. GraphQL makes
+cross-platform and mobile development simpler with availability in multiple
+programming languages that are consistent and feature parity across multiple
+platforms such as web, iOS, Android, and embedded and IoT applications.
+
+[The Linux Foundation](https://www.linuxfoundation.org/) and the
+[Facebook Open Source](https://opensource.facebook.com/) team leveraged the
+JDF’s proven framework to create a lightweight governance structure for
+specifications — allowing communities to quickly spin-up neutral collaborations.
+
+“We’re thrilled to see GraphQL and the Joint Development Foundation join forces
+and get to work so quickly to advance open standards,” said Jim Zemlin,
+executive director of the Linux Foundation. “Working with the JDF, the GraphQL
+community is able to leverage turnkey infrastructure to create and manage open
+standards more quickly and nimbly than ever before. This allows developers to
+continue to break barriers and modernize application development.”
+
+“We are very pleased to have worked closely with the Linux Foundation in
+creating this novel approach to specification-based collaborations,” said
+Michael Cheng from the Facebook Open Source team. “By offering open source
+communities a streamlined path to standardization and nurturing open source
+implementations, this strategic alignment benefits GraphQL developers, corporate
+contributors and end users who need both outcomes to succeed.”
+
+“We look forward to working closely with the GraphQL Foundation and we expect
+many other Linux Foundation projects to work with us this year to accelerate
+specifications and standards development to advance their mission and drive the
+creation of innovative technology, ” said David Rudin, president of the Joint
+Development Foundation.
## Member Quotes
-> “Given GraphQL’s centrality in the modern app development stack, the foundation we’re launching today is not just necessary, but overdue. As the creators of Apollo, the most widely used implementation of GraphQL, we’re looking forward to working together with the Linux Foundation to define appropriate governance processes and accelerate the adoption of this critical Internet standard.” — Geoff Schmidt, CEO and Co-Founder, Apollo
-
-> “GraphQL is a foundational technology for building APIs that empower frontend developers to deliver the best user experience for their customers. With AWS AppSync and the Amplify Framework, AWS is enabling developers to build and run critical GraphQL workloads at scale, and we are excited to join the Foundation to support and grow the GraphQL community.” — Adrian Cockcroft, Vice President of Cloud Architecture Strategy, AWS
-
-> “GraphQL has been invaluable to Butterfly Network in advancing our mission of democratizing medical imaging. It’s enabled us to build data-efficient APIs to serve healthcare providers in areas with limited broadband internet access, while preserving our ability to quickly develop new API functionality. GraphQL has played a key role in allowing our back end and front end teams to work together with a minimum of friction. We’re excited to support the GraphQL Foundation in its work to further shepherd the standard.” — Jimmy Jia, Principal Scientist, Butterfly Network
-
-> “Dgraph started just a few months after a draft GraphQL spec was released in mid-2015. Unsatisfied with existing graph languages, we decided to bet the future of our distributed graph database on GraphQL. Dgraph is now the only database to natively support a language very close to GraphQL. Considering how easy and intuitive it is for our users, it has been the best decision we made. So, we stand proud with the GraphQL Foundation to help build the next generation of apps on graphs.” – Manish R. Jain, CEO, Dgraph Labs
-
-> “Our goal at Gastby is to provide the best platform for building fast, compelling websites. We use GraphQL to provide a flexible data layer that can be used with different sources. We welcome the establishment of the GraphQL Specification Project and are very excited to be part of it.” — Mikhail Novikov, Software Developer, Gatsby Inc.
-
-> “GraphZen strives to deliver a fantastic developer experience for C# developers building GraphQL APIs and to provide the support and training needed by enterprises to realize the benefits of GraphQL. GraphZen is excited to join the GraphQL Foundation and steward the GraphQL specification in a way that continues to drive innovation and adoption through open standards.” — Craig Smitham, Creator & Founder, GraphZen
-
-> “The GraphQL technology and community is spearheading a much required shift in the API experience for the modern web, especially as applications are becoming more ‘frontend’ heavy. At Hasura, we’re extremely excited about the potential of GraphQL to evolve the way teams organize their codebases, and communicate with each other; especially in relation to the ongoing serverless movement. There could not be a better home for GraphQL projects and events than the GraphQL Foundation, and we are proud to do our bit to help make the technology and community around GraphQL sustainable and open.” — Tanmai Gopal, CEO, Hasura
-
-> “IBM has continued to be an industry leader, helping clients keep pace with the rapidly evolving API technologies landscape. We are pleased to join the new GraphQL Foundation as a founding member to help drive greater open source innovation and adoption of this important data access language and runtime for APIs.” – Juan Carlos Soto, VP Hybrid Cloud Integration and API Economy, IBM
-
-> “Intuit began using GraphQL shortly after it arrived in open source. We have developed a complex schema with over 600 core objects, 1,600 types and thousands of connections between objects. We’ve made major contributions to the open source GraphQL Java library. We look forward to participating in the GraphQL Foundation to advance its capabilities and more directly participate in the thriving community.” — Jeff Brewer, Vice President, Chief Architect, Small Business and Self-Employed Group, Intuit
-
-> “Neo4j is pleased to support GraphQL, due to its unique ability to enable front-end developers, API developers and data architects to all work with the same graph-based data model. Our GraphQL integration and GRANDstack have already helped thousands of developers build graph applications with Neo4j, thanks to the huge developer productivity gain of GraphQL and the graph thinking mindset it brings for both developers and API consumers. The GraphQL Foundation is an important step to cement today’s most relevant standard for building APIs and we’re honored to join as founding members to help steward GraphQL as the ecosystem continues to evolve.” — Emil Eifrem, CEO and Co-Founder, Neo4j
-
-> “We are grateful that Novvum has grown alongside GraphQL and its community over the past four years. We couldn’t be more excited about the future of GraphQL, and look forward to working with the Linux Foundation and GraphQL Foundation to improve the quality and experience of API development for engineers.” — Raj Singh, CEO and Co-Founder, Novvum
-
-> “At Pipefy we are building the lean management platform. Since the beginning, GraphQL has enabled our developers to deliver new features and services more efficiently and with better communication from front-end and back-end teams. After we started using it internally, we decided to build our public API using GraphQL, a choice that enabled us to deliver a better developer experience to the developers who are building on top of our platform. We are excited to contribute to the GraphQL ecosystem and support the GraphQL Foundation.” — Raphael Costa, Head of Platform, Pipefy
-
-> “Salsify provides a data platform that enables the world’s largest brands to deliver compelling product experiences across the retail ecosystem. Our GraphQL powered APIs enable us to support a diverse set of use cases with great developer ergonomics and excellent performance. We look forward to working with the GraphQL Foundation to support the continued evolution of GraphQL.” — Joel Turkel, Chief Software Architect, Salsify
-
-> “[Solo.io](http://solo.io)’s mission is to empower enterprise organizations rapidly adopt innovative technology and extend their existing investments. GraphQL is a powerful way to help “glue” monolith, microservices, and serverless applications with a unified API. Our open-source project, Sqoop, leverages GraphQL and other innovative projects like Envoy to streamline the developer experience, and simply glue together environments without writing a single line of code. We are excited to join the GraphQL Foundation and look forward to working within the GraphQL community” — Idit Levine, CEO & Founder, Solo.io
-
-> “GraphQL, and alongside its tooling, has grown to proof its worth and is here to stay. Time for a power-up supported by many hands and brains through the Joint Development Foundation and Linux Foundation. GraphQL is the glue that keeps your domain data in context, understandable, and always ready to empower the next ideas. Looking forward to new and improved power’s, to evolution.” — Tim Govers, CEO, Thicit
+> “Given GraphQL’s centrality in the modern app development stack, the
+> foundation we’re launching today is not just necessary, but overdue. As the
+> creators of Apollo, the most widely used implementation of GraphQL, we’re
+> looking forward to working together with the Linux Foundation to define
+> appropriate governance processes and accelerate the adoption of this critical
+> Internet standard.” — Geoff Schmidt, CEO and Co-Founder, Apollo
+
+> “GraphQL is a foundational technology for building APIs that empower frontend
+> developers to deliver the best user experience for their customers. With AWS
+> AppSync and the Amplify Framework, AWS is enabling developers to build and run
+> critical GraphQL workloads at scale, and we are excited to join the Foundation
+> to support and grow the GraphQL community.” — Adrian Cockcroft, Vice President
+> of Cloud Architecture Strategy, AWS
+
+> “GraphQL has been invaluable to Butterfly Network in advancing our mission of
+> democratizing medical imaging. It’s enabled us to build data-efficient APIs to
+> serve healthcare providers in areas with limited broadband internet access,
+> while preserving our ability to quickly develop new API functionality. GraphQL
+> has played a key role in allowing our back end and front end teams to work
+> together with a minimum of friction. We’re excited to support the GraphQL
+> Foundation in its work to further shepherd the standard.” — Jimmy Jia,
+> Principal Scientist, Butterfly Network
+
+> “Dgraph started just a few months after a draft GraphQL spec was released in
+> mid-2015. Unsatisfied with existing graph languages, we decided to bet the
+> future of our distributed graph database on GraphQL. Dgraph is now the only
+> database to natively support a language very close to GraphQL. Considering how
+> easy and intuitive it is for our users, it has been the best decision we made.
+> So, we stand proud with the GraphQL Foundation to help build the next
+> generation of apps on graphs.” – Manish R. Jain, CEO, Dgraph Labs
+
+> “Our goal at Gastby is to provide the best platform for building fast,
+> compelling websites. We use GraphQL to provide a flexible data layer that can
+> be used with different sources. We welcome the establishment of the GraphQL
+> Specification Project and are very excited to be part of it.” — Mikhail
+> Novikov, Software Developer, Gatsby Inc.
+
+> “GraphZen strives to deliver a fantastic developer experience for C#
+> developers building GraphQL APIs and to provide the support and training
+> needed by enterprises to realize the benefits of GraphQL. GraphZen is excited
+> to join the GraphQL Foundation and steward the GraphQL specification in a way
+> that continues to drive innovation and adoption through open standards.” —
+> Craig Smitham, Creator & Founder, GraphZen
+
+> “The GraphQL technology and community is spearheading a much required shift in
+> the API experience for the modern web, especially as applications are becoming
+> more ‘frontend’ heavy. At Hasura, we’re extremely excited about the potential
+> of GraphQL to evolve the way teams organize their codebases, and communicate
+> with each other; especially in relation to the ongoing serverless movement.
+> There could not be a better home for GraphQL projects and events than the
+> GraphQL Foundation, and we are proud to do our bit to help make the technology
+> and community around GraphQL sustainable and open.” — Tanmai Gopal, CEO,
+> Hasura
+
+> “IBM has continued to be an industry leader, helping clients keep pace with
+> the rapidly evolving API technologies landscape. We are pleased to join the
+> new GraphQL Foundation as a founding member to help drive greater open source
+> innovation and adoption of this important data access language and runtime for
+> APIs.” – Juan Carlos Soto, VP Hybrid Cloud Integration and API Economy, IBM
+
+> “Intuit began using GraphQL shortly after it arrived in open source. We have
+> developed a complex schema with over 600 core objects, 1,600 types and
+> thousands of connections between objects. We’ve made major contributions to
+> the open source GraphQL Java library. We look forward to participating in the
+> GraphQL Foundation to advance its capabilities and more directly participate
+> in the thriving community.” — Jeff Brewer, Vice President, Chief Architect,
+> Small Business and Self-Employed Group, Intuit
+
+> “Neo4j is pleased to support GraphQL, due to its unique ability to enable
+> front-end developers, API developers and data architects to all work with the
+> same graph-based data model. Our GraphQL integration and GRANDstack have
+> already helped thousands of developers build graph applications with Neo4j,
+> thanks to the huge developer productivity gain of GraphQL and the graph
+> thinking mindset it brings for both developers and API consumers. The GraphQL
+> Foundation is an important step to cement today’s most relevant standard for
+> building APIs and we’re honored to join as founding members to help steward
+> GraphQL as the ecosystem continues to evolve.” — Emil Eifrem, CEO and
+> Co-Founder, Neo4j
+
+> “We are grateful that Novvum has grown alongside GraphQL and its community
+> over the past four years. We couldn’t be more excited about the future of
+> GraphQL, and look forward to working with the Linux Foundation and GraphQL
+> Foundation to improve the quality and experience of API development for
+> engineers.” — Raj Singh, CEO and Co-Founder, Novvum
+
+> “At Pipefy we are building the lean management platform. Since the beginning,
+> GraphQL has enabled our developers to deliver new features and services more
+> efficiently and with better communication from front-end and back-end teams.
+> After we started using it internally, we decided to build our public API using
+> GraphQL, a choice that enabled us to deliver a better developer experience to
+> the developers who are building on top of our platform. We are excited to
+> contribute to the GraphQL ecosystem and support the GraphQL Foundation.” —
+> Raphael Costa, Head of Platform, Pipefy
+
+> “Salsify provides a data platform that enables the world’s largest brands to
+> deliver compelling product experiences across the retail ecosystem. Our
+> GraphQL powered APIs enable us to support a diverse set of use cases with
+> great developer ergonomics and excellent performance. We look forward to
+> working with the GraphQL Foundation to support the continued evolution of
+> GraphQL.” — Joel Turkel, Chief Software Architect, Salsify
+
+> “[Solo.io](http://solo.io)’s mission is to empower enterprise organizations
+> rapidly adopt innovative technology and extend their existing investments.
+> GraphQL is a powerful way to help “glue” monolith, microservices, and
+> serverless applications with a unified API. Our open-source project, Sqoop,
+> leverages GraphQL and other innovative projects like Envoy to streamline the
+> developer experience, and simply glue together environments without writing a
+> single line of code. We are excited to join the GraphQL Foundation and look
+> forward to working within the GraphQL community” — Idit Levine, CEO & Founder,
+> Solo.io
+
+> “GraphQL, and alongside its tooling, has grown to proof its worth and is here
+> to stay. Time for a power-up supported by many hands and brains through the
+> Joint Development Foundation and Linux Foundation. GraphQL is the glue that
+> keeps your domain data in context, understandable, and always ready to empower
+> the next ideas. Looking forward to new and improved power’s, to evolution.” —
+> Tim Govers, CEO, Thicit
diff --git a/src/pages/blog/2019-10-28-interactive-landscape.mdx b/src/pages/blog/2019-10-28-interactive-landscape.mdx
index 03a457646f..1b7dbbd1d6 100644
--- a/src/pages/blog/2019-10-28-interactive-landscape.mdx
+++ b/src/pages/blog/2019-10-28-interactive-landscape.mdx
@@ -1,48 +1,129 @@
---
-title: GraphQL Foundation Launches Interactive Landscape and Welcomes New Members from Open Source Summit Europe
+title:
+ GraphQL Foundation Launches Interactive Landscape and Welcomes New Members
+ from Open Source Summit Europe
tags: ["announcements"]
date: 2019-10-28
byline: GraphQL Foundation
---
-[The GraphQL Foundation](/), a neutral home for the GraphQL community to accelerate development of the surrounding ecosystem, today announced seven new members to support the Foundation's efforts, along with the launch of the [GraphQL Landscape](https://landscape.graphql.org).
-
-The GraphQL Landscape is a dynamically generated tool designed to help explore the burgeoning GraphQL community of projects, adopters and member organizations. Currently, it is comprised of 100+ cards representing a market cap of more than $3.4T.
-
-"When we first created GraphQL, we set out to make product development easier with APIs driven by the needs of mobile and app developers and dramatic simplifications of how APIs are built and maintained," said Lee Byron, Director of the GraphQL Foundation. "I'm thrilled to see this influx of multi-industry support for GraphQL and a commitment to increase developer productivity, showcased throughout the impressive and growing landscape."
-
-"I'm thrilled to help launch the GraphQL Foundation's first landscape, displaying GraphQL's vast range of projects, adopters and members," said Chris Aniszczyk, VP of Developer Relations and CTO of CNCF at the Linux Foundation. "This interactive resource has been a labor of love from and for our community, and I look forward to watching it grow into the same standard for real-time ecosystem information that the CNCF Landscape has been for the cloud native space."
-
-GraphQL is a next-generation API technology developed internally by Facebook in 2012 before being publicly [open sourced in 2015](https://code.fb.com/core-data/graphql-a-data-query-language/). Unlike REST-based APIs, which take advantage of HTTP and existing protocols, GraphQL APIs provide developers with the flexibility to query the exact data they need from a diverse set of cloud data sources, with less code, greater performance and security, and a faster development cycle. Not only does this enable developers to rapidly build top quality apps, it also helps them achieve consistency and feature parity across multiple platforms such as web, iOS, Android, and embedded and IoT applications.
-
-Brian Warner of The Linux Foundation has joined the GraphQL Foundation as its Program Director, helping to support the growing community and the project's ongoing needs. "I look forward to working with Lee and the governing board to establish the infrastructure and support needed to ensure the health and sustainability of the vibrant GraphQL community."
-
-GraphQL is being used in production by a [variety of high scale companies](https://graphql.org/users/) such as Airbnb, Atlassian, Audi, CNBC, GitHub, Major League Soccer, Netflix, Shopify, The New York Times, Twitter, Pinterest and Yelp. GraphQL also [powers hundreds of billions of API calls a day at Facebook](https://code.fb.com/core-data/graphql-a-data-query-language/).
+[The GraphQL Foundation](/), a neutral home for the GraphQL community to
+accelerate development of the surrounding ecosystem, today announced seven new
+members to support the Foundation's efforts, along with the launch of the
+[GraphQL Landscape](https://landscape.graphql.org).
+
+The GraphQL Landscape is a dynamically generated tool designed to help explore
+the burgeoning GraphQL community of projects, adopters and member organizations.
+Currently, it is comprised of 100+ cards representing a market cap of more than
+$3.4T.
+
+"When we first created GraphQL, we set out to make product development easier
+with APIs driven by the needs of mobile and app developers and dramatic
+simplifications of how APIs are built and maintained," said Lee Byron, Director
+of the GraphQL Foundation. "I'm thrilled to see this influx of multi-industry
+support for GraphQL and a commitment to increase developer productivity,
+showcased throughout the impressive and growing landscape."
+
+"I'm thrilled to help launch the GraphQL Foundation's first landscape,
+displaying GraphQL's vast range of projects, adopters and members," said Chris
+Aniszczyk, VP of Developer Relations and CTO of CNCF at the Linux Foundation.
+"This interactive resource has been a labor of love from and for our community,
+and I look forward to watching it grow into the same standard for real-time
+ecosystem information that the CNCF Landscape has been for the cloud native
+space."
+
+GraphQL is a next-generation API technology developed internally by Facebook in
+2012 before being publicly
+[open sourced in 2015](https://code.fb.com/core-data/graphql-a-data-query-language/).
+Unlike REST-based APIs, which take advantage of HTTP and existing protocols,
+GraphQL APIs provide developers with the flexibility to query the exact data
+they need from a diverse set of cloud data sources, with less code, greater
+performance and security, and a faster development cycle. Not only does this
+enable developers to rapidly build top quality apps, it also helps them achieve
+consistency and feature parity across multiple platforms such as web, iOS,
+Android, and embedded and IoT applications.
+
+Brian Warner of The Linux Foundation has joined the GraphQL Foundation as its
+Program Director, helping to support the growing community and the project's
+ongoing needs. "I look forward to working with Lee and the governing board to
+establish the infrastructure and support needed to ensure the health and
+sustainability of the vibrant GraphQL community."
+
+GraphQL is being used in production by a
+[variety of high scale companies](https://graphql.org/users/) such as Airbnb,
+Atlassian, Audi, CNBC, GitHub, Major League Soccer, Netflix, Shopify, The New
+York Times, Twitter, Pinterest and Yelp. GraphQL also
+[powers hundreds of billions of API calls a day at Facebook](https://code.fb.com/core-data/graphql-a-data-query-language/).
## Member Quotes
-"Open source specifications rely on strong collaboration and proper stewardship. 8base loves GraphQL and we joined the GraphQL Foundation to be involved in the specification's future with other leading-edge technology companies. Our hope is that, with our involvement, the surrounding ecosystem continues to flourish at an accelerated pace." - _Albert Santalo, CEO & Founder, 8base_
-
-"It's truly surreal to see GraphQL grow from its conception to spread throughout the entire technology industry. The Foundation provides the infrastructure to make this a true industry standard, backed by stable, trusted, company-neutral governance." - _Nick Schrock, Founder, Elementl_
-
-"At Expedia Group, GraphQL is helping us build better experiences for our travelers. As a rapidly adopted technology in software development, we believe an open and community supported GraphQL specification and ecosystem is critical to its continued success." - _Trevor Livingston, Principal Architect, Expedia Group (VRBO)_
-
-"At Fauna, we have seen first-hand the productivity and architectural benefits GraphQL offers developers. We believe that an open ecosystem and shared specification are a benefit to all. We're excited to contribute to the GraphQL community and collaborate on its continued innovation." - _Matt Freels, CTO, Fauna, Inc._
-
-"We are thrilled to be a part of the GraphQL Foundation. We see GraphQL as one of the most important emerging API technologies and strongly believe in its bright future! We're excited to continue investing in the GraphQL ecosystem and community with tools, events and educational content." - _Johannes Schickling, CEO, Prisma_
-
-"We're deliberate about the technology we build and adopt. That's why we're excited to double-down on our investment in GraphQL as a foundational technology at Shopify. We believe GraphQL provides great tools for our internal teams and app developers to extend our platform and create faster merchant experiences." - _Jean-Michel Lemieux, CTO, Shopify_
-
-"GraphQL plays a key part in helping us serve the public conversation on Twitter by enabling faster product iteration across our teams. As GraphQL is gaining tremendous adoption as one of the best protocols for remote retrieval of large object graphs, we are very excited to support the GraphQL Foundation." - _Anna Sulkina Engineering Director, Core Services Group, Twitter_
+"Open source specifications rely on strong collaboration and proper stewardship.
+8base loves GraphQL and we joined the GraphQL Foundation to be involved in the
+specification's future with other leading-edge technology companies. Our hope is
+that, with our involvement, the surrounding ecosystem continues to flourish at
+an accelerated pace." - _Albert Santalo, CEO & Founder, 8base_
+
+"It's truly surreal to see GraphQL grow from its conception to spread throughout
+the entire technology industry. The Foundation provides the infrastructure to
+make this a true industry standard, backed by stable, trusted, company-neutral
+governance." - _Nick Schrock, Founder, Elementl_
+
+"At Expedia Group, GraphQL is helping us build better experiences for our
+travelers. As a rapidly adopted technology in software development, we believe
+an open and community supported GraphQL specification and ecosystem is critical
+to its continued success." - _Trevor Livingston, Principal Architect, Expedia
+Group (VRBO)_
+
+"At Fauna, we have seen first-hand the productivity and architectural benefits
+GraphQL offers developers. We believe that an open ecosystem and shared
+specification are a benefit to all. We're excited to contribute to the GraphQL
+community and collaborate on its continued innovation." - _Matt Freels, CTO,
+Fauna, Inc._
+
+"We are thrilled to be a part of the GraphQL Foundation. We see GraphQL as one
+of the most important emerging API technologies and strongly believe in its
+bright future! We're excited to continue investing in the GraphQL ecosystem and
+community with tools, events and educational content." - _Johannes Schickling,
+CEO, Prisma_
+
+"We're deliberate about the technology we build and adopt. That's why we're
+excited to double-down on our investment in GraphQL as a foundational technology
+at Shopify. We believe GraphQL provides great tools for our internal teams and
+app developers to extend our platform and create faster merchant experiences." -
+_Jean-Michel Lemieux, CTO, Shopify_
+
+"GraphQL plays a key part in helping us serve the public conversation on Twitter
+by enabling faster product iteration across our teams. As GraphQL is gaining
+tremendous adoption as one of the best protocols for remote retrieval of large
+object graphs, we are very excited to support the GraphQL Foundation." - _Anna
+Sulkina Engineering Director, Core Services Group, Twitter_
## About the GraphQL Foundation
-The GraphQL Foundation is an open, neutral organization that provides oversight of funding, operations, and marketing resources for the GraphQL community to enable widespread adoption and help accelerate development of the broader ecosystem. The [GraphQL specification](https://github.com/graphql/graphql-spec), [GraphQL.js](https://github.com/graphql/graphql-js) reference implementation, [DataLoader](https://github.com/graphql/dataloader) library, and [GraphiQL](https://github.com/graphql/graphiql) developer tool are technical projects supported by the GraphQL Foundation. More details can be found at https://foundation.graphql.org.
+The GraphQL Foundation is an open, neutral organization that provides oversight
+of funding, operations, and marketing resources for the GraphQL community to
+enable widespread adoption and help accelerate development of the broader
+ecosystem. The [GraphQL specification](https://github.com/graphql/graphql-spec),
+[GraphQL.js](https://github.com/graphql/graphql-js) reference implementation,
+[DataLoader](https://github.com/graphql/dataloader) library, and
+[GraphiQL](https://github.com/graphql/graphiql) developer tool are technical
+projects supported by the GraphQL Foundation. More details can be found at
+https://foundation.graphql.org.
## About The Linux Foundation
-The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and industry adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at www.linuxfoundation.org.
+The Linux Foundation is the organization of choice for the world’s top
+developers and companies to build ecosystems that accelerate open technology
+development and industry adoption. Together with the worldwide open source
+community, it is solving the hardest technology problems by creating the largest
+shared technology investment in history. Founded in 2000, The Linux Foundation
+today provides tools, training and events to scale any open source project,
+which together deliver an economic impact not achievable by any one company.
+More information can be found at www.linuxfoundation.org.
---
-_The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds._
+_The Linux Foundation has registered trademarks and uses trademarks. For a list
+of trademarks of The Linux Foundation, please see our trademark usage page:
+https://linuxfoundation.org/trademark-usage. Linux is a registered trademark of
+Linus Torvalds._
diff --git a/src/pages/blog/2019-10-31-linux-foundation-training.mdx b/src/pages/blog/2019-10-31-linux-foundation-training.mdx
index 5d9bd5f7f2..862b3c5b60 100644
--- a/src/pages/blog/2019-10-31-linux-foundation-training.mdx
+++ b/src/pages/blog/2019-10-31-linux-foundation-training.mdx
@@ -1,29 +1,68 @@
---
-title: "Linux Foundation Training Announces a Free Online Course-Exploring GraphQL: A Query Language for APIs"
+title:
+ "Linux Foundation Training Announces a Free Online Course-Exploring GraphQL: A
+ Query Language for APIs"
tags: [announcements]
date: 2019-10-31
byline: GraphQL Foundation
---
-[The Linux Foundation](http://www.linuxfoundation.org/), the nonprofit organization enabling mass innovation through open source, today announced enrollment is now open for a new, free, course – [Exploring GraphQL: A Query Language for APIs](https://www.edx.org/course/introduction-to-graphql). This course is offered through [edX](https://www.edx.org/), the trusted platform for learning.
+[The Linux Foundation](http://www.linuxfoundation.org/), the nonprofit
+organization enabling mass innovation through open source, today announced
+enrollment is now open for a new, free, course –
+[Exploring GraphQL: A Query Language for APIs](https://www.edx.org/course/introduction-to-graphql).
+This course is offered through [edX](https://www.edx.org/), the trusted platform
+for learning.
-[GraphQL](https://graphql.org) is revolutionizing the way developers are building APIs for web, mobile and even databases. But what exactly is GraphQL? GraphQL is an open source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data.
+[GraphQL](https://graphql.org) is revolutionizing the way developers are
+building APIs for web, mobile and even databases. But what exactly is GraphQL?
+GraphQL is an open source data query and manipulation language for APIs, and a
+runtime for fulfilling queries with existing data.
-This course explains what GraphQL is and why it is getting so much attention from software engineers. It covers the advantages over REST, what types of software architectures to use it with, and why it benefits both frontend and backend developers. The student practices GraphQL queries in an interactive playground, and learns advanced topics such as how to implement a GraphQL server on the backend, how to use a GraphQL server with a client, and how to keep the GraphQL server secure. The course content was originally created by [Prisma](https://prisma.io), and updated and maintained by [Novvum](https://novvum.io).
+This course explains what GraphQL is and why it is getting so much attention
+from software engineers. It covers the advantages over REST, what types of
+software architectures to use it with, and why it benefits both frontend and
+backend developers. The student practices GraphQL queries in an interactive
+playground, and learns advanced topics such as how to implement a GraphQL server
+on the backend, how to use a GraphQL server with a client, and how to keep the
+GraphQL server secure. The course content was originally created by
+[Prisma](https://prisma.io), and updated and maintained by
+[Novvum](https://novvum.io).
-"Since open sourcing GraphQL, I have been blown away by the growth of the technology and community. I'm excited to see the introduction of more educational material which I hope will help our community continue to grow and reach developers world-wide." – _Lee Byron, Executive Director, GraphQL Foundation, and GraphQL Co-Creator_
+"Since open sourcing GraphQL, I have been blown away by the growth of the
+technology and community. I'm excited to see the introduction of more
+educational material which I hope will help our community continue to grow and
+reach developers world-wide." – _Lee Byron, Executive Director, GraphQL
+Foundation, and GraphQL Co-Creator_
-This course will help programmers gain the skills needed to use GraphQL for a small project or professionally in production. They will feel comfortable getting started with the right tools for their use case.
+This course will help programmers gain the skills needed to use GraphQL for a
+small project or professionally in production. They will feel comfortable
+getting started with the right tools for their use case.
-For the nontechnical person, this course will help them improve communication with developers and to participate in conversations about GraphQL. They will understand when and why to use GraphQL for a project.
+For the nontechnical person, this course will help them improve communication
+with developers and to participate in conversations about GraphQL. They will
+understand when and why to use GraphQL for a project.
-[Exploring GraphQL: A Query Language for APIs](https://www.edx.org/course/introduction-to-graphql) is available at no cost, with content access for up to 7 weeks. Learners may upgrade to the verified track for $99, which includes all graded assessments, unlimited access to the course content and the ability to earn a Verified Certificate upon passing the course.
+[Exploring GraphQL: A Query Language for APIs](https://www.edx.org/course/introduction-to-graphql)
+is available at no cost, with content access for up to 7 weeks. Learners may
+upgrade to the verified track for $99, which includes all graded assessments,
+unlimited access to the course content and the ability to earn a Verified
+Certificate upon passing the course.
## About The Linux Foundation
-The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and industry adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at https://linuxfoundation.org.
+The Linux Foundation is the organization of choice for the world’s top
+developers and companies to build ecosystems that accelerate open technology
+development and industry adoption. Together with the worldwide open source
+community, it is solving the hardest technology problems by creating the largest
+shared technology investment in history. Founded in 2000, The Linux Foundation
+today provides tools, training and events to scale any open source project,
+which together deliver an economic impact not achievable by any one company.
+More information can be found at https://linuxfoundation.org.
-The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://linuxfoundation.org/trademark-usage.
+The Linux Foundation has registered trademarks and uses trademarks. For a list
+of trademarks of The Linux Foundation, please see our trademark usage page:
+https://linuxfoundation.org/trademark-usage.
Linux is a registered trademark of Linus Torvalds.
diff --git a/src/pages/blog/2020-04-02-graphql-annual-report-2019.mdx b/src/pages/blog/2020-04-02-graphql-annual-report-2019.mdx
index a00b056a6d..ca5b291990 100644
--- a/src/pages/blog/2020-04-02-graphql-annual-report-2019.mdx
+++ b/src/pages/blog/2020-04-02-graphql-annual-report-2019.mdx
@@ -5,20 +5,62 @@ date: 2020-04-02
byline: GraphQL Foundation
---
-The GraphQL Foundation recently turned 1 year old and is happy to announce its [first annual report](/foundation/annual-reports/2019/)!
+The GraphQL Foundation recently turned 1 year old and is happy to announce its
+[first annual report](/foundation/annual-reports/2019/)!
-The annual report details the accomplishments of the organization in its first year, along with a forward looking statement for 2020 and beyond from Lee Byron, the GraphQL Foundation Executive Director:
+The annual report details the accomplishments of the organization in its first
+year, along with a forward looking statement for 2020 and beyond from Lee Byron,
+the GraphQL Foundation Executive Director:
-> As the Executive Director of the GraphQL project, I hope I can speak for the whole community when I say we are looking forward to another productive year of GraphQL development. We are putting the final touches on the GraphQL 2020 spec release, and continue to make great progress developing new features, stabilizing existing ones, and exploring beyond core GraphQL.
+> As the Executive Director of the GraphQL project, I hope I can speak for the
+> whole community when I say we are looking forward to another productive year
+> of GraphQL development. We are putting the final touches on the GraphQL 2020
+> spec release, and continue to make great progress developing new features,
+> stabilizing existing ones, and exploring beyond core GraphQL.
>
-> It has been really encouraging to see GraphQL continue to evolve over the past year as a technology and as a community. GraphQL is being used at scale by not only Facebook but now a great number of organizations large and small. As I said when first introducing the project, GraphQL is unapologetically driven by the needs of the client. This has been a critical aspect of GraphQL's success and it is great to see this principle reflect itself in our community, where those more interested in consuming APIs than producing them have come together to support the ongoing sustainability of the project.
+> It has been really encouraging to see GraphQL continue to evolve over the past
+> year as a technology and as a community. GraphQL is being used at scale by not
+> only Facebook but now a great number of organizations large and small. As I
+> said when first introducing the project, GraphQL is unapologetically driven by
+> the needs of the client. This has been a critical aspect of GraphQL's success
+> and it is great to see this principle reflect itself in our community, where
+> those more interested in consuming APIs than producing them have come together
+> to support the ongoing sustainability of the project.
>
-> Since establishing the GraphQL Foundation, we've had an outpouring of support from these companies. This neutral, non-profit home for the GraphQL project has provided a healthy way for users, contributors, and supporters to collaborate and contribute funding in support of our programs and collaborative processes. For example, this support has enabled us to support long-time contributor Ivan Goncharov to focus on crucial development and maintenance of the reference implementation, specification and other community gardening work. It has also allowed us to launch a [free GraphQL edX course](https://edx.org/course/exploring-graphql-a-query-language-for-apis), and has enabled us to take some first steps toward supporting and producing community events.
+> Since establishing the GraphQL Foundation, we've had an outpouring of support
+> from these companies. This neutral, non-profit home for the GraphQL project
+> has provided a healthy way for users, contributors, and supporters to
+> collaborate and contribute funding in support of our programs and
+> collaborative processes. For example, this support has enabled us to support
+> long-time contributor Ivan Goncharov to focus on crucial development and
+> maintenance of the reference implementation, specification and other community
+> gardening work. It has also allowed us to launch a
+> [free GraphQL edX course](https://edx.org/course/exploring-graphql-a-query-language-for-apis),
+> and has enabled us to take some first steps toward supporting and producing
+> community events.
>
-> Development of the GraphQL spec has remained open to all contributors. Over the last year we've brought more rigor and clarity to the development process. I've found it encouraging that contributions have been a healthy mix of aspirational new features and iterative improvements to the stable base. This demonstrates that GraphQL is evolving in meaningful ways to address exciting new use cases while also building confidence and stability around what thousands of companies use in production every day. Both of these are essential for GraphQL's long term success.
+> Development of the GraphQL spec has remained open to all contributors. Over
+> the last year we've brought more rigor and clarity to the development process.
+> I've found it encouraging that contributions have been a healthy mix of
+> aspirational new features and iterative improvements to the stable base. This
+> demonstrates that GraphQL is evolving in meaningful ways to address exciting
+> new use cases while also building confidence and stability around what
+> thousands of companies use in production every day. Both of these are
+> essential for GraphQL's long term success.
>
-> Looking ahead, I have great optimism for GraphQL and see huge opportunities. First, we've been hard at work on the 2020 spec and that release is imminent. Spec development continues to accelerate and exciting advancements and improvements are underway for the 2021 release and beyond. Second, we have been accepted to participate in Google Summer of Code and are looking forward to adding these talented students as project collaborators. Third, the communities around the core GraphQL project are collaborating. For example, GraphiQL and Playground recently announced they will be joining efforts to build better tools for us all.
+> Looking ahead, I have great optimism for GraphQL and see huge opportunities.
+> First, we've been hard at work on the 2020 spec and that release is imminent.
+> Spec development continues to accelerate and exciting advancements and
+> improvements are underway for the 2021 release and beyond. Second, we have
+> been accepted to participate in Google Summer of Code and are looking forward
+> to adding these talented students as project collaborators. Third, the
+> communities around the core GraphQL project are collaborating. For example,
+> GraphiQL and Playground recently announced they will be joining efforts to
+> build better tools for us all.
>
-> Thank you again for your involvement in this project and your support of the GraphQL Foundation. I am pleased with our progress and am looking forward to another productive year.
+> Thank you again for your involvement in this project and your support of the
+> GraphQL Foundation. I am pleased with our progress and am looking forward to
+> another productive year.
>
-> _– **Lee Byron**, Executive Director, GraphQL Foundation, and GraphQL Co-Creator_
+> _– **Lee Byron**, Executive Director, GraphQL Foundation, and GraphQL
+> Co-Creator_
diff --git a/src/pages/blog/2020-04-03-graphiql-graphql-playground.mdx b/src/pages/blog/2020-04-03-graphiql-graphql-playground.mdx
index 1263e334a1..2f3e166c94 100644
--- a/src/pages/blog/2020-04-03-graphiql-graphql-playground.mdx
+++ b/src/pages/blog/2020-04-03-graphiql-graphql-playground.mdx
@@ -1,5 +1,7 @@
---
-title: "Web-based GraphQL IDEs for the win: How & Why Playground & GraphiQL are joining forces"
+title:
+ "Web-based GraphQL IDEs for the win: How & Why Playground & GraphiQL are
+ joining forces"
tags: ["announcements"]
date: 2020-04-03
byline: Rikki Schulte, Jason Kuhrt
@@ -11,36 +13,79 @@ byline: Rikki Schulte, Jason Kuhrt
The initial public commit to GraphiQL was in 2014.
-When [Lee Byron](https://github.com/leebyron), [Hyo Jeong](https://github.com/asiandrummer) and [Angel Gomez](https://github.com/AGS-) first published it, the intention was to create a minimal reference IDE development ecosystem for GraphQL. [Greg Hurrell](https://github.com/wincent) created the streaming `graphql-language-service-parser`, designed to empower the `codemirror-graphql` mode.
-
-The goal was to give people the utility packages they needed to build their own web based or desktop IDE tool, and at its core, a relatively simple tool for folks to start learning and applying the language, and for exploring schemas. At the time, LSP was not yet a commonly accepted standard, and VSCode had yet to become the incredibly popular development tool it is today.
-
-Last year, these original engineers handed over to the graphql foundation three repositories: GraphiQL, `codemirror-graphql` and the `graphql-language-service` packages.
-
-Fast forward to now, and GraphiQL is now used by GraphQL implementations in dozens of languages, as well as hundreds of frameworks and runtimes. It's used for everything from HTTP operations, to querying local schemas, data science tools, and even for data transmission for IOT platforms. You'll find it in the AWS dashboard, GitHub developer tools, and many more places we are honored to see this library used.
+When [Lee Byron](https://github.com/leebyron),
+[Hyo Jeong](https://github.com/asiandrummer) and
+[Angel Gomez](https://github.com/AGS-) first published it, the intention was to
+create a minimal reference IDE development ecosystem for GraphQL.
+[Greg Hurrell](https://github.com/wincent) created the streaming
+`graphql-language-service-parser`, designed to empower the `codemirror-graphql`
+mode.
+
+The goal was to give people the utility packages they needed to build their own
+web based or desktop IDE tool, and at its core, a relatively simple tool for
+folks to start learning and applying the language, and for exploring schemas. At
+the time, LSP was not yet a commonly accepted standard, and VSCode had yet to
+become the incredibly popular development tool it is today.
+
+Last year, these original engineers handed over to the graphql foundation three
+repositories: GraphiQL, `codemirror-graphql` and the `graphql-language-service`
+packages.
+
+Fast forward to now, and GraphiQL is now used by GraphQL implementations in
+dozens of languages, as well as hundreds of frameworks and runtimes. It's used
+for everything from HTTP operations, to querying local schemas, data science
+tools, and even for data transmission for IOT platforms. You'll find it in the
+AWS dashboard, GitHub developer tools, and many more places we are honored to
+see this library used.
## Enter Playground
-Alongside GraphiQL, many of us are familiar with its sibling - the handsome & feature-full [GraphQL Playground](https://github.com/prisma-labs/graphql-playground). Following GraphiQL's lead, it uses our `codemirror-graphql` ([Insomnia](https://insomnia.rest/graphql/), [Altair](https://altair.sirmuel.design/) and many others are also in this club!). This is why there are so many similarities between the direct editing experience of these tools.
+Alongside GraphiQL, many of us are familiar with its sibling - the handsome &
+feature-full
+[GraphQL Playground](https://github.com/prisma-labs/graphql-playground).
+Following GraphiQL's lead, it uses our `codemirror-graphql`
+([Insomnia](https://insomnia.rest/graphql/),
+[Altair](https://altair.sirmuel.design/) and many others are also in this
+club!). This is why there are so many similarities between the direct editing
+experience of these tools.
-Playground is _exactly_ what we wanted to happen. It helped drive the development of our language ecosystem, and gave users an easier option than the more customization-oriented GraphiQL. It provided a ton of excellent features - `graphql-config` support, multiple tabs, i18n, and http server middlewares.
+Playground is _exactly_ what we wanted to happen. It helped drive the
+development of our language ecosystem, and gave users an easier option than the
+more customization-oriented GraphiQL. It provided a ton of excellent features -
+`graphql-config` support, multiple tabs, i18n, and http server middlewares.
## Prisma Donates Playground to GraphQL Foundation
-As many have successfully guessed, **Prisma _is_ donating Playground to the GraphQL Foundation.** Entering 2019 Prisma envisioned an eventual Playground 2.0 but then the advent of a modular GraphiQL 2 project showed an opportunity for great synergy, made all the more natural by Prisma's pivot toward modular database tooling for developers.
-
-Playground 1.x has been a community effort of [dozens of contributors](https://github.com/prisma-labs/graphql-playground/graphs/contributors). Prisma thanks all contributors who helped out along the way. Prisma remains deeply committed to supporting the future of the GraphQL language. For example the [Prisma Labs team](https://github.com/prisma-labs) continues to focus on GraphQL API layer and [recently announced](https://github.com/prisma-labs/nexus/issues/373) the transition of [Nexus](https://nexus.js.org/) from a schema building library into a full [fledged GraphQL API framework](https://www.nexusjs.org).
+As many have successfully guessed, **Prisma _is_ donating Playground to the
+GraphQL Foundation.** Entering 2019 Prisma envisioned an eventual Playground 2.0
+but then the advent of a modular GraphiQL 2 project showed an opportunity for
+great synergy, made all the more natural by Prisma's pivot toward modular
+database tooling for developers.
+
+Playground 1.x has been a community effort of
+[dozens of contributors](https://github.com/prisma-labs/graphql-playground/graphs/contributors).
+Prisma thanks all contributors who helped out along the way. Prisma remains
+deeply committed to supporting the future of the GraphQL language. For example
+the [Prisma Labs team](https://github.com/prisma-labs) continues to focus on
+GraphQL API layer and
+[recently announced](https://github.com/prisma-labs/nexus/issues/373) the
+transition of [Nexus](https://nexus.js.org/) from a schema building library into
+a full [fledged GraphQL API framework](https://www.nexusjs.org).
## The Playground Features you love
-In the interest of parity, we will keep a lot of the same features, whether by introducing them to the core or proving plugins that will ship with the playground preset.
+In the interest of parity, we will keep a lot of the same features, whether by
+introducing them to the core or proving plugins that will ship with the
+playground preset.
- multiple tabs (GraphiQL Core)
- headers tab per operation tab (plugin)
- tracing tab (plugin)
- playground doc explorer (plugin)
- internationalization (GraphiQL Core)
-- `graphql-config` support, with new features thanks to our fantastic colleagues at the [Guild Dev](https://github.com/orgs/the-guild-org/people), who Prisma has entrusted with many other projects.
+- `graphql-config` support, with new features thanks to our fantastic colleagues
+ at the [Guild Dev](https://github.com/orgs/the-guild-org/people), who Prisma
+ has entrusted with many other projects.
- easy to use middlewares
## New Features
@@ -50,24 +95,54 @@ These new features will come with the new `graphql@2.0.0`:
- vscode style command palette (via `monaco-editor`)
- jump to fragment or other type definitions
- generate a collection of operations from your project's source files
-- more customizable network options - default headers per project, as well as headers per-operation
+- more customizable network options - default headers per project, as well as
+ headers per-operation
- helpers for integrating custom authentication flows
-- extensive theme, layout, and component customization abilities (you can start with the playground theme preset and work from there!)
+- extensive theme, layout, and component customization abilities (you can start
+ with the playground theme preset and work from there!)
- custom tabs and panels
-- a first-class `graphiql-explorer` plugin in partnership with the original creators, our colleagues at [OneGraph](https://www.onegraph.com/)
+- a first-class `graphiql-explorer` plugin in partnership with the original
+ creators, our colleagues at [OneGraph](https://www.onegraph.com/)
## How will it be re-implemented?
-Playground 2.0 will be a GraphiQL preset that includes the custom theme as well as the custom playground doc explorer plugin (as an alternative to the new doc explorer proposed by @orta and other users), HTTP headers and tracing tab plugins. You can find more technical detail, ongoing discussion and things to work on the [GraphiQL Plugin API Meta Issue](https://github.com/graphql/graphiql/issues/983) or in [other playground related discussion issues](https://github.com/graphql/graphiql/issues?q=label%3Agraphql-playground-preset) in the GraphiQL monorepo.
-
-While the Playground team's baseline goal will be relative parity with Playground 1.0, the team will be accepting proposals for new features and plugins that build on the existing GraphQL Playground experience. The [Features Roundup](https://github.com/graphql/graphiql/projects/10) project is a great place to see what we have planned already for plugins that Playground's preset can use, or you can also create a proposal if you don't see what you're looking for.
+Playground 2.0 will be a GraphiQL preset that includes the custom theme as well
+as the custom playground doc explorer plugin (as an alternative to the new doc
+explorer proposed by @orta and other users), HTTP headers and tracing tab
+plugins. You can find more technical detail, ongoing discussion and things to
+work on the
+[GraphiQL Plugin API Meta Issue](https://github.com/graphql/graphiql/issues/983)
+or in
+[other playground related discussion issues](https://github.com/graphql/graphiql/issues?q=label%3Agraphql-playground-preset)
+in the GraphiQL monorepo.
+
+While the Playground team's baseline goal will be relative parity with
+Playground 1.0, the team will be accepting proposals for new features and
+plugins that build on the existing GraphQL Playground experience. The
+[Features Roundup](https://github.com/graphql/graphiql/projects/10) project is a
+great place to see what we have planned already for plugins that Playground's
+preset can use, or you can also create a proposal if you don't see what you're
+looking for.
## `graphql-playground` repository next steps
-The existing `graphql-playground` repository will get one or two more maintenance/bugfix releases before it will be archived. You can still fork it of course. You can learn more about this in [the graphql-playground issue](https://github.com/prisma-labs/graphql-playground/issues/1143) we created for this migration.
+The existing `graphql-playground` repository will get one or two more
+maintenance/bugfix releases before it will be archived. You can still fork it of
+course. You can learn more about this in
+[the graphql-playground issue](https://github.com/prisma-labs/graphql-playground/issues/1143)
+we created for this migration.
## Call for Contributors
-We're also looking for contributors to form a team to develop, support and maintain a playground preset. The goal would be for them to help iterate on and stabilize the plugin API effort, as well as work towards the effort of contributing to and maintaining the playground preset and its associated plugins. If you are interested leave comment in the [Call for Contributors Github issue](https://github.com/graphql/graphiql/issues/1443).
-
-You can also follow the [Plugin API Proposal discussion issue](https://github.com/graphql/graphiql/issues/983) for updates, and get involved in our [discord channel](https://discord.gg/EXUYPaY) we've created just for the playground initiative.
+We're also looking for contributors to form a team to develop, support and
+maintain a playground preset. The goal would be for them to help iterate on and
+stabilize the plugin API effort, as well as work towards the effort of
+contributing to and maintaining the playground preset and its associated
+plugins. If you are interested leave comment in the
+[Call for Contributors Github issue](https://github.com/graphql/graphiql/issues/1443).
+
+You can also follow the
+[Plugin API Proposal discussion issue](https://github.com/graphql/graphiql/issues/983)
+for updates, and get involved in our
+[discord channel](https://discord.gg/EXUYPaY) we've created just for the
+playground initiative.
diff --git a/src/pages/blog/2020-06-13-season-of-docs.mdx b/src/pages/blog/2020-06-13-season-of-docs.mdx
index 3b8841ae2c..30a38a3df7 100644
--- a/src/pages/blog/2020-06-13-season-of-docs.mdx
+++ b/src/pages/blog/2020-06-13-season-of-docs.mdx
@@ -5,28 +5,59 @@ date: 2020-06-13
byline: Obinna Ekwuno
---
-Open source communities are one of the best ways to collaborate with a larger scale of developers, it incorporates the best part of learning, mentorship, and collaboration on a large scale.
-**Open-source** software has been proven to create large effective ecosystems of users that improve quality. It has been known for many years that the more a piece of software is used, the quicker bugs **will** be identified. In the **open-source** community when a bug is found, users contribute fixes.
-**GraphQL** is an **open**-**source** data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. **GraphQL** was developed internally by Facebook in 2012 before being publicly released in 2015.
+Open source communities are one of the best ways to collaborate with a larger
+scale of developers, it incorporates the best part of learning, mentorship, and
+collaboration on a large scale. **Open-source** software has been proven to
+create large effective ecosystems of users that improve quality. It has been
+known for many years that the more a piece of software is used, the quicker bugs
+**will** be identified. In the **open-source** community when a bug is found,
+users contribute fixes. **GraphQL** is an **open**-**source** data query and
+manipulation language for APIs, and a runtime for fulfilling queries with
+existing data. **GraphQL** was developed internally by Facebook in 2012 before
+being publicly released in 2015.
## What is Google Season of Docs?
-The Google Season of Docs is the intersection of technical writing, open-source contribution, and mentorship. In this three month program, you will be working closely with maintainers of open source projects to improve on existing documentation and processes to better the community.
+The Google Season of Docs is the intersection of technical writing, open-source
+contribution, and mentorship. In this three month program, you will be working
+closely with maintainers of open source projects to improve on existing
+documentation and processes to better the community.
-For technical writers who are new to open source, the program provides an opportunity to gain experience in contributing to open source projects.
+For technical writers who are new to open source, the program provides an
+opportunity to gain experience in contributing to open source projects.
-For technical writers who're already working in open source, the program provides a potentially new way of working together. Season of Docs also gives open source projects an opportunity to engage more of the technical writing community.
+For technical writers who're already working in open source, the program
+provides a potentially new way of working together. Season of Docs also gives
+open source projects an opportunity to engage more of the technical writing
+community.
## How can I be a part of this?
-Open source organizations apply to be mentor organizations in the Season of Docs which includes a list of documentation project ideas with their applications. Technical writers can look through the list of proposals here are the [project ideas for the GraphQL organization](https://github.com/graphql/foundation/tree/master/mentorship/2020/gsod).
-When you have selected a project you would like to work on, write up a project proposal and submit it to [Season of Docs](https://developers.google.com/season-of-docs). You may continue to refine your proposals until July 9th. If you need clarifications, please contact Ivan Goncharov and Uri Goldshtein by sending a message to mentorship@lists.foundation.graphql.org.
-
-The GraphQL organization will reach out to you after they have evaluated the proposals. The accepted technical writers spend a few months working with mentors from the open-source organizations to complete their projects. At the end of the program, the Google program administrators announce the projects that finished successfully.
-Check out the [official technical writer guide.](https://developers.google.com/season-of-docs/docs/tech-writer-guide)
+Open source organizations apply to be mentor organizations in the Season of Docs
+which includes a list of documentation project ideas with their applications.
+Technical writers can look through the list of proposals here are the
+[project ideas for the GraphQL organization](https://github.com/graphql/foundation/tree/master/mentorship/2020/gsod).
+When you have selected a project you would like to work on, write up a project
+proposal and submit it to
+[Season of Docs](https://developers.google.com/season-of-docs). You may continue
+to refine your proposals until July 9th. If you need clarifications, please
+contact Ivan Goncharov and Uri Goldshtein by sending a message to
+mentorship@lists.foundation.graphql.org.
+
+The GraphQL organization will reach out to you after they have evaluated the
+proposals. The accepted technical writers spend a few months working with
+mentors from the open-source organizations to complete their projects. At the
+end of the program, the Google program administrators announce the projects that
+finished successfully. Check out the
+[official technical writer guide.](https://developers.google.com/season-of-docs/docs/tech-writer-guide)
## How long is this program?
-The technical writing applications started on June 9th, 2020 and will last till July 9th, 2020. The selection process for the proposals submitted to organizations lasts till July 31st, 2020. Then Doc development officially begins September 14th, 2020, and ends December 5th, 2020. For a more detailed timeline check out the [official season of docs timeline](https://developers.google.com/season-of-docs/docs/timeline).
+The technical writing applications started on June 9th, 2020 and will last till
+July 9th, 2020. The selection process for the proposals submitted to
+organizations lasts till July 31st, 2020. Then Doc development officially begins
+September 14th, 2020, and ends December 5th, 2020. For a more detailed timeline
+check out the
+[official season of docs timeline](https://developers.google.com/season-of-docs/docs/timeline).
_– **Obinna Ekwuno**, Software Engineer, DevRel GatsbyJS_
diff --git a/src/pages/blog/2020-06-30-gsoc-2020-naman.mdx b/src/pages/blog/2020-06-30-gsoc-2020-naman.mdx
index 2d29631972..9fd7f8a18c 100644
--- a/src/pages/blog/2020-06-30-gsoc-2020-naman.mdx
+++ b/src/pages/blog/2020-06-30-gsoc-2020-naman.mdx
@@ -7,20 +7,63 @@ byline: Naman Kumar
-> [Naman Kumar](https://naman.sh) is a Computer Science & Engineering student from New Delhi, India and a FullStack Engineer at [ProductHunt](https://producthunt.com). He is selected for Google Summer of Code 2020 - GraphQL Foundation under the mentorship of [Ivan Goncharov](https://github.com/IvanGoncharov). In this post he will share his plans on how he is going to spend his summer contributing to the Graphql Foundation.
+> [Naman Kumar](https://naman.sh) is a Computer Science & Engineering student
+> from New Delhi, India and a FullStack Engineer at
+> [ProductHunt](https://producthunt.com). He is selected for Google Summer of
+> Code 2020 - GraphQL Foundation under the mentorship of
+> [Ivan Goncharov](https://github.com/IvanGoncharov). In this post he will share
+> his plans on how he is going to spend his summer contributing to the Graphql
+> Foundation.
-Hi, GraphQL is a technology I use everyday at my work place and other projects building platforms with 200 to 2 million users. I am surely in love with it, acknowledging how much it improves the development speed and removes the overhead of documentation for starters.
+Hi, GraphQL is a technology I use everyday at my work place and other projects
+building platforms with 200 to 2 million users. I am surely in love with it,
+acknowledging how much it improves the development speed and removes the
+overhead of documentation for starters.
-I have huge respect for Open Source organisations and really inspired by the work the whole graphql community is doing to make lives of developers easier. I have always wanted to participating in GSOC, which I assure you is a dream of every student.
+I have huge respect for Open Source organisations and really inspired by the
+work the whole graphql community is doing to make lives of developers easier. I
+have always wanted to participating in GSOC, which I assure you is a dream of
+every student.
-I got to know about the acceptance of Graphql Foundation under GSOC from Ivan’s [talk](https://www.youtube.com/watch?v=PsXxL1oJLrc&list=PLTRTpHrUcSB9jtvOwnq1yVwZl5k2DdBb2&index=24&t=0s) at GraphQL Asia Submit 2020. I was really excited about having a chance to contribute to the tools which are used not only by me but are powering applications used by billions of people on the planet.
+I got to know about the acceptance of Graphql Foundation under GSOC from Ivan’s
+[talk](https://www.youtube.com/watch?v=PsXxL1oJLrc&list=PLTRTpHrUcSB9jtvOwnq1yVwZl5k2DdBb2&index=24&t=0s)
+at GraphQL Asia Submit 2020. I was really excited about having a chance to
+contribute to the tools which are used not only by me but are powering
+applications used by billions of people on the planet.
-Having a keen interest in compiler design, the project idea of working on the [graphql.js](https://github.com/graphql/graphql-js/) reference parser looked really interesting to me. Fortunately being selected for the program, I am going to spend the summer of 2020 working on Graphql.js reference parser and [GraphiQL parser](https://github.com/graphql/graphiql/tree/main/packages/graphql-language-service-parser), to merge the two together. Graphql.js reference parser do not have streaming support or the best error recovery setup. The goal is to take inspiration from the GraphiQL parser and implement the streaming support in the reference parser so that it can be used by IDEs and other development tools.
+Having a keen interest in compiler design, the project idea of working on the
+[graphql.js](https://github.com/graphql/graphql-js/) reference parser looked
+really interesting to me. Fortunately being selected for the program, I am going
+to spend the summer of 2020 working on Graphql.js reference parser and
+[GraphiQL parser](https://github.com/graphql/graphiql/tree/main/packages/graphql-language-service-parser),
+to merge the two together. Graphql.js reference parser do not have streaming
+support or the best error recovery setup. The goal is to take inspiration from
+the GraphiQL parser and implement the streaming support in the reference parser
+so that it can be used by IDEs and other development tools.
-I spent the community bonding period getting to know both the people in the graphql community and getting myself familiar with the projects. I explored the code base and solved few minor bugs with the help of Ivan. The graphql.js reference parser which is well maintained has a really good code quality and readability which helped me gain it's understanding really quickly, on the other hand the GraphiQL parser with just 1000 lines of pure “old is gold” code base, implemented 3 years ago, looks difficult to grasp at first but with proper understanding is a very simple and cute state machine.
+I spent the community bonding period getting to know both the people in the
+graphql community and getting myself familiar with the projects. I explored the
+code base and solved few minor bugs with the help of Ivan. The graphql.js
+reference parser which is well maintained has a really good code quality and
+readability which helped me gain it's understanding really quickly, on the other
+hand the GraphiQL parser with just 1000 lines of pure “old is gold” code base,
+implemented 3 years ago, looks difficult to grasp at first but with proper
+understanding is a very simple and cute state machine.
-Ivan and I also spent the time ideating about dividing the whole project into 3 milestones and breaking those into smaller goals. As the graphiql parser is not actively maintained and has zero test coverage it was really important to have the parser fully covered before we make any changes. Our goal was to enable the graphql.js parser be able to used by the IDEs and performance is a major factor we need to care about for that. Considering it, we also decided to do benchmarking of the GraphiQL parser. Ergo the first milestones includes reaching 100% test coverage for the GraphiQL parser and thorough benchmarking.
+Ivan and I also spent the time ideating about dividing the whole project into 3
+milestones and breaking those into smaller goals. As the graphiql parser is not
+actively maintained and has zero test coverage it was really important to have
+the parser fully covered before we make any changes. Our goal was to enable the
+graphql.js parser be able to used by the IDEs and performance is a major factor
+we need to care about for that. Considering it, we also decided to do
+benchmarking of the GraphiQL parser. Ergo the first milestones includes reaching
+100% test coverage for the GraphiQL parser and thorough benchmarking.
-The next steps will be to use the graphql.js reference parser’s lexer in the GraphiQL parser and construct a plan to merge the parsers. Once the graphql.js parser reaches the capabilities as that of the GraphiQL parser, we can migrate the GraphiQL IDE to use graphql.js parser. Near to the completion of the first milestone I am really happy with the new thing I have learned under the mentorship of Ivan and really excited to work on the upcoming tasks.
+The next steps will be to use the graphql.js reference parser’s lexer in the
+GraphiQL parser and construct a plan to merge the parsers. Once the graphql.js
+parser reaches the capabilities as that of the GraphiQL parser, we can migrate
+the GraphiQL IDE to use graphql.js parser. Near to the completion of the first
+milestone I am really happy with the new thing I have learned under the
+mentorship of Ivan and really excited to work on the upcoming tasks.
> – **Naman Kumar**, GSOC 2020, GraphQL Foundation
diff --git a/src/pages/blog/2020-09-11-newsletter-august-2020.mdx b/src/pages/blog/2020-09-11-newsletter-august-2020.mdx
index 753735b2b3..3729dff3a8 100644
--- a/src/pages/blog/2020-09-11-newsletter-august-2020.mdx
+++ b/src/pages/blog/2020-09-11-newsletter-august-2020.mdx
@@ -5,53 +5,106 @@ date: 2020-09-11
byline: GraphQL Foundation
---
-[GraphQL](https://graphql.org) has redefined how developers work with APIs and client-server interactions. And as the community works hard to foster the growth and adoption of GraphQL, we are excited to share the work of the community and discussions via a new monthly GraphQL Foundation newsletter.
-
-All work on GraphQL and related projects, both big and small, is important to the growth and maturity of the project, which has already seen adoption from many of the world’s largest internet-scale companies.
-
-Many of these items are just in beginning discussions while some are further along. The goal of this monthly post is to summarize and share what’s top of mind for the community and help others get involved. These are only initial discussion topics. For notes on the full discussion during the monthly WG calls please refer to these [call notes](https://docs.google.com/document/d/1_jvxzCkI6VWo2KEobisoiW1n_irJ4dp0aD8Pq9UXuvw/edit#)
+[GraphQL](https://graphql.org) has redefined how developers work with APIs and
+client-server interactions. And as the community works hard to foster the growth
+and adoption of GraphQL, we are excited to share the work of the community and
+discussions via a new monthly GraphQL Foundation newsletter.
+
+All work on GraphQL and related projects, both big and small, is important to
+the growth and maturity of the project, which has already seen adoption from
+many of the world’s largest internet-scale companies.
+
+Many of these items are just in beginning discussions while some are further
+along. The goal of this monthly post is to summarize and share what’s top of
+mind for the community and help others get involved. These are only initial
+discussion topics. For notes on the full discussion during the monthly WG calls
+please refer to these
+[call notes](https://docs.google.com/document/d/1_jvxzCkI6VWo2KEobisoiW1n_irJ4dp0aD8Pq9UXuvw/edit#)
## Updates
### [GraphQL over WebSocket refresh, existing issues and security implications](https://github.com/enisdenjo/graphql-transport-ws/blob/master/PROTOCOL.md)
-This discussion topic proposes taking on the following two critical items of security and bypassing the onConnect event. And possibly re-writing the WebSocket protocol from scratch with full RFCs
+This discussion topic proposes taking on the following two critical items of
+security and bypassing the onConnect event. And possibly re-writing the
+WebSocket protocol from scratch with full RFCs
### [Tagged Type RFC](https://github.com/graphql/graphql-spec/pull/733)
-This is an RFC for a new "Tagged" type to be added to GraphQL, to help address the input polymorphism feature gap. Originally proposed as the @oneField directive, the Tagged type has evolved into an entire new type in the type system, and is currently the lead proposal from the Input Unions Working Group.
+This is an RFC for a new "Tagged" type to be added to GraphQL, to help address
+the input polymorphism feature gap. Originally proposed as the @oneField
+directive, the Tagged type has evolved into an entire new type in the type
+system, and is currently the lead proposal from the Input Unions Working Group.
-A Tagged type defines a list of named member fields each with an associated type (like the fields in Object and Input Object types); but with the stipulation that exactly one of these fields must be present (no more, no less). Depending on the types of the member fields, a Tagged type could be appropriate for input, output, or both, which is proving to be quite controversial; it's possible that the tagged type might be scoped to input only before release. The Tagged type was most recently introduced to the GraphQL Working Group in August and is undergoing feedback and revision before an expected update with the working group in October or November.
+A Tagged type defines a list of named member fields each with an associated type
+(like the fields in Object and Input Object types); but with the stipulation
+that exactly one of these fields must be present (no more, no less). Depending
+on the types of the member fields, a Tagged type could be appropriate for input,
+output, or both, which is proving to be quite controversial; it's possible that
+the tagged type might be scoped to input only before release. The Tagged type
+was most recently introduced to the GraphQL Working Group in August and is
+undergoing feedback and revision before an expected update with the working
+group in October or November.
-If you have use-cases for input polymorphism, please take a look - feedback is very welcome.
+If you have use-cases for input polymorphism, please take a look - feedback is
+very welcome.
### [Standardize naming for Field coordinates](https://github.com/graphql/graphql-spec/issues/735)
This PR proposes the following 2 RFCs
-1. Formalizing the naming and definition of field coordinates (as discussed in [#735](https://github.com/graphql/graphql-spec/issues/735))
-2. Formalizing the way in which a Field Node (and list thereof) contained within a query document can be serialized as field coordinates
+1. Formalizing the naming and definition of field coordinates (as discussed in
+ [#735](https://github.com/graphql/graphql-spec/issues/735))
+2. Formalizing the way in which a Field Node (and list thereof) contained within
+ a query document can be serialized as field coordinates
### [Adding generics to DocumentNode and Source to allow TypeScript type inference](https://github.com/graphql/graphql-js/issues/2727)
-[@dotansimha](https://github.com/dotansimha) from [The Guild](https://the-guild.dev) had recently implemented an improved version of DocumentNode, called TypedDocumentNode, that allows type generics for result type and variable type and contributed it to graphql-js.
+[@dotansimha](https://github.com/dotansimha) from
+[The Guild](https://the-guild.dev) had recently implemented an improved version
+of DocumentNode, called TypedDocumentNode, that allows type generics for result
+type and variable type and contributed it to graphql-js.
-This improved version allows TypeScript to infer the types automatically when an object that matches the signature is used.
+This improved version allows TypeScript to infer the types automatically when an
+object that matches the signature is used.
-You can learn more by reading about it on his [blog post](https://the-guild.dev/blog/typed-document-node).
+You can learn more by reading about it on his
+[blog post](https://the-guild.dev/blog/typed-document-node).
## In Other News
-- We recently welcomed the newest member of the GraphQL Foundation - [The Guild](https://the-guild.dev). [Here](https://foundation.graphql.org/members/) you can find the list of all current members of the foundation.
-- [@hereisnaman](https://github.com/hereisnaman) successfully finished his Google Summer of Code (GSoC) project and is in the process of merging his[PR](https://github.com/graphql/graphql-js/pull/2770). Learn more about it [here](https://foundation.graphql.org/news/2020/06/30/google-summer-of-code-2020-participant-naman/).
-- GraphQL was accepted to the Google Season of Docs (GSoD) and [@carolstran](https://github.com/carolstran) will be working on the [FAQ section](https://developers.google.com/season-of-docs/docs/participants/project-graphql-carolstran) of graphql.org
-- [GraphQL over HTTP](https://github.com/graphql/graphql-over-http) was moved and is now under GraphQL Foundation
-- [@lilianammmatos](https://github.com/lilianammmatos) and [@robrichard have](https://github.com/robrichard) made big progress on `@deferer & @stream`. Yo can learn more by watching their talk about it at the [GraphQL Summit](https://www.youtube.com/watch?v=icv_Pq06aOY):
-- [@andimarek](https://github.com/andimarek) and [@eapache](https://github.com/eapache) started the [GraphQL Scalars](https://github.com/graphql/graphql-scalars/issues) initiative. You can also learn more by watching their talk about it at the [GraphQL Summit](https://www.youtube.com/watch?v=SRGTaYL3h9c).
-- All WG recordings were published on [YouTube](https://www.youtube.com/channel/UCERcwLeheOXp_u61jEXxHMA).
+- We recently welcomed the newest member of the GraphQL Foundation -
+ [The Guild](https://the-guild.dev).
+ [Here](https://foundation.graphql.org/members/) you can find the list of all
+ current members of the foundation.
+- [@hereisnaman](https://github.com/hereisnaman) successfully finished his
+ Google Summer of Code (GSoC) project and is in the process of merging
+ his[PR](https://github.com/graphql/graphql-js/pull/2770). Learn more about it
+ [here](https://foundation.graphql.org/news/2020/06/30/google-summer-of-code-2020-participant-naman/).
+- GraphQL was accepted to the Google Season of Docs (GSoD) and
+ [@carolstran](https://github.com/carolstran) will be working on the
+ [FAQ section](https://developers.google.com/season-of-docs/docs/participants/project-graphql-carolstran)
+ of graphql.org
+- [GraphQL over HTTP](https://github.com/graphql/graphql-over-http) was moved
+ and is now under GraphQL Foundation
+- [@lilianammmatos](https://github.com/lilianammmatos) and
+ [@robrichard have](https://github.com/robrichard) made big progress on
+ `@deferer & @stream`. Yo can learn more by watching their talk about it at the
+ [GraphQL Summit](https://www.youtube.com/watch?v=icv_Pq06aOY):
+- [@andimarek](https://github.com/andimarek) and
+ [@eapache](https://github.com/eapache) started the
+ [GraphQL Scalars](https://github.com/graphql/graphql-scalars/issues)
+ initiative. You can also learn more by watching their talk about it at the
+ [GraphQL Summit](https://www.youtube.com/watch?v=SRGTaYL3h9c).
+- All WG recordings were published on
+ [YouTube](https://www.youtube.com/channel/UCERcwLeheOXp_u61jEXxHMA).
## Get Involved!
-Developers can get involved in the community and contribute to the project at https://github.com/graphql.
+Developers can get involved in the community and contribute to the project at
+https://github.com/graphql.
-Organizations interested in becoming members of the GraphQL Foundation or the GraphQL Specification can learn more on our [member page](/foundation/join). If you have questions about membership, please send an email to membership@graphql.org.
+Organizations interested in becoming members of the GraphQL Foundation or the
+GraphQL Specification can learn more on our [member page](/foundation/join). If
+you have questions about membership, please send an email to
+membership@graphql.org.
diff --git a/src/pages/blog/2020-09-21-gsod-2020-carolyn.mdx b/src/pages/blog/2020-09-21-gsod-2020-carolyn.mdx
index f518779d5f..6fd2bf0efa 100644
--- a/src/pages/blog/2020-09-21-gsod-2020-carolyn.mdx
+++ b/src/pages/blog/2020-09-21-gsod-2020-carolyn.mdx
@@ -5,29 +5,82 @@ date: 2020-09-21
byline: Carolyn Stransky
---
-> [Carolyn Stransky](https://workwithcarolyn.com) is a frontend developer and journalist based in Berlin, Germany. She is selected for [Google Season of Docs 2020](https://developers.google.com/season-of-docs) - GraphQL Foundation under the mentorship of [Ivan Goncharov](https://github.com/IvanGoncharov). In this post, she will share her plans on how she is going to spend the next couple of months contributing to the GraphQL Foundation.
+> [Carolyn Stransky](https://workwithcarolyn.com) is a frontend developer and
+> journalist based in Berlin, Germany. She is selected for
+> [Google Season of Docs 2020](https://developers.google.com/season-of-docs) -
+> GraphQL Foundation under the mentorship of
+> [Ivan Goncharov](https://github.com/IvanGoncharov). In this post, she will
+> share her plans on how she is going to spend the next couple of months
+> contributing to the GraphQL Foundation.
-When I first heard about GraphQL three years ago, I thought that it was a programming language that constructed charts or plotted points on graphs. After building my first application with GraphQL, I would have categorized it as React-specific tooling, like Redux or React Router. Months later, I was still convinced it was just another Twitter-fueled programming trend.
+When I first heard about GraphQL three years ago, I thought that it was a
+programming language that constructed charts or plotted points on graphs. After
+building my first application with GraphQL, I would have categorized it as
+React-specific tooling, like Redux or React Router. Months later, I was still
+convinced it was just another Twitter-fueled programming trend.
-Looking back now, it’s clear that my initial perceptions of GraphQL were incorrect… but they weren’t uncommon.
+Looking back now, it’s clear that my initial perceptions of GraphQL were
+incorrect… but they weren’t uncommon.
-Learning a new technology comes with a lot of questions - and GraphQL is no exception. There are so many misconceptions about what GraphQL is and how it can be used. And I wasn’t the only GraphQL newbie holding on to those same, inaccurate beliefs.
+Learning a new technology comes with a lot of questions - and GraphQL is no
+exception. There are so many misconceptions about what GraphQL is and how it can
+be used. And I wasn’t the only GraphQL newbie holding on to those same,
+inaccurate beliefs.
-After gaining a solid understanding of what GraphQL _really_ is, I started giving presentations at conferences about how difficult I found the learning process (literally the talk title was [Life is hard and so is learning GraphQL](https://workwithcarolyn.com/speaking/life-is-hard-and-so-is-learning-graphql)). This talk was cathartic, both for me and the audiences I was presenting to. Through my research, I also realized that while [graphql.org](/) thoroughly covers the core concepts, it doesn’t directly address some of the questions you face as a new learner.
+After gaining a solid understanding of what GraphQL _really_ is, I started
+giving presentations at conferences about how difficult I found the learning
+process (literally the talk title was
+[Life is hard and so is learning GraphQL](https://workwithcarolyn.com/speaking/life-is-hard-and-so-is-learning-graphql)).
+This talk was cathartic, both for me and the audiences I was presenting to.
+Through my research, I also realized that while [graphql.org](/) thoroughly
+covers the core concepts, it doesn’t directly address some of the questions you
+face as a new learner.
-Fortunately, GraphQL has evolved enough that the information is out there and available. It’s more a matter of finding it because that information is scattered throughout various resources and programming communities. That’s why I was excited to see a [Frequently Asked Questions](https://github.com/graphql/faq) (FAQ) page as one of the proposed Season of Docs projects. And as someone who has openly critiqued the GraphQL documentation, I wanted to play a part in actively improving them.
+Fortunately, GraphQL has evolved enough that the information is out there and
+available. It’s more a matter of finding it because that information is
+scattered throughout various resources and programming communities. That’s why I
+was excited to see a
+[Frequently Asked Questions](https://github.com/graphql/faq) (FAQ) page as one
+of the proposed Season of Docs projects. And as someone who has openly critiqued
+the GraphQL documentation, I wanted to play a part in actively improving them.
There are two main goals behind this FAQ page:
-1. **Build a centralized resource for everyone**. As of now, much of the GraphQL ecosystem is focused on JavaScript due to the early ties with Relay and React. But GraphQL is for everyone, regardless of programming language, so this resource should be too. To ensure this, the FAQ content will be framework agnostic and vendor-neutral.
-2. **Become a truly community-owned resource**. GraphQL was initially passed down from Facebook, but it’s no longer maintained solely by Facebook. This should be a resource that everyone is welcome to contribute to and the community feels empowered to change and grow. That way, common questions won’t be left unanswered.
+1. **Build a centralized resource for everyone**. As of now, much of the GraphQL
+ ecosystem is focused on JavaScript due to the early ties with Relay and
+ React. But GraphQL is for everyone, regardless of programming language, so
+ this resource should be too. To ensure this, the FAQ content will be
+ framework agnostic and vendor-neutral.
+2. **Become a truly community-owned resource**. GraphQL was initially passed
+ down from Facebook, but it’s no longer maintained solely by Facebook. This
+ should be a resource that everyone is welcome to contribute to and the
+ community feels empowered to change and grow. That way, common questions
+ won’t be left unanswered.
-The plan for exactly how to tackle this page will morph and evolve throughout the next two and a half months. My hope, though, is that keeping these goals in mind will lead to a new resource that will help both newcomers and seasoned GraphQL users thrive.
+The plan for exactly how to tackle this page will morph and evolve throughout
+the next two and a half months. My hope, though, is that keeping these goals in
+mind will lead to a new resource that will help both newcomers and seasoned
+GraphQL users thrive.
-In preparation for the documentation development part of Season of Docs, I became familiar with the repository behind [graphql.org](/) by triaging issues and reviewing open pull requests. I also helped with the [ongoing migration to Gatsby](https://github.com/graphql/graphql.github.io/issues/875) because I’ll be building the new FAQ page in Gatsby (there are still [open issues](https://github.com/graphql/graphql.github.io/pull/913#issuecomment-687325610) if you want to contribute). You can read more details about the community bonding phase [on my blog](https://workwithcarolyn.com/blog/community-bonding-gsod).
+In preparation for the documentation development part of Season of Docs, I
+became familiar with the repository behind [graphql.org](/) by triaging issues
+and reviewing open pull requests. I also helped with the
+[ongoing migration to Gatsby](https://github.com/graphql/graphql.github.io/issues/875)
+because I’ll be building the new FAQ page in Gatsby (there are still
+[open issues](https://github.com/graphql/graphql.github.io/pull/913#issuecomment-687325610)
+if you want to contribute). You can read more details about the community
+bonding phase
+[on my blog](https://workwithcarolyn.com/blog/community-bonding-gsod).
-The next step is to create the inaugural batch of FAQ content. This will be about 10-15 questions sourced from various areas of the Internet and in consultation with prominent GraphQL teachers. Once those are complete with thorough answers and built into the new Gatsby site, I’ll get feedback from the community (that’s you) and continue to iterate on the content, design, layout - everything!
+The next step is to create the inaugural batch of FAQ content. This will be
+about 10-15 questions sourced from various areas of the Internet and in
+consultation with prominent GraphQL teachers. Once those are complete with
+thorough answers and built into the new Gatsby site, I’ll get feedback from the
+community (that’s you) and continue to iterate on the content, design, layout -
+everything!
-If you have opinions or would like to follow the project’s progress, [open an issue](https://github.com/graphql/graphql.github.io/issues/new) or [lurk around the website repository](https://github.com/graphql/graphql.github.io).
+If you have opinions or would like to follow the project’s progress,
+[open an issue](https://github.com/graphql/graphql.github.io/issues/new) or
+[lurk around the website repository](https://github.com/graphql/graphql.github.io).
> – **Carolyn Stransky**, GSoD 2020, GraphQL Foundation
diff --git a/src/pages/blog/2020-10-15-newsletter-september-2020.mdx b/src/pages/blog/2020-10-15-newsletter-september-2020.mdx
index a4d6748a75..8ce7bb4a5e 100644
--- a/src/pages/blog/2020-10-15-newsletter-september-2020.mdx
+++ b/src/pages/blog/2020-10-15-newsletter-september-2020.mdx
@@ -5,28 +5,55 @@ date: 2020-10-15
byline: GraphQL Foundation
---
-[GraphQL](/) has redefined how developers work with APIs and client-server interactions. And as the community works hard to foster the growth and adoption of GraphQL, we are excited to share the work of the community and discussions via a new monthly GraphQL Foundation newsletter.
-
-All work on GraphQL and related projects, both big and small, is important to the growth and maturity of the project, which has already seen adoption from many of the world’s largest internet-scale companies.
-
-Many of these items are just in beginning discussions while some are further along. The goal of this monthly post is to summarize and share what’s top of mind for the community and help others get involved. These are only initial discussion topics. For notes on the full discussion during the monthly WG calls please refer to these [call notes](https://github.com/graphql/graphql-wg/blob/b1bfe0cee461d752146dc77e5c35a5e8d7921272/notes/2020-09-03.md#allowing-deprecation-of-inputs-10m-evan).
+[GraphQL](/) has redefined how developers work with APIs and client-server
+interactions. And as the community works hard to foster the growth and adoption
+of GraphQL, we are excited to share the work of the community and discussions
+via a new monthly GraphQL Foundation newsletter.
+
+All work on GraphQL and related projects, both big and small, is important to
+the growth and maturity of the project, which has already seen adoption from
+many of the world’s largest internet-scale companies.
+
+Many of these items are just in beginning discussions while some are further
+along. The goal of this monthly post is to summarize and share what’s top of
+mind for the community and help others get involved. These are only initial
+discussion topics. For notes on the full discussion during the monthly WG calls
+please refer to these
+[call notes](https://github.com/graphql/graphql-wg/blob/b1bfe0cee461d752146dc77e5c35a5e8d7921272/notes/2020-09-03.md#allowing-deprecation-of-inputs-10m-evan).
## WG Updates
### Allowing deprecation of inputs
-Discussed whether the spec should allow deprecating an input that is required. Two concerns: deprecations are intended to be actionable; introspection does not include deprecated things by default - could break tooling that's no longer receiving deprecated inputs as part of their introspection results.
+Discussed whether the spec should allow deprecating an input that is required.
+Two concerns: deprecations are intended to be actionable; introspection does not
+include deprecated things by default - could break tooling that's no longer
+receiving deprecated inputs as part of their introspection results.
-- Regarding case 1: not much of a blocker; the action from deprecation doesn't need to come from a schema (e.g. it could be switch to a new version/endpoint)
-- Regarding case 2: much more of an issue because we could be breaking clients. My suggestion is to return required arguments even if they're deprecated - introspection should always give you what's necessary even if you say you don't want it.
+- Regarding case 1: not much of a blocker; the action from deprecation doesn't
+ need to come from a schema (e.g. it could be switch to a new version/endpoint)
+- Regarding case 2: much more of an issue because we could be breaking clients.
+ My suggestion is to return required arguments even if they're deprecated -
+ introspection should always give you what's necessary even if you say you
+ don't want it.
### `@defer`/`@stream`
-trying to answer the “why we don’t support Defer on field question”. The reasoning for that is the original Apollo implementation was only on fields. We ran into problems in that it’s difficult to coordinate
+trying to answer the “why we don’t support Defer on field question”. The
+reasoning for that is the original Apollo implementation was only on fields. We
+ran into problems in that it’s difficult to coordinate
### Querying Query query queries: "query" ambiguity
-The issue was first raised around the ambiguity of the term "query" as used in the GraphQL spec and ecosystem back in April. In just this title, we've referred to requesting, the Query type, a query operation, and a nested selection set; but that's just some of the ways we use this term, which can make it really hard for people new to GraphQL to get up to speed. Benjie has analyzed the use of the term, and has proposed a consistent set of terminology to use based on other terms used in the GraphQL spec already, this was discussed at the most recent Working Group. See [Spec PR #777](https://github.com/graphql/graphql-spec/pull/777).
+The issue was first raised around the ambiguity of the term "query" as used in
+the GraphQL spec and ecosystem back in April. In just this title, we've referred
+to requesting, the Query type, a query operation, and a nested selection set;
+but that's just some of the ways we use this term, which can make it really hard
+for people new to GraphQL to get up to speed. Benjie has analyzed the use of the
+term, and has proposed a consistent set of terminology to use based on other
+terms used in the GraphQL spec already, this was discussed at the most recent
+Working Group. See
+[Spec PR #777](https://github.com/graphql/graphql-spec/pull/777).
### Other topics discussed
@@ -37,23 +64,52 @@ The issue was first raised around the ambiguity of the term "query" as used in t
## Ecosystem Updates
-Vscode-graphql, which uses the official GraphQL Language Server, has now become the official reference vscode extension! Like GraphiQL, we will work to ensure all new spec language features are introduced here. After making the announcement we gained 30,000 new users! [This blog post](https://rikki.dev/vscode-graphql-lsp-0-3-0/) will tell you more about all the new features.
+Vscode-graphql, which uses the official GraphQL Language Server, has now become
+the official reference vscode extension! Like GraphiQL, we will work to ensure
+all new spec language features are introduced here. After making the
+announcement we gained 30,000 new users!
+[This blog post](https://rikki.dev/vscode-graphql-lsp-0-3-0/) will tell you more
+about all the new features.
## In Other News...
-- Dgraph Labs launched [Slash GraphQL](https://www.producthunt.com/posts/slash-graphql), a product that can help you get a working GraphQL backend in minutes
-- A new library for the WebSocket Protocol has been created. Read more [here](https://the-guild.dev/blog/graphql-over-websockets).
-- The Guild has created a new [GraphQL-ESLint library](https://github.com/dotansimha/graphql-eslint) for linting your GraphQL schemas and operations with community and custom rules. Read more [here](https://the-guild.dev/blog/introducing-graphql-eslint).
-- GraphQL CLI 4.1 has been released. [Read here](https://the-guild.dev/blog/whats-new-in-graphql-cli-4.1.0) about the new functionality.
-- You can now consume WebHooks as GraphQL Subscriptions thanks to the new version of [GraphQL Mesh](https://github.com/urigo/graphql-mesh). Read more [here](https://the-guild.dev/blog/graphql-mesh-subscriptions).
-- Hasura’s [Enterprise GraphQL Conf](https://hasura.io/enterprisegraphql/) is taking place October 20-22. There is still time to register
-- AWS released a new webinar “[Build Modern Serverless Applications with GraphQL APIs and AWS AppSync](https://pages.awscloud.com/Build-Modern-Serverless-Applications-with-GraphQL-APIs-and-AWS-AppSync_2020_0918-MBL_OD.html?&trk=ep_card-el_a131L0000084iG3QAI&trkCampaign=NA-FY20-AWS-DIGMKT-WEBINAR-SERIES-September_2020_0918-MBL&sc_channel=el&sc_campaign=pac_2018-2019_exlinks_ondemand_OTT_evergreen&sc_outcome=Product_Adoption_Campaigns&sc_geo=NAMER&sc_country=mult)”
-- Catch up on recent talks from the [GraphQL Berlin](https://www.youtube.com/watch?v=4UDsR4z2KIY) Meetup
-- [GraphQL Amsterdam](https://www.meetup.com/Amsterdam-GraphQL-Meetup/events/273901137/), [GraphQL Copenhagen](https://www.meetup.com/Copenhagen-GraphQL-Meetup-Group/events/273901144/), React GraphQL Academy and The Guild are collaborating on an online GraphQL Meetup. Check out the details [here](https://twitter.com/reactgqlacademy/status/1313789927834947585?s=20).
-- Apollo created an [Error Handling Visualizer](https://apollo-visualizer.vercel.app/) tool, which provides an interactive playground to visualize the relationship between nullability and error handling in GraphQL, specifically with Apollo Client.
+- Dgraph Labs launched
+ [Slash GraphQL](https://www.producthunt.com/posts/slash-graphql), a product
+ that can help you get a working GraphQL backend in minutes
+- A new library for the WebSocket Protocol has been created. Read more
+ [here](https://the-guild.dev/blog/graphql-over-websockets).
+- The Guild has created a new
+ [GraphQL-ESLint library](https://github.com/dotansimha/graphql-eslint) for
+ linting your GraphQL schemas and operations with community and custom rules.
+ Read more [here](https://the-guild.dev/blog/introducing-graphql-eslint).
+- GraphQL CLI 4.1 has been released.
+ [Read here](https://the-guild.dev/blog/whats-new-in-graphql-cli-4.1.0) about
+ the new functionality.
+- You can now consume WebHooks as GraphQL Subscriptions thanks to the new
+ version of [GraphQL Mesh](https://github.com/urigo/graphql-mesh). Read more
+ [here](https://the-guild.dev/blog/graphql-mesh-subscriptions).
+- Hasura’s [Enterprise GraphQL Conf](https://hasura.io/enterprisegraphql/) is
+ taking place October 20-22. There is still time to register
+- AWS released a new webinar
+ “[Build Modern Serverless Applications with GraphQL APIs and AWS AppSync](https://pages.awscloud.com/Build-Modern-Serverless-Applications-with-GraphQL-APIs-and-AWS-AppSync_2020_0918-MBL_OD.html?&trk=ep_card-el_a131L0000084iG3QAI&trkCampaign=NA-FY20-AWS-DIGMKT-WEBINAR-SERIES-September_2020_0918-MBL&sc_channel=el&sc_campaign=pac_2018-2019_exlinks_ondemand_OTT_evergreen&sc_outcome=Product_Adoption_Campaigns&sc_geo=NAMER&sc_country=mult)”
+- Catch up on recent talks from the
+ [GraphQL Berlin](https://www.youtube.com/watch?v=4UDsR4z2KIY) Meetup
+- [GraphQL Amsterdam](https://www.meetup.com/Amsterdam-GraphQL-Meetup/events/273901137/),
+ [GraphQL Copenhagen](https://www.meetup.com/Copenhagen-GraphQL-Meetup-Group/events/273901144/),
+ React GraphQL Academy and The Guild are collaborating on an online GraphQL
+ Meetup. Check out the details
+ [here](https://twitter.com/reactgqlacademy/status/1313789927834947585?s=20).
+- Apollo created an
+ [Error Handling Visualizer](https://apollo-visualizer.vercel.app/) tool, which
+ provides an interactive playground to visualize the relationship between
+ nullability and error handling in GraphQL, specifically with Apollo Client.
## Get Involved!
-Developers can get involved in the community and contribute to the project at https://github.com/graphql.
+Developers can get involved in the community and contribute to the project at
+https://github.com/graphql.
-Organizations interested in becoming members of the GraphQL Foundation or the GraphQL Specification can learn more on our [member page](/foundation/join). If you have questions about membership, please send an email to membership@graphql.org.
+Organizations interested in becoming members of the GraphQL Foundation or the
+GraphQL Specification can learn more on our [member page](/foundation/join). If
+you have questions about membership, please send an email to
+membership@graphql.org.
diff --git a/src/pages/blog/2020-11-12-newsletter-october-2020.mdx b/src/pages/blog/2020-11-12-newsletter-october-2020.mdx
index 3569ccc636..5b1503b3e0 100644
--- a/src/pages/blog/2020-11-12-newsletter-october-2020.mdx
+++ b/src/pages/blog/2020-11-12-newsletter-october-2020.mdx
@@ -5,15 +5,27 @@ date: 2020-11-12
byline: GraphQL Foundation
---
-[GraphQL](/) has redefined how developers work with APIs and client-server interactions. And as the community works hard to foster the growth and adoption of GraphQL, we are excited to share the work of the community and discussions via the monthly GraphQL Foundation newsletter.
+[GraphQL](/) has redefined how developers work with APIs and client-server
+interactions. And as the community works hard to foster the growth and adoption
+of GraphQL, we are excited to share the work of the community and discussions
+via the monthly GraphQL Foundation newsletter.
## WG Updates
-The [GraphQL Working Group](https://github.com/graphql/graphql-wg) meets monthly, and records [detailed minutes](https://github.com/graphql/graphql-wg/blob/master/notes/2020-10-01.md). You can also listen to the replays of GraphQL technical meetings on [YouTube](https://youtube.graphql.org).
+The [GraphQL Working Group](https://github.com/graphql/graphql-wg) meets
+monthly, and records
+[detailed minutes](https://github.com/graphql/graphql-wg/blob/master/notes/2020-10-01.md).
+You can also listen to the replays of GraphQL technical meetings on
+[YouTube](https://youtube.graphql.org).
### [Query ambiguity: discussion of replacement terms](https://github.com/graphql/graphql-spec/issues/715)
-In the GraphQL ecosystem the term "query" can seem overloaded and ambiguous - sometimes it refers to the query operation type or a query operation, sometimes it refers to a GraphQL request or a GraphQL document containing operations, sometimes it refers to the contents of selection sets (as in "query reuse"), and sometimes it is used as a verb to refer to the generic act of querying a server for information.
+In the GraphQL ecosystem the term "query" can seem overloaded and ambiguous -
+sometimes it refers to the query operation type or a query operation, sometimes
+it refers to a GraphQL request or a GraphQL document containing operations,
+sometimes it refers to the contents of selection sets (as in "query reuse"), and
+sometimes it is used as a verb to refer to the generic act of querying a server
+for information.
The WG discussed the best way to remove this ambiguity and how to move forward.
@@ -23,30 +35,71 @@ The RFC is filed, and the next action is to turn this into an actual spec edit.
### [Tagged type update](https://github.com/graphql/graphql-spec/pull/733)
-This is an RFC for a new "Tagged type" to be added to GraphQL. It replaces the ["@oneField directive"](https://github.com/graphql/graphql-spec/pull/586) proposal following feedback from the Input Unions Working Group. Please note that "Tagged type" is the working name, and may change if we come up with a better name for it.
+This is an RFC for a new "Tagged type" to be added to GraphQL. It replaces the
+["@oneField directive"](https://github.com/graphql/graphql-spec/pull/586)
+proposal following feedback from the Input Unions Working Group. Please note
+that "Tagged type" is the working name, and may change if we come up with a
+better name for it.
-A Tagged type defines a list of named members each with an associated type (like the fields in Object types and Input Object types), but differs from Object types and Input Object types in that exactly one of those members must be present.
+A Tagged type defines a list of named members each with an associated type (like
+the fields in Object types and Input Object types), but differs from Object
+types and Input Object types in that exactly one of those members must be
+present.
-The aim of the Tagged type is to introduce a form of polymorphism in GraphQL that can be symmetric between input and output. In output, it can generally be used as an alternative to Union (the differences will be outlined below). It goes beyond interfaces and unions in that it allows the same type to be specified more than once, which is particularly useful to represent filters such as this pseudocode `{greaterThan: Int} | {lessThan: Int}`.
+The aim of the Tagged type is to introduce a form of polymorphism in GraphQL
+that can be symmetric between input and output. In output, it can generally be
+used as an alternative to Union (the differences will be outlined below). It
+goes beyond interfaces and unions in that it allows the same type to be
+specified more than once, which is particularly useful to represent filters such
+as this pseudocode `{greaterThan: Int} | {lessThan: Int}`.
## In Other News...
-- [Vox Media evaluates Apollo GraphQL Federation and The Guild Schema Stitching](https://product.voxmedia.com/2020/11/2/21494865/to-federate-or-stitch-a-graphql-gateway-revisited) for the best GraphQL platform to manage “a chorus of applications working together to publish modern media”
-- AWS released a “[Decision Guide to GraphQL Implementation](https://aws.amazon.com/graphql/guide/)”
-- [Netflix discusses](https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2) how it scales its API with [Apollo GraphQL](https://www.apollographql.com/) Federation via its next generation architecture, “Studio Edge”, which uses federation as a critical element.
-- [Building a GraphQL server with GraphQL Helix](https://dev.to/danielrearden/building-a-graphql-server-with-graphql-helix-2k44), a newly released library for building GraphQL APIs. The aim of GraphQL Helix is to allow developers to use new features that are not yet supported in other libraries and to prevent vendor lock-in.
-- [GraphQL Tools v7 was released to deliver the next generation GraphQL API Gateway](https://the-guild.dev/blog/graphql-tools-v7), bringing a new way to federate multiple GraphQL servers, focusing on standard spec compliant GraphQ
-- We’ve already announced that The Guild has recently joined the GraphQL Foundation and now [they wrote a blog post about it](https://the-guild.dev/blog/joining-graphql-foundation). Who will be the next to join?
+- [Vox Media evaluates Apollo GraphQL Federation and The Guild Schema Stitching](https://product.voxmedia.com/2020/11/2/21494865/to-federate-or-stitch-a-graphql-gateway-revisited)
+ for the best GraphQL platform to manage “a chorus of applications working
+ together to publish modern media”
+- AWS released a
+ “[Decision Guide to GraphQL Implementation](https://aws.amazon.com/graphql/guide/)”
+- [Netflix discusses](https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2)
+ how it scales its API with [Apollo GraphQL](https://www.apollographql.com/)
+ Federation via its next generation architecture, “Studio Edge”, which uses
+ federation as a critical element.
+- [Building a GraphQL server with GraphQL Helix](https://dev.to/danielrearden/building-a-graphql-server-with-graphql-helix-2k44),
+ a newly released library for building GraphQL APIs. The aim of GraphQL Helix
+ is to allow developers to use new features that are not yet supported in other
+ libraries and to prevent vendor lock-in.
+- [GraphQL Tools v7 was released to deliver the next generation GraphQL API Gateway](https://the-guild.dev/blog/graphql-tools-v7),
+ bringing a new way to federate multiple GraphQL servers, focusing on standard
+ spec compliant GraphQ
+- We’ve already announced that The Guild has recently joined the GraphQL
+ Foundation and now
+ [they wrote a blog post about it](https://the-guild.dev/blog/joining-graphql-foundation).
+ Who will be the next to join?
## Upcoming Events
-- **Nov 17**: [GraphQL Contributor Days](https://www.graphql-meetup.com/#/graphql-contributor-days-november-2020), in partnership with [Hasura](https://hasura.io/), will give important updates to the community, and provide a forum for anyone using GraphQL to have direct access to core contributors and authors of various libraries and frameworks through live chat and an online broadcast.
-- **Dec 2**: [Relay Meetup](https://relaymeetup.com/) is a global, online meetup on Relay, the GraphQL client. This event will feature a conversation about the @defer and @stream directives and why it should be brought to the official GraphQL specification.
-- **Dec 7-8**: [GraphQL Galaxy Conference](https://graphqlgalaxy.com) is a new remote conference focusing on all things [GraphQL](https://twitter.com/search?q=%23GraphQL&src=hashtag_click).
-- Missed Apollo Day on Nov. 10th? Check out some of the great talks on [Twitch](https://www.twitch.tv/apollographql).
+- **Nov 17**:
+ [GraphQL Contributor Days](https://www.graphql-meetup.com/#/graphql-contributor-days-november-2020),
+ in partnership with [Hasura](https://hasura.io/), will give important updates
+ to the community, and provide a forum for anyone using GraphQL to have direct
+ access to core contributors and authors of various libraries and frameworks
+ through live chat and an online broadcast.
+- **Dec 2**: [Relay Meetup](https://relaymeetup.com/) is a global, online meetup
+ on Relay, the GraphQL client. This event will feature a conversation about the
+ @defer and @stream directives and why it should be brought to the official
+ GraphQL specification.
+- **Dec 7-8**: [GraphQL Galaxy Conference](https://graphqlgalaxy.com) is a new
+ remote conference focusing on all things
+ [GraphQL](https://twitter.com/search?q=%23GraphQL&src=hashtag_click).
+- Missed Apollo Day on Nov. 10th? Check out some of the great talks on
+ [Twitch](https://www.twitch.tv/apollographql).
## Get Involved!
-Developers can get involved in the community and contribute to the project at https://github.com/graphql.
+Developers can get involved in the community and contribute to the project at
+https://github.com/graphql.
-Organizations interested in becoming members of the GraphQL Foundation or the GraphQL Specification can learn more on our [member page](/foundation/join). If you have questions about membership, please send an email to membership@graphql.org.
+Organizations interested in becoming members of the GraphQL Foundation or the
+GraphQL Specification can learn more on our [member page](/foundation/join). If
+you have questions about membership, please send an email to
+membership@graphql.org.
diff --git a/src/pages/blog/2020-12-08-defer-stream.mdx b/src/pages/blog/2020-12-08-defer-stream.mdx
index 94c1967323..2092a05471 100644
--- a/src/pages/blog/2020-12-08-defer-stream.mdx
+++ b/src/pages/blog/2020-12-08-defer-stream.mdx
@@ -5,13 +5,35 @@ date: 2020-12-08
byline: Rob Richard, Liliana Matos
---
-> Rob Richard and Liliana Matos are front-end engineers at [1stDibs.com](https://1stdibs.com). They have been working with the GraphQL Working Group as champions of the `@defer` and `@stream` directives.
-
-The `@defer` and `@stream` directives have been a much anticipated set of features ever since Lee Byron first talked about it at [GraphQL Europe 2016](https://youtu.be/ViXL0YQnioU?t=769). For most of 2020, we have been working with the GraphQL Working Group to standardize this feature. It is now a Stage 2 proposal, but to advance further, we are looking to the GraphQL community to try using these directives and provide feedback. We have released experimental versions of `GraphQL.js` and `express-graphql`. They are published to npm under `graphql@experimental-stream-defer` and `express-graphql@experimental-stream-defer`. We encourage everyone interested in this feature to try out these releases and let us know how it goes in the [issue created for feedback](https://github.com/graphql/graphql-js/issues/2848). Read on to find out more about what this proposal offers.
-
-One of the disadvantages of GraphQL’s request/response model is that the GraphQL response is not returned to clients until the entire request has finished processing. However, not all requested data may be of equal importance, and in some use cases it may be possible for applications to act on a subset of the requested data. An application can speed up its time-to-interactive if the GraphQL server can send the most important data as soon as it’s ready. The new `@defer` and `@stream` directives allow GraphQL servers to do exactly that by returning multiple payloads from a single GraphQL response.
-
-The `@defer` directive can be applied to fragment spreads and inline fragments. It is a declarative way for developers to mark parts of a query as non-essential for immediate return.
+> Rob Richard and Liliana Matos are front-end engineers at
+> [1stDibs.com](https://1stdibs.com). They have been working with the GraphQL
+> Working Group as champions of the `@defer` and `@stream` directives.
+
+The `@defer` and `@stream` directives have been a much anticipated set of
+features ever since Lee Byron first talked about it at
+[GraphQL Europe 2016](https://youtu.be/ViXL0YQnioU?t=769). For most of 2020, we
+have been working with the GraphQL Working Group to standardize this feature. It
+is now a Stage 2 proposal, but to advance further, we are looking to the GraphQL
+community to try using these directives and provide feedback. We have released
+experimental versions of `GraphQL.js` and `express-graphql`. They are published
+to npm under `graphql@experimental-stream-defer` and
+`express-graphql@experimental-stream-defer`. We encourage everyone interested in
+this feature to try out these releases and let us know how it goes in the
+[issue created for feedback](https://github.com/graphql/graphql-js/issues/2848).
+Read on to find out more about what this proposal offers.
+
+One of the disadvantages of GraphQL’s request/response model is that the GraphQL
+response is not returned to clients until the entire request has finished
+processing. However, not all requested data may be of equal importance, and in
+some use cases it may be possible for applications to act on a subset of the
+requested data. An application can speed up its time-to-interactive if the
+GraphQL server can send the most important data as soon as it’s ready. The new
+`@defer` and `@stream` directives allow GraphQL servers to do exactly that by
+returning multiple payloads from a single GraphQL response.
+
+The `@defer` directive can be applied to fragment spreads and inline fragments.
+It is a declarative way for developers to mark parts of a query as non-essential
+for immediate return.
Here’s an example of the `@defer` directive:
@@ -64,9 +86,15 @@ fragment HomeworldFragment on Person {
}
```
-When the GraphQL execution engine encounters the `@defer` directive, it will fork execution and begin to resolve those fields asynchronously. While the deferred payload is still being prepared, the client can receive and act on the initial payload. This is most useful when the deferred data is large, expensive to load, or not on the critical path for interactivity.
+When the GraphQL execution engine encounters the `@defer` directive, it will
+fork execution and begin to resolve those fields asynchronously. While the
+deferred payload is still being prepared, the client can receive and act on the
+initial payload. This is most useful when the deferred data is large, expensive
+to load, or not on the critical path for interactivity.
-Similar to `@defer`, the `@stream` directive also allows the client to receive data before the entire result is ready. `@stream` can be used on list fields. Here’s an example of the `@stream` directive:
+Similar to `@defer`, the `@stream` directive also allows the client to receive
+data before the entire result is ready. `@stream` can be used on list fields.
+Here’s an example of the `@stream` directive:
## `@stream`
@@ -128,9 +156,19 @@ query {
}
```
-When the GraphQL execution engine encounters the `@stream` directive, it will resolve as many list items specified by the `initialCount` argument. The rest will be resolved asynchronously. This is especially useful for an interface where only a few elements can be rendered above the fold. The client can render these elements as soon as possible while the server is still resolving the rest of the data.
-
-While the GraphQL specification doesn’t specify transport protocols, we expect the most common transport for queries with `@defer`/`@stream` to be HTTP with chunked transfer encoding. This allows a GraphQL server to keep a standard HTTP connection open, while streaming each payload to the client as soon as it’s ready. It has low overhead, has been supported by browsers for decades, and can work easily with most infrastructure.
+When the GraphQL execution engine encounters the `@stream` directive, it will
+resolve as many list items specified by the `initialCount` argument. The rest
+will be resolved asynchronously. This is especially useful for an interface
+where only a few elements can be rendered above the fold. The client can render
+these elements as soon as possible while the server is still resolving the rest
+of the data.
+
+While the GraphQL specification doesn’t specify transport protocols, we expect
+the most common transport for queries with `@defer`/`@stream` to be HTTP with
+chunked transfer encoding. This allows a GraphQL server to keep a standard HTTP
+connection open, while streaming each payload to the client as soon as it’s
+ready. It has low overhead, has been supported by browsers for decades, and can
+work easily with most infrastructure.
You can learn more about these directives at:
diff --git a/src/pages/blog/2021-02-15-newsletter-february-2021.mdx b/src/pages/blog/2021-02-15-newsletter-february-2021.mdx
index ef77fdc6ba..8e102d4f37 100644
--- a/src/pages/blog/2021-02-15-newsletter-february-2021.mdx
+++ b/src/pages/blog/2021-02-15-newsletter-february-2021.mdx
@@ -5,35 +5,59 @@ date: 2021-02-15
byline: GraphQL Foundation
---
-[GraphQL](/) has redefined how developers work with APIs and client-server interactions. And as the community works hard to foster the growth and adoption of GraphQL, we are excited to share the work of the community and discussions via the monthly GraphQL Foundation newsletter.
+[GraphQL](/) has redefined how developers work with APIs and client-server
+interactions. And as the community works hard to foster the growth and adoption
+of GraphQL, we are excited to share the work of the community and discussions
+via the monthly GraphQL Foundation newsletter.
-GraphQL reached new heights in 2020 and is only poised to continue its meteoric rise in 2021. Thank you again for your involvement in this project and your support of the GraphQL Foundation. We are excited for another productive year!
+GraphQL reached new heights in 2020 and is only poised to continue its meteoric
+rise in 2021. Thank you again for your involvement in this project and your
+support of the GraphQL Foundation. We are excited for another productive year!
## Working Group Updates
### [Advancing no introspection at root of Subscription operation](https://github.com/graphql/graphql-spec/pull/776)
-The group decided to disallow since it doesn’t work in the reference implementation. During the graphql-js implementation some issues were discovered around fragments that are being fixed. Read more [here](https://github.com/graphql/graphql-spec/pull/776).
+The group decided to disallow since it doesn’t work in the reference
+implementation. During the graphql-js implementation some issues were discovered
+around fragments that are being fixed. Read more
+[here](https://github.com/graphql/graphql-spec/pull/776).
### [Default value coercion update](https://github.com/graphql/graphql-spec/pull/793)
-Currently this is a case where infinite loops can occur. The WG is working to figure out how to avoid this in the spec [here](https://github.com/graphql/graphql-spec/pull/793#issuecomment-738736539).
+Currently this is a case where infinite loops can occur. The WG is working to
+figure out how to avoid this in the spec
+[here](https://github.com/graphql/graphql-spec/pull/793#issuecomment-738736539).
### [Defer/stream updates](https://github.com/graphql/graphql-spec/blob/main/rfcs/DeferStream.md)
-The official experimental branch of graphql-js/express-graphql. The WG is working to update the initialCount, validation rule in GraphQL.js, and the spec.
+The official experimental branch of graphql-js/express-graphql. The WG is
+working to update the initialCount, validation rule in GraphQL.js, and the spec.
### Schema Coordinates Spec
-The RFC and spec edit have been out for a few months with credit due to everyone who has reviewed those. Last time the field arguments were the discussion there were two main contenders: `Query.business(id:)` versus `Query.business.id`. The WG is looking for consensus. The discussion summarized can be found [here](https://github.com/graphql/graphql-spec/pull/746#issuecomment-740914167).
+The RFC and spec edit have been out for a few months with credit due to everyone
+who has reviewed those. Last time the field arguments were the discussion there
+were two main contenders: `Query.business(id:)` versus `Query.business.id`. The
+WG is looking for consensus. The discussion summarized can be found
+[here](https://github.com/graphql/graphql-spec/pull/746#issuecomment-740914167).
### \_Typename is not valid at subscription root
-`__typename` does not return an async iterator and has been deemed not useful at the root of a subscription operation, yet it is allowed by GraphQL validation. This field has caused some confusion in the community, and the WG has proposed explicitly validating it to prevent the field to catch these issues earlier.
+`__typename` does not return an async iterator and has been deemed not useful at
+the root of a subscription operation, yet it is allowed by GraphQL validation.
+This field has caused some confusion in the community, and the WG has proposed
+explicitly validating it to prevent the field to catch these issues earlier.
### Default value coercion
-There's inconsistency in the handling of default values between user-supplied defaults (i.e. variables in operation documents) and schema-supplied defaults (for arguments or input object fields). The WG discussed ways in which a poorly constructed GraphQL schema can break the type safety guarantees of GraphQL and proposed addressing this by making schema defaults operate in a more expected manner. Next steps are to get an implementation finished so that we can advance the spec changes to stage 2.
+There's inconsistency in the handling of default values between user-supplied
+defaults (i.e. variables in operation documents) and schema-supplied defaults
+(for arguments or input object fields). The WG discussed ways in which a poorly
+constructed GraphQL schema can break the type safety guarantees of GraphQL and
+proposed addressing this by making schema defaults operate in a more expected
+manner. Next steps are to get an implementation finished so that we can advance
+the spec changes to stage 2.
## In Other News...
@@ -42,22 +66,40 @@ There's inconsistency in the handling of default values between user-supplied de
- [How Netflix Scales its API with GraphQL Federation (Part 2)](https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-2-bbe71aaec44a)
- [Hasura launched a 3 week series of articles, live-streams, and A.M.As for GraphQL beginners and experts.](https://hasura.io/blog/graphql-january-with-hasura/)
- [Prisma announced Nexus 1.0: A Major Release for Type-Safe, Code-First GraphQL APIs](https://www.prisma.io/blog/announcing-the-release-of-nexus-schema-v1-b5eno5g08d0b)
-- ZDNet: [2021 Technology trend review: Cloud, Kubernetes, and GraphQL](https://zdnet.com/article/2021-technology-trend-review-part-1-blockchain-cloud-open-source/)
-- TechTarget: [Enterprise application trends that will impact 2021: GraphQL vs. REST choice steers microservices development](https://searchapparchitecture.techtarget.com/feature/Enterprise-application-trends-that-will-impact)
+- ZDNet:
+ [2021 Technology trend review: Cloud, Kubernetes, and GraphQL](https://zdnet.com/article/2021-technology-trend-review-part-1-blockchain-cloud-open-source/)
+- TechTarget:
+ [Enterprise application trends that will impact 2021: GraphQL vs. REST choice steers microservices development](https://searchapparchitecture.techtarget.com/feature/Enterprise-application-trends-that-will-impact)
- [Top 20 GraphQL Jobs Postings](https://www.dice.com/jobs/q-GraphQL-jobs)
-- GraphQL Galaxy’s talk uploaded online, [check out the Keynote](https://youtu.be/mfg6ZJ2GGRc)!
-- The [new Schema Stitching Handbook was released](https://the-guild.dev/blog/a-new-year-for-schema-stitching), together with examples and video walkthrough with everything you need to know about Federated/Distributed GraphQL Gateways
-- [The Guild announced GraphQL Modules 1.0](https://the-guild.dev/blog/graphql-modules-v1) as a major rewrite after 3 years of experience. The new version includes better simplicity and performance
-- With [GraphQL Mesh](https://graphql-mesh.com/) you can now wrap any existing API and add reactivity to it - check out [this blog post about how to do it](https://the-guild.dev/blog/add-reactivity-to-an-existing-source)
-- [spotify-graphql is approaching v2.0](https://twitter.com/whereischarly/status/1349467930166239232?s=20) as a complete rewrite, instead of manual code it uses GraphQL Mesh under the hood to generate the API
-- Software Engineering Daily: [Podcast with DGraph’s Manit Jain](https://softwareengineeringdaily.com/2021/01/19/dgraph-native-graphql-database-with-manish-jain/)
+- GraphQL Galaxy’s talk uploaded online,
+ [check out the Keynote](https://youtu.be/mfg6ZJ2GGRc)!
+- The
+ [new Schema Stitching Handbook was released](https://the-guild.dev/blog/a-new-year-for-schema-stitching),
+ together with examples and video walkthrough with everything you need to know
+ about Federated/Distributed GraphQL Gateways
+- [The Guild announced GraphQL Modules 1.0](https://the-guild.dev/blog/graphql-modules-v1)
+ as a major rewrite after 3 years of experience. The new version includes
+ better simplicity and performance
+- With [GraphQL Mesh](https://graphql-mesh.com/) you can now wrap any existing
+ API and add reactivity to it - check out
+ [this blog post about how to do it](https://the-guild.dev/blog/add-reactivity-to-an-existing-source)
+- [spotify-graphql is approaching v2.0](https://twitter.com/whereischarly/status/1349467930166239232?s=20)
+ as a complete rewrite, instead of manual code it uses GraphQL Mesh under the
+ hood to generate the API
+- Software Engineering Daily:
+ [Podcast with DGraph’s Manit Jain](https://softwareengineeringdaily.com/2021/01/19/dgraph-native-graphql-database-with-manish-jain/)
## Upcoming Events
-- Asia’s largest [GraphQL conference](https://graphql.asia/) is back! February 24th & 25th
+- Asia’s largest [GraphQL conference](https://graphql.asia/) is back! February
+ 24th & 25th
## Get Involved!
-Developers can get involved in the community and contribute to the project at https://github.com/graphql.
+Developers can get involved in the community and contribute to the project at
+https://github.com/graphql.
-Organizations interested in becoming members of the GraphQL Foundation or the GraphQL Specification can learn more on our [member page](/foundation/join). If you have questions about membership, please send an email to membership@graphql.org.
+Organizations interested in becoming members of the GraphQL Foundation or the
+GraphQL Specification can learn more on our [member page](/foundation/join). If
+you have questions about membership, please send an email to
+membership@graphql.org.
diff --git a/src/pages/blog/2021-03-31-newsletter-march-2021.mdx b/src/pages/blog/2021-03-31-newsletter-march-2021.mdx
index ed6afe6749..213a64358e 100644
--- a/src/pages/blog/2021-03-31-newsletter-march-2021.mdx
+++ b/src/pages/blog/2021-03-31-newsletter-march-2021.mdx
@@ -5,42 +5,73 @@ date: 2021-03-31
byline: GraphQL Foundation
---
-[GraphQL](/) has redefined how developers work with APIs and client-server interactions. And as the community works hard to foster the growth and adoption of GraphQL, we are excited to share the work of the community and discussions via the monthly GraphQL Foundation newsletter.
+[GraphQL](/) has redefined how developers work with APIs and client-server
+interactions. And as the community works hard to foster the growth and adoption
+of GraphQL, we are excited to share the work of the community and discussions
+via the monthly GraphQL Foundation newsletter.
-GraphQL reached new heights in 2020 and is only poised to continue its meteoric rise in 2021. Thank you again for your involvement in this project and your support of the GraphQL Foundation. We are excited for another productive year!
+GraphQL reached new heights in 2020 and is only poised to continue its meteoric
+rise in 2021. Thank you again for your involvement in this project and your
+support of the GraphQL Foundation. We are excited for another productive year!
## Working Group Updates
**GraphQL Foundation marketing committee**
-The newly created GraphQL Foundation marketing committee is responsible for coordinating marketing activities in support of the [Foundation](https://foundation.graphql.org/) and the [projects](https://github.com/graphql). They meet regularly, and welcome participation from Foundation and community members.
+The newly created GraphQL Foundation marketing committee is responsible for
+coordinating marketing activities in support of the
+[Foundation](https://foundation.graphql.org/) and the
+[projects](https://github.com/graphql). They meet regularly, and welcome
+participation from Foundation and community members.
-The meeting agendas and minutes are open and available in [meetings/](https://github.com/graphql/marketing/blob/main/meetings). We generally meet on the fourth Thursday of the month at 9am PT. To be added to the recurring invite, please contact operations@graphql.org.
+The meeting agendas and minutes are open and available in
+[meetings/](https://github.com/graphql/marketing/blob/main/meetings). We
+generally meet on the fourth Thursday of the month at 9am PT. To be added to the
+recurring invite, please contact operations@graphql.org.
**Allowing fields to diverge more**
-This is one of the most complicated validation rules, which is about overlapping fields and not forcing to ensure every field is unique in a query, especially if you compose queries. They have to be merged together and ensure the field is only executed once. There's a rule to ensure this merging can be done.
+This is one of the most complicated validation rules, which is about overlapping
+fields and not forcing to ensure every field is unique in a query, especially if
+you compose queries. They have to be merged together and ensure the field is
+only executed once. There's a rule to ensure this merging can be done.
-The working group has agreed to add prose or a non-normative note to this validation rule to explain this.
+The working group has agreed to add prose or a non-normative note to this
+validation rule to explain this.
**Operation Expressions**
-Operation expressions is an extension to the Schema Coordinates syntax that allows for a host of new use cases. Outlined [here](https://github.com/graphql/graphql-spec/pull/823) are some of the use cases that have been discussed so far, and have iterated on the syntax, but everything in this is very much in flux.
+Operation expressions is an extension to the Schema Coordinates syntax that
+allows for a host of new use cases. Outlined
+[here](https://github.com/graphql/graphql-spec/pull/823) are some of the use
+cases that have been discussed so far, and have iterated on the syntax, but
+everything in this is very much in flux.
**Directions via introspection report**
-Custom directives are not currently introspectable. This has been a big discussion over the years. Recently, graphql-java has implemented (almost merged) the ability to query directive by introspection.
+Custom directives are not currently introspectable. This has been a big
+discussion over the years. Recently, graphql-java has implemented (almost
+merged) the ability to query directive by introspection.
**Oneof Input Objects and Oneof Fields**
-Oneof Input Objects are a special variant of Input Objects where the type system asserts that exactly one of the fields must be set and non-null, all others being omitted. This is represented in introspection with the `__Type.oneField: Boolean` field, and in SDL via the `@oneOf` directive on the input object. The working group has agreed to Contribute syntax thoughts and on the RFC itself, and write an implementation in GraphQL.js
+Oneof Input Objects are a special variant of Input Objects where the type system
+asserts that exactly one of the fields must be set and non-null, all others
+being omitted. This is represented in introspection with the
+`__Type.oneField: Boolean` field, and in SDL via the `@oneOf` directive on the
+input object. The working group has agreed to Contribute syntax thoughts and on
+the RFC itself, and write an implementation in GraphQL.js
## In Other News...
-- ZDNet: [Databases, graphs, and GraphQL: The past, present, and future](https://www.zdnet.com/article/databases-graphs-and-graphql-past-present-and-future/)
-- ZDNet: [Hasura connects GraphQL to the REST of the world](https://www.zdnet.com/article/hasura-connects-graphql-to-the-rest-of-the-world/)
-- ADT Mag: [Netflix Open Sources GraphQL for Spring Boot](https://adtmag.com/articles/2021/02/17/netflix-open-sources-graphql-for-spring-boot.aspx)
-- ProgrammableWeb: [Facebook Adds Relay Hooks for Improved GraphQL Data Fetching](https://www.programmableweb.com/news/facebook-adds-relay-hooks-improved-graphql-data-fetching/brief/2021/03/11)
+- ZDNet:
+ [Databases, graphs, and GraphQL: The past, present, and future](https://www.zdnet.com/article/databases-graphs-and-graphql-past-present-and-future/)
+- ZDNet:
+ [Hasura connects GraphQL to the REST of the world](https://www.zdnet.com/article/hasura-connects-graphql-to-the-rest-of-the-world/)
+- ADT Mag:
+ [Netflix Open Sources GraphQL for Spring Boot](https://adtmag.com/articles/2021/02/17/netflix-open-sources-graphql-for-spring-boot.aspx)
+- ProgrammableWeb:
+ [Facebook Adds Relay Hooks for Improved GraphQL Data Fetching](https://www.programmableweb.com/news/facebook-adds-relay-hooks-improved-graphql-data-fetching/brief/2021/03/11)
- [Dgraph Labs Launches Slash GraphQL, Industry’s First GraphQL-Native Database Backend-As-A-Service](https://www.globenewswire.com/news-release/2020/09/10/2091563/0/en/Dgraph-Labs-Launches-Slash-GraphQL-Industry-s-First-GraphQL-Native-Database-Backend-As-A-Service.html)
- [How Square accelerates product development with Apollo GraphQL](https://www.apollographql.com/blog/how-square-accelerates-product-development-with-apollo-graphql/)
- [Netflix: Beyond REST Rapid Development with GraphQL Microservices](https://netflixtechblog.com/beyond-rest-1b76f7c20ef6)
@@ -48,10 +79,15 @@ Oneof Input Objects are a special variant of Input Objects where the type system
## Upcoming Events
-- The GraphQL community will come together once again for [GraphQL Summit](https://summit.graphql.com) April 7th & 8th
+- The GraphQL community will come together once again for
+ [GraphQL Summit](https://summit.graphql.com) April 7th & 8th
## Get Involved!
-Developers can get involved in the community and contribute to the project at https://github.com/graphql.
+Developers can get involved in the community and contribute to the project at
+https://github.com/graphql.
-Organizations interested in becoming members of the GraphQL Foundation or the GraphQL Specification can learn more on our [member page](https://foundation.graphql.org/join). If you have questions about membership, please send an email to membership@graphql.org.
+Organizations interested in becoming members of the GraphQL Foundation or the
+GraphQL Specification can learn more on our
+[member page](https://foundation.graphql.org/join). If you have questions about
+membership, please send an email to membership@graphql.org.
diff --git a/src/pages/blog/2021-04-30-newsletter-april-2021.mdx b/src/pages/blog/2021-04-30-newsletter-april-2021.mdx
index fac5182005..2063873b0d 100644
--- a/src/pages/blog/2021-04-30-newsletter-april-2021.mdx
+++ b/src/pages/blog/2021-04-30-newsletter-april-2021.mdx
@@ -5,51 +5,90 @@ date: 2021-04-30
byline: GraphQL Foundation
---
-[GraphQL](/) has redefined how developers work with APIs and client-server interactions. And as the community works hard to foster the growth and adoption of GraphQL, we are excited to share the work of the community and discussions via the monthly GraphQL Foundation newsletter.
+[GraphQL](/) has redefined how developers work with APIs and client-server
+interactions. And as the community works hard to foster the growth and adoption
+of GraphQL, we are excited to share the work of the community and discussions
+via the monthly GraphQL Foundation newsletter.
-GraphQL reached new heights in 2020 and is only poised to continue its meteoric rise in 2021. Thank you again for your involvement in this project and your support of the GraphQL Foundation. We are excited for another productive year!
+GraphQL reached new heights in 2020 and is only poised to continue its meteoric
+rise in 2021. Thank you again for your involvement in this project and your
+support of the GraphQL Foundation. We are excited for another productive year!
## Working Group Updates
### GraphQL Foundation marketing committee
-The newly created GraphQL Foundation marketing committee is responsible for coordinating marketing activities in support of the [Foundation](https://foundation.graphql.org/) and the [projects](https://github.com/graphql). They meet regularly, and welcome participation from Foundation and community members.
+The newly created GraphQL Foundation marketing committee is responsible for
+coordinating marketing activities in support of the
+[Foundation](https://foundation.graphql.org/) and the
+[projects](https://github.com/graphql). They meet regularly, and welcome
+participation from Foundation and community members.
-The meeting agendas and minutes are open and available in [meetings/](https://github.com/graphql/marketing/blob/main/meetings). We generally meet on the fourth Thursday of the month at 9am PT. To be added to the recurring invite, please contact [operations@graphql.org](mailto:operations@graphql.org).
+The meeting agendas and minutes are open and available in
+[meetings/](https://github.com/graphql/marketing/blob/main/meetings). We
+generally meet on the fourth Thursday of the month at 9am PT. To be added to the
+recurring invite, please contact
+[operations@graphql.org](mailto:operations@graphql.org).
### Spec cut
-There are few more final phase proposals still waiting on review, as well as updating the version of the legal text). The next step will include having the TSC take a formal vote to cut the draft.
+There are few more final phase proposals still waiting on review, as well as
+updating the version of the legal text). The next step will include having the
+TSC take a formal vote to cut the draft.
### TypeScript migration for GraphQL.js
-Representing almost 6 million downloads per week. TypeScript is in need of additional clean up, including GraphQLList and GraphQLNonNull. The WG decided to drop Flow types, and have a PR for converting to TypeScript. The plan is to incorporate the fixes into the main release, which is very close to being done. Once finished, it will be added to release 16.0.0-alpha.1. Once that is complete it will merge the PR and convert to TypeScript.
+Representing almost 6 million downloads per week. TypeScript is in need of
+additional clean up, including GraphQLList and GraphQLNonNull. The WG decided to
+drop Flow types, and have a PR for converting to TypeScript. The plan is to
+incorporate the fixes into the main release, which is very close to being done.
+Once finished, it will be added to release 16.0.0-alpha.1. Once that is complete
+it will merge the PR and convert to TypeScript.
### Adding descriptions to queries and fragments
-The purpose of this discussion is to add necessary comments for various business use cases. As of now we have to parse SDL data and it's problematic when people add other comments. The WG is working on the best way to solve this issue.
+The purpose of this discussion is to add necessary comments for various business
+use cases. As of now we have to parse SDL data and it's problematic when people
+add other comments. The WG is working on the best way to solve this issue.
### Schema introspection extensions
-First implemented by GraphQL Java,then some issues were found and it was discovered there was some additional work to be done before turning it into an RFC. The Working Group is planning to address these issues shortly.
+First implemented by GraphQL Java,then some issues were found and it was
+discovered there was some additional work to be done before turning it into an
+RFC. The Working Group is planning to address these issues shortly.
## In Other News...
- [Dgraph announces v21.03 - Resilient Rocket Release](https://dgraph.io/blog/post/v2103-release/)
-- Read: [GraphQL API Security best practices with AWS AppSync and Amplify](https://github.com/danilop/graphql-api-security-with-aws-appsync-and-amplify)
-- AWS AppSync is a fully managed service which allows developers to deploy and interact with serverless scalable GraphQL backends on AWS.
+- Read:
+ [GraphQL API Security best practices with AWS AppSync and Amplify](https://github.com/danilop/graphql-api-security-with-aws-appsync-and-amplify)
+- AWS AppSync is a fully managed service which allows developers to deploy and
+ interact with serverless scalable GraphQL backends on AWS.
- [Neo4j announces GraphQL Library Beta Release](https://medium.com/neo4j/announcing-the-neo4j-graphql-library-beta-99ae8541bbe7)
-- TechTarget: [Dgraph GraphQL database users detail graph use cases](https://searchdatamanagement.techtarget.com/news/252499595/Dgraph-GraphQL-database-users-detail-graph-use-cases)
-- Devops.com: [Apollo GraphQL Makes Federated Server More Accessible](https://devops.com/apollo-graphql-makes-federated-server-more-accessible/)
-- The New Stack: [Why Shopify Favors GraphQL over REST for Its APIs](https://thenewstack.io/why-shopify-favors-graphql-over-rest-for-its-apis/)
-- Code Story: [E17: Matt Debergalis, Apollo GraphQL](https://codestory.co/podcast/e17-matt-debergalis-apollo-graphql/)
+- TechTarget:
+ [Dgraph GraphQL database users detail graph use cases](https://searchdatamanagement.techtarget.com/news/252499595/Dgraph-GraphQL-database-users-detail-graph-use-cases)
+- Devops.com:
+ [Apollo GraphQL Makes Federated Server More Accessible](https://devops.com/apollo-graphql-makes-federated-server-more-accessible/)
+- The New Stack:
+ [Why Shopify Favors GraphQL over REST for Its APIs](https://thenewstack.io/why-shopify-favors-graphql-over-rest-for-its-apis/)
+- Code Story:
+ [E17: Matt Debergalis, Apollo GraphQL](https://codestory.co/podcast/e17-matt-debergalis-apollo-graphql/)
## Upcoming Events
-- [Hasura Con '21: The Big Hasura User Conference](https://hasura.io/events/hasura-con-2021/) The 2021 installment of Hasura Con will take place on June 23rd and 24th. The event brings together users from all over the world to celebrate all things Hasura and will feature top-notch speakers and workshops. Sign up today to attend Hasura Con '21 or submit a talk proposal to share your knowledge at the event.
+- [Hasura Con '21: The Big Hasura User Conference](https://hasura.io/events/hasura-con-2021/)
+ The 2021 installment of Hasura Con will take place on June 23rd and 24th. The
+ event brings together users from all over the world to celebrate all things
+ Hasura and will feature top-notch speakers and workshops. Sign up today to
+ attend Hasura Con '21 or submit a talk proposal to share your knowledge at the
+ event.
## Get Involved!
-Developers can get involved in the community and contribute to the project at https://github.com/graphql.
+Developers can get involved in the community and contribute to the project at
+https://github.com/graphql.
-Organizations interested in becoming members of the GraphQL Foundation or the GraphQL Specification can learn more on our [member page](https://foundation.graphql.org/join). If you have questions about membership, please send an email to membership@graphql.org.
+Organizations interested in becoming members of the GraphQL Foundation or the
+GraphQL Specification can learn more on our
+[member page](https://foundation.graphql.org/join). If you have questions about
+membership, please send an email to membership@graphql.org.
diff --git a/src/pages/blog/2021-06-30-newsletter-june-2021.mdx b/src/pages/blog/2021-06-30-newsletter-june-2021.mdx
index ffc23c75bb..c4bda76d00 100644
--- a/src/pages/blog/2021-06-30-newsletter-june-2021.mdx
+++ b/src/pages/blog/2021-06-30-newsletter-june-2021.mdx
@@ -5,63 +5,107 @@ date: 2021-06-30
byline: GraphQL Foundation
---
-[GraphQL](/) has redefined how developers work with APIs and client-server interactions. And as the community works hard to foster the growth and adoption of GraphQL, we are excited to share the work of the community and discussions via the monthly GraphQL Foundation newsletter.
+[GraphQL](/) has redefined how developers work with APIs and client-server
+interactions. And as the community works hard to foster the growth and adoption
+of GraphQL, we are excited to share the work of the community and discussions
+via the monthly GraphQL Foundation newsletter.
-GraphQL reached new heights in 2020 and is only poised to continue its meteoric rise in 2021. Thank you again for your involvement in this project and your support of the GraphQL Foundation. We are excited for another productive year!
+GraphQL reached new heights in 2020 and is only poised to continue its meteoric
+rise in 2021. Thank you again for your involvement in this project and your
+support of the GraphQL Foundation. We are excited for another productive year!
## Working Group Updates
### GraphQL Foundation marketing committee
-The newly created GraphQL Foundation marketing committee is responsible for coordinating marketing activities in support of the [Foundation](https://foundation.graphql.org/) and the [projects](https://github.com/graphql). They meet regularly, and welcome participation from Foundation and community members.
+The newly created GraphQL Foundation marketing committee is responsible for
+coordinating marketing activities in support of the
+[Foundation](https://foundation.graphql.org/) and the
+[projects](https://github.com/graphql). They meet regularly, and welcome
+participation from Foundation and community members.
-The meeting agendas and minutes are open and available in [meetings/](https://github.com/graphql/marketing/blob/main/meetings). We generally meet on the fourth Thursday of the month at 9am PT. To be added to the recurring invite, please contact [operations@graphql.org](mailto:operations@graphql.org).
+The meeting agendas and minutes are open and available in
+[meetings/](https://github.com/graphql/marketing/blob/main/meetings). We
+generally meet on the fourth Thursday of the month at 9am PT. To be added to the
+recurring invite, please contact
+[operations@graphql.org](mailto:operations@graphql.org).
### [Release plan for next version of GraphQL specification](https://github.com/graphql/graphql-spec/milestone/2)
-The next release is in the final stages of review and is anticipated to be released soon. Details on the release are TBD.
+The next release is in the final stages of review and is anticipated to be
+released soon. Details on the release are TBD.
## Schema Coordinates update
-The WG is evaluating how to use Schema Coordinates (e.g. what can we improve by using schema coordinates, and is Looking for support in advancing from Draft to Accepted.
+The WG is evaluating how to use Schema Coordinates (e.g. what can we improve by
+using schema coordinates, and is Looking for support in advancing from Draft to
+Accepted.
## Full unicode support
-The WG is looking for support in advancing this iteration from Proposal to Draft. Most notably full unicode is already supported today, albeit without having explicit tests for it.
+The WG is looking for support in advancing this iteration from Proposal to
+Draft. Most notably full unicode is already supported today, albeit without
+having explicit tests for it.
-The only new code that is added is the verification of the surrogate pairs. The current implementation allows for invalid surrogate pairs.
+The only new code that is added is the verification of the surrogate pairs. The
+current implementation allows for invalid surrogate pairs.
### Fragment Arguments RFC
-For the past 5+ years, Relay has had the [@arguments directive](https://relay.dev/docs/api-reference/graphql-and-directives/#arguments), which is not spec compliant. In some sense, Relay is a _dual GraphQL client_: there's Relay syntax which is used to resolve data available locally on the client, and then that syntax compiles down into a spec compliant syntax to resolve data from an external source (aka a "server"), which hydrates a graph of "local" data the relay-specific resolvers operate over.
+For the past 5+ years, Relay has had the
+[@arguments directive](https://relay.dev/docs/api-reference/graphql-and-directives/#arguments),
+which is not spec compliant. In some sense, Relay is a _dual GraphQL client_:
+there's Relay syntax which is used to resolve data available locally on the
+client, and then that syntax compiles down into a spec compliant syntax to
+resolve data from an external source (aka a "server"), which hydrates a graph of
+"local" data the relay-specific resolvers operate over.
-This means Relay can get away with having user-written fragments that are freed from operation-defined knowledge: Relay's fragments can be provided with variable values that were never defined at the operation level, to use when resolving arguments.
+This means Relay can get away with having user-written fragments that are freed
+from operation-defined knowledge: Relay's fragments can be provided with
+variable values that were never defined at the operation level, to use when
+resolving arguments.
## Roundtable discussion on `@defer`/`@stream`
-Read the lengthy and informative conversation [here](https://github.com/graphql/graphql-wg/blob/main/notes/2021-06-03.md), or watch on YouTube [here](https://www.youtube.com/watch?v=d4HhIo82Whg&list=PLP1igyLx8foH30_sDnEZnxV_8pYW3SDtb&index=1).
+Read the lengthy and informative conversation
+[here](https://github.com/graphql/graphql-wg/blob/main/notes/2021-06-03.md), or
+watch on YouTube
+[here](https://www.youtube.com/watch?v=d4HhIo82Whg&list=PLP1igyLx8foH30_sDnEZnxV_8pYW3SDtb&index=1).
### graphql-js update on the Typescript migration
-The working group will be converting as much of graphql-js to TypeScript as possible, which will probably need some breaking changes due to default values and other changes. One of the aims is to also be readable so they might release these breaking changes along with the TypeScript migration.
+The working group will be converting as much of graphql-js to TypeScript as
+possible, which will probably need some breaking changes due to default values
+and other changes. One of the aims is to also be readable so they might release
+these breaking changes along with the TypeScript migration.
### Default Value Coercion RFC
-The WG has spent several weeks working to integrate the default value changes into GraphQL Ruby, which has resulted in several architectural discussions and some bug reports.
+The WG has spent several weeks working to integrate the default value changes
+into GraphQL Ruby, which has resulted in several architectural discussions and
+some bug reports.
### Glossary RFC
-The purpose of this RFC is to add clarity and precision, especially after the many meanings of a query. The WG is working to define the terms first, then will revisit extracting it into an appendix.
+The purpose of this RFC is to add clarity and precision, especially after the
+many meanings of a query. The WG is working to define the terms first, then will
+revisit extracting it into an appendix.
### Query Level Nullability RFC
-Used by many including Yelp and Netflix, the proposal is to allow queries that can include a non-null designator (!) to indicate that a field should be treated non-nullable and if it returns null it should escalate following the standard GraphQL error bubbling.
+Used by many including Yelp and Netflix, the proposal is to allow queries that
+can include a non-null designator (!) to indicate that a field should be treated
+non-nullable and if it returns null it should escalate following the standard
+GraphQL error bubbling.
## In Other News...
-- Database, Trends & Applications: [Hasura Adds the Ability to Access Existing Data and Move it with GraphQL API](https://www.dbta.com/Editorial/News-Flashes/Hasura-Adds-the-Ability-to-Access-Existing-Data-and-Move-it-with-GraphQL-API-147680.aspx)
-- InfoQ: [Rebuilding Twitter's Public API](https://www.infoq.com/presentations/twitter-public-api/)
-- ZDNet: [MuleSoft adds DataGraph to Anypoint Platform to streamline API requests](https://www.zdnet.com/article/mulesoft-adds-datagraph-to-anypoint-platform-streamlining-api-requests/)
+- Database, Trends & Applications:
+ [Hasura Adds the Ability to Access Existing Data and Move it with GraphQL API](https://www.dbta.com/Editorial/News-Flashes/Hasura-Adds-the-Ability-to-Access-Existing-Data-and-Move-it-with-GraphQL-API-147680.aspx)
+- InfoQ:
+ [Rebuilding Twitter's Public API](https://www.infoq.com/presentations/twitter-public-api/)
+- ZDNet:
+ [MuleSoft adds DataGraph to Anypoint Platform to streamline API requests](https://www.zdnet.com/article/mulesoft-adds-datagraph-to-anypoint-platform-streamlining-api-requests/)
## Upcoming Events
@@ -69,6 +113,10 @@ Used by many including Yelp and Netflix, the proposal is to allow queries that c
## Get Involved!
-Developers can get involved in the community and contribute to the project at https://github.com/graphql.
+Developers can get involved in the community and contribute to the project at
+https://github.com/graphql.
-Organizations interested in becoming members of the GraphQL Foundation or the GraphQL Specification can learn more on our [member page](https://graphql.org/foundation/join). If you have questions about membership, please send an email to membership@graphql.org.
+Organizations interested in becoming members of the GraphQL Foundation or the
+GraphQL Specification can learn more on our
+[member page](https://graphql.org/foundation/join). If you have questions about
+membership, please send an email to membership@graphql.org.
diff --git a/src/pages/blog/2022-11-07-graphql-http.mdx b/src/pages/blog/2022-11-07-graphql-http.mdx
index eed5d39dc0..395a0facca 100644
--- a/src/pages/blog/2022-11-07-graphql-http.mdx
+++ b/src/pages/blog/2022-11-07-graphql-http.mdx
@@ -7,7 +7,8 @@ byline: GraphQL Foundation
GraphQL is most commonly served over HTTP. However, despite GraphQL being well
specified, this HTTP transport is not. To correct for this, the GraphQL working
-group has been working on the [GraphQL over HTTP](https://graphql.github.io/graphql-over-http/draft/)
+group has been working on the
+[GraphQL over HTTP](https://graphql.github.io/graphql-over-http/draft/)
specification.
Alongside a specification, we prefer a true implementation to have as a
@@ -15,23 +16,26 @@ reference. This ensures the ideas we specify can be implemented well, and that
as edge-cases arise in software we can ensure their solutions are reflected in
the specification as well.
-For GraphQL over HTTP, this has nominally been [express-graphql](https://github.com/graphql/express-graphql).
-This package makes it easy to create a GraphQL serving endpoint from an express
-server. However, as the Node community has grown over the years, alternatives to
-express have emerged and there is no longer one framework to align to. Also, as
-our maintenance bandwidth has focused on other projects, express-graphql has
-fallen behind.
+For GraphQL over HTTP, this has nominally been
+[express-graphql](https://github.com/graphql/express-graphql). This package
+makes it easy to create a GraphQL serving endpoint from an express server.
+However, as the Node community has grown over the years, alternatives to express
+have emerged and there is no longer one framework to align to. Also, as our
+maintenance bandwidth has focused on other projects, express-graphql has fallen
+behind.
-Luckily, thanks to the focused efforts of [Denis Badurina](https://github.com/enisdenjo),
-we have an alternative in [graphql-http](https://github.com/graphql/graphql-http).
-Denis has been part of the committee working on the GraphQL over HTTP
-specification, and sought to build a dependency-free compliant GraphQL server
-that works with most all existing Node.js and Deno HTTP frameworks.
+Luckily, thanks to the focused efforts of
+[Denis Badurina](https://github.com/enisdenjo), we have an alternative in
+[graphql-http](https://github.com/graphql/graphql-http). Denis has been part of
+the committee working on the GraphQL over HTTP specification, and sought to
+build a dependency-free compliant GraphQL server that works with most all
+existing Node.js and Deno HTTP frameworks.
-The decision was made to adopt the [graphql-http](https://github.com/graphql/graphql-http)
-project into the GraphQL Foundation (with Denis continuing as the lead
-maintainer), as well as to make it the official reference implementation of
-GraphQL over HTTP.
+The decision was made to adopt the
+[graphql-http](https://github.com/graphql/graphql-http) project into the GraphQL
+Foundation (with Denis continuing as the lead maintainer), as well as to make it
+the official reference implementation of GraphQL over HTTP.
-We will be deprecating [express-graphql](https://github.com/graphql/express-graphql)
-as part of this change, and recommending those using it migrate to graphql-http.
+We will be deprecating
+[express-graphql](https://github.com/graphql/express-graphql) as part of this
+change, and recommending those using it migrate to graphql-http.
diff --git a/src/pages/blog/2023-01-14-graphql-scalars.mdx b/src/pages/blog/2023-01-14-graphql-scalars.mdx
index 52fb5e404c..494cdc9d54 100644
--- a/src/pages/blog/2023-01-14-graphql-scalars.mdx
+++ b/src/pages/blog/2023-01-14-graphql-scalars.mdx
@@ -5,11 +5,21 @@ date: 2023-01-14
byline: Andreas Marek, Donna Zhou
---
-We are very happy to announce the official home for contributed GraphQL [custom scalar](https://spec.graphql.org/draft/#sec-Scalars.Custom-Scalars) specifications at [scalars.graphql.org](https://scalars.graphql.org/).
+We are very happy to announce the official home for contributed GraphQL
+[custom scalar](https://spec.graphql.org/draft/#sec-Scalars.Custom-Scalars)
+specifications at [scalars.graphql.org](https://scalars.graphql.org/).
-You are welcome to contribute custom scalar specifications (abbreviated as "specs"). Once your spec is merged in, it will be hosted at `scalars.graphql.org/<GitHub-username>/<specification-name>`. See how to contribute on the [contribution guide](https://scalars.graphql.org/readme-contribution-guide).
+You are welcome to contribute custom scalar specifications (abbreviated as
+"specs"). Once your spec is merged in, it will be hosted at
+`scalars.graphql.org/<GitHub-username>/<specification-name>`. See how to
+contribute on the
+[contribution guide](https://scalars.graphql.org/readme-contribution-guide).
-Our first contributed spec is for [DateTime](https://scalars.graphql.org/andimarek/date-time). You can point users to the spec's URL with the built-in `@specifiedBy` [directive](https://spec.graphql.org/draft/#sec--specifiedBy) in your GraphQL schema.
+Our first contributed spec is for
+[DateTime](https://scalars.graphql.org/andimarek/date-time). You can point users
+to the spec's URL with the built-in `@specifiedBy`
+[directive](https://spec.graphql.org/draft/#sec--specifiedBy) in your GraphQL
+schema.
```graphql
scalar DateTime
@@ -18,20 +28,38 @@ scalar DateTime
## Elevating the GraphQL type system with custom scalars
-Custom scalars have been part of the GraphQL spec since day one. They have the unique ability to extend the GraphQL type system with custom types. While custom scalars are powerful, they were more like a black box for the consumers of the API.
+Custom scalars have been part of the GraphQL spec since day one. They have the
+unique ability to extend the GraphQL type system with custom types. While custom
+scalars are powerful, they were more like a black box for the consumers of the
+API.
-Originally, it was very hard for consumers to understand custom scalars as a GraphQL schema did not provide any information apart from its name. For example, it was difficult to understand the exact format of a `DateTime` custom scalar. It was also difficult to know whether the `DateTime` custom scalar in API A was exactly the same as the `DateTime` in API B.
+Originally, it was very hard for consumers to understand custom scalars as a
+GraphQL schema did not provide any information apart from its name. For example,
+it was difficult to understand the exact format of a `DateTime` custom scalar.
+It was also difficult to know whether the `DateTime` custom scalar in API A was
+exactly the same as the `DateTime` in API B.
-We added the built-in `@specifiedBy` directive some time ago, which assigns a URL for the spec of a custom scalar. This provides a standard way to document custom scalars. The `@specifiedBy` directive is also introspectable.
+We added the built-in `@specifiedBy` directive some time ago, which assigns a
+URL for the spec of a custom scalar. This provides a standard way to document
+custom scalars. The `@specifiedBy` directive is also introspectable.
-However, we have since learned that this was not enough. The burden of writing a custom scalar specs and hosting them was left for each API itself to solve.
+However, we have since learned that this was not enough. The burden of writing a
+custom scalar specs and hosting them was left for each API itself to solve.
-With the custom scalar spec project, we provide templates for writing custom scalar specs and also host the specs at a GraphQL Foundation owned domain [scalars.graphql.org](https://scalars.graphql.org/). This greatly reduces the effort to clearly document and share your custom scalar specs.
+With the custom scalar spec project, we provide templates for writing custom
+scalar specs and also host the specs at a GraphQL Foundation owned domain
+[scalars.graphql.org](https://scalars.graphql.org/). This greatly reduces the
+effort to clearly document and share your custom scalar specs.
-Our hope is that this enables an ecosystem of clearly documented custom scalars and eliminates the need to reinvent popular ones again and again. Ultimately, a popular enough custom scalar will be practically indistinguishable from the built-in ones and elevate the GraphQL type system.
+Our hope is that this enables an ecosystem of clearly documented custom scalars
+and eliminates the need to reinvent popular ones again and again. Ultimately, a
+popular enough custom scalar will be practically indistinguishable from the
+built-in ones and elevate the GraphQL type system.
## Get involved!
-See how to contribute a custom scalar spec on the [contribution guide](https://scalars.graphql.org/readme-contribution-guide).
+See how to contribute a custom scalar spec on the
+[contribution guide](https://scalars.graphql.org/readme-contribution-guide).
-If you have any comments or questions, please open an issue on the [graphql-scalars GitHub repository](https://github.com/graphql/graphql-scalars).
+If you have any comments or questions, please open an issue on the
+[graphql-scalars GitHub repository](https://github.com/graphql/graphql-scalars).
diff --git a/src/pages/blog/2023-02-03-community-gardening.mdx b/src/pages/blog/2023-02-03-community-gardening.mdx
index ed4667b951..e4d1e7aa9b 100644
--- a/src/pages/blog/2023-02-03-community-gardening.mdx
+++ b/src/pages/blog/2023-02-03-community-gardening.mdx
@@ -5,34 +5,32 @@ date: 2023-02-03
byline: Benjie Gillam
---
-> The GraphQL Foundation offers [Community
-> Grants](https://graphql.org/foundation/community-grant/) to help incentivize
-> key technical and community initiatives. As part of the grant, applicants
-> commit to write a blog post report describing their work and its impact on
-> the GraphQL community. The following report was written by successful grant
-> applicant [Benjie Gillam](https://github.com/sponsors/benjie) in August 2022,
-> detailing the community gardening he performed during May, June and July of
-> that year.
+> The GraphQL Foundation offers
+> [Community Grants](https://graphql.org/foundation/community-grant/) to help
+> incentivize key technical and community initiatives. As part of the grant,
+> applicants commit to write a blog post report describing their work and its
+> impact on the GraphQL community. The following report was written by
+> successful grant applicant [Benjie Gillam](https://github.com/sponsors/benjie)
+> in August 2022, detailing the community gardening he performed during May,
+> June and July of that year.
## Backstory
In 2019 I started turning up to GraphQL Working Group meetings regularly and
-helping take [the
-notes](https://github.com/graphql/graphql-wg/tree/main/notes). Back then we had
-a system for filing and reviewing action items, but very few people used it, so
-items would easily get lost. Further, the notes and videos would be uploaded in
-batches every few months, which prevented attendees referring to them in the
-interim.
+helping take [the notes](https://github.com/graphql/graphql-wg/tree/main/notes).
+Back then we had a system for filing and reviewing action items, but very few
+people used it, so items would easily get lost. Further, the notes and videos
+would be uploaded in batches every few months, which prevented attendees
+referring to them in the interim.
Over the next couple years I set about trying to improve these processes. I
-started by filing the [action
-items](https://github.com/graphql/graphql-wg/issues?q=is%3Aissue+sort%3Aupdated-desc+label%3A%22Action+item+%3Aclapper%3A%22)
-myself. After a while, I started categorizing them into [GitHub
-projects](https://github.com/graphql/graphql-wg/projects?type=classic&query=is%3Aopen+sort%3Aupdated-desc),
+started by filing the
+[action items](https://github.com/graphql/graphql-wg/issues?q=is%3Aissue+sort%3Aupdated-desc+label%3A%22Action+item+%3Aclapper%3A%22)
+myself. After a while, I started categorizing them into
+[GitHub projects](https://github.com/graphql/graphql-wg/projects?type=classic&query=is%3Aopen+sort%3Aupdated-desc),
one for each meeting, which made keeping track of them (particularly the old
ones) much easier and helped us to see progress. Later I introduced a new
-["ready for review"
-label](https://github.com/graphql/graphql-wg/issues?q=is%3Aissue+sort%3Aupdated-desc+label%3A%22Ready+for+review+%F0%9F%99%8C%22+)
+["ready for review" label](https://github.com/graphql/graphql-wg/issues?q=is%3Aissue+sort%3Aupdated-desc+label%3A%22Ready+for+review+%F0%9F%99%8C%22+)
that enabled us to quickly focus on the action items that needed discussion
rather than trying to go over every item (or skip the lot entirely) each
meeting. These processes were very much appreciated by the working group, but
@@ -43,95 +41,90 @@ diminished.
## Funding approved
-In May 2022, the GraphQL Foundation kindly approved my application for a [GraphQL
-Community Grant](https://graphql.org/foundation/community-grant/) to enable me
-to dedicate more time to these tasks. I'm a community-funded open source
-developer, so I rely on [sponsorship](https://github.com/sponsors/benjie) to
-fund my open source endeavors - both on my own open source projects ([the
-Graphile suite](https://github.com/graphile)) and also my contributions to the
-[GraphQL](https://github.com/graphql/graphql-spec/graphs/contributors)
+In May 2022, the GraphQL Foundation kindly approved my application for a
+[GraphQL Community Grant](https://graphql.org/foundation/community-grant/) to
+enable me to dedicate more time to these tasks. I'm a community-funded open
+source developer, so I rely on [sponsorship](https://github.com/sponsors/benjie)
+to fund my open source endeavors - both on my own open source projects
+([the Graphile suite](https://github.com/graphile)) and also my contributions to
+the [GraphQL](https://github.com/graphql/graphql-spec/graphs/contributors)
[Working](https://github.com/graphql/graphql-wg/graphs/contributors)
[Groups](https://github.com/graphql/graphql-over-http/graphs/contributors).
-Since being approved for the grant, I've been better able to execute the role
-of community gardener; let me tell you about some of the ways in which the
+Since being approved for the grant, I've been better able to execute the role of
+community gardener; let me tell you about some of the ways in which the
Foundation's grant has enabled me to better support you, the GraphQL community!
The [main GraphQL working group](https://github.com/graphql/graphql-wg) meets
-each month; and it is recorded on Zoom and made available via [the Foundation's
-YouTube
-channel](https://www.youtube.com/channel/UCERcwLeheOXp_u61jEXxHMA/playlists).
+each month; and it is recorded on Zoom and made available via
+[the Foundation's YouTube channel](https://www.youtube.com/channel/UCERcwLeheOXp_u61jEXxHMA/playlists).
Soon after each meeting I've been uploading the videos not just for the main
-meeting but also for the various other subcommittees ([GraphiQL
-WG](https://github.com/graphql/graphiql/tree/main/working-group), [GraphQL.js
-WG](https://github.com/graphql/graphql-js-wg), [GraphQL-over-HTTP
-WG](https://github.com/graphql/graphql-over-http/tree/main/working-group),
-Metadata WG, [Composite Schemas
-WG](https://github.com/graphql/composite-schemas-wg)) that may have met during
-the previous month. Whilst uploading the video of the main meeting, I file its
-notes and the action items, while also categorizing them making sure they're
-assigned to the relevant person. Recently, I've also started adding timestamped
-links to the YouTube video for each action item, so we can hear the original
-instructions rather than just the paraphrased summaries from the notes - I
-think this makes them even more useful!
+meeting but also for the various other subcommittees
+([GraphiQL WG](https://github.com/graphql/graphiql/tree/main/working-group),
+[GraphQL.js WG](https://github.com/graphql/graphql-js-wg),
+[GraphQL-over-HTTP WG](https://github.com/graphql/graphql-over-http/tree/main/working-group),
+Metadata WG,
+[Composite Schemas WG](https://github.com/graphql/composite-schemas-wg)) that
+may have met during the previous month. Whilst uploading the video of the main
+meeting, I file its notes and the action items, while also categorizing them
+making sure they're assigned to the relevant person. Recently, I've also started
+adding timestamped links to the YouTube video for each action item, so we can
+hear the original instructions rather than just the paraphrased summaries from
+the notes - I think this makes them even more useful!
## Empowering other contributors
As part of my aim to document our processes and streamline things, I've created
-[a template repository](https://github.com/graphql/wg-template) that can be
-used whenever a new GraphQL subcommittee is created. This enables all
-subcommittees to adopt the GraphQL meeting practices with minimal effort from
-the committee chair - just [a small list of
-edits](https://github.com/graphql/wg-template#working-group-template) that take
-about 5 minutes when setting up the repository and of course the regular
-scheduling.
+[a template repository](https://github.com/graphql/wg-template) that can be used
+whenever a new GraphQL subcommittee is created. This enables all subcommittees
+to adopt the GraphQL meeting practices with minimal effort from the committee
+chair - just
+[a small list of edits](https://github.com/graphql/wg-template#working-group-template)
+that take about 5 minutes when setting up the repository and of course the
+regular scheduling.
I've also been working with the Linux Foundation to get subcommittee meetings
-scheduled onto [the GraphQL
-calendar](https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com),
+scheduled onto
+[the GraphQL calendar](https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com),
and to expand [EasyCLA](https://docs.linuxfoundation.org/v2/easycla) to the new
-repositories to ensure that everyone contributing has signed the [GraphQL
-Membership
-Agreement](https://github.com/graphql/graphql-wg/tree/main/membership). This
-should make releasing future versions of the spec and any subcommittee
+repositories to ensure that everyone contributing has signed the
+[GraphQL Membership Agreement](https://github.com/graphql/graphql-wg/tree/main/membership).
+This should make releasing future versions of the spec and any subcommittee
deliverables much easier since the intellectual property paperwork is in place
from the start.
Thanks to the new funding I've also been able to be more active on GitHub
-issues, PRs, discussions and in [the GraphQL Discord
-server](https://discord.graphql.org/), enabling me to offer assistance to
-people interested in contributing, and to help moderate these environments.
-This includes [explaining how to become a
-champion](https://github.com/graphql/graphql-spec/issues/174#issuecomment-1129621529),
+issues, PRs, discussions and in
+[the GraphQL Discord server](https://discord.graphql.org/), enabling me to offer
+assistance to people interested in contributing, and to help moderate these
+environments. This includes
+[explaining how to become a champion](https://github.com/graphql/graphql-spec/issues/174#issuecomment-1129621529),
performing timely moderation actions when the Discord server suffers from spam,
and giving guidance on how to improve PRs.
## Extra-curricular activities
-Whilst not technically under the umbrella of the grant, having the time spent
-on the above tasks funded by the GraphQL Grant has freed me up to dedicate more
-time to other key issues in GraphQL - for example I [recently revived the
-GraphQL-over-HTTP
-project](https://github.com/graphql/graphql-over-http/pull/175) and we're well
-on the way towards v1 of that specification. I've also helped kick-start [the
-GraphQL Composite Schemas working
-group](https://github.com/graphql/composite-schemas-wg) for the community to
-collaborate on shared solutions to common problems felt across all the
-different ways of building a GraphQL schema by combining other GraphQL schemas
-together. I've also finally been able [to follow through on my intent to push
-the "GraphQL Metadata" topic
-forward](https://github.com/graphql/graphql-spec/issues/300#issuecomment-1119676731)
-including researching, digesting, and [sharing my analysis of the existing
-solutions and their problems at the GraphQL
-Conference](https://youtu.be/c1oa7p73rTw), and [suggesting a solution of my
-own](https://github.com/graphql/graphql-wg/blob/main/rfcs/AnnotationStructs.md).
-Another thing that this reduced pressure on my time has enabled is the [new
-SpecNews podcast](https://specnewspod.com/) in which my co-host Jem and I
+Whilst not technically under the umbrella of the grant, having the time spent on
+the above tasks funded by the GraphQL Grant has freed me up to dedicate more
+time to other key issues in GraphQL - for example I
+[recently revived the GraphQL-over-HTTP project](https://github.com/graphql/graphql-over-http/pull/175)
+and we're well on the way towards v1 of that specification. I've also helped
+kick-start
+[the GraphQL Composite Schemas working group](https://github.com/graphql/composite-schemas-wg)
+for the community to collaborate on shared solutions to common problems felt
+across all the different ways of building a GraphQL schema by combining other
+GraphQL schemas together. I've also finally been able
+[to follow through on my intent to push the "GraphQL Metadata" topic forward](https://github.com/graphql/graphql-spec/issues/300#issuecomment-1119676731)
+including researching, digesting, and
+[sharing my analysis of the existing solutions and their problems at the GraphQL Conference](https://youtu.be/c1oa7p73rTw),
+and
+[suggesting a solution of my own](https://github.com/graphql/graphql-wg/blob/main/rfcs/AnnotationStructs.md).
+Another thing that this reduced pressure on my time has enabled is the
+[new SpecNews podcast](https://specnewspod.com/) in which my co-host Jem and I
summarize the latest GraphQL Specification Working Group session in just 5-10
minutes.
## Get involved!
If you're interested in contributing to GraphQL and need help getting started,
-feel free to reach out to me, @benjie, on
-[Discord](https://discord.graphql.org) or via a GitHub issue or PR, and I'll do
-my best to help!
+feel free to reach out to me, @benjie, on [Discord](https://discord.graphql.org)
+or via a GitHub issue or PR, and I'll do my best to help!
diff --git a/src/pages/blog/2023-06-20-the-guild-qna-recap.mdx b/src/pages/blog/2023-06-20-the-guild-qna-recap.mdx
index f4a923f24e..b329b1ad49 100644
--- a/src/pages/blog/2023-06-20-the-guild-qna-recap.mdx
+++ b/src/pages/blog/2023-06-20-the-guild-qna-recap.mdx
@@ -5,40 +5,111 @@ date: 2023-06-20
byline: Jory Burson
---
-In the fast-paced world of software development, staying updated with the latest technologies and best practices is crucial. GraphQL, a query language for APIs, has gained immense popularity for its flexibility and efficiency in fetching data. To delve deeper into the realm of GraphQL and its impact, a recent Q&A session with members of [The Guild](https://the-guild.dev/), an organization of open source contributors, provided valuable insights and recommendations. Let's explore the highlights of this session and gain a better understanding of the power of GraphQL.
+In the fast-paced world of software development, staying updated with the latest
+technologies and best practices is crucial. GraphQL, a query language for APIs,
+has gained immense popularity for its flexibility and efficiency in fetching
+data. To delve deeper into the realm of GraphQL and its impact, a recent Q&A
+session with members of [The Guild](https://the-guild.dev/), an organization of
+open source contributors, provided valuable insights and recommendations. Let's
+explore the highlights of this session and gain a better understanding of the
+power of GraphQL.
## Philosophies and structure for open source organizations
-During the Q&A session, The Guild members emphasized that their organization was created for the main purpose of long term open source maintenance. This decision led the organization to structure the group's work in a different way, such as having all of their projects under individual contributors names and not under the Guild’s [GitHub org](https://github.com/the-guild-org/), like [Yoga](https://github.com/dotansimha/graphql-yoga), [Mesh](https://github.com/Urigo/graphql-mesh) and [others](https://the-guild.dev/#platform).
-
-They also focused on hiring people who were already community contributors before joining The Guild, in order to ensure that they support existing open source contributors and reduce bias in the selection process (by focusing on the individual's work, rather than their location or identity). That led into a diverse team from all across the globe, and they have written more about that model [in their about page](https://the-guild.dev/about-us).
-
-During the Q&A, The Guild emphasized their support for local Meetup groups and their history of helping to start new ones. This commitment to community involvement reflects their dedication to fostering knowledge sharing and collaboration, which is essential for sustainable open source projects.
+During the Q&A session, The Guild members emphasized that their organization was
+created for the main purpose of long term open source maintenance. This decision
+led the organization to structure the group's work in a different way, such as
+having all of their projects under individual contributors names and not under
+the Guild’s [GitHub org](https://github.com/the-guild-org/), like
+[Yoga](https://github.com/dotansimha/graphql-yoga),
+[Mesh](https://github.com/Urigo/graphql-mesh) and
+[others](https://the-guild.dev/#platform).
+
+They also focused on hiring people who were already community contributors
+before joining The Guild, in order to ensure that they support existing open
+source contributors and reduce bias in the selection process (by focusing on the
+individual's work, rather than their location or identity). That led into a
+diverse team from all across the globe, and they have written more about that
+model [in their about page](https://the-guild.dev/about-us).
+
+During the Q&A, The Guild emphasized their support for local Meetup groups and
+their history of helping to start new ones. This commitment to community
+involvement reflects their dedication to fostering knowledge sharing and
+collaboration, which is essential for sustainable open source projects.
## Authorization and Shielding with Envelop
-The Guild team recommended using [Envelop](https://the-guild.dev/blog/introducing-envelop), a plugin system that manipulates the execution flow, for [authorization and shielding in GraphQL APIs](https://the-guild.dev/blog/graphql-authentication-with-envelop-and-auth0). This approach provides a powerful alternative to directly wrapping resolvers, ensuring robust security measures are in place. By leveraging Envelop, developers can enhance the authorization control in their GraphQL APIs.
+The Guild team recommended using
+[Envelop](https://the-guild.dev/blog/introducing-envelop), a plugin system that
+manipulates the execution flow, for
+[authorization and shielding in GraphQL APIs](https://the-guild.dev/blog/graphql-authentication-with-envelop-and-auth0).
+This approach provides a powerful alternative to directly wrapping resolvers,
+ensuring robust security measures are in place. By leveraging Envelop,
+developers can enhance the authorization control in their GraphQL APIs.
## Granular Authorization Control with Postgres' Row-Level Security
-In addition to Envelop, the discussion highlighted the use of Postgres' Row-Level Security as a means of achieving more granular authorization control. This feature allows developers to define security policies at the database level, ensuring that only authorized users can access specific rows of data. By incorporating Postgres' Row-Level Security, developers can further fortify their GraphQL APIs against unauthorized access.
+In addition to Envelop, the discussion highlighted the use of Postgres'
+Row-Level Security as a means of achieving more granular authorization control.
+This feature allows developers to define security policies at the database
+level, ensuring that only authorized users can access specific rows of data. By
+incorporating Postgres' Row-Level Security, developers can further fortify their
+GraphQL APIs against unauthorized access.
## The Advantages of "Non-Spec" GraphQL and Envelop/Yoga plugins
-The discussion also touched upon the benefits of using "non-spec" GraphQL features. With Envelop, you can safely use [advanced GraphQL features](https://the-guild.dev/graphql/envelop/v3/guides/using-graphql-features-from-the-future) before they are included in the official spec, which releases less frequently.
+The discussion also touched upon the benefits of using "non-spec" GraphQL
+features. With Envelop, you can safely use
+[advanced GraphQL features](https://the-guild.dev/graphql/envelop/v3/guides/using-graphql-features-from-the-future)
+before they are included in the official spec, which releases less frequently.
-These tools offer additional functionalities and optimizations, enabling developers to maximize the potential of GraphQL in their projects. The Guild team emphasized the value of exploring these options to enhance performance and streamline development processes while also giving valuable feedback from real production usage to the [GraphQL Working Group](https://graphql.org/community/developers/#the-graphql-working-group) about these features.
+These tools offer additional functionalities and optimizations, enabling
+developers to maximize the potential of GraphQL in their projects. The Guild
+team emphasized the value of exploring these options to enhance performance and
+streamline development processes while also giving valuable feedback from real
+production usage to the
+[GraphQL Working Group](https://graphql.org/community/developers/#the-graphql-working-group)
+about these features.
## Caching GraphQL Operations
-Participants in the session raised intriguing points about caching GraphQL operations. The Guild team acknowledged the potential advantages of adding caching to GraphQL requests, optimizing response times and reducing unnecessary network traffic. The point was raised that one can achieve more granular caching with GraphQL than with REST, and a primary reason people think caching is harder in GraphQL is the lack of knowledge about tools like [Stellate](https://stellate.co) and [Yoga’s response caching support](https://the-guild.dev/graphql/yoga-server/docs/features/response-caching).
+Participants in the session raised intriguing points about caching GraphQL
+operations. The Guild team acknowledged the potential advantages of adding
+caching to GraphQL requests, optimizing response times and reducing unnecessary
+network traffic. The point was raised that one can achieve more granular caching
+with GraphQL than with REST, and a primary reason people think caching is harder
+in GraphQL is the lack of knowledge about tools like
+[Stellate](https://stellate.co) and
+[Yoga’s response caching support](https://the-guild.dev/graphql/yoga-server/docs/features/response-caching).
## GraphQL Workflows at scale
-In discussing larger-scale usage of GraphQL, The Guild participants referenced some of their work helping large teams manage GraphQL APIs using workflows and tools using tools such as [GraphQL Hive](https://the-guild.dev/graphql/hive), an open source schema registry. Some of the [new features recently released to Hive](https://the-guild.dev/blog/tag/graphql-hive), such as the [schema policy feature](https://the-guild.dev/blog/hive-introducing-schema-policy), enable organizations to enforce best practices and schema rules across many different teams automatically.
+In discussing larger-scale usage of GraphQL, The Guild participants referenced
+some of their work helping large teams manage GraphQL APIs using workflows and
+tools using tools such as [GraphQL Hive](https://the-guild.dev/graphql/hive), an
+open source schema registry. Some of the
+[new features recently released to Hive](https://the-guild.dev/blog/tag/graphql-hive),
+such as the
+[schema policy feature](https://the-guild.dev/blog/hive-introducing-schema-policy),
+enable organizations to enforce best practices and schema rules across many
+different teams automatically.
## Community Stewardship and Future Collaborations
-The Guild team acknowledged the importance of community contributions and discussed their efforts to improve and simplify the [GraphQL community website](/), and emphasized the importance of fostering a vibrant and inclusive GraphQL community. The Q&A session with The Guild offered a wealth of knowledge and insights into the world of GraphQL. Furthermore, the session highlighted areas for improvement and opportunities for community members to contribute. For more information check out [The Guild’s projects](https://the-guild.dev/#platform) and [blog](https://the-guild.dev/blog) and our [GraphQL official community page](https://graphql.org/community).
-
-As the GraphQL ecosystem continues to evolve, sessions like these provide valuable guidance and foster a sense of community among developers, paving the way for innovation and growth in our exciting ecosystem. Please [join us on June 28](https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=N25ycGVoaXViOHZxdXFzN3Y5dWNiaGY2OGsgbGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBn&tmsrc=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com) for our next [Discord Q&A](http://discord.graphql.org) session featuring engineering leaders from Hasura.
+The Guild team acknowledged the importance of community contributions and
+discussed their efforts to improve and simplify the
+[GraphQL community website](/), and emphasized the importance of fostering a
+vibrant and inclusive GraphQL community. The Q&A session with The Guild offered
+a wealth of knowledge and insights into the world of GraphQL. Furthermore, the
+session highlighted areas for improvement and opportunities for community
+members to contribute. For more information check out
+[The Guild’s projects](https://the-guild.dev/#platform) and
+[blog](https://the-guild.dev/blog) and our
+[GraphQL official community page](https://graphql.org/community).
+
+As the GraphQL ecosystem continues to evolve, sessions like these provide
+valuable guidance and foster a sense of community among developers, paving the
+way for innovation and growth in our exciting ecosystem. Please
+[join us on June 28](https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=N25ycGVoaXViOHZxdXFzN3Y5dWNiaGY2OGsgbGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBn&tmsrc=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com)
+for our next [Discord Q&A](http://discord.graphql.org) session featuring
+engineering leaders from Hasura.
diff --git a/src/pages/blog/2023-07-06-youtube-updated.mdx b/src/pages/blog/2023-07-06-youtube-updated.mdx
index 0d63a8bd8d..0fe5952755 100644
--- a/src/pages/blog/2023-07-06-youtube-updated.mdx
+++ b/src/pages/blog/2023-07-06-youtube-updated.mdx
@@ -5,9 +5,19 @@ date: 2023-07-06
byline: Jory Burson
---
-Have you been missing out on recent GraphQL Working Group meetings? Want to catch up on the latest conversations about Incremental Delivery, GraphQL over HTTP, and Input Unions?
-Thanks to [Benjie Gillam](https://github.com/benjie), now you can!
+Have you been missing out on recent GraphQL Working Group meetings? Want to
+catch up on the latest conversations about Incremental Delivery, GraphQL over
+HTTP, and Input Unions? Thanks to [Benjie Gillam](https://github.com/benjie),
+now you can!
-Benjie has done the onerous job of updating the GraphQL Foundation’s YouTube playlists with all the latest recordings of GraphQL Working Group meetings, which are now available for you to view here: https://youtube.com/@GraphQLFoundation/playlists
+Benjie has done the onerous job of updating the GraphQL Foundation’s YouTube
+playlists with all the latest recordings of GraphQL Working Group meetings,
+which are now available for you to view here:
+https://youtube.com/@GraphQLFoundation/playlists
-GraphQL technical working group meetings are open to the public, and can be found on our calendar at https://calendar.graphql.org. Community members can subscribe to the whole calendar or to a specific meeting series for personal updates. For those who can’t make it, we encourage you to [subscribe to the YouTube channel](https://youtube.com/@GraphQLFoundation) to get notified when working group meetings are posted.
+GraphQL technical working group meetings are open to the public, and can be
+found on our calendar at https://calendar.graphql.org. Community members can
+subscribe to the whole calendar or to a specific meeting series for personal
+updates. For those who can’t make it, we encourage you to
+[subscribe to the YouTube channel](https://youtube.com/@GraphQLFoundation) to
+get notified when working group meetings are posted.
diff --git a/src/pages/blog/2023-08-01-key-insights-from-the-graphql-eu-gathering.mdx b/src/pages/blog/2023-08-01-key-insights-from-the-graphql-eu-gathering.mdx
index 748524185b..6ee3af67a7 100644
--- a/src/pages/blog/2023-08-01-key-insights-from-the-graphql-eu-gathering.mdx
+++ b/src/pages/blog/2023-08-01-key-insights-from-the-graphql-eu-gathering.mdx
@@ -5,113 +5,229 @@ date: 2023-08-01
byline: Jamie Barton
---
-As the adage goes, unity is strength. The premier GraphQL EU "unconference", held in Berlin, is a testament to this belief. This phenomenal event was the result of immense collaboration between various companies and providers within our vibrant ecosystem. The partnership among these key players, backed by the tireless efforts of the [GraphQL Foundation](/foundation/), truly highlighted the strength of our community and the unity we foster.
-
-Such dedication from all corners reinforces our commitment to growing and strengthening the global GraphQL community. We understand that a robust community is not built on grand events alone, but through localized meetups and smaller gatherings that allow enthusiasts and experts to exchange knowledge and ideas on a more intimate level.
-
-To that end, we encourage and are excited to support local contributors eager to organize GraphQL meetups. A shining example of a successful local event was the recent gathering in Amsterdam, which saw a vibrant mix of participants sharing their GraphQL journeys, learning from each other, and expanding their networks. Now, with the backing of the GraphQL Foundation, anyone with the zeal and passion to bring the GraphQL community together at a local level can do so with our full support.
+As the adage goes, unity is strength. The premier GraphQL EU "unconference",
+held in Berlin, is a testament to this belief. This phenomenal event was the
+result of immense collaboration between various companies and providers within
+our vibrant ecosystem. The partnership among these key players, backed by the
+tireless efforts of the [GraphQL Foundation](/foundation/), truly highlighted
+the strength of our community and the unity we foster.
+
+Such dedication from all corners reinforces our commitment to growing and
+strengthening the global GraphQL community. We understand that a robust
+community is not built on grand events alone, but through localized meetups and
+smaller gatherings that allow enthusiasts and experts to exchange knowledge and
+ideas on a more intimate level.
+
+To that end, we encourage and are excited to support local contributors eager to
+organize GraphQL meetups. A shining example of a successful local event was the
+recent gathering in Amsterdam, which saw a vibrant mix of participants sharing
+their GraphQL journeys, learning from each other, and expanding their networks.
+Now, with the backing of the GraphQL Foundation, anyone with the zeal and
+passion to bring the GraphQL community together at a local level can do so with
+our full support.
## GraphQL EU
-The "unconference" format encourages an open dialogue; it provides a platform for all participants to express their ideas, facilitating enriching discussions about their daily experiences with GraphQL, both the victories and the challenges.
+The "unconference" format encourages an open dialogue; it provides a platform
+for all participants to express their ideas, facilitating enriching discussions
+about their daily experiences with GraphQL, both the victories and the
+challenges.
-After everyone had gathered and invigorated themselves with coffee and croissants (it was a tad too early for currywurst), we proceeded to convene in the main hall.
+After everyone had gathered and invigorated themselves with coffee and
+croissants (it was a tad too early for currywurst), we proceeded to convene in
+the main hall.
### The Day
-The day kicked off with brief presentations from all sponsors - [Mirumee Software](https://mirumee.com/), [The Guild Software](https://the-guild.dev/), [Stellate](https://stellate.co/), [Saleor Commerce](https://saleor.io/), [Hasura](https://hasura.io/), [Escape](https://escape.tech/). Far from being standard sponsor speeches, each speaker conveyed an inspiring experience that would later spark a day brimming with engaging discussions.
+The day kicked off with brief presentations from all sponsors -
+[Mirumee Software](https://mirumee.com/),
+[The Guild Software](https://the-guild.dev/), [Stellate](https://stellate.co/),
+[Saleor Commerce](https://saleor.io/), [Hasura](https://hasura.io/),
+[Escape](https://escape.tech/). Far from being standard sponsor speeches, each
+speaker conveyed an inspiring experience that would later spark a day brimming
+with engaging discussions.
-After the sponsor presentations concluded, [Van Riper](https://twitter.com/vanriper) did an outstanding job outlining the subsequent plan of action, ensuring we kept to the allocated timetable!
+After the sponsor presentations concluded,
+[Van Riper](https://twitter.com/vanriper) did an outstanding job outlining the
+subsequent plan of action, ensuring we kept to the allocated timetable!
-Each participant was given a card to jot down their discussion topic, followed by a 20-second slot on stage to present it. Once we deciphered the correct usage of sticky tape, these cards were affixed to the whiteboards. This interactive activity essentially laid down the structure for the remainder of the day's events.
+Each participant was given a card to jot down their discussion topic, followed
+by a 20-second slot on stage to present it. Once we deciphered the correct usage
+of sticky tape, these cards were affixed to the whiteboards. This interactive
+activity essentially laid down the structure for the remainder of the day's
+events.
### Round 1
-The moment had come to choose a topic and dive right in! We were allocated approximately an hour to join a section of the hall for in-depth topic discussions.
+The moment had come to choose a topic and dive right in! We were allocated
+approximately an hour to join a section of the hall for in-depth topic
+discussions.
-Given the multitude of subjects presented on various whiteboards, selecting just one posed quite a challenge.
+Given the multitude of subjects presented on various whiteboards, selecting just
+one posed quite a challenge.
-I chose to participate in the conversation at location **R1/D**, which encompassed three related topics:
+I chose to participate in the conversation at location **R1/D**, which
+encompassed three related topics:
1. **Enhancing the GraphQL Developer Experience**
2. **Simplifying GraphQL Servers (with a gateway)**
3. **Identifying missing elements in GraphQL Developer Tooling**
-Even though the discussion adhered to the set time limit, it undoubtedly contained a wealth of material.
-
-The primary conclusion drawn from this conversation was the pressing need for additional standards, or even better, detailed specifications for GraphQL implementation on both the server and client side. Developers frequently find themselves reapplying identical logic across different languages due to a lack of standardization. This often results in using one language as a foundation for the next.
-
-However, if there's a deviation from the original, it could negatively impact the developer experience, especially for those working with numerous languages across different stacks.
-
-Creating a specification doesn't have to be a complex process, nor does it need the sanction of anyone to be beneficial. Several years ago, [Jayden Seric](https://github.com/jaydenseric/graphql-multipart-request-spec) introduced the GraphQL multipart request specification. Anyone who is implementing multipart uploads will appreciate the guidance and insights offered by such a singular specification, allowing developers to concentrate on the tasks of building and delivering their applications.
-
-During the first round's intermission, I had the chance to observe Uri Goldshtein guiding the Beyond GraphQL group. This intriguing dialogue explored how GraphQL's concepts could be integrated with other tools and standards, including OpenAPI and gRPC. The group also pondered over the existing divide and potential ways to bridge these specifications, aiming for a more unified landscape where the right tool can be chosen for the job.
-
-The discussion, under Uri's skillful moderation, took an exciting turn as they probed the potential for repurposing existing APIs using GraphQL by means of automation. Numerous organizations and tools like GraphQL Mesh, Grafbase, SOFA, Hasura, and Wundergraph are already navigating these waters. They invite and appreciate the participation of anyone interested in contributing to this evolving domain through open-source projects.
-
-In his concluding remarks, Uri underscored, "The moment has arrived for the discourse within the GraphQL ecosystem to evolve beyond the 'GraphQL vs. REST' debate. Instead, we should focus on how we can apply GraphQL's robust features to enrich other existing APIs."
+Even though the discussion adhered to the set time limit, it undoubtedly
+contained a wealth of material.
+
+The primary conclusion drawn from this conversation was the pressing need for
+additional standards, or even better, detailed specifications for GraphQL
+implementation on both the server and client side. Developers frequently find
+themselves reapplying identical logic across different languages due to a lack
+of standardization. This often results in using one language as a foundation for
+the next.
+
+However, if there's a deviation from the original, it could negatively impact
+the developer experience, especially for those working with numerous languages
+across different stacks.
+
+Creating a specification doesn't have to be a complex process, nor does it need
+the sanction of anyone to be beneficial. Several years ago,
+[Jayden Seric](https://github.com/jaydenseric/graphql-multipart-request-spec)
+introduced the GraphQL multipart request specification. Anyone who is
+implementing multipart uploads will appreciate the guidance and insights offered
+by such a singular specification, allowing developers to concentrate on the
+tasks of building and delivering their applications.
+
+During the first round's intermission, I had the chance to observe Uri
+Goldshtein guiding the Beyond GraphQL group. This intriguing dialogue explored
+how GraphQL's concepts could be integrated with other tools and standards,
+including OpenAPI and gRPC. The group also pondered over the existing divide and
+potential ways to bridge these specifications, aiming for a more unified
+landscape where the right tool can be chosen for the job.
+
+The discussion, under Uri's skillful moderation, took an exciting turn as they
+probed the potential for repurposing existing APIs using GraphQL by means of
+automation. Numerous organizations and tools like GraphQL Mesh, Grafbase, SOFA,
+Hasura, and Wundergraph are already navigating these waters. They invite and
+appreciate the participation of anyone interested in contributing to this
+evolving domain through open-source projects.
+
+In his concluding remarks, Uri underscored, "The moment has arrived for the
+discourse within the GraphQL ecosystem to evolve beyond the 'GraphQL vs. REST'
+debate. Instead, we should focus on how we can apply GraphQL's robust features
+to enrich other existing APIs."
### Round 2
-Choosing the next discussion to attend proved to be quite a difficult task that saw me staring at a board of topic cards longer than I would like to admit. I was torn between the following topics:
+Choosing the next discussion to attend proved to be quite a difficult task that
+saw me staring at a board of topic cards longer than I would like to admit. I
+was torn between the following topics:
- **Relay**
- **Federation in Practice / Combining and Extending GraphQL APIs**
-Given my day-to-day role involves guiding and assisting developers to excel in extending GraphQL APIs with [Grafbase](https://grafbase.com), I felt a strong inclination towards this topic. However, my intuition, coupled with the palpable growing support for Relay, guided my decision in the end.
+Given my day-to-day role involves guiding and assisting developers to excel in
+extending GraphQL APIs with [Grafbase](https://grafbase.com), I felt a strong
+inclination towards this topic. However, my intuition, coupled with the palpable
+growing support for Relay, guided my decision in the end.
-Hearing from [Denis Badurina](https://twitter.com/enisdenjo), [Marion Schleifer](https://twitter.com/rubydwarf), [Stephan Schneider](https://twitter.com/zcei_GER), and others about their experiences with Relay was enlightening.
+Hearing from [Denis Badurina](https://twitter.com/enisdenjo),
+[Marion Schleifer](https://twitter.com/rubydwarf),
+[Stephan Schneider](https://twitter.com/zcei_GER), and others about their
+experiences with Relay was enlightening.
-I openly admitted to the group that it had been several years since my last encounter with Relay (which, admittedly, was not entirely successful), but I was eager to understand the current usage patterns and share some of the narratives I've come across in my GraphQL journey regarding why developers often don't select Relay as their first choice.
+I openly admitted to the group that it had been several years since my last
+encounter with Relay (which, admittedly, was not entirely successful), but I was
+eager to understand the current usage patterns and share some of the narratives
+I've come across in my GraphQL journey regarding why developers often don't
+select Relay as their first choice.
-As the session neared its end, it became evident that there were some common reasons why Relay wasn't the first choice for developers:
+As the session neared its end, it became evident that there were some common
+reasons why Relay wasn't the first choice for developers:
-- A perceived steep learning curve, mainly resulting from the mental model shift surrounding components and data dependencies.
+- A perceived steep learning curve, mainly resulting from the mental model shift
+ surrounding components and data dependencies.
- Setting up the compiler configuration was frequently a tedious task.
**Interestingly, those developers who do use Relay are indeed very fond of it!**
### Round 3
-As the day was nearing its conclusion, it was time to choose a topic that would potentially ignite conversations even during the evening reception drinks. And I must say, I certainly opted for such a topic!
+As the day was nearing its conclusion, it was time to choose a topic that would
+potentially ignite conversations even during the evening reception drinks. And I
+must say, I certainly opted for such a topic!
-The subject at **R3/C** centred around **the role of GraphQL in the era of TRPC and RSC**. I commend [Bogdan](https://twitter.com/soarebo) for his audacity to bring up such a contentious topic. But then again, we were at a GraphQL event, so the reactions wouldn't have been as fiery as they would have been if this topic had emerged on a tweet.
+The subject at **R3/C** centred around **the role of GraphQL in the era of TRPC
+and RSC**. I commend [Bogdan](https://twitter.com/soarebo) for his audacity to
+bring up such a contentious topic. But then again, we were at a GraphQL event,
+so the reactions wouldn't have been as fiery as they would have been if this
+topic had emerged on a tweet.
-All participants were given the opportunity to express their opinions and explain why the topic stirred up so much controversy. [Uri Goldshtein](https://twitter.com/UriGoldshtein) introduced some impressive open source projects within the community, particularly [Garph](https://garph.dev/)/[GQty](https://gqty.dev/), which aim to close the gap and simplify the process of generating types for end-to-end type safety.
+All participants were given the opportunity to express their opinions and
+explain why the topic stirred up so much controversy.
+[Uri Goldshtein](https://twitter.com/UriGoldshtein) introduced some impressive
+open source projects within the community, particularly
+[Garph](https://garph.dev/)/[GQty](https://gqty.dev/), which aim to close the
+gap and simplify the process of generating types for end-to-end type safety.
-The omnipresence of React is no secret. Its adoption is surging across the board, a trend further amplified by the significant influence that Next.js has exerted within the ecosystem.
+The omnipresence of React is no secret. Its adoption is surging across the
+board, a trend further amplified by the significant influence that Next.js has
+exerted within the ecosystem.
> [State of JavaScript 2022: Front-end Frameworks](https://2022.stateofjs.com/en-US/libraries/front-end-frameworks)
-It's also well-known that the rise of Next.js and RSC is stirring up numerous concerns and questions, and encountering some challenges, as it propels the community forward with their runtime implementation of **React Server Components**. I believe GraphQL is also at a crossroads, trying to determine its ideal niche within this evolving React ecosystem.
+It's also well-known that the rise of Next.js and RSC is stirring up numerous
+concerns and questions, and encountering some challenges, as it propels the
+community forward with their runtime implementation of **React Server
+Components**. I believe GraphQL is also at a crossroads, trying to determine its
+ideal niche within this evolving React ecosystem.
-However, it's crucial to remember that while React and Next.js are prevalent choices, there are many other languages and frameworks that can leverage GraphQL. As a community, we sometimes overlook these alternatives.
+However, it's crucial to remember that while React and Next.js are prevalent
+choices, there are many other languages and frameworks that can leverage
+GraphQL. As a community, we sometimes overlook these alternatives.
-If you haven't yet used [Houdini GraphQL](https://www.houdinigraphql.com) and Svelte, you're in for a treat. Houdini offers a refreshing approach to constructing type-safe web applications powered by GraphQL.
+If you haven't yet used [Houdini GraphQL](https://www.houdinigraphql.com) and
+Svelte, you're in for a treat. Houdini offers a refreshing approach to
+constructing type-safe web applications powered by GraphQL.
-Overall, it seemed that GraphQL was continuing to expand, but its applications were shifting. Developers who are building web and mobile applications seem to be moving towards simpler routing mechanisms, like Tanstack and React Router, coupled with Relay for client-side data loading and caching.
+Overall, it seemed that GraphQL was continuing to expand, but its applications
+were shifting. Developers who are building web and mobile applications seem to
+be moving towards simpler routing mechanisms, like Tanstack and React Router,
+coupled with Relay for client-side data loading and caching.
## Key Insights from GraphQL EU
-While I couldn't be part of every conversation, a myriad of topics were undoubtedly discussed during the reception after-party, and even the after-after-party.
+While I couldn't be part of every conversation, a myriad of topics were
+undoubtedly discussed during the reception after-party, and even the
+after-after-party.
Below are the main insights I jotted down in my Notes App throughout the day:
-- Despite its initial complexity and paradigm shift, Relay is increasingly adopted by those with more GraphQL experience, especially due to its ability to co-locate fragments with their respective components.
-- While tRPC is attractive, not all companies have total control over their tech stacks and rely on external GraphQL APIs. Consequently, more developers are utilizing gateway or federation methods to integrate these APIs.
-- Ensuring GraphQL APIs are versionless is vital for mobile applications to function smoothly, given users frequently lag in updating their apps.
-- For SPAs or mobile apps, where client fetching is preferable, GraphQL still offers a superior experience. React Server Components (RSC), particularly with Next.js, doesn't provide much scope for GraphQL, and that's acceptable.
-- For server-rendered applications, GraphQL remains a viable choice. As a simple function or network call, it can facilitate integration with multiple APIs more efficiently than having to install numerous SDKs.
+- Despite its initial complexity and paradigm shift, Relay is increasingly
+ adopted by those with more GraphQL experience, especially due to its ability
+ to co-locate fragments with their respective components.
+- While tRPC is attractive, not all companies have total control over their tech
+ stacks and rely on external GraphQL APIs. Consequently, more developers are
+ utilizing gateway or federation methods to integrate these APIs.
+- Ensuring GraphQL APIs are versionless is vital for mobile applications to
+ function smoothly, given users frequently lag in updating their apps.
+- For SPAs or mobile apps, where client fetching is preferable, GraphQL still
+ offers a superior experience. React Server Components (RSC), particularly with
+ Next.js, doesn't provide much scope for GraphQL, and that's acceptable.
+- For server-rendered applications, GraphQL remains a viable choice. As a simple
+ function or network call, it can facilitate integration with multiple APIs
+ more efficiently than having to install numerous SDKs.
## What's next for GraphQL?
-As significant as this event was, we are set to surpass it with the official [GraphQL Conf](https://graphql.org/conf), scheduled for September 19-21 in San Francisco. If you thought this event was insightful, I guarantee you that the upcoming conference is going to be a game-changer!
+As significant as this event was, we are set to surpass it with the official
+[GraphQL Conf](https://graphql.org/conf), scheduled for September 19-21 in San
+Francisco. If you thought this event was insightful, I guarantee you that the
+upcoming conference is going to be a game-changer!
-You wouldn't want to miss out, so grab your tickets soon! I look forward to seeing many familiar faces and meeting new ones at the conference.
+You wouldn't want to miss out, so grab your tickets soon! I look forward to
+seeing many familiar faces and meeting new ones at the conference.
- [Buy a Ticket!](/conf/2023#attend)
- [See the schedule](/conf/2023/schedule)
@@ -119,6 +235,9 @@ You wouldn't want to miss out, so grab your tickets soon! I look forward to seei
## Get involved
-Though the aforementioned reflections encapsulate my journey, I encourage you to contribute your unique experiences to our collective narrative. [Connect with us on Discord](https://discord.graphql.org) and enrich the GraphQL community with your insights.
+Though the aforementioned reflections encapsulate my journey, I encourage you to
+contribute your unique experiences to our collective narrative.
+[Connect with us on Discord](https://discord.graphql.org) and enrich the GraphQL
+community with your insights.
See you in San Francisco!
diff --git a/src/pages/blog/2023-08-24-announcing-the-schedule-for-graphqlconf.mdx b/src/pages/blog/2023-08-24-announcing-the-schedule-for-graphqlconf.mdx
index 8f5cddcb02..b8b996c55a 100644
--- a/src/pages/blog/2023-08-24-announcing-the-schedule-for-graphqlconf.mdx
+++ b/src/pages/blog/2023-08-24-announcing-the-schedule-for-graphqlconf.mdx
@@ -5,35 +5,79 @@ date: 2023-08-24
byline: Jory Burson
---
-_The inaugural event for the GraphQL Foundation, GraphQLConf, delivers the best GraphQL content available._
-
-**SAN FRANCISCO, August 24, 2023** – The GraphQL Foundation, dedicated to promoting widespread adoption and accelerating development of the surrounding ecosystem, today announced the schedule for [GraphQLConf 2023](https://graphql.org/conf/). The conference will be held in the San Francisco Bay area, CA, September 19-21, 2023.
-
-GraphQLConf brings together the creators of some of the most important technologies behind GraphQL. Speakers from a wide range of organizations working with GraphQL at enterprise scale will share their experience, insights and knowledge as they discuss the challenges facing the growing GraphQL ecosystem. The program was developed by a community-led committee, which selected over 60 sessions after an open CFP that produced a large and diverse set of submissions that span topics from technical challenges and deep dives to end-user stories and introductory content.
-
-“This event is a truly special moment for the GraphQL community,” said Lee Byron, Co-creator of GraphQL and Executive Director of the GraphQL Foundation. “GraphQLConf is the only vendor-agnostic, community-focused conference for developers. We’re thrilled to bring everyone together and celebrate big milestones for our projects and the spec.”
-
-The GraphQLConf community-curated [schedule](https://graphql.org/conf/schedule/) will feature talks from leaders in the industry, and will focus on the most important and relevant topics facing the ecosystem, such as new specifications and features, GraphQL Gateways, GraphQL Security, interoperability between GraphQL and other API protocols, Generative AI and GraphQL performance, caching and no-code tools.
-
-Keynote sessions from developer-entrepreneurs Idit Levine, Marc-Andre Giroux, Tanmai Gopal, and Theo Browne will be featured, along with workshops and breakout sessions on using GraphQL across tech stacks, languages, and deployment technologies. There will also be community-driven unconference sessions held on Sept. 19.
+_The inaugural event for the GraphQL Foundation, GraphQLConf, delivers the best
+GraphQL content available._
+
+**SAN FRANCISCO, August 24, 2023** – The GraphQL Foundation, dedicated to
+promoting widespread adoption and accelerating development of the surrounding
+ecosystem, today announced the schedule for
+[GraphQLConf 2023](https://graphql.org/conf/). The conference will be held in
+the San Francisco Bay area, CA, September 19-21, 2023.
+
+GraphQLConf brings together the creators of some of the most important
+technologies behind GraphQL. Speakers from a wide range of organizations working
+with GraphQL at enterprise scale will share their experience, insights and
+knowledge as they discuss the challenges facing the growing GraphQL ecosystem.
+The program was developed by a community-led committee, which selected over 60
+sessions after an open CFP that produced a large and diverse set of submissions
+that span topics from technical challenges and deep dives to end-user stories
+and introductory content.
+
+“This event is a truly special moment for the GraphQL community,” said Lee
+Byron, Co-creator of GraphQL and Executive Director of the GraphQL Foundation.
+“GraphQLConf is the only vendor-agnostic, community-focused conference for
+developers. We’re thrilled to bring everyone together and celebrate big
+milestones for our projects and the spec.”
+
+The GraphQLConf community-curated [schedule](https://graphql.org/conf/schedule/)
+will feature talks from leaders in the industry, and will focus on the most
+important and relevant topics facing the ecosystem, such as new specifications
+and features, GraphQL Gateways, GraphQL Security, interoperability between
+GraphQL and other API protocols, Generative AI and GraphQL performance, caching
+and no-code tools.
+
+Keynote sessions from developer-entrepreneurs Idit Levine, Marc-Andre Giroux,
+Tanmai Gopal, and Theo Browne will be featured, along with workshops and
+breakout sessions on using GraphQL across tech stacks, languages, and deployment
+technologies. There will also be community-driven unconference sessions held on
+Sept. 19.
## Registration
-GraphQLConf will be held at the Hyatt Regency SFO September 19-21 and registration is open at https://graphql.org/conf. Attendees are encouraged to [register](https://graphql.org/conf/#attend) for in-person attendance by September 4 before prices increase.
+GraphQLConf will be held at the Hyatt Regency SFO September 19-21 and
+registration is open at https://graphql.org/conf. Attendees are encouraged to
+[register](https://graphql.org/conf/#attend) for in-person attendance by
+September 4 before prices increase.
## Thank You to Our Sponsors
-GraphQLConf is made possible with support from our Diamond Sponsors: [Hasura](https://hasura.io), [Postman](https://postman.com), and [The Guild](https://the-guild.dev), Platinum Sponsors: [Hygraph](https://hygraph.com) and [Solo.io](https://solo.io), and Gold Sponsors: [StepZen](https://stepzen.com), [Inigo](https://inigo.io), and [The Graph](https://thegraph.com).
+GraphQLConf is made possible with support from our Diamond Sponsors:
+[Hasura](https://hasura.io), [Postman](https://postman.com), and
+[The Guild](https://the-guild.dev), Platinum Sponsors:
+[Hygraph](https://hygraph.com) and [Solo.io](https://solo.io), and Gold
+Sponsors: [StepZen](https://stepzen.com), [Inigo](https://inigo.io), and
+[The Graph](https://thegraph.com).
## About the GraphQL Foundation
-The GraphQL Foundation is a neutral foundation founded by global technology and application development companies. The GraphQL Foundation encourages contributions, stewardship, and a shared investment from a broad group in vendor-neutral events, documentation, tools, and support for GraphQL.
+The GraphQL Foundation is a neutral foundation founded by global technology and
+application development companies. The GraphQL Foundation encourages
+contributions, stewardship, and a shared investment from a broad group in
+vendor-neutral events, documentation, tools, and support for GraphQL.
-GraphQL was created in 2012 and open sourced by Facebook in 2015. In 2019, Facebook and others created the GraphQL Foundation as a neutral, non-profit home for the GraphQL assets and ongoing collaboration, and hosted by The Linux Foundation. The GraphQL Foundation is a fully neutral home for the GraphQL trademark, and provides a means of collecting and distributing membership dues to support core community infrastructure and programs. For more information about the GraphQL Foundation, please visit https://graphql.org.
+GraphQL was created in 2012 and open sourced by Facebook in 2015. In 2019,
+Facebook and others created the GraphQL Foundation as a neutral, non-profit home
+for the GraphQL assets and ongoing collaboration, and hosted by The Linux
+Foundation. The GraphQL Foundation is a fully neutral home for the GraphQL
+trademark, and provides a means of collecting and distributing membership dues
+to support core community infrastructure and programs. For more information
+about the GraphQL Foundation, please visit https://graphql.org.
---
-The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page. Linux is a registered trademark of Linus Torvalds.
+The Linux Foundation has registered trademarks and uses trademarks. For a list
+of trademarks of The Linux Foundation, please see our trademark usage page.
+Linux is a registered trademark of Linus Torvalds.
Media Contact
diff --git a/src/pages/blog/2024-01-17-announcing-grant-awardees.mdx b/src/pages/blog/2024-01-17-announcing-grant-awardees.mdx
index 07b7295dda..86eafc9312 100644
--- a/src/pages/blog/2024-01-17-announcing-grant-awardees.mdx
+++ b/src/pages/blog/2024-01-17-announcing-grant-awardees.mdx
@@ -1,40 +1,118 @@
---
-title: "Announcing the GraphQL Foundation's Grant Awardees: Benefitting a GraphQL Ecosystem for All"
+title:
+ "Announcing the GraphQL Foundation's Grant Awardees: Benefitting a GraphQL
+ Ecosystem for All"
tags: ["blog"]
date: 2024-01-17
byline: Jory Burson and Benjie Gillam
---
-We are thrilled to announce the recipients of grants from the GraphQL Foundation, which were selected from an application process initiated in late 2022. Awardees were selected after an extensive review and vote of the GraphQL TSC. These grant awards recognize and support important projects that advance GraphQL technologies, particularly in the realms of GraphQL over HTTP and the GraphQL Language Service Server.
+We are thrilled to announce the recipients of grants from the GraphQL
+Foundation, which were selected from an application process initiated in
+late 2022. Awardees were selected after an extensive review and vote of the
+GraphQL TSC. These grant awards recognize and support important projects that
+advance GraphQL technologies, particularly in the realms of GraphQL over HTTP
+and the GraphQL Language Service Server.
**Bolstering GraphQL over HTTP — Denis Badurina**
-The first grant has been awarded to a project focussed on increasing interoperability between the various implementations of GraphQL clients and servers using HTTP as the transport layer. The [GraphQL–over–HTTP subcommittee](https://github.com/graphql/graphql-over-http) was formed with the goal of writing a specification to increase interoperability between clients and servers that expose GraphQL schemas via HTTP endpoints. At a [recent GraphQL Working Group](https://github.com/graphql/graphql-wg/blob/main/notes/2023/2023-11.md#graphql-over-http-is-advancing-to-stage-2-5m-benjie), the GraphQL–over–HTTP spec was advanced to Stage 2 (Draft) status. This achievement was thanks in a large part to [Denis Badurina](https://github.com/enisdenjo)'s development and maintenance of the reference implementation of the GraphQL–over–HTTP specification: [graphql-http](https://github.com/graphql/graphql-http) and the associated [testing tool](https://graphql-http.com/). This tool can be used to test if any GraphQL API is compliant with the GraphQL–over–HTTP specification, no matter what language it is written in. Denis has worked tirelessly with maintainers of various servers to ensure that the tool, the server, and the specification are aligned.
-
-This grant will enable Denis to continue to invest into maintenance and development of this important project for GraphQL interoperability and collaboration. When informed he was to be a grant awardee, Denis said: "this is awesome news! I'll start by saying thank you. I am very humbled, excited and happy that my work has a worthwhile impact on the GraphQL ecosystem. Thank you for choosing me, I will continue doing my best."
+The first grant has been awarded to a project focussed on increasing
+interoperability between the various implementations of GraphQL clients and
+servers using HTTP as the transport layer. The
+[GraphQL–over–HTTP subcommittee](https://github.com/graphql/graphql-over-http)
+was formed with the goal of writing a specification to increase interoperability
+between clients and servers that expose GraphQL schemas via HTTP endpoints. At a
+[recent GraphQL Working Group](https://github.com/graphql/graphql-wg/blob/main/notes/2023/2023-11.md#graphql-over-http-is-advancing-to-stage-2-5m-benjie),
+the GraphQL–over–HTTP spec was advanced to Stage 2 (Draft) status. This
+achievement was thanks in a large part to
+[Denis Badurina](https://github.com/enisdenjo)'s development and maintenance of
+the reference implementation of the GraphQL–over–HTTP specification:
+[graphql-http](https://github.com/graphql/graphql-http) and the associated
+[testing tool](https://graphql-http.com/). This tool can be used to test if any
+GraphQL API is compliant with the GraphQL–over–HTTP specification, no matter
+what language it is written in. Denis has worked tirelessly with maintainers of
+various servers to ensure that the tool, the server, and the specification are
+aligned.
+
+This grant will enable Denis to continue to invest into maintenance and
+development of this important project for GraphQL interoperability and
+collaboration. When informed he was to be a grant awardee, Denis said: "this is
+awesome news! I'll start by saying thank you. I am very humbled, excited and
+happy that my work has a worthwhile impact on the GraphQL ecosystem. Thank you
+for choosing me, I will continue doing my best."
**Future–proofing the GraphQL Language Service Server — Rikki Schulte**
-The second grant recognizes a project that is vital for consumers of GraphQL. One of the most popular tools in the GraphQL toolbox is [GraphiQL](https://github.com/graphql/graphiql/blob/a80801970e095e493eb0fda7687766f103bf701e/packages/graphiql/README.md) — our in–browser IDE that enables exploring and querying a GraphQL API. It's often the first experience that potential users have with GraphQL, and very quickly helps them to "[grok](https://dictionary.cambridge.org/dictionary/english/grok)" some core concepts such as the built in documentation, type safety, and only receiving what you ask for. Underlying this beautifully simple interface is a powerful and complex combination of tools and libraries which also power other projects such as alternative GraphQL IDEs and code editor integrations. Key to this is the GraphQL Language Server and associated libraries.
-
-[Rikki Schulte](https://github.com/acao), one of the long term maintainers of GraphiQL and the associated projects, is the recipient of this second grant. The grant will support her to improve the stability and maintainability of the GraphQL Language Server by providing a more comprehensive end–to–end test suite which should enable an overhaul of its aging architecture. Building on the Language Server's existing schema–aware auto–complete, jump to definition, and real–time error feedback; the ultimate goal of the Language Server project is to give all GraphQL programmers access to advanced features such as support for more languages and sophisticated refactoring tools whilst keeping astride of advances to the GraphQL specification itself.
-
-What makes this project particularly exciting is its commitment to making GraphQL development more accessible and efficient. By providing tools that integrate seamlessly into existing development environments, Rikki hopes to lower the barrier to entry for new GraphQL developers and increase productivity for seasoned professionals. Rikki commented:
-
-"I'm thrilled to receive this grant, as it will help me to focus on improving the stability and maintainability of the LSP server and vscode reference implementation, so that we can refactor for improved performance and contributor experience, and to introduce new exciting features with greater confidence. I owe it all to the GraphQL community!"
+The second grant recognizes a project that is vital for consumers of GraphQL.
+One of the most popular tools in the GraphQL toolbox is
+[GraphiQL](https://github.com/graphql/graphiql/blob/a80801970e095e493eb0fda7687766f103bf701e/packages/graphiql/README.md)
+— our in–browser IDE that enables exploring and querying a GraphQL API. It's
+often the first experience that potential users have with GraphQL, and very
+quickly helps them to
+"[grok](https://dictionary.cambridge.org/dictionary/english/grok)" some core
+concepts such as the built in documentation, type safety, and only receiving
+what you ask for. Underlying this beautifully simple interface is a powerful and
+complex combination of tools and libraries which also power other projects such
+as alternative GraphQL IDEs and code editor integrations. Key to this is the
+GraphQL Language Server and associated libraries.
+
+[Rikki Schulte](https://github.com/acao), one of the long term maintainers of
+GraphiQL and the associated projects, is the recipient of this second grant. The
+grant will support her to improve the stability and maintainability of the
+GraphQL Language Server by providing a more comprehensive end–to–end test suite
+which should enable an overhaul of its aging architecture. Building on the
+Language Server's existing schema–aware auto–complete, jump to definition, and
+real–time error feedback; the ultimate goal of the Language Server project is to
+give all GraphQL programmers access to advanced features such as support for
+more languages and sophisticated refactoring tools whilst keeping astride of
+advances to the GraphQL specification itself.
+
+What makes this project particularly exciting is its commitment to making
+GraphQL development more accessible and efficient. By providing tools that
+integrate seamlessly into existing development environments, Rikki hopes to
+lower the barrier to entry for new GraphQL developers and increase productivity
+for seasoned professionals. Rikki commented:
+
+"I'm thrilled to receive this grant, as it will help me to focus on improving
+the stability and maintainability of the LSP server and vscode reference
+implementation, so that we can refactor for improved performance and contributor
+experience, and to introduce new exciting features with greater confidence. I
+owe it all to the GraphQL community!"
**A Commitment to Ecosystem and Community Growth**
-Both projects embody the GraphQL Foundation's commitment to open source and community–driven development. By supporting these initiatives, the foundation is not only investing in individual technologies but also in the broader GraphQL community. These grants will facilitate collaboration, knowledge sharing and innovation, fostering a vibrant ecosystem around GraphQL.
-
-In recognition of the work required to tend to such an ecosystem, the GraphQL Foundation together with the TSC has also funded [Benjie Gillam](https://github.com/benjie) to support the crucial “gardening” work that helps keep the GraphQL community moving forward, together. Benjie will continue to serve as our Community Manager in 2024 on contract with the Foundation, commenting:
-
-"It has been a joy and a privilege helping to cultivate the vibrant ecosystem of the GraphQL community, and this support from the GraphQL Foundation will help me to continue this work: welcoming new members, fostering collaboration across the Foundation's own projects and beyond, and helping the wheels of progress to keep turning smoothly. Thank you GraphQL community!"
+Both projects embody the GraphQL Foundation's commitment to open source and
+community–driven development. By supporting these initiatives, the foundation is
+not only investing in individual technologies but also in the broader GraphQL
+community. These grants will facilitate collaboration, knowledge sharing and
+innovation, fostering a vibrant ecosystem around GraphQL.
+
+In recognition of the work required to tend to such an ecosystem, the GraphQL
+Foundation together with the TSC has also funded
+[Benjie Gillam](https://github.com/benjie) to support the crucial “gardening”
+work that helps keep the GraphQL community moving forward, together. Benjie will
+continue to serve as our Community Manager in 2024 on contract with the
+Foundation, commenting:
+
+"It has been a joy and a privilege helping to cultivate the vibrant ecosystem of
+the GraphQL community, and this support from the GraphQL Foundation will help me
+to continue this work: welcoming new members, fostering collaboration across the
+Foundation's own projects and beyond, and helping the wheels of progress to keep
+turning smoothly. Thank you GraphQL community!"
**Looking Forward**
-As we celebrate the recipients of this year's grants, we also look forward to the impact their work will have on the GraphQL community and the tech industry at large. Their projects are not just about advancing individual technologies; they are about shaping the future of how we build and interact with GraphQL APIs.
+As we celebrate the recipients of this year's grants, we also look forward to
+the impact their work will have on the GraphQL community and the tech industry
+at large. Their projects are not just about advancing individual technologies;
+they are about shaping the future of how we build and interact with GraphQL
+APIs.
-The GraphQL Foundation is proud to support these talented individuals and teams, and we are excited to see their projects come to fruition. We believe their work will be instrumental in driving the next wave of innovation in GraphQL technology.
+The GraphQL Foundation is proud to support these talented individuals and teams,
+and we are excited to see their projects come to fruition. We believe their work
+will be instrumental in driving the next wave of innovation in GraphQL
+technology.
-Stay tuned for updates on these projects and their contributions to the GraphQL ecosystem. We are just at the beginning of a new chapter in GraphQL's story, and the best is yet to come!
+Stay tuned for updates on these projects and their contributions to the GraphQL
+ecosystem. We are just at the beginning of a new chapter in GraphQL's story, and
+the best is yet to come!
diff --git a/src/pages/blog/2024-01-23-graphql-tsc-election-results.mdx b/src/pages/blog/2024-01-23-graphql-tsc-election-results.mdx
index c8916a6aa9..2795be2281 100644
--- a/src/pages/blog/2024-01-23-graphql-tsc-election-results.mdx
+++ b/src/pages/blog/2024-01-23-graphql-tsc-election-results.mdx
@@ -5,30 +5,69 @@ date: 2024-01-23
byline: Jory Burson and Benjie Gillam
---
-We are pleased to announce the results of this year's GraphQL Technical Steering Committee (TSC) elections. Every year, five of the ten TSC seats are up for election, and this year has seen some changes in the committee lineup.
+We are pleased to announce the results of this year's GraphQL Technical Steering
+Committee (TSC) elections. Every year, five of the ten TSC seats are up for
+election, and this year has seen some changes in the committee lineup.
## Outgoing Member: Marc-André Giroux
-Firstly, we would like to extend our gratitude to [Marc-André Giroux](https://github.com/xuorig), who chose not to seek re–election this year. Marc-André has been a valuable member of the TSC, contributing significantly to the GraphQL ecosystem. We appreciate his dedication to the GraphQL Foundation!
+Firstly, we would like to extend our gratitude to
+[Marc-André Giroux](https://github.com/xuorig), who chose not to seek
+re–election this year. Marc-André has been a valuable member of the TSC,
+contributing significantly to the GraphQL ecosystem. We appreciate his
+dedication to the GraphQL Foundation!
## Continuing Members: Benjie Gillam, Ivan Goncharov, Matt Mohoney, and Michael Staib
-We are pleased to announce that the four other TSC members whose seats were up for election — [Benjie Gillam](https://github.com/benjie), [Ivan Goncharov](https://github.com/IvanGoncharov), [Matt Mohoney](https://github.com/mjmahone), and [Michael Staib](https://github.com/michaelstaib) — have been re–elected and will continue to serve on the TSC. Their ongoing commitment and expertise will undoubtedly contribute to the continued success of GraphQL.
+We are pleased to announce that the four other TSC members whose seats were up
+for election — [Benjie Gillam](https://github.com/benjie),
+[Ivan Goncharov](https://github.com/IvanGoncharov),
+[Matt Mohoney](https://github.com/mjmahone), and
+[Michael Staib](https://github.com/michaelstaib) — have been re–elected and will
+continue to serve on the TSC. Their ongoing commitment and expertise will
+undoubtedly contribute to the continued success of GraphQL.
## Welcoming Denis Badurina
-Joining the TSC this year is [Denis Badurina](https://github.com/enisdenjo), who will be filling the seat vacated by Marc-André Giroux. You may know Denis from his work on the `graphql-http` project, the reference implementation of GraphQL-over-HTTP and a test suite to help ensure compliance across all the servers in the ecosystem. Denis brings a wealth of experience and a fresh perspective to the committee, and we look forward to working with him to shape the future of GraphQL.
+Joining the TSC this year is [Denis Badurina](https://github.com/enisdenjo), who
+will be filling the seat vacated by Marc-André Giroux. You may know Denis from
+his work on the `graphql-http` project, the reference implementation of
+GraphQL-over-HTTP and a test suite to help ensure compliance across all the
+servers in the ecosystem. Denis brings a wealth of experience and a fresh
+perspective to the committee, and we look forward to working with him to shape
+the future of GraphQL.
## About the GraphQL TSC
-Composed of ten elected members and led by Executive Director Lee Byron, the [GraphQL Technical Steering Committee](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md) is responsible for technical oversight for all of the GraphQL Foundation's open source projects, both software and specifications. However, we believe in the power of collaboration and recognize that impactful contributions can come from all corners of our community. While the TSC plays a crucial role in overseeing the technical aspects of our projects, we want to emphasize that one doesn't need to be a TSC member to make a significant impact.
+Composed of ten elected members and led by Executive Director Lee Byron, the
+[GraphQL Technical Steering Committee](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md)
+is responsible for technical oversight for all of the GraphQL Foundation's open
+source projects, both software and specifications. However, we believe in the
+power of collaboration and recognize that impactful contributions can come from
+all corners of our community. While the TSC plays a crucial role in overseeing
+the technical aspects of our projects, we want to emphasize that one doesn't
+need to be a TSC member to make a significant impact.
-We actively encourage working groups to manage themselves autonomously, fostering a sense of ownership and innovation within each group. The TSC is here to provide support and guidance, and to perform administrative actions that cannot be delegated. We value the diverse talents and expertise within our community, and we believe that every individual has the potential to contribute meaningfully to the success of our projects.
+We actively encourage working groups to manage themselves autonomously,
+fostering a sense of ownership and innovation within each group. The TSC is here
+to provide support and guidance, and to perform administrative actions that
+cannot be delegated. We value the diverse talents and expertise within our
+community, and we believe that every individual has the potential to contribute
+meaningfully to the success of our projects.
## Expressing Gratitude
-We would like to express our gratitude to everyone who participated in the election process, especially the candidates who stepped forward — your involvement is vital to the success of the GraphQL ecosystem.
+We would like to express our gratitude to everyone who participated in the
+election process, especially the candidates who stepped forward — your
+involvement is vital to the success of the GraphQL ecosystem.
## Looking Ahead
-As we move forward, the GraphQL TSC remains dedicated to fostering collaboration, inclusivity, and technical excellence within the GraphQL community. We are excited about the future of GraphQL and the continued impact it will have on API development and beyond; if you're interested in helping us on this mission then [get involved in the GraphQL Working Group](https://github.com/graphql/graphql-wg/blob/main/JoiningAMeeting.md) and maybe even consider nominating yourself for a TSC position in the December election!
+As we move forward, the GraphQL TSC remains dedicated to fostering
+collaboration, inclusivity, and technical excellence within the GraphQL
+community. We are excited about the future of GraphQL and the continued impact
+it will have on API development and beyond; if you're interested in helping us
+on this mission then
+[get involved in the GraphQL Working Group](https://github.com/graphql/graphql-wg/blob/main/JoiningAMeeting.md)
+and maybe even consider nominating yourself for a TSC position in the December
+election!
diff --git a/src/pages/blog/2024-03-07-graphql-community-grant-refresh.mdx b/src/pages/blog/2024-03-07-graphql-community-grant-refresh.mdx
index 82632ddba1..c958058728 100644
--- a/src/pages/blog/2024-03-07-graphql-community-grant-refresh.mdx
+++ b/src/pages/blog/2024-03-07-graphql-community-grant-refresh.mdx
@@ -11,13 +11,12 @@ core projects!
## Improved process
-We've revamped the application process to accept submissions
-year-round, ensuring your innovative ideas get the attention they deserve
-promptly. Our focus is sharper than ever, with grants specifically aimed at
-projects tied closely to the GraphQL Foundation's efforts, including
-code and documentation contributions to [our repositories on
-GitHub](https://github.com/graphql) and enhancements to the
-[graphql.org](https://graphql.org) website.
+We've revamped the application process to accept submissions year-round,
+ensuring your innovative ideas get the attention they deserve promptly. Our
+focus is sharper than ever, with grants specifically aimed at projects tied
+closely to the GraphQL Foundation's efforts, including code and documentation
+contributions to [our repositories on GitHub](https://github.com/graphql) and
+enhancements to the [graphql.org](https://graphql.org) website.
Rather than our previous twice-annual review process, our new process will
perform basic appropriateness checks on a much higher cadence, and will pass
@@ -33,9 +32,10 @@ advocacy, or improving the user experience on our platforms, we're looking for
your unique contributions. Don't miss this chance to make an impact on the
GraphQL ecosystem.
-For a detailed overview of the grant scope, application guidelines, and how
-your project can contribute to the GraphQL community, we invite you to visit
+For a detailed overview of the grant scope, application guidelines, and how your
+project can contribute to the GraphQL community, we invite you to visit
[our dedicated program page](https://graphql.org/foundation/community-grant/).
-Join us in shaping the future of GraphQL; [apply
-today](https://graphql.org/foundation/community-grant/) and make your mark!
+Join us in shaping the future of GraphQL;
+[apply today](https://graphql.org/foundation/community-grant/) and make your
+mark!
diff --git a/src/pages/blog/2024-03-12-welcome-copilot.mdx b/src/pages/blog/2024-03-12-welcome-copilot.mdx
index 765613c616..88eb49f887 100644
--- a/src/pages/blog/2024-03-12-welcome-copilot.mdx
+++ b/src/pages/blog/2024-03-12-welcome-copilot.mdx
@@ -5,10 +5,21 @@ date: 2024-03-12
byline: Jory Burson
---
-We're thrilled to announce that Copilot Travel is now a General Member of the GraphQL Foundation. This partnership underscores our shared commitment to driving innovation and collaboration within the GraphQL ecosystem.
+We're thrilled to announce that Copilot Travel is now a General Member of the
+GraphQL Foundation. This partnership underscores our shared commitment to
+driving innovation and collaboration within the GraphQL ecosystem.
-With Copilot Travel's expertise in leveraging cutting-edge technologies to enhance the travel experience, their involvement will undoubtedly enrich our community. Together, we anticipate active participation in working groups, contributions to open-source projects, and collaborative efforts to advance GraphQL adoption across various industries.
+With Copilot Travel's expertise in leveraging cutting-edge technologies to
+enhance the travel experience, their involvement will undoubtedly enrich our
+community. Together, we anticipate active participation in working groups,
+contributions to open-source projects, and collaborative efforts to advance
+GraphQL adoption across various industries.
-At the GraphQL Foundation, we recognize the transformative power of collaboration in shaping the future of technology. With Copilot Travel on board, we're excited to embark on this journey of exploration and innovation, unlocking new possibilities for GraphQL in the connected travel industry.
+At the GraphQL Foundation, we recognize the transformative power of
+collaboration in shaping the future of technology. With Copilot Travel on board,
+we're excited to embark on this journey of exploration and innovation, unlocking
+new possibilities for GraphQL in the connected travel industry.
-Check out our Landscape to learn more about our [Member organizations](https://graphql.org/foundation/members/) and how other companies leverage GraphQL: https://landscape.graphql.org/
+Check out our Landscape to learn more about our
+[Member organizations](https://graphql.org/foundation/members/) and how other
+companies leverage GraphQL: https://landscape.graphql.org/
diff --git a/src/pages/blog/2024-03-28-announcing-graphqlconf-2024.mdx b/src/pages/blog/2024-03-28-announcing-graphqlconf-2024.mdx
index 3746a645b2..a59e328416 100644
--- a/src/pages/blog/2024-03-28-announcing-graphqlconf-2024.mdx
+++ b/src/pages/blog/2024-03-28-announcing-graphqlconf-2024.mdx
@@ -5,37 +5,77 @@ date: 2024-03-28
byline: GraphQL Conference & Event Committee
---
-Inviting innovators, decision-makers, and GraphQL aficionados alike! GraphQL Foundation are thrilled to announce the return of [GraphQLConf](/conf/2024), the much-anticipated official conference for anyone working with GraphQL. After a very successful inaugural conference last year, we are setting the stage for an even bigger event, returning once again to San Francisco — but this time to the heart of this vibrant city! Mark your calendars for September 10-12, 2024, as we invite you to join us at the stunning JW Marriott in San Francisco Union Square for a three-day celebration of learning, innovation, networking, and community.
+Inviting innovators, decision-makers, and GraphQL aficionados alike! GraphQL
+Foundation are thrilled to announce the return of [GraphQLConf](/conf/2024), the
+much-anticipated official conference for anyone working with GraphQL. After a
+very successful inaugural conference last year, we are setting the stage for an
+even bigger event, returning once again to San Francisco — but this time to the
+heart of this vibrant city! Mark your calendars for September 10-12, 2024, as we
+invite you to join us at the stunning JW Marriott in San Francisco Union Square
+for a three-day celebration of learning, innovation, networking, and community.
## 🌟 What To Expect?
-* **Production Insights:** Gain exclusive insights into how leading companies of all sizes are leveraging GraphQL to drive innovation, streamline operations, and enhance their tech stack's efficiency.
-* **Access to Innovators:** GraphQLConf offers a rare opportunity to meet the visionaries and maintainers behind GraphQL's groundbreaking projects. Engage with the minds shaping the future of API technology.
-* **Interactive Workshops:** By popular demand, we’re bringing back a dedicated hands-on workshop day, allowing you to dive deep into practical GraphQL applications and techniques firsthand.
-* **Diverse Perspectives:** If GraphQL is on your radar, this is the place to sharpen your understanding, evaluate its impact, and envision its role in your organization’s future. Whether you're CTO, architect, system integrator, API developer or frontend engineer, if it's about GraphQL, we want to hear from you!
-* **Prime Location:** We're moving from the outskirts to the beating heart of San Francisco! We’ll have the city's dynamic vibe as our backdrop, with plenty of space for gathering, meeting, and collaborating.
+- **Production Insights:** Gain exclusive insights into how leading companies of
+ all sizes are leveraging GraphQL to drive innovation, streamline operations,
+ and enhance their tech stack's efficiency.
+- **Access to Innovators:** GraphQLConf offers a rare opportunity to meet the
+ visionaries and maintainers behind GraphQL's groundbreaking projects. Engage
+ with the minds shaping the future of API technology.
+- **Interactive Workshops:** By popular demand, we’re bringing back a dedicated
+ hands-on workshop day, allowing you to dive deep into practical GraphQL
+ applications and techniques firsthand.
+- **Diverse Perspectives:** If GraphQL is on your radar, this is the place to
+ sharpen your understanding, evaluate its impact, and envision its role in your
+ organization’s future. Whether you're CTO, architect, system integrator, API
+ developer or frontend engineer, if it's about GraphQL, we want to hear from
+ you!
+- **Prime Location:** We're moving from the outskirts to the beating heart of
+ San Francisco! We’ll have the city's dynamic vibe as our backdrop, with plenty
+ of space for gathering, meeting, and collaborating.
## 🔭 Navigating API Innovation
-For technology leaders navigating the complexities of modern API architectures, GraphQLConf 2024 is more than just a conference. It's a strategic platform to foresee industry trends, meet the pioneers, and evaluate how GraphQL can fit into and enhance your technology strategy. Whether you're assessing GraphQL for your next project, looking to optimize existing infrastructures, or keen to foster innovation within your team, GraphQLConf promises a wealth of knowledge and networking opportunities to help steer your decisions in the right direction.
+For technology leaders navigating the complexities of modern API architectures,
+GraphQLConf 2024 is more than just a conference. It's a strategic platform to
+foresee industry trends, meet the pioneers, and evaluate how GraphQL can fit
+into and enhance your technology strategy. Whether you're assessing GraphQL for
+your next project, looking to optimize existing infrastructures, or keen to
+foster innovation within your team, GraphQLConf promises a wealth of knowledge
+and networking opportunities to help steer your decisions in the right
+direction.
## 📢 Call for Proposals (CFP) is OPEN!
-Do you have a big idea, a transformative project, or an insightful case study? We want you on our stage! [The CFP is officially open](/conf/2024), and we’re on the lookout for speakers who can bring fresh perspectives and valuable knowledge to our community. Don't miss this chance to showcase your expertise and contribute to the collective learning of the GraphQL ecosystem. Submit your proposal now—CFP closes on May 22, 2024, at 11:59 pm PDT.
+Do you have a big idea, a transformative project, or an insightful case study?
+We want you on our stage! [The CFP is officially open](/conf/2024), and we’re on
+the lookout for speakers who can bring fresh perspectives and valuable knowledge
+to our community. Don't miss this chance to showcase your expertise and
+contribute to the collective learning of the GraphQL ecosystem. Submit your
+proposal now—CFP closes on May 22, 2024, at 11:59 pm PDT.
## 🎟️ Snag Your Early Bird Tickets!
-Early birds get the worm, or in this case, the best deal on tickets! Early bird registration is open until May 22, offering you the chance to secure your spot at a special rate. Don't wait too long, though - we anticipate a sold-out event!
+Early birds get the worm, or in this case, the best deal on tickets! Early bird
+registration is open until May 22, offering you the chance to secure your spot
+at a special rate. Don't wait too long, though - we anticipate a sold-out event!
## 📅 Mark Your Calendars
-* **CFP Deadline:** May 22, 2024, at 11:59 pm PDT
-* **Early Bird Registration Ends:** May 22, 2024
-* **Schedule Announcement:** June 26, 2024
-* **Event Dates:** September 10-12, 2024
+- **CFP Deadline:** May 22, 2024, at 11:59 pm PDT
+- **Early Bird Registration Ends:** May 22, 2024
+- **Schedule Announcement:** June 26, 2024
+- **Event Dates:** September 10-12, 2024
## 🤝 Get Ready to Connect and Collaborate
-[GraphQLConf 2024](/conf/2024) is not just another tech conference; it's a gathering of diverse and vibrant community members who are passionate about pushing the boundaries of GraphQL and building the future of APIs together. Whether you're a seasoned GraphQL user, or just looking to understand how GraphQL can help your business, GraphQLConf is a can’t-miss opportunity to be part of this ecosystem.
+[GraphQLConf 2024](/conf/2024) is not just another tech conference; it's a
+gathering of diverse and vibrant community members who are passionate about
+pushing the boundaries of GraphQL and building the future of APIs together.
+Whether you're a seasoned GraphQL user, or just looking to understand how
+GraphQL can help your business, GraphQLConf is a can’t-miss opportunity to be
+part of this ecosystem.
-We can't wait to see you in San Francisco! Stay tuned for more updates, and don't forget to check out our conference page [here](/conf/2024) for the latest news and announcements.
+We can't wait to see you in San Francisco! Stay tuned for more updates, and
+don't forget to check out our conference page [here](/conf/2024) for the latest
+news and announcements.
diff --git a/src/pages/blog/2024-05-16-composite-schemas-announcement.mdx b/src/pages/blog/2024-05-16-composite-schemas-announcement.mdx
index 0b6949ae76..0e4e464afe 100644
--- a/src/pages/blog/2024-05-16-composite-schemas-announcement.mdx
+++ b/src/pages/blog/2024-05-16-composite-schemas-announcement.mdx
@@ -2,13 +2,49 @@
title: "Announcing the Composite Schemas Working Group"
tags: ["announcements"]
date: 2024-05-16
-byline: Jeff Auriemma, Benjie Gillam, Michael Staib, Kamil Kisiela, Praveen Durairaju
+byline:
+ Jeff Auriemma, Benjie Gillam, Michael Staib, Kamil Kisiela, Praveen Durairaju
---
-In 2019, Apollo introduced GraphQL Federation as a way of splitting the task of building a GraphQL schema along team boundaries. It proposed a compelling alternative to prior techniques such as schema stitching and delegation, focussing on addressing the collaboration problems inherent in building a coherent schema within a large organization. Federation clearly filled a need and was adopted widely by platform engineers and API developers, a compelling way to compose microservices into a single access layer while retaining service boundaries and team ownership. Solutions from other vendors arose, tackling the same problems in similar ways but with different trade-offs, and some of the world’s largest enterprises have adopted these various patterns and are betting on GraphQL to solve some of their biggest pain points.
+In 2019, Apollo introduced GraphQL Federation as a way of splitting the task of
+building a GraphQL schema along team boundaries. It proposed a compelling
+alternative to prior techniques such as schema stitching and delegation,
+focussing on addressing the collaboration problems inherent in building a
+coherent schema within a large organization. Federation clearly filled a need
+and was adopted widely by platform engineers and API developers, a compelling
+way to compose microservices into a single access layer while retaining service
+boundaries and team ownership. Solutions from other vendors arose, tackling the
+same problems in similar ways but with different trade-offs, and some of the
+world’s largest enterprises have adopted these various patterns and are betting
+on GraphQL to solve some of their biggest pain points.
-Adopting this style of collaboration has become a standard way of creating API platforms, with wide support from an array of vendors. Common patterns and best practices have been established around the various implementations and the underlying architecture has proven effective at scale. Today there are many approaches to collaborative GraphQL schema design, requiring different ways of defining the underlying schemas and composing the resulting architecture; for example Federation and Fusion take an approach that optimizes for collaborative schema composition, whereas Mesh and Hasura prioritize flexibility with a variety of heterogenous services or even databases. API architects are having to make hard decisions early on in their projects, deciding which of the many patterns to follow.
+Adopting this style of collaboration has become a standard way of creating API
+platforms, with wide support from an array of vendors. Common patterns and best
+practices have been established around the various implementations and the
+underlying architecture has proven effective at scale. Today there are many
+approaches to collaborative GraphQL schema design, requiring different ways of
+defining the underlying schemas and composing the resulting architecture; for
+example Federation and Fusion take an approach that optimizes for collaborative
+schema composition, whereas Mesh and Hasura prioritize flexibility with a
+variety of heterogenous services or even databases. API architects are having to
+make hard decisions early on in their projects, deciding which of the many
+patterns to follow.
-Organizations large and small are making huge investments in GraphQL, and those investments are even more sound when they are underwritten by open standards. That’s why the GraphQL Specification Working Group is proud to announce that the Composite Schemas Subcommittee re-convened earlier this year and is making steady progress toward a common specification describing composition and distributed execution across multiple collaborative GraphQL services. The focus is on standardizing common aspects to enable interoperability whilst leaving significant room for innovation so consumers can find the best solution for their needs. Engineers from a wide variety of organizations including Apollo GraphQL, ChilliCream, Google, Graphile, The Guild, Hasura, and IBM have brought their valuable insights to meetings so far; and the community is abuzz with possibilities!
+Organizations large and small are making huge investments in GraphQL, and those
+investments are even more sound when they are underwritten by open standards.
+That’s why the GraphQL Specification Working Group is proud to announce that the
+Composite Schemas Subcommittee re-convened earlier this year and is making
+steady progress toward a common specification describing composition and
+distributed execution across multiple collaborative GraphQL services. The focus
+is on standardizing common aspects to enable interoperability whilst leaving
+significant room for innovation so consumers can find the best solution for
+their needs. Engineers from a wide variety of organizations including Apollo
+GraphQL, ChilliCream, Google, Graphile, The Guild, Hasura, and IBM have brought
+their valuable insights to meetings so far; and the community is abuzz with
+possibilities!
-As with any GraphQL Working Group, anyone is welcome to join and contribute! To get involved, add yourself to an [upcoming agenda](https://github.com/graphql/composite-schemas-wg/tree/main/agendas) or watch all former meetings on the [official YouTube channel](https://www.youtube.com/playlist?list=PLP1igyLx8foFjxyTg6wPn4pUkZwuAk2GR).
+As with any GraphQL Working Group, anyone is welcome to join and contribute! To
+get involved, add yourself to an
+[upcoming agenda](https://github.com/graphql/composite-schemas-wg/tree/main/agendas)
+or watch all former meetings on the
+[official YouTube channel](https://www.youtube.com/playlist?list=PLP1igyLx8foFjxyTg6wPn4pUkZwuAk2GR).
diff --git a/src/pages/blog/2024-06-11-announcing-new-graphql-website/index.mdx b/src/pages/blog/2024-06-11-announcing-new-graphql-website/index.mdx
index 4e1c6d522b..c6e6520daa 100644
--- a/src/pages/blog/2024-06-11-announcing-new-graphql-website/index.mdx
+++ b/src/pages/blog/2024-06-11-announcing-new-graphql-website/index.mdx
@@ -9,8 +9,9 @@ Hi, everyone! I'm [Dimitri Postolov](https://x.com/dimaMachina_) from
[The Guild](https://the-guild.dev), and today I'm excited to announce the new
[graphql.org](/) website.
-2 months ago, we released a new GraphQL website after 8 weeks period of development, we're excited
-to share with you the reasons behind the changes and what you can expect going forward.
+2 months ago, we released a new GraphQL website after 8 weeks period of
+development, we're excited to share with you the reasons behind the changes and
+what you can expect going forward.
## A Little Dive into History
@@ -67,18 +68,18 @@ website's performance and developer experience.
This migration was the final part before releasing the upcoming Nextra version.
You can read my blog post about Nextra 3 in
[The Guild blog](https://the-guild.dev/blog/nextra-3). Recently, we migrated all
-The Guild documentation websites to Nextra 3, so we know it's stable
-for production.
+The Guild documentation websites to Nextra 3, so we know it's stable for
+production.
-While migrating this website, I started work on the
-future Nextra 4 version with [app router support](https://nextjs.org/docs/app).
-Once the first Nextra 4 alpha is out, `graphql.org` will be updated to it!
+While migrating this website, I started work on the future Nextra 4 version with
+[app router support](https://nextjs.org/docs/app). Once the first Nextra 4 alpha
+is out, `graphql.org` will be updated to it!
### New Search Engine
Search was migrated from Algolia to Nextra's built-in search
-[Flexsearch](https://github.com/nextapps-de/flexsearch), providing users
-with realtime results and improved privacy.
+[Flexsearch](https://github.com/nextapps-de/flexsearch), providing users with
+realtime results and improved privacy.
### Light and Dark Themes
@@ -98,8 +99,8 @@ and Libraries". You can read in the
[GitHub repo](https://github.com/graphql/graphql.github.io/blob/source/notes/ContributingToCodePage.md)
how to contribute to this page and add your library or tool.
-[The community](/community) page was redesigned and restructured; now you
-can find all community resources in one place.
+[The community](/community) page was redesigned and restructured; now you can
+find all community resources in one place.
### New [/conf](/conf) Page for GraphQLConf 2024
@@ -111,9 +112,10 @@ More info can be read on [GraphQLConf 2024 page](/conf/2024) or in
## Conclusion
-When I started to learn GraphQL in 2018, I could never have imagined that one day I
-would be working on this migration! I am excited to be a part of this journey
-and to have finally released the new website, a significant improvement over the old one! 🥳
+When I started to learn GraphQL in 2018, I could never have imagined that one
+day I would be working on this migration! I am excited to be a part of this
+journey and to have finally released the new website, a significant improvement
+over the old one! 🥳
Subscribe to me in [X](https://x.com/dimaMachina_) and
[GitHub](https://github.com/dimaMachina) and see you at GraphQLConf 2024 🚀.
diff --git a/src/pages/blog/2024-07-22-jovi-de-croock-graphqljs.mdx b/src/pages/blog/2024-07-22-jovi-de-croock-graphqljs.mdx
index a3d0aca94f..3435002063 100644
--- a/src/pages/blog/2024-07-22-jovi-de-croock-graphqljs.mdx
+++ b/src/pages/blog/2024-07-22-jovi-de-croock-graphqljs.mdx
@@ -5,15 +5,28 @@ date: 2024-07-22
byline: Jory Burson & Benjie Gillam
---
-We are thrilled to announce that Jovi De Croock [@JoviDeCroock](https://github.com/JoviDeCroock) has been approved as a co-maintainer of GraphQL.js!
-Jovi brings a wealth of experience and a deep passion for the GraphQL ecosystem, making him an invaluable addition to the team.
+We are thrilled to announce that Jovi De Croock
+[@JoviDeCroock](https://github.com/JoviDeCroock) has been approved as a
+co-maintainer of GraphQL.js! Jovi brings a wealth of experience and a deep
+passion for the GraphQL ecosystem, making him an invaluable addition to the
+team.
-GraphQL.js is a fundamental library in the GraphQL ecosystem, serving as the reference implementation of the GraphQL specification.
-It provides essential building blocks for defining GraphQL schemas, executing queries, and validating data, making it a critical tool for developers building GraphQL APIs in JavaScript/TypeScript and acting as the backbone of many GraphQL-based applications and services.
-As the reference implementation, it aids anyone wishing to implement GraphQL in another programming language.
-These roles make GraphQL.js pivotal in driving the adoption and evolution of GraphQL technology across the web development community.
+GraphQL.js is a fundamental library in the GraphQL ecosystem, serving as the
+reference implementation of the GraphQL specification. It provides essential
+building blocks for defining GraphQL schemas, executing queries, and validating
+data, making it a critical tool for developers building GraphQL APIs in
+JavaScript/TypeScript and acting as the backbone of many GraphQL-based
+applications and services. As the reference implementation, it aids anyone
+wishing to implement GraphQL in another programming language. These roles make
+GraphQL.js pivotal in driving the adoption and evolution of GraphQL technology
+across the web development community.
-The GraphQL.js maintainers ensure the project's health by managing contributions, reviewing code, addressing issues, and guiding its evolution alongside the GraphQL specification.
-The maintainer role is vital in ensuring the quality, security, and relevance of the software, fostering a collaborative environment, and engaging with the community.
+The GraphQL.js maintainers ensure the project's health by managing
+contributions, reviewing code, addressing issues, and guiding its evolution
+alongside the GraphQL specification. The maintainer role is vital in ensuring
+the quality, security, and relevance of the software, fostering a collaborative
+environment, and engaging with the community.
-Please join us in welcoming Jovi De Croock to the GraphQL.js team, and join us for an upcoming [GraphQL.js Working Group meeting](https://github.com/graphql/graphql-js-wg/blob/main/README.md)!
+Please join us in welcoming Jovi De Croock to the GraphQL.js team, and join us
+for an upcoming
+[GraphQL.js Working Group meeting](https://github.com/graphql/graphql-js-wg/blob/main/README.md)!
diff --git a/src/pages/blog/2024-09-19-codegen.mdx b/src/pages/blog/2024-09-19-codegen.mdx
index 83aee20e5e..9d7a724381 100644
--- a/src/pages/blog/2024-09-19-codegen.mdx
+++ b/src/pages/blog/2024-09-19-codegen.mdx
@@ -5,9 +5,12 @@ date: 2024-09-19
byline: Martin Bonnin
---
-A GraphQL endpoint usually returns a JSON payload. While you can use the result as a dynamic object, the GraphQL type system gives us a lot of information about what is inside that JSON payload.
+A GraphQL endpoint usually returns a JSON payload. While you can use the result
+as a dynamic object, the GraphQL type system gives us a lot of information about
+what is inside that JSON payload.
-If you're not using code generation, you're missing out on a lot, especially if you're using a type-safe language such as TypeScript, Swift or Kotlin.
+If you're not using code generation, you're missing out on a lot, especially if
+you're using a type-safe language such as TypeScript, Swift or Kotlin.
By using code generation, you get:
@@ -16,9 +19,14 @@ By using code generation, you get:
All of that without having to write and maintain types manually!
-For simplicity, this post uses TypeScript for code blocks but the same concepts can be applied to Swift/Kotlin.
+For simplicity, this post uses TypeScript for code blocks but the same concepts
+can be applied to Swift/Kotlin.
-A common mistake is to attempt to use the GraphQL schema directly for type generation, but this is not type-safe since GraphQL only returns the fields that you ask for, and allows you to alias fields in the response. Instead, types should be generated based on the GraphQL operations (requests) that you issue. Here's an illustration of the issue:
+A common mistake is to attempt to use the GraphQL schema directly for type
+generation, but this is not type-safe since GraphQL only returns the fields that
+you ask for, and allows you to alias fields in the response. Instead, types
+should be generated based on the GraphQL operations (requests) that you issue.
+Here's an illustration of the issue:
## Problem: Generating code from schema types loses nullability information
@@ -44,7 +52,6 @@ type Product {
price: Float
}
-
type Query {
products: [Product!]!
}
@@ -55,14 +62,15 @@ A translation to TypeScript might yield the following:
```typescript
// First attempt at generating code from the product type
type Product = {
- id: string;
- name: string;
- description: string | null;
- price: string | null
+ id: string
+ name: string
+ description: string | null
+ price: string | null
}
```
-Pretty neat, right? Typescript and GraphQL look really similar... Unfortunately, this is not type safe!
+Pretty neat, right? Typescript and GraphQL look really similar... Unfortunately,
+this is not type safe!
Let's perform a query that doesn't request the product name:
@@ -87,7 +95,8 @@ Returned product:
}
```
-It's now impossible to map that returned value to our type because `name` must be non-null.
+It's now impossible to map that returned value to our type because `name` must
+be non-null.
We can also apply aliases:
@@ -113,15 +122,20 @@ Returned product:
}
```
-Note that the `productName`, despite being non-null, does not match up with the expected `name` field.
+Note that the `productName`, despite being non-null, does not match up with the
+expected `name` field.
-We simply cannot safely use the schema types to represent requests unless we fetch every single field on every single type, which would go against GraphQL's very nature!
+We simply cannot safely use the schema types to represent requests unless we
+fetch every single field on every single type, which would go against GraphQL's
+very nature!
-Thankfully, we can solve this by generating code based on operations instead (queries, mutations, and subscriptions).
+Thankfully, we can solve this by generating code based on operations instead
+(queries, mutations, and subscriptions).
## Solution: Generating code from GraphQL operations
-By generating code from GraphQL operations, we are now certain that the TypeScript fields always represent GraphQL fields that have been requested.
+By generating code from GraphQL operations, we are now certain that the
+TypeScript fields always represent GraphQL fields that have been requested.
Reusing our first example:
@@ -153,18 +167,27 @@ type GetProductData_products = {
With this `GetProductData_products` type:
-* `name` is not present in the generated type because it was not queried.
-* `id` is not-nullable, as intended. A product always has an `id`.
-* `description` and `price` are nullable, as intended. If `null`, it means the product doesn't have a description/price.
+- `name` is not present in the generated type because it was not queried.
+- `id` is not-nullable, as intended. A product always has an `id`.
+- `description` and `price` are nullable, as intended. If `null`, it means the
+ product doesn't have a description/price.
This is what we expected!
## Conclusion
-By using code generation based on operations, you get type safety from your backend all the way to your UI. On top of that, your IDE can use the generated code to provide autocomplete and a better experience overall.
+By using code generation based on operations, you get type safety from your
+backend all the way to your UI. On top of that, your IDE can use the generated
+code to provide autocomplete and a better experience overall.
-All the major code generators ([graphql-code-generator](https://github.com/dotansimha/graphql-code-generator), [Relay](https://relay.dev/), [Apollo iOS](https://github.com/apollographql/apollo-ios), [Apollo Kotlin](https://github.com/apollographql/apollo-kotlin), ...) generate code based on operations.
+All the major code generators
+([graphql-code-generator](https://github.com/dotansimha/graphql-code-generator),
+[Relay](https://relay.dev/),
+[Apollo iOS](https://github.com/apollographql/apollo-ios),
+[Apollo Kotlin](https://github.com/apollographql/apollo-kotlin), ...) generate
+code based on operations.
If you have not already, try them out!
-And look out for a new post soon on the improvements we're hoping to bring to GraphQL nullability!
+And look out for a new post soon on the improvements we're hoping to bring to
+GraphQL nullability!
diff --git a/src/pages/blog/2024-10-08-graphql-conf-2024-wrap/index.mdx b/src/pages/blog/2024-10-08-graphql-conf-2024-wrap/index.mdx
index 3c3c88adcc..01ccb40702 100644
--- a/src/pages/blog/2024-10-08-graphql-conf-2024-wrap/index.mdx
+++ b/src/pages/blog/2024-10-08-graphql-conf-2024-wrap/index.mdx
@@ -5,39 +5,91 @@ date: 2024-10-08
byline: GraphQL Events Committee
---
-We’re (almost) recuperated from all the excellent talks, socializing, and networking that went down at [GraphQL Conf 2024](https://graphql.org/conf/2024/). It was an event that celebrated the community, and brought GraphQL contributors, Working Group members, and nearly every single TSC member together under one roof for the first time in… a while. Read on for a round-up of the biggest news and takeaways from the conference.
+We’re (almost) recuperated from all the excellent talks, socializing, and
+networking that went down at
+[GraphQL Conf 2024](https://graphql.org/conf/2024/). It was an event that
+celebrated the community, and brought GraphQL contributors, Working Group
+members, and nearly every single TSC member together under one roof for the
+first time in… a while. Read on for a round-up of the biggest news and takeaways
+from the conference.
## GraphQL Is Still Expanding
-Although GraphQL was originally created to solve the needs of the front-end developer, it has proven its staying power as a tool for all kinds of applications and use cases. For example, GraphQL naturally complements LLMs - several talks highlighted applications for generative AI, AI integrations, and data mesh networks. As Lee Byron noted in his [welcoming keynote](https://youtu.be/ZJHSCyZCup4), GraphQL reached ubiquity and continues to expand as developers discover new ways to apply it to new contexts.
+
+Although GraphQL was originally created to solve the needs of the front-end
+developer, it has proven its staying power as a tool for all kinds of
+applications and use cases. For example, GraphQL naturally complements LLMs -
+several talks highlighted applications for generative AI, AI integrations, and
+data mesh networks. As Lee Byron noted in his
+[welcoming keynote](https://youtu.be/ZJHSCyZCup4), GraphQL reached ubiquity and
+continues to expand as developers discover new ways to apply it to new contexts.
## Distributed GraphQL has arrived
-Distributed GraphQL including Federation was the talk of the conference. We heard about the state of distributed GraphQL from TSC leaders, case studies on production deployment from end-users, and design principles for federated GraphQL from core contributors. Expect to hear a lot more about distributed GraphQL deployments over the next year.
+
+Distributed GraphQL including Federation was the talk of the conference. We
+heard about the state of distributed GraphQL from TSC leaders, case studies on
+production deployment from end-users, and design principles for federated
+GraphQL from core contributors. Expect to hear a lot more about distributed
+GraphQL deployments over the next year.
## Have You Heard the Word About Trusted Documents
-Data and application security are as relevant as ever. Our own plucky, GraphQL Community Gardener Benjie Gillam was on hand to tell attendees about one easy thing they can do to harden their GraphQL security posture and boost performance - use Trusted Documents! If you’re already using Trusted Documents, check out [Top 10 GraphQL Security Checks for Every Developer](https://youtu.be/fA81OFu9BVY).
+
+Data and application security are as relevant as ever. Our own plucky, GraphQL
+Community Gardener Benjie Gillam was on hand to tell attendees about one easy
+thing they can do to harden their GraphQL security posture and boost
+performance - use Trusted Documents! If you’re already using Trusted Documents,
+check out
+[Top 10 GraphQL Security Checks for Every Developer](https://youtu.be/fA81OFu9BVY).
-## Our Community had an Amazing Time
-Between the excellent content and workshops, focused unconference sessions, Working Group member chats, TSC and Board meetings, and quality bond-building between attendees, we made the most out of our short time together. We can’t wait to do it again, and are so thankful for our sponsors and attendees for making it all happen. In the words of a few of our attendees:
+## Our Community had an Amazing Time
-*“As a beginner in GraphQL, it was very helpful to see real use cases and honest accounts of the challenges along the way. I learned a lot about performance and security and had a great opportunity to network with other participants and potential vendors." - Nicolai Draslov, Danish Agency for Digital Government*
+Between the excellent content and workshops, focused unconference sessions,
+Working Group member chats, TSC and Board meetings, and quality bond-building
+between attendees, we made the most out of our short time together. We can’t
+wait to do it again, and are so thankful for our sponsors and attendees for
+making it all happen. In the words of a few of our attendees:
-*"Great community. It's the first conference I've been to where multiple people remembered me from previous conferences."*
+_“As a beginner in GraphQL, it was very helpful to see real use cases and honest
+accounts of the challenges along the way. I learned a lot about performance and
+security and had a great opportunity to network with other participants and
+potential vendors." - Nicolai Draslov, Danish Agency for Digital Government_
-*"GraphQL is evolving to new use cases every day and it's really a competitive advantage to experience them first hand with everyone that matters. I look forward the next edition!" - Vincent Desmares, Teamstarter*
+_"Great community. It's the first conference I've been to where multiple people
+remembered me from previous conferences."_
-*"GraphQLConf 24 was a well organized event that empowered new and existing organizations to adopt GraphQL, navigating how to rollout GraphQL within their organizations by building understanding of eco-system." - Satish Chitnis*
+_"GraphQL is evolving to new use cases every day and it's really a competitive
+advantage to experience them first hand with everyone that matters. I look
+forward the next edition!" - Vincent Desmares, Teamstarter_
+
+_"GraphQLConf 24 was a well organized event that empowered new and existing
+organizations to adopt GraphQL, navigating how to rollout GraphQL within their
+organizations by building understanding of eco-system." - Satish Chitnis_
## GraphQL Conf 2025 is coming to Europe!
-Lee Byron shared that the GraphQL Foundation Board is committed to hosting the next edition of GraphQL Conf somewhere in Europe in 2025. Planning is still in the early stages, so stay tuned, but this was welcome news for the dozens of community members who flew in from as far away as Belgium to join us in San Francisco.
+
+Lee Byron shared that the GraphQL Foundation Board is committed to hosting the
+next edition of GraphQL Conf somewhere in Europe in 2025. Planning is still in
+the early stages, so stay tuned, but this was welcome news for the dozens of
+community members who flew in from as far away as Belgium to join us in San
+Francisco.
**Interested in getting involved? Drop a line to graphqlconf@graphql.org!**
-If you want to relive the experience of GraphQL Conf or just re-watch and share a favorite talk, you can check out all the [photos](https://www.flickr.com/photos/linuxfoundation/albums/72177720320386221/) and [videos](https://graphql.org/conf/2024/schedule/) on our conference website. Subscribe to our [Working Group YouTube](https://www.youtube.com/@GraphQLFoundation), new [Foundation Events YouTube](https://www.youtube.com/@GraphQLFoundationTalks), [X](https://twitter.com/graphql), and [LinkedIn](https://www.linkedin.com/company/graphql-foundation/) channels to get content you may have missed and find out when we launch the new GraphQL Conf 2025 website!
+If you want to relive the experience of GraphQL Conf or just re-watch and share
+a favorite talk, you can check out all the
+[photos](https://www.flickr.com/photos/linuxfoundation/albums/72177720320386221/)
+and [videos](https://graphql.org/conf/2024/schedule/) on our conference website.
+Subscribe to our
+[Working Group YouTube](https://www.youtube.com/@GraphQLFoundation), new
+[Foundation Events YouTube](https://www.youtube.com/@GraphQLFoundationTalks),
+[X](https://twitter.com/graphql), and
+[LinkedIn](https://www.linkedin.com/company/graphql-foundation/) channels to get
+content you may have missed and find out when we launch the new GraphQL Conf
+2025 website!
diff --git a/src/pages/blog/announcing-graphqlconf-2025-amsterdam-awaits.mdx b/src/pages/blog/announcing-graphqlconf-2025-amsterdam-awaits.mdx
index a5efcfb460..dc989ac168 100644
--- a/src/pages/blog/announcing-graphqlconf-2025-amsterdam-awaits.mdx
+++ b/src/pages/blog/announcing-graphqlconf-2025-amsterdam-awaits.mdx
@@ -5,9 +5,15 @@ date: 2024-12-18
byline: GraphQL Foundation
---
-Mark your calendars - **GraphQLConf** is set to take place in the vibrant and historic city of **Amsterdam, Netherlands**, on **September 8-10, 2025**!
+Mark your calendars - **GraphQLConf** is set to take place in the vibrant and
+historic city of **Amsterdam, Netherlands**, on **September 8-10, 2025**!
-After a successful 2024 event, we’re thrilled to announce that GraphQLConf is heading to Europe for the very first time in 2025! This milestone reflects an overwhelming interest and passion from the European developer community, making GraphQL more accessible for developers and innovators worldwide. Get ready to immerse yourself in three days of learning, connecting, and celebrating the GraphQL ecosystem with a truly diverse, international community.
+After a successful 2024 event, we’re thrilled to announce that GraphQLConf is
+heading to Europe for the very first time in 2025! This milestone reflects an
+overwhelming interest and passion from the European developer community, making
+GraphQL more accessible for developers and innovators worldwide. Get ready to
+immerse yourself in three days of learning, connecting, and celebrating the
+GraphQL ecosystem with a truly diverse, international community.
---
@@ -15,45 +21,68 @@ After a successful 2024 event, we’re thrilled to announce that GraphQLConf is
#### **🚀 High-Quality Content**
-Hear from the pioneers of GraphQL and influential thought leaders shaping the future of APIs and developer experience. From the original creators to cutting-edge contributors, our stage will host the best minds in the industry.
+Hear from the pioneers of GraphQL and influential thought leaders shaping the
+future of APIs and developer experience. From the original creators to
+cutting-edge contributors, our stage will host the best minds in the industry.
#### **💡 Hands-On Workshops**
-Level up your GraphQL skills with immersive, hands-on workshops. Whether you're a beginner or a seasoned pro, we’ll have sessions tailored to help you build faster, query smarter, and optimize better.
+Level up your GraphQL skills with immersive, hands-on workshops. Whether you're
+a beginner or a seasoned pro, we’ll have sessions tailored to help you build
+faster, query smarter, and optimize better.
#### **🌐 Community Connections**
-Network with developers, maintainers, and contributors from around the world. The conference will feature meetups, collaboration zones, and plenty of space to share ideas.
+Network with developers, maintainers, and contributors from around the world.
+The conference will feature meetups, collaboration zones, and plenty of space to
+share ideas.
#### **🎉 A Memorable Venue**
-Amsterdam offers a perfect blend of historic charm and modern innovation. From the canals to the cutting-edge tech scene, the city provides an inspiring backdrop for this year’s event.
+Amsterdam offers a perfect blend of historic charm and modern innovation. From
+the canals to the cutting-edge tech scene, the city provides an inspiring
+backdrop for this year’s event.
---
### **Why Amsterdam?**
-As one of Europe’s most tech-forward cities, Amsterdam is an innovative environment with a thriving GraphQL developer community. Its central location makes it easily accessible for attendees from across Europe and beyond. Plus, its rich culture and welcoming vibe ensure you’ll leave with more than just new knowledge—you’ll have memories to last a lifetime.
+As one of Europe’s most tech-forward cities, Amsterdam is an innovative
+environment with a thriving GraphQL developer community. Its central location
+makes it easily accessible for attendees from across Europe and beyond. Plus,
+its rich culture and welcoming vibe ensure you’ll leave with more than just new
+knowledge—you’ll have memories to last a lifetime.
---
### **Save the Date & Get Your Ticket**
-📅 **When?** September 8-10, 2025
+📅 **When?** September 8-10, 2025
- 📍 **Where?** [Pakhuis de Zwijger](https://maps.app.goo.gl/FoJG5KrjrM7U9Pva6) - Amsterdam, Netherlands
+📍 **Where?** [Pakhuis de Zwijger](https://maps.app.goo.gl/FoJG5KrjrM7U9Pva6) -
+Amsterdam, Netherlands
-Mark your calendars and secure your spot at the best rates - [early bird registration](https://cvent.me/PBNYEe) is a great way to spend any remaining 2024 budget!
+Mark your calendars and secure your spot at the best rates -
+[early bird registration](https://cvent.me/PBNYEe) is a great way to spend any
+remaining 2024 budget!
---
### **Get Involved**
-Want to help shape the GraphQLConf 2025 experience? Here’s how you can participate:
+Want to help shape the GraphQLConf 2025 experience? Here’s how you can
+participate:
-* **[Speak at the Event](https://forms.gle/jRsE2u8pokLX93RGA)**: We’re looking for diverse voices to share innovative ideas, technical insights, and real-world GraphQL success stories. Our CFP will open in early 2025.
-* **[Become a Sponsor](https://events.linuxfoundation.org/wp-content/uploads/2024/12/sponsor_GraphQLConf_2025.pdf)**: Align your brand with the global GraphQL community and connect with influential developers. As a GraphQLConf sponsor, you’ll be an authoritative voice on cutting edge API topics.
-* **[Join the Community Team](https://forms.gle/jRsE2u8pokLX93RGA)**: Help us make the event unforgettable and highly relevant by volunteering with our programming committee or hosting local meetups leading up to the conference.
+- **[Speak at the Event](https://forms.gle/jRsE2u8pokLX93RGA)**: We’re looking
+ for diverse voices to share innovative ideas, technical insights, and
+ real-world GraphQL success stories. Our CFP will open in early 2025.
+- **[Become a Sponsor](https://events.linuxfoundation.org/wp-content/uploads/2024/12/sponsor_GraphQLConf_2025.pdf)**:
+ Align your brand with the global GraphQL community and connect with
+ influential developers. As a GraphQLConf sponsor, you’ll be an authoritative
+ voice on cutting edge API topics.
+- **[Join the Community Team](https://forms.gle/jRsE2u8pokLX93RGA)**: Help us
+ make the event unforgettable and highly relevant by volunteering with our
+ programming committee or hosting local meetups leading up to the conference.
Questions about getting involved? Send us a note at graphqlconf@graphql.org.
@@ -61,6 +90,10 @@ Questions about getting involved? Send us a note at graphqlconf@graphql.org.
### **Follow for Updates**
-Stay connected for announcements about speakers, schedules, and registration. Follow us on [Bluesky](https://bsky.app/profile/graphql.org), [Twitter/X](https://twitter.com/GraphQLConf) and[LinkedIn](https://linkedin.com/company/graphqlconf) and join the conversation with #GraphQLConf2025.
+Stay connected for announcements about speakers, schedules, and registration.
+Follow us on [Bluesky](https://bsky.app/profile/graphql.org),
+[Twitter/X](https://twitter.com/GraphQLConf)
+and[LinkedIn](https://linkedin.com/company/graphqlconf) and join the
+conversation with #GraphQLConf2025.
We can’t wait to see you in Amsterdam!
diff --git a/src/pages/brand.mdx b/src/pages/brand.mdx
index 243a23271c..fdb8482292 100644
--- a/src/pages/brand.mdx
+++ b/src/pages/brand.mdx
@@ -1,80 +1,87 @@
-import { Rubik } from 'next/font/google'
-import NextImage from 'next-image-export-optimizer'
-import { useState } from 'react'
-import graphqlLogo from '../../public/img/logo.svg'
-import graphqlLogoWhite from '../../public/img/brand/logos/logo-white.svg'
-import graphqlLogoBlack from '../../public/img/brand/logos/logo-black.svg'
-import graphqlLogoDontColor from '../../public/img/brand/logo-dont/dont-color.svg'
-import graphqlLogoDontGradient from '../../public/img/brand/logo-dont/dont-gradient.svg'
-import graphqlLogoDontWordmark from '../../public/img/brand/logo-dont/dont-color-wordmark.svg'
+import { Rubik } from "next/font/google"
+import NextImage from "next-image-export-optimizer"
+import { useState } from "react"
+import graphqlLogo from "../../public/img/logo.svg"
+import graphqlLogoWhite from "../../public/img/brand/logos/logo-white.svg"
+import graphqlLogoBlack from "../../public/img/brand/logos/logo-black.svg"
+import graphqlLogoDontColor from "../../public/img/brand/logo-dont/dont-color.svg"
+import graphqlLogoDontGradient from "../../public/img/brand/logo-dont/dont-gradient.svg"
+import graphqlLogoDontWordmark from "../../public/img/brand/logo-dont/dont-color-wordmark.svg"
export const font = Rubik({
- weight: ['300'],
- subsets: ['latin']
+ weight: ["300"],
+ subsets: ["latin"]
})
# GraphQL Logo & Brand Guidelines
-Here you'll find dos and don’ts for use of the GraphQL brand and
-GraphQL logo files in supported arrangement and colors.
+Here you'll find dos and don’ts for use of the GraphQL brand and GraphQL logo
+files in supported arrangement and colors.
-"GraphQL" is a trademark managed by the [GraphQL Foundation](/foundation).
-Use of the trademark and logo are subject to the
+"GraphQL" is a trademark managed by the [GraphQL Foundation](/foundation). Use
+of the trademark and logo are subject to the
[LF Projects trademark policy](https://lfprojects.org/policies/trademark-policy).
Certain fair use of the GraphQL mark are pre-approved, such as factual
-references to the project. Others require permission first, such as
-apparel for sale or any other commercial purpose, using the word
-GraphQL in domain names, or using the mark on printed materials, to
-name a few. You can find a more comprehensive list in the trademark
-policy.
+references to the project. Others require permission first, such as apparel for
+sale or any other commercial purpose, using the word GraphQL in domain names, or
+using the mark on printed materials, to name a few. You can find a more
+comprehensive list in the trademark policy.
-Please email [info@graphql.org](mailto:info@graphql.org?subject=Trademark%20Request) with any questions or requests.
+Please email
+[info@graphql.org](mailto:info@graphql.org?subject=Trademark%20Request) with any
+questions or requests.
## The GraphQL™ Trademark
-The word "GraphQL" may only be used to refer to the GraphQL project
-and technologies which conform to the [GraphQL specification](https://spec.graphql.org).
+The word "GraphQL" may only be used to refer to the GraphQL project and
+technologies which conform to the
+[GraphQL specification](https://spec.graphql.org).
<style global jsx>{`
-.rhodamine-sample {
- font-family: ${font.style.fontFamily};
- font-weight: ${font.style.fontWeight};
- padding: 1em;
-}
-.rhodamine-sample a { color: inherit; }
-.rhodamine-sample dl dd { grid-column-start: 2; }
-.rhodamine-sample dl {
- margin: 0.5em 0;
- font-size: .9rem;
- line-height: 1.5;
- display: grid;
- grid-template-columns: 1fr 3fr;
-}
-.rhodamine-sample dl dt {
- grid-column-start: 1;
- padding-right: 2em;
-}
+ .rhodamine-sample {
+ font-family: ${font.style.fontFamily};
+ font-weight: ${font.style.fontWeight};
+ padding: 1em;
+ }
+ .rhodamine-sample a {
+ color: inherit;
+ }
+ .rhodamine-sample dl dd {
+ grid-column-start: 2;
+ }
+ .rhodamine-sample dl {
+ margin: 0.5em 0;
+ font-size: 0.9rem;
+ line-height: 1.5;
+ display: grid;
+ grid-template-columns: 1fr 3fr;
+ }
+ .rhodamine-sample dl dt {
+ grid-column-start: 1;
+ padding-right: 2em;
+ }
`}</style>
<div className="grid md:grid-cols-2 md:gap-5">
-<div className="dos">
-- _Do_ keep the "GraphQL" word consistent, with the first letter and QL capitalized.
-- _Do_ use "GraphQL" to clearly describe the GraphQL project or a conforming technology.
- - GraphQL for Go
- - Quick Start to GraphQL by <company>
-- _Do_ provide clear attribution for projects, services and events, balancing "GraphQL" with your own brand.
- - <service> for GraphQL by <company>
- - Seattle GraphQL Meetup hosted by <company>
-</div>
-<div className="donts">
-- _Don't_ lowercase or abbreviate "GraphQL" (for example "Graphql" or "GQL").
-- _Don't_ directly combine “GraphQL” with another trademark or generic term.
- - Go GraphQL
- - GraphQL Quick Start by <company>
-- _Don't_ use "GraphQL" in a way that could imply partnership, sponsorship, or endorsement by the GraphQL project or GraphQL Foundation either directly or by omission.
-- _Don't_ use the GraphQL brand disparagingly or in any other way that violates our [code of conduct](/codeofconduct).
-</div>
+ <div className="dos">
+ - _Do_ keep the "GraphQL" word consistent, with the first letter and QL
+ capitalized. - _Do_ use "GraphQL" to clearly describe the GraphQL project or
+ a conforming technology. - GraphQL for Go - Quick Start to GraphQL by
+ <company> - _Do_ provide clear attribution for projects, services and
+ events, balancing "GraphQL" with your own brand. - <service> for
+ GraphQL by <company> - Seattle GraphQL Meetup hosted by
+ <company>
+ </div>
+ <div className="donts">
+ - _Don't_ lowercase or abbreviate "GraphQL" (for example "Graphql" or
+ "GQL"). - _Don't_ directly combine “GraphQL” with another trademark or
+ generic term. - Go GraphQL - GraphQL Quick Start by <company> -
+ _Don't_ use "GraphQL" in a way that could imply partnership, sponsorship, or
+ endorsement by the GraphQL project or GraphQL Foundation either directly or
+ by omission. - _Don't_ use the GraphQL brand disparagingly or in any other
+ way that violates our [code of conduct](/codeofconduct).
+ </div>
</div>
## Color & Typeface
@@ -83,100 +90,128 @@ Our core color is called Rhodamine.
The GraphQL wordmark and headlines are set in Rubik Light.
-<div className="flex gap-5 mt-6 max-sm:flex-col">
-<div className="rhodamine-sample bg-primary text-lg text-white">
-Rhodamine
-<dl>
- <dt>P3</dt><dd>0.8824, 0, 0.5961</dd>
- <dt>RGB</dt><dd>225, 0, 152 / #E10098</dd>
- <dt>PMS</dt><dd>[Rhodamine Red C](https://pantone.com/color-finder/Rhodamine-Red-C)</dd>
- <dt>CMYK</dt><dd>5, 92, 0, 0</dd>
-</dl>
-</div>
-<div className="rhodamine-sample bg-gray-100 dark:text-black">
-[Rubik Light](https://fonts.google.com/specimen/Rubik?sidebar.open=true&selection.family=Rubik:wght@300&preview.text=GraphQL&preview.text_type=custom)
-<dl>
- <dt>Weight</dt><dd>300</dd>
- <dt>License</dt><dd>[Open Font License](https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL)</dd>
-</dl>
-<div className="text-4xl">GraphQL ÅBCørm123</div>
-</div>
+<div className="mt-6 flex gap-5 max-sm:flex-col">
+ <div className="rhodamine-sample bg-primary text-lg text-white">
+ Rhodamine
+ <dl>
+ <dt>P3</dt>
+ <dd>0.8824, 0, 0.5961</dd>
+ <dt>RGB</dt>
+ <dd>225, 0, 152 / #E10098</dd>
+ <dt>PMS</dt>
+ <dd>
+ [Rhodamine Red C](https://pantone.com/color-finder/Rhodamine-Red-C)
+ </dd>
+ <dt>CMYK</dt>
+ <dd>5, 92, 0, 0</dd>
+ </dl>
+ </div>
+ <div className="rhodamine-sample bg-gray-100 dark:text-black">
+ [Rubik
+ Light](https://fonts.google.com/specimen/Rubik?sidebar.open=true&selection.family=Rubik:wght@300&preview.text=GraphQL&preview.text_type=custom)
+ <dl>
+ <dt>Weight</dt>
+ <dd>300</dd>
+ <dt>License</dt>
+ <dd>
+ [Open Font
+ License](https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL)
+ </dd>
+ </dl>
+ <div className="text-4xl">GraphQL ÅBCørm123</div>
+ </div>
</div>
<div className="grid md:grid-cols-2 md:gap-5">
-<div className="dos">
-- _Do_ use Rhodamine alongside grayscale or neutral colors.
-- _Do_ prefer the P3 wide gamut color over RGB in digital; the PMS spot color over CMYK process in print.
-- _Do_ use Rubik Light with optical kerning and standard letter spacing.
-</div>
-<div className="donts">
-- _Don't_ use Rhodamine for large background areas.
-- _Don't_ directly combine Rhodamine with other bright or saturated colors.
-- _Don't_ bold, italicize, or alter the letter spacing of the GraphQL wordmark.
-</div>
+ <div className="dos">
+ - _Do_ use Rhodamine alongside grayscale or neutral colors. - _Do_ prefer
+ the P3 wide gamut color over RGB in digital; the PMS spot color over CMYK
+ process in print. - _Do_ use Rubik Light with optical kerning and
+ standard letter spacing.
+ </div>
+ <div className="donts">
+ - _Don't_ use Rhodamine for large background areas. - _Don't_ directly
+ combine Rhodamine with other bright or saturated colors. - _Don't_ bold,
+ italicize, or alter the letter spacing of the GraphQL wordmark.
+ </div>
</div>
## GraphQL Logo & Hexagraph
-Our logomark is called the "hexagraph". The GraphQL logo is composed
-of the hexagraph and the GraphQL wordmark set in Rubik Light.
+Our logomark is called the "hexagraph". The GraphQL logo is composed of the
+hexagraph and the GraphQL wordmark set in Rubik Light.
-<div className="flex gap-3 [&_img]:min-w-0 mt-6">
- <div className="bg-gray-100 flex p-4 sm:p-10">
- <></>
+<div className="mt-6 flex gap-3 [&_img]:min-w-0">
+ <div className="flex bg-gray-100 p-4 sm:p-10">
+ <></>
</div>
- <div className="flex bg-gray-100 p-4 sm:p-10 gap-4 sm:gap-10">
+ <div className="flex gap-4 bg-gray-100 p-4 sm:gap-10 sm:p-10">
<div className="flex flex-col gap-4 sm:gap-10">
<></>
- <></>
+ <>
+ 
+ </>
</div>
<div className="flex gap-4 sm:gap-10">
<></>
- <></>
+ <>
+ 
+ </>
</div>
</div>
</div>
<div className="dos">
-- _Do_ prefer the horizontal logo, but use the stacked logo at larger sizes.
-- _Do_ use the provided assets, don't redraw the hexgraph.
+ - _Do_ prefer the horizontal logo, but use the stacked logo at larger sizes. -
+ _Do_ use the provided assets, don't redraw the hexgraph.
</div>
<div className="donts donts-images">
-- <div>_Don't_ rotate or stretch the hexagraph. Position the inner triangle pointing upwards.</div>
-<></>
-<></>
-- <div>_Don't_ remove or add any elements within the hexagraph, or combine with another logo.</div>
-<></>
-<></>
-- <div>_Don't_ decorate or add effects to any part of the logo.</div>
-<></>
-<></>
-- <div>_Don't_ resize or reposition elements of the hexagraph.</div>
-<></>
-<></>
-- <div>_Don't_ resize or reposition the wordmark relative to the hexagraph.</div>
-<></>
-- <div>_Don't_ change the typeface of the wordmark.</div>
-<></>
+ -{" "}
+ <div>
+ _Don't_ rotate or stretch the hexagraph. Position the inner triangle
+ pointing upwards.
+ </div>
+ <></>
+ <></>-{" "}
+ <div>
+ _Don't_ remove or add any elements within the hexagraph, or combine with
+ another logo.
+ </div>
+ <></>
+ <></>-{" "}
+ <div>_Don't_ decorate or add effects to any part of the logo.</div>
+ <></>
+ <></>-{" "}
+ <div>_Don't_ resize or reposition elements of the hexagraph.</div>
+ <></>
+ <></>-{" "}
+ <div>
+ _Don't_ resize or reposition the wordmark relative to the hexagraph.
+ </div>
+ <></>-{" "}
+ <div>_Don't_ change the typeface of the wordmark.</div>
+ <></>
</div>
### Spacing
-Give the logo some space to breathe. Keep a clear space of at least
-half the height of the hexagraph along on all sides.
+Give the logo some space to breathe. Keep a clear space of at least half the
+height of the hexagraph along on all sides.
-<div className="mt-6 flex flex-wrap justify-center *:max-h-36 *:w-auto gap-9">
+<div className="mt-6 flex flex-wrap justify-center gap-9 *:max-h-36 *:w-auto">
<></>
<></>
</div>
### Color use
-The GraphQL logo should appear in Rhodamine, white, or black. It may
-appear on any color background with the appropriate logo color.
+The GraphQL logo should appear in Rhodamine, white, or black. It may appear on
+any color background with the appropriate logo color.
-<div className="*:rounded-full mt-6 bg-gray-100 p-6 flex gap-6 *:p-6 flex-wrap justify-center">
+<div className="mt-6 flex flex-wrap justify-center gap-6 bg-gray-100 p-6 *:rounded-full *:p-6">
<NextImage src={graphqlLogo} className="bg-white" />
<NextImage src={graphqlLogo} className="bg-gray-300" />
<NextImage src={graphqlLogo} className="bg-black" />
@@ -187,40 +222,45 @@ appear on any color background with the appropriate logo color.
</div>
<div className="dos">
-- _Do_ prefer Rhodamine on a white background, our default color combination.
-- _Do_ otherwise prefer use the white logo on most backgrounds unless contrast requires use of black.
+ - _Do_ prefer Rhodamine on a white background, our default color combination.
+ - _Do_ otherwise prefer use the white logo on most backgrounds unless contrast
+ requires use of black.
</div>
-<div className="*:h-[100px] *:w-auto *:rounded-full mt-6 bg-gray-100 p-6 inline-flex gap-6 *:p-6 flex-wrap justify-center">
+<div className="mt-6 inline-flex flex-wrap justify-center gap-6 bg-gray-100 p-6 *:h-[100px] *:w-auto *:rounded-full *:p-6">
<NextImage src={graphqlLogoBlack} className="bg-primary" />
<NextImage src={graphqlLogo} className="bg-cyan-400" />
- <NextImage src={graphqlLogo} className="bg-[url(/img/brand/logo-dont/dont-complex-background.jpg)]" />
+ <NextImage
+ src={graphqlLogo}
+ className="bg-[url(/img/brand/logo-dont/dont-complex-background.jpg)]"
+ />
<NextImage src={graphqlLogoDontColor} className="bg-white" />
<NextImage src={graphqlLogoDontGradient} className="bg-white" />
<NextImage src={graphqlLogoDontWordmark} className="bg-white" />
</div>
<div className="donts">
-- _Don't_ use black on a background of Rhodamine.
-- _Don't_ use Rhodamine on a color or patterned background; use white instead.
-- _Don't_ use different colors or apply gradients to the logo.
-- _Don't_ use different colors for elements of the logo. Always use the same color for the hexagraph and wordmark.
+ - _Don't_ use black on a background of Rhodamine. - _Don't_ use Rhodamine on a
+ color or patterned background; use white instead. - _Don't_ use different
+ colors or apply gradients to the logo. - _Don't_ use different colors for
+ elements of the logo. Always use the same color for the hexagraph and
+ wordmark.
</div>
---
-<AgreeActions/>
+<AgreeActions />
export function AgreeActions() {
- const [agree, setAgree] = useState(false);
+ const [agree, setAgree] = useState(false)
return (
- <div className="flex items-center flex-col gap-5 bg-zinc-100 dark:bg-zinc-800 p-5 border rounded">
+ <div className="flex flex-col items-center gap-5 rounded border bg-zinc-100 p-5 dark:bg-zinc-800">
<div className="flex gap-2">
<input
id="agree"
type="checkbox"
checked={agree}
- onChange={(event) => setAgree(event.target.checked)}
+ onChange={event => setAgree(event.target.checked)}
/>
<label htmlFor="agree" className="cursor-pointer">
I have read and accept the brand and trademark guidelines.
@@ -229,17 +269,21 @@ export function AgreeActions() {
<a
{...(agree
? { href: "/img/brand/graphql-brand-assets.zip" }
- : { className: "cursor-not-allowed text-gray-500 dark:text-gray-400" })}
+ : {
+ className: "cursor-not-allowed text-gray-500 dark:text-gray-400"
+ })}
>
- Download Logo Files
+ Download Logo Files
</a>
<a
{...(agree
? { href: "mailto:info@graphql.org?subject=Trademark%20Request" }
- : { className: "cursor-not-allowed text-gray-500 dark:text-gray-400" })}
+ : {
+ className: "cursor-not-allowed text-gray-500 dark:text-gray-400"
+ })}
>
- Request Permission
+ Request Permission
</a>
</div>
- );
+ )
}
diff --git a/src/pages/codeofconduct.mdx b/src/pages/codeofconduct.mdx
index 5de3333795..0bcf626b8b 100644
--- a/src/pages/codeofconduct.mdx
+++ b/src/pages/codeofconduct.mdx
@@ -6,11 +6,17 @@ title: Code of Conduct
## Our Pledge
-In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and
+expression, level of experience, education, socio-economic status, nationality,
+personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
-Examples of behavior that contributes to creating a positive environment include:
+Examples of behavior that contributes to creating a positive environment
+include:
- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
@@ -20,28 +26,64 @@ Examples of behavior that contributes to creating a positive environment include
Examples of unacceptable behavior by participants include:
-- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
-- Publishing others’ private information, such as a physical or electronic address, without explicit permission
-- Other conduct which could reasonably be considered inappropriate in a professional setting
+- Publishing others’ private information, such as a physical or electronic
+ address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+ professional setting
## Our Responsibilities
-GraphQL Specification members, project participants and contributors (collectively, "participants") are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
-
-The steering committee of the GraphQL Specification has the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any participant for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
-
-All participants have determined that The Linux Foundation is the most optimal organization to shepherd the development of this project. Participants acknowledge and agree to The Linux Foundation's exclusive right to use "GraphQL" and any other names and trademarks associated with the GraphQL open source project and GraphQL Specification and to authorize others’ use of the marks, establish guidelines for such use, and to delegate these responsibilities. Participants agree not to take any action inconsistent with such rights and to cooperate in any action which The Linux Foundation deems necessary or desirable to prevent confusion or establish or preserve these rights. Participants will not independently adopt, use, or attempt to register any trademarks or trade names that are confusingly similar to these names.
+GraphQL Specification members, project participants and contributors
+(collectively, "participants") are responsible for clarifying the standards of
+acceptable behavior and are expected to take appropriate and fair corrective
+action in response to any instances of unacceptable behavior.
+
+The steering committee of the GraphQL Specification has the right and
+responsibility to remove, edit, or reject comments, commits, code, wiki edits,
+issues, and other contributions that are not aligned to this Code of Conduct, or
+to ban temporarily or permanently any participant for other behaviors that they
+deem inappropriate, threatening, offensive, or harmful.
+
+All participants have determined that The Linux Foundation is the most optimal
+organization to shepherd the development of this project. Participants
+acknowledge and agree to The Linux Foundation's exclusive right to use "GraphQL"
+and any other names and trademarks associated with the GraphQL open source
+project and GraphQL Specification and to authorize others’ use of the marks,
+establish guidelines for such use, and to delegate these responsibilities.
+Participants agree not to take any action inconsistent with such rights and to
+cooperate in any action which The Linux Foundation deems necessary or
+desirable to prevent confusion or establish or preserve these rights.
+Participants will not independently adopt, use, or attempt to register any
+trademarks or trade names that are confusingly similar to these names.
## Scope
-This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
## Enforcement
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Executive Director, or, if the complaint involves the Executive Director, a member of the steering committee. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Participants who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by the steering committee.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the Executive Director, or, if the complaint involves the
+Executive Director, a member of the steering committee. All complaints will be
+reviewed and investigated and will result in a response that is deemed necessary
+and appropriate to the circumstances. The project team is obligated to maintain
+confidentiality with regard to the reporter of an incident. Further details of
+specific enforcement policies may be posted separately. Participants who do not
+follow or enforce the Code of Conduct in good faith may face temporary or
+permanent repercussions as determined by the steering committee.
## Attribution
-This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://contributor-covenant.org/version/1/4/code-of-conduct. For answers to common questions about this code of conduct, see https://contributor-covenant.org/faq.
+This Code of Conduct is adapted from the Contributor Covenant, version 1.4,
+available at https://contributor-covenant.org/version/1/4/code-of-conduct. For
+answers to common questions about this code of conduct, see
+https://contributor-covenant.org/faq.
diff --git a/src/pages/community/contribute/development.mdx b/src/pages/community/contribute/development.mdx
index 64cdd2af3f..ef40ec3e1a 100644
--- a/src/pages/community/contribute/development.mdx
+++ b/src/pages/community/contribute/development.mdx
@@ -1,17 +1,34 @@
# Participating in Development
-GraphQL is developed in the open, through [GitHub](https://github.com/graphql) and working group meetings that are open for anyone to attend (so long as they are covered under the [free membership agreement](https://github.com/graphql/graphql-wg/tree/HEAD/membership)). In addition, anybody is welcome to view the [recordings of our meetings on YouTube](https://youtube.graphql.org)
+GraphQL is developed in the open, through [GitHub](https://github.com/graphql)
+and working group meetings that are open for anyone to attend (so long as they
+are covered under the
+[free membership agreement](https://github.com/graphql/graphql-wg/tree/HEAD/membership)).
+In addition, anybody is welcome to view the
+[recordings of our meetings on YouTube](https://youtube.graphql.org)
## First steps
-If you want to get involved in GraphQL, add yourself to the meeting agenda for one of our [working groups or implementations](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md#about-the-graphql-specification-project), sign the document if you haven't already, and show up! Or, if you prefer, just open a PR against our projects as this will also initiate the spec membership signature process.
+If you want to get involved in GraphQL, add yourself to the meeting agenda for
+one of our
+[working groups or implementations](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md#about-the-graphql-specification-project),
+sign the document if you haven't already, and show up! Or, if you prefer, just
+open a PR against our projects as this will also initiate the spec membership
+signature process.
We welcome your participation!
## Getting up to speed
-All of our work [happens in the open](https://github.com/graphql). In addition, we record our workgroups' meetings on [YouTube](https://youtube.graphql.org). If you are interested in quickly getting up to speed on what's happening in a working group, the meeting minutes and [replays](https://youtube.graphql.org) are a great place to begin.
+All of our work [happens in the open](https://github.com/graphql). In addition,
+we record our workgroups' meetings on [YouTube](https://youtube.graphql.org). If
+you are interested in quickly getting up to speed on what's happening in a
+working group, the meeting minutes and [replays](https://youtube.graphql.org)
+are a great place to begin.
## Asking questions
-The best place to ask a development-related question is in a working group meeting, or by opening a GitHub issue. Please note that if you have an implementation question, you may get a faster answer by [asking in one of the channels more geared toward users](/community/resources/official-channels/).
+The best place to ask a development-related question is in a working group
+meeting, or by opening a GitHub issue. Please note that if you have an
+implementation question, you may get a faster answer by
+[asking in one of the channels more geared toward users](/community/resources/official-channels/).
diff --git a/src/pages/community/contribute/essential-links.mdx b/src/pages/community/contribute/essential-links.mdx
index d24ffe98b1..69c6266422 100644
--- a/src/pages/community/contribute/essential-links.mdx
+++ b/src/pages/community/contribute/essential-links.mdx
@@ -6,7 +6,7 @@ import {
CodeIcon,
TextIcon,
GoogleCalendarIcon,
- YouTubeIcon,
+ YouTubeIcon
} from "../../../icons"
# Essential Links
@@ -16,43 +16,43 @@ import {
{
icon: TextIcon,
title: "The GraphQL Specification",
- link: "https://spec.graphql.org",
+ link: "https://spec.graphql.org"
},
{
icon: CodeIcon,
title: "GraphQL Reference Implementation",
- link: "https://graphql.org/code",
+ link: "https://graphql.org/code"
},
{
icon: GitHubIcon,
title: "The official GraphQL GitHub org",
- link: "https://github.com/graphql",
+ link: "https://github.com/graphql"
},
{
icon: DiscordIcon,
title: "The official GraphQL Discord",
- link: "https://discord.graphql.org",
+ link: "https://discord.graphql.org"
},
{
icon: GoogleCalendarIcon,
title: "The GraphQL Project Calendar",
- link: "https://calendar.graphql.org",
+ link: "https://calendar.graphql.org"
},
{
icon: GitHubIcon,
title: "GraphQL Specification Membership Agreement",
link: "https://github.com/graphql/graphql-wg/tree/HEAD/membership",
- description: "",
+ description: ""
},
{
icon: YouTubeIcon,
title: "GraphQL YouTube Channel",
- link: "https://youtube.graphql.org",
+ link: "https://youtube.graphql.org"
},
{
icon: <StarIcon className="fill-primary" />,
title: "The GraphQL Community Grant Program",
- link: "https://graphql.org/foundation",
- },
+ link: "https://graphql.org/foundation"
+ }
]}
/>
diff --git a/src/pages/community/contribute/governance.mdx b/src/pages/community/contribute/governance.mdx
index 2698f29dbe..12cfbd9536 100644
--- a/src/pages/community/contribute/governance.mdx
+++ b/src/pages/community/contribute/governance.mdx
@@ -1,18 +1,41 @@
# GraphQL Project Governance
-GraphQL was open sourced by Facebook in 2015, and became a neutrally governed project managed by the Linux Foundation in 2019. In keeping with best practices, the technical governance of the GraphQL project is separate and distinct from the financial and policy governance of the [GraphQL Foundation](/foundation).
+GraphQL was open sourced by Facebook in 2015, and became a neutrally governed
+project managed by the Linux Foundation in 2019. In keeping with best practices,
+the technical governance of the GraphQL project is separate and distinct from
+the financial and policy governance of the [GraphQL Foundation](/foundation).
## Technical governance
-The GraphQL project is a chartered under the [Joint Development Foundation](https://www.jointdevelopment.org/) (JDF). JDF is a part of the Linux Foundation family, and is an organization specifically dedicated to making open standards easier to manage.
-
-The GraphQL specification, the GraphQL Working Group, and all other sub-working groups and implementations in the [GraphQL GitHub organization](https://github.com/graphql) are governed by the [GraphQL project charter](https://technical-charter.graphql.org).
-
-The [Technical Steering Committee](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md), or TSC, is established in the [technical charter](https://technical-charter.graphql.org) as the top technical decision-making body. It consists of [representatives from the GraphQL technical community](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md#tsc-voting-members) and is responsible for overseeing specification and development work, and approving new releases. TSC members serve a two-year term.
+The GraphQL project is a chartered under the
+[Joint Development Foundation](https://www.jointdevelopment.org/) (JDF). JDF is
+a part of the Linux Foundation family, and is an organization specifically
+dedicated to making open standards easier to manage.
+
+The GraphQL specification, the GraphQL Working Group, and all other sub-working
+groups and implementations in the
+[GraphQL GitHub organization](https://github.com/graphql) are governed by the
+[GraphQL project charter](https://technical-charter.graphql.org).
+
+The
+[Technical Steering Committee](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md),
+or TSC, is established in the
+[technical charter](https://technical-charter.graphql.org) as the top technical
+decision-making body. It consists of
+[representatives from the GraphQL technical community](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md#tsc-voting-members)
+and is responsible for overseeing specification and development work, and
+approving new releases. TSC members serve a two-year term.
## Financial and policy governance
-The [GraphQL Foundation](/foundation) provides financial support for the GraphQL project. In keeping with best practices, the Foundation is a separate organization, which helps to ensure that technical decisions are made upon their own merit and independent of financial contributions. The GraphQL Foundation uses the funds raised through [membership dues](/foundation/join) to support the work of the GraphQL Project through investments in infrastructure, coordination support services, developer grants, and mentorship programs.
-
-The [GraphQL Foundation](/foundation) is supported entirely by [membership dues](/foundation/join), from [companies](/foundation/members) who wish to support the long-term sustainability of the GraphQL ecosystem.
-
+The [GraphQL Foundation](/foundation) provides financial support for the GraphQL
+project. In keeping with best practices, the Foundation is a separate
+organization, which helps to ensure that technical decisions are made upon their
+own merit and independent of financial contributions. The GraphQL Foundation
+uses the funds raised through [membership dues](/foundation/join) to support the
+work of the GraphQL Project through investments in infrastructure, coordination
+support services, developer grants, and mentorship programs.
+
+The [GraphQL Foundation](/foundation) is supported entirely by
+[membership dues](/foundation/join), from [companies](/foundation/members) who
+wish to support the long-term sustainability of the GraphQL ecosystem.
diff --git a/src/pages/community/contribute/grant.mdx b/src/pages/community/contribute/grant.mdx
index cacd71234d..e327a42b6c 100644
--- a/src/pages/community/contribute/grant.mdx
+++ b/src/pages/community/contribute/grant.mdx
@@ -1,3 +1,8 @@
# Community Grant Program
-The [GraphQL Foundation](/foundation) funds a [Community Grant](/foundation/community-grant) program that is administered by the [GraphQL TSC](/community/contribute/governance/#technical-governance). The goal of the community grant program is to provide support to individuals working on initiatives that benefit the core technical project and the community at large.
+The [GraphQL Foundation](/foundation) funds a
+[Community Grant](/foundation/community-grant) program that is administered by
+the [GraphQL TSC](/community/contribute/governance/#technical-governance). The
+goal of the community grant program is to provide support to individuals working
+on initiatives that benefit the core technical project and the community at
+large.
diff --git a/src/pages/community/contribute/how-graphql-is-developed.mdx b/src/pages/community/contribute/how-graphql-is-developed.mdx
index 210b471a7d..be92cc7d81 100644
--- a/src/pages/community/contribute/how-graphql-is-developed.mdx
+++ b/src/pages/community/contribute/how-graphql-is-developed.mdx
@@ -1,24 +1,37 @@
import { Cards } from "../../../components/cards"
-import {
- GitHubIcon,
- GoogleCalendarIcon,
- YouTubeIcon,
-} from "../../../icons"
+import { GitHubIcon, GoogleCalendarIcon, YouTubeIcon } from "../../../icons"
# How GraphQL Is Developed
-At its core, the GraphQL project is organized around the [specification](https://spec.graphql.org), with a wide variety of supporting implementations and tools.
+At its core, the GraphQL project is organized around the
+[specification](https://spec.graphql.org), with a wide variety of supporting
+implementations and tools.
-GraphQL has an active and mutually beneficial relationship with its many implementations. The GraphQL specification is continuously evolving under the care of the [GraphQL Working Group](https://github.com/graphql/graphql-wg), which consists of GraphQL spec experts, contributors to public [reference implementations](/code), and implementers. At any given time, GraphQL specification updates are a combination of anticipatory planning with documentation of patterns and behaviors that are already proven in production, sometimes at very large scale.
+GraphQL has an active and mutually beneficial relationship with its many
+implementations. The GraphQL specification is continuously evolving under the
+care of the [GraphQL Working Group](https://github.com/graphql/graphql-wg),
+which consists of GraphQL spec experts, contributors to public
+[reference implementations](/code), and implementers. At any given time, GraphQL
+specification updates are a combination of anticipatory planning with
+documentation of patterns and behaviors that are already proven in production,
+sometimes at very large scale.
## Working Groups
-The GraphQL specification, sub-specifications, and official reference implementations are developed using the working group model. The working groups meet monthly or as-needed in order to review ideas and plan their work.
+The GraphQL specification, sub-specifications, and official reference
+implementations are developed using the working group model. The working groups
+meet monthly or as-needed in order to review ideas and plan their work.
<div className="border-l-2 border-primary pl-6 md:pl-10">
### The GraphQL Working Group
- The [GraphQL Working Group](https://github.com/graphql/graphql-wg) is the main group that plans and implements changes to the [GraphQL specification](https://spec.graphql.org). It meets actively and is the default place for discussion for topics which do not have a separate breakout working group (breakout working groups include the [Input Union WG](https://github.com/graphql/graphql-spec/blob/main/rfcs/InputUnion.md) and the [GraphQL-over-HTTP WG](https://github.com/graphql/graphql-over-http)).
+The [GraphQL Working Group](https://github.com/graphql/graphql-wg) is the main
+group that plans and implements changes to the
+[GraphQL specification](https://spec.graphql.org). It meets actively and is the
+default place for discussion for topics which do not have a separate breakout
+working group (breakout working groups include the
+[Input Union WG](https://github.com/graphql/graphql-spec/blob/main/rfcs/InputUnion.md)
+and the [GraphQL-over-HTTP WG](https://github.com/graphql/graphql-over-http)).
<Cards
items={[
diff --git a/src/pages/community/contribute/project-meetings.mdx b/src/pages/community/contribute/project-meetings.mdx
index 3064dadcf2..ab3289bcc6 100644
--- a/src/pages/community/contribute/project-meetings.mdx
+++ b/src/pages/community/contribute/project-meetings.mdx
@@ -1,31 +1,57 @@
# Project Meetings
-All GraphQL technical meetings are open to anyone who is interested, so long as they first complete the [GraphQL Specification Membership agreement](https://github.com/graphql/graphql-wg/tree/HEAD/membership).
+All GraphQL technical meetings are open to anyone who is interested, so long as
+they first complete the
+[GraphQL Specification Membership agreement](https://github.com/graphql/graphql-wg/tree/HEAD/membership).
-All GraphQL technical meetings should appear on the [GraphQL public calendar](https://calendar.graphql.org). If a project's meeting isn't on the calendar or is incorrect, please email operations@graphql.org.
+All GraphQL technical meetings should appear on the
+[GraphQL public calendar](https://calendar.graphql.org). If a project's meeting
+isn't on the calendar or is incorrect, please email operations@graphql.org.
-- **Who can join GraphQL technical meetings:** Anyone who has signed the free [GraphQL Specification Membership agreement](https://github.com/graphql/graphql-wg/tree/HEAD/membership).
+- **Who can join GraphQL technical meetings:** Anyone who has signed the free
+ [GraphQL Specification Membership agreement](https://github.com/graphql/graphql-wg/tree/HEAD/membership).
-- **How to join:** Each GraphQL project must maintain an agenda document for each meeting, and each attendee must add themselves to it prior to attending. To join, open a PR to add your name to the attendee list on an upcoming meeting's agenda (for example, the [GraphQL Working Group](https://github.com/graphql/graphql-wg/tree/HEAD/agendas) or [GraphQL.js](https://github.com/graphql/graphql-js-wg/tree/main/agendas)). The agenda document will have the date, time and Zoom links.
+- **How to join:** Each GraphQL project must maintain an agenda document for
+ each meeting, and each attendee must add themselves to it prior to attending.
+ To join, open a PR to add your name to the attendee list on an upcoming
+ meeting's agenda (for example, the
+ [GraphQL Working Group](https://github.com/graphql/graphql-wg/tree/HEAD/agendas)
+ or [GraphQL.js](https://github.com/graphql/graphql-js-wg/tree/main/agendas)).
+ The agenda document will have the date, time and Zoom links.
-import { Callout } from 'nextra/components'
+import { Callout } from "nextra/components"
<Callout type="warning">
- **IMPORTANT:** Your PR against the agenda **must** be merged before you can attend. If the EasyCLA bot says you are not covered, you need to follow the links in the bot's comment to sign the [GraphQL Specification Membership agreement](https://github.com/graphql/graphql-wg/tree/HEAD/membership) before you can attend.
+ **IMPORTANT:** Your PR against the agenda **must** be merged before you can
+ attend. If the EasyCLA bot says you are not covered, you need to follow the
+ links in the bot's comment to sign the [GraphQL Specification Membership
+ agreement](https://github.com/graphql/graphql-wg/tree/HEAD/membership) before
+ you can attend.
</Callout>
-If you have questions about this process, please ask [operations@graphql.org](mailto:operations@graphql.org).
+If you have questions about this process, please ask
+[operations@graphql.org](mailto:operations@graphql.org).
## GraphQL Working Group / TSC meeting
-The [GraphQL Working Group](https://github.com/graphql/graphql-wg) meets on the first Thursday of each month. When there are topics to address, the [GraphQL Technical Steering Committee (TSC)](https://github.com/graphql/graphql-wg/blob/HEAD/GraphQL-TSC.md) may meet briefly prior to the start of the Working Group meeting.
+The [GraphQL Working Group](https://github.com/graphql/graphql-wg) meets on the
+first Thursday of each month. When there are topics to address, the
+[GraphQL Technical Steering Committee (TSC)](https://github.com/graphql/graphql-wg/blob/HEAD/GraphQL-TSC.md)
+may meet briefly prior to the start of the Working Group meeting.
-The goal of the working group meeting is to discuss current work and future plans for the GraphQL specification. The Working Group meeting is also the place to coordinate between other GraphQL working groups and reference implementations.
+The goal of the working group meeting is to discuss current work and future
+plans for the GraphQL specification. The Working Group meeting is also the place
+to coordinate between other GraphQL working groups and reference
+implementations.
-To join, add yourself to an [upcoming meeting agenda](https://github.com/graphql/graphql-wg/tree/HEAD/agendas).
+To join, add yourself to an
+[upcoming meeting agenda](https://github.com/graphql/graphql-wg/tree/HEAD/agendas).
## GraphQL.js Working Group meeting
-The [GraphQL.js working group](https://github.com/graphql/graphql-js-wg) meets the second Tuesday of each month. The goal is to plan development work and resolve issues with [GraphQL.js](https://github.com/graphql/graphql-js).
+The [GraphQL.js working group](https://github.com/graphql/graphql-js-wg) meets
+the second Tuesday of each month. The goal is to plan development work and
+resolve issues with [GraphQL.js](https://github.com/graphql/graphql-js).
-To join, add yourself to an [upcoming meeting agenda](https://github.com/graphql/graphql-js-wg/tree/HEAD/agendas).
+To join, add yourself to an
+[upcoming meeting agenda](https://github.com/graphql/graphql-js-wg/tree/HEAD/agendas).
diff --git a/src/pages/community/contribute/project-resources.mdx b/src/pages/community/contribute/project-resources.mdx
index c487e7ea44..9c511401cf 100644
--- a/src/pages/community/contribute/project-resources.mdx
+++ b/src/pages/community/contribute/project-resources.mdx
@@ -1,71 +1,116 @@
# Project Resources
-The following resources are intended to help official GraphQL projects understand what resources are available to them, and how to correctly run meetings.
+The following resources are intended to help official GraphQL projects
+understand what resources are available to them, and how to correctly run
+meetings.
## Types of GraphQL projects
-The GraphQL community is incredibly broad, with a large number of reference implementations which are developed and evolving in parallel to the GraphQL project. Many of them are listed [here](/code).
+The GraphQL community is incredibly broad, with a large number of reference
+implementations which are developed and evolving in parallel to the GraphQL
+project. Many of them are listed [here](/code).
-The primary distinction between official GraphQL projects and other implementations is that GraphQL projects are managed under the [GraphQL technical charter](https://technical-charter.graphql.org) and [GraphQL Code of Conduct](https://code-of-conduct.graphql.org).
+The primary distinction between official GraphQL projects and other
+implementations is that GraphQL projects are managed under the
+[GraphQL technical charter](https://technical-charter.graphql.org) and
+[GraphQL Code of Conduct](https://code-of-conduct.graphql.org).
-We welcome and encourage community members and third-parties to maintain their own implementations.
+We welcome and encourage community members and third-parties to maintain their
+own implementations.
> ### Making an independent project official
>
-> If you maintain a tool or reference implementation that you'd like to transfer to the [GraphQL GitHub org](https://github.com/graphql), or if you are planning to start a new workgroup or implementation within the official GraphQL project, please add your name to the agenda of an upcoming [GraphQL Working Group meeting](https://github.com/graphql/graphql-wg/tree/HEAD/agendas) to introduce your idea.
+> If you maintain a tool or reference implementation that you'd like to transfer
+> to the [GraphQL GitHub org](https://github.com/graphql), or if you are
+> planning to start a new workgroup or implementation within the official
+> GraphQL project, please add your name to the agenda of an upcoming
+> [GraphQL Working Group meeting](https://github.com/graphql/graphql-wg/tree/HEAD/agendas)
+> to introduce your idea.
>
-> Should your proposal meet with approval, a few things will then need to happen. For example, we will work with you to adopt our policies and neutral governance, and help you transfer the project and its assets (generally the domain name and any trademarks) so that they are neutrally held at the Linux Foundation. If you'd like to explore the idea before making a proposal, please reach out to [operations@graphql.org](mailto:operations@graphql.org)
+> Should your proposal meet with approval, a few things will then need to
+> happen. For example, we will work with you to adopt our policies and neutral
+> governance, and help you transfer the project and its assets (generally the
+> domain name and any trademarks) so that they are neutrally held at the Linux
+> Foundation. If you'd like to explore the idea before making a proposal, please
+> reach out to [operations@graphql.org](mailto:operations@graphql.org)
## Running project meetings
-Because GraphQL is a [Joint Development Foundation](https://www.jointdevelopment.org/) project, all meeting participants and contributors must complete the GraphQL specification membership agreement prior to participating.
+Because GraphQL is a
+[Joint Development Foundation](https://www.jointdevelopment.org/) project, all
+meeting participants and contributors must complete the GraphQL specification
+membership agreement prior to participating.
Each **technical meeting** must:
-- Have an agenda Markdown document in the project repo published at least a week before the call.
-- Have an "Attendees" section where people can open a PR and add their own names in advance.
-- Optional, but encouraged: Use the GraphQL Zoom account so that we can easily post the meeting recording to [YouTube](https://youtube.graphql.org).
+- Have an agenda Markdown document in the project repo published at least a week
+ before the call.
+- Have an "Attendees" section where people can open a PR and add their own names
+ in advance.
+- Optional, but encouraged: Use the GraphQL Zoom account so that we can easily
+ post the meeting recording to [YouTube](https://youtube.graphql.org).
Each **attendee** must:
- Add their name to the agenda prior to the meeting.
-- Pass the EasyCLA check by signing the agreement as an individual, or asking their company to add them to the list.
+- Pass the EasyCLA check by signing the agreement as an individual, or asking
+ their company to add them to the list.
The **person running the call** must:
-- Merge all appropriate attendance and agenda PRs with passing checks prior to the meeting.
+- Merge all appropriate attendance and agenda PRs with passing checks prior to
+ the meeting.
- Verify that everyone who connects to the meeting appears on the list.
-- If someone joins who is not on the list, they need to disconnect until they can PR themselves onto the attendee list with all checks passing.
+- If someone joins who is not on the list, they need to disconnect until they
+ can PR themselves onto the attendee list with all checks passing.
- Notify all attendees the meeting is being recorded, and record to the cloud.
-- Keep minutes, or have a volunteer to write them. Minutes should be published to the project repo.
+- Keep minutes, or have a volunteer to write them. Minutes should be published
+ to the project repo.
## Resources for projects
### Zoom
-Official GraphQL projects and workgroups are welcome and encouraged to use the GraphQL zoom. Please contact [operations@graphql.org](mailto:operations@graphql.org) to get the credentials.
+Official GraphQL projects and workgroups are welcome and encouraged to use the
+GraphQL zoom. Please contact
+[operations@graphql.org](mailto:operations@graphql.org) to get the credentials.
### GitHub
-Official GraphQL projects can host their repos in the [graphql organization](https://github.com/graphql). This includes code repos, spec repos, and workgroup coordination repos. Please contact [operations@graphql.org](mailto:operations@graphql.org) for details.
+Official GraphQL projects can host their repos in the
+[graphql organization](https://github.com/graphql). This includes code repos,
+spec repos, and workgroup coordination repos. Please contact
+[operations@graphql.org](mailto:operations@graphql.org) for details.
### YouTube playlist
-Wherever possible, we record meetings and post them to a playlist on the [GraphQL YouTube channel](https://youtube.graphql.org). If your project does not have a playlist, please contact [operations@graphql.org](mailto:operations@graphql.org) and we can set you up.
+Wherever possible, we record meetings and post them to a playlist on the
+[GraphQL YouTube channel](https://youtube.graphql.org). If your project does not
+have a playlist, please contact
+[operations@graphql.org](mailto:operations@graphql.org) and we can set you up.
### GraphQL calendar
-Project meetings should be added to the [GraphQL calendar](https://calendar.graphql.org), so that people can easily find them.
+Project meetings should be added to the
+[GraphQL calendar](https://calendar.graphql.org), so that people can easily find
+them.
### GraphQL domain registration and DNS management
-The Linux Foundation holds the top-level graphql.org domain, and a number of others. If you need to register a domain for your project (particularly if it includes the word "graphql") or need to manage DNS for a registered domain, please contact [operations@graphql.org](mailto:operations@graphql.org).
+The Linux Foundation holds the top-level graphql.org domain, and a number of
+others. If you need to register a domain for your project (particularly if it
+includes the word "graphql") or need to manage DNS for a registered domain,
+please contact [operations@graphql.org](mailto:operations@graphql.org).
### Trademark guidance
-The GraphQL trademark is managed by LF Projects. GraphQL projects are able to use the GraphQL name and marks in accordance with the [trademark policy](https://lfprojects.org/policies/trademark-policy/). If your project has questions about how you or others can use the mark, please contact [trademark@graphql.org](mailto:trademark@graphql.org).
+The GraphQL trademark is managed by LF Projects. GraphQL projects are able to
+use the GraphQL name and marks in accordance with the
+[trademark policy](https://lfprojects.org/policies/trademark-policy/). If your
+project has questions about how you or others can use the mark, please contact
+[trademark@graphql.org](mailto:trademark@graphql.org).
### All other questions
-If you have a question not covered here, please reach out to [operations@graphql.org](mailto:operations@graphql.org).
-
+If you have a question not covered here, please reach out to
+[operations@graphql.org](mailto:operations@graphql.org).
diff --git a/src/pages/community/events.mdx b/src/pages/community/events.mdx
index 91153aa71d..5f9f4e8be6 100644
--- a/src/pages/community/events.mdx
+++ b/src/pages/community/events.mdx
@@ -14,45 +14,45 @@ import { meetups } from "../../components/meetups"
import { events } from "../../components/events"
import "leaflet/dist/leaflet.css"
import pinkCircle from "./pink-circle.svg"
-import { Button } from '../../app/conf/_components/button'
+import { Button } from "../../app/conf/_components/button"
export function EventCard({ href, date, city, name, meta }) {
return (
<a
href={href}
className={clsx(
- "text-current no-underline flex border border-neutral-300 dark:border-neutral-700 rounded-none",
- "hover:!border-primary hover:shadow-2xl hover:shadow-primary/10 transition-colors *:transition-colors hover:relative group",
- "relative after:content-['_↗'] after:font-sans after:absolute after:right-4 after:top-4",
+ "flex rounded-none border border-neutral-300 text-current no-underline dark:border-neutral-700",
+ "group transition-colors *:transition-colors hover:relative hover:!border-primary hover:shadow-2xl hover:shadow-primary/10",
+ "relative after:absolute after:right-4 after:top-4 after:font-sans after:content-['_↗']"
)}
target="_blank"
rel="noreferrer"
>
{date && (
- <div className="shrink-0 flex flex-col justify-center items-center bg-zinc-100 dark:bg-zinc-800 group-hover:dark:bg-zinc-700 lg:w-48 w-28">
- <div className="text-5xl lg:text-7xl font-bold">{date.getDate()}</div>
+ <div className="flex w-28 shrink-0 flex-col items-center justify-center bg-zinc-100 dark:bg-zinc-800 group-hover:dark:bg-zinc-700 lg:w-48">
+ <div className="text-5xl font-bold lg:text-7xl">{date.getDate()}</div>
<div className="text-sm lg:text-lg">
{date.toLocaleString("en", {
month: "short",
- year: "numeric",
+ year: "numeric"
})}
</div>
</div>
)}
- <div className="bg-white dark:bg-neutral-900 group-hover:dark:bg-zinc-800 grow py-4 lg:py-7 px-5 lg:px-10 flex flex-col gap-4">
+ <div className="flex grow flex-col gap-4 bg-white px-5 py-4 dark:bg-neutral-900 group-hover:dark:bg-zinc-800 lg:px-10 lg:py-7">
<b className="text-primary max-lg:text-xs">{meta}</b>
- <div className="font-bold text-lg lg:text-2xl">{name}</div>
- <div className="text-xs lg:text-lg flex flex-wrap lg:gap-x-6 gap-2">
+ <div className="text-lg font-bold lg:text-2xl">{name}</div>
+ <div className="flex flex-wrap gap-2 text-xs lg:gap-x-6 lg:text-lg">
<div className="flex items-center gap-2">
- <LocationIcon className="fill-primary size-5" />
+ <LocationIcon className="size-5 fill-primary" />
{city}
</div>
{date && (
<div className="flex items-center gap-2">
- <ClockIcon className="fill-primary size-5" />
+ <ClockIcon className="size-5 fill-primary" />
{date.toLocaleString("en", {
hour: "numeric",
- minute: "numeric",
+ minute: "numeric"
})}
</div>
)}
@@ -73,7 +73,7 @@ export const { pastEvents, upcomingEvents } = events.reduce(
}
return acc
},
- { pastEvents: [], upcomingEvents: [] },
+ { pastEvents: [], upcomingEvents: [] }
)
export function Events({ events }) {
@@ -97,7 +97,10 @@ export function Events({ events }) {
<Events events={upcomingEvents} />
-<Button href="/community/foundation/local-initiative" className="mx-auto my-6 !block">
+<Button
+ href="/community/foundation/local-initiative"
+ className="mx-auto my-6 !block"
+>
Start a GraphQL Local!
</Button>
@@ -123,7 +126,7 @@ export function Meetups() {
// and replace default marker image
L.Icon.Default.mergeOptions({
iconRetinaUrl: pinkCircle.src,
- shadowUrl: "",
+ shadowUrl: ""
})
const map = L.map("map").setView([45, -15], 2)
L.tileLayer("https://tile.openstreetmap.org/{z}/{x}/{y}.png").addTo(map)
@@ -131,14 +134,14 @@ export function Meetups() {
L.marker([node.latitude, node.longitude])
.addTo(map)
.bindPopup(
- `<a href="${node.link}" target="_blank" rel="noreferrer" class="!text-primary">${node.name}</a>`,
+ `<a href="${node.link}" target="_blank" rel="noreferrer" class="!text-primary">${node.name}</a>`
)
}
})
}, [])
return (
<>
- <div id="map" className="h-96 my-6 z-0" />
+ <div id="map" className="z-0 my-6 h-96" />
{meetups.map(({ node }) => (
<EventCard
key={node.id}
@@ -152,226 +155,3 @@ export function Meetups() {
}
<Meetups />
-
-{/*
-# Join the GraphQL Community
-
-The GraphQL community is growing fast, with conferences, workshops, and meetups happening around the world.
-
-Join our community to stay up to date with the latest developments, to learn from your peers, and to share your own experiences.
-
-Browse the list of community meetups below, or search through the GraphQL events to find an event near you.
-
-export const CommunityIntro = () => {
- const { meetups } = useData()
- return (
- <p>
- Join one of <strong>{meetups.length}</strong> GraphQL Meetups around the
- world!
- </p>
- )
-}
-
-export const UrlList = ({ urls }) => {
- return (
- <div>
- <ul className="list-disc ml-3">
- {urls.map(link => (
- <li key={link.href}>
- <a href={link.href} className="block p-1 text-sm">
- {link.text}
- </a>
- </li>
- ))}
- </ul>
- </div>
- )
-}
-
-export const CommunityList = () => {
- const data = useData();
- const meetups = data.meetups;
- const unsetContinents = meetups.map((meetup) => meetup.continent);
- const continents = [...new Set(unsetContinents)];
-
-return (
-<div>
-<div>
-<div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-3 w-full">
-{continents.map((continent, index) => {
-const urls = meetups.filter(
-(meetup) => meetup.continent === continent
-);
-
- return (
- <div key={index}>
- <h3>{continent}</h3>
- <UrlList urls={urls} />
- </div>
- );
- })}
- </div>
- </div>
- </div>
-)
-}
-
-export const EventsIntro = () => {
- const { events } = useData();
- return <p>Join one of <strong>{events.length}</strong> recent or upcoming GraphQL events around the world!</p>
-}
-
-export const EventsList = () => {
-const data = useData();
-const events = data.events;
-
- return (
- <div className='mt-5'>
- <div>
- <div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-3 w-full">
- {events.map((event) => {
- return (
- <div
- key={event.slug}
- className="rounded-lg shadow-md"
- >
- <img
- loading="lazy"
- src={event.coverImage}
- alt={event.name}
- className="w-full h-40 object-contain"
- />
- <div className="p-4 flex flex-col gap-3">
- <a
- href={event.eventLink}
- target="_blank"
- rel="noopener noreferrer"
- className="text-md font-semibold mb-2 underline"
- >
- {event.name}
- </a>
- <p className="text-xs">
- Hosted by:{" "}
- <a
- href={event.hostLink}
- target="_blank"
- rel="noopener noreferrer"
- className="font-bold underline"
- >
- {event.host}
- </a>
- </p>
- </div>
- <div className="p-4">
- <p className="text-xs">
- Location:{" "}
- <span className="font-bold">{event.location}</span>
- </p>
- </div>
- </div>
- );
- })}
- </div>
- </div>
- </div>
- )
-}
-
-## GraphQL Communities
-<CommunityIntro />
-
-<CommunityList />
-
-## GraphQL Events
-<EventsIntro />
-
-<EventsList />
-
-## Events
-*/}
-{/* _None currently scheduled_ */}
-
-{/* Event template, copy and paste what you need. Please note that the only three required fields are the name of the event, who is organizing and hosting it, and the link to the code of conduct. Events without this information can't be posted.
-
-### [Name of the event - REQUIRED]
-
-* **Date(s):** [date]
-* **Location:** [city, state, country|Virtual|Hybrid]
-* **Registration:** [link to reg site, with cost]
-* **CFP:** [link to CFP site]
-* **Schedule:** [link to schedule site]
-* **Host:** [name of organization or company hosting the event - REQUIRED]
-* **Code of Conduct:** [link to code of conduct - REQUIRED]
-
-*/}
-
-{/*
-
-### GraphQLConf 2023
-
-- **Date:** September 19-21, 2023
-- **Location:** San Francisco Bay Area, CA
-- **Host:** GraphQL Foundation
-- [**Registration**](https://graphql.org/conf/#attend)
-- [**Schedule**](https://graphql.org/conf/schedule/)
-- [**Code of Conduct**](https://graphql.org/conf/faq/#codeofconduct)
-
-## Meetups
-
-### North America
-
-- [GraphQL San Francisco](https://www.meetup.com/sf-graphql/)
-- [GraphQL APIs (San Francisco)](http://www.meetup.com/graphql/)
-- [GraphQL By the Bay (San Francisco)](https://www.meetup.com/graphql-by-the-bay/)
-- [GraphQL Seattle](https://www.meetup.com/seattlegraphql/)
-- [GraphQL Boston](https://www.meetup.com/graphql-boston/)
-- [GraphQL NYC](https://www.meetup.com/graphql-newyork/)
-- [GraphQL Austin](https://www.meetup.com/ATX-GraphQL/)
-- [GraphQL Minneapolis](https://www.meetup.com/GraphQL-MN/)
-- [GraphQL Denver](https://www.meetup.com/graphql-denver)
-- [GraphQL Chicago](https://www.meetup.com/graphql-chicago/)
-
-### South America
-
-- [GraphQL São Paulo](https://www.meetup.com/graphql-sp/)
-- [GraphQL Buenos Aires](https://www.meetup.com/GraphQL-BA/)
-
-### Europe
-
-- [GraphQL Amsterdam](https://www.meetup.com/Amsterdam-GraphQL-Meetup/)
-- [GraphQL Berlin](https://www.meetup.com/graphql-berlin/)
-- [GraphQL Barcelona](https://www.meetup.com/GraphQL-Barcelona/)
-- [GraphQL Budapest](https://www.meetup.com/Budapest-GraphQL/)
-- [GraphQL Copenhagen](https://www.meetup.com/Copenhagen-GraphQL-Meetup-Group/)
-- [GraphQL London](https://guild.host/graphql-london/events)
-- [GraphQL Milano](https://www.meetup.com/GraphQL-Milano/)
-- [GraphQL Munich](https://www.meetup.com/GraphQL-Munich/)
-- [GraphQL Paris](https://www.meetup.com/GraphQL-Paris/)
-- [GraphQL Paris 2](https://www.meetup.com/fr-FR/parisgraphql/)
-- [GraphQL Sarajevo](https://www.meetup.com/graphql-sarajevo/)
-- [GraphQL Stockholm](https://www.meetup.com/GraphQL-Stockholm/)
-- [GraphQL Zurich](https://www.meetup.com/graphql-zurich/)
-- [GraphQL Wroclaw](https://www.meetup.com/GraphQL-Wroclaw/)
-
-### Australia
-
-- [GraphQL Melbourne](http://graphql.melbourne/)
-- [GraphQL Sydney](https://graphql.sydney/)
-
-### Asia
-
-- [GraphQL Tel Aviv](https://www.meetup.com/GraphQL-TLV/)
-- [GraphQL Tokyo](https://www.meetup.com/GraphQL-Tokyo/)
-- [GraphQL Meetup (Bangalore)](https://www.meetup.com/graphql-bangalore/)
-- [GraphQL Meetup (Bangkok)](https://www.meetup.com/GraphQL-Bangkok/)
-- [GraphQL Meetup (Singapore)](https://www.meetup.com/GraphQL-SG/)
-- [GraphQL Meetup (Hong Kong)](https://www.meetup.com/GraphQLHongKong/)
-- [GraphQL Shenzhen](https://www.meetup.com/graphqlshenzhen/)
-- [GraphQL Korea](https://www.facebook.com/groups/graphql.kr)
-- [GraphQL Seoul](https://www.meetup.com/graphql-seoul/)
-
-### Africa
-
-- [GraphQL Nairobi](https://www.meetup.com/Nairobi-GraphQL-Meetup/)
-
-*/}
diff --git a/src/pages/community/foundation/annual-reports.mdx b/src/pages/community/foundation/annual-reports.mdx
index 6c874ec2fc..91794bcd93 100644
--- a/src/pages/community/foundation/annual-reports.mdx
+++ b/src/pages/community/foundation/annual-reports.mdx
@@ -4,12 +4,15 @@ description: Reflecting upon our accomplishments, anticipating our future
# Annual Reports
-The GraphQL annual reports are a celebration of the ongoing work happening in the GraphQL technical community, the GraphQL Foundation, and our members.
+The GraphQL annual reports are a celebration of the ongoing work happening in
+the GraphQL technical community, the GraphQL Foundation, and our members.
-If you have an item you'd like to add to the annual report, please contact [operations@graphql.org](mailto:operations@graphql.org).
+If you have an item you'd like to add to the annual report, please contact
+[operations@graphql.org](mailto:operations@graphql.org).
## 2019
-The GraphQL Foundation was founded in 2019, to support and sustain the GraphQL ecosystem. We had a busy first year!
+The GraphQL Foundation was founded in 2019, to support and sustain the GraphQL
+ecosystem. We had a busy first year!
[Read the 2019 Annual Report »](/foundation/annual-reports/2019/)
diff --git a/src/pages/community/foundation/annual-reports/2019.mdx b/src/pages/community/foundation/annual-reports/2019.mdx
index a601de1aac..38a857a80b 100644
--- a/src/pages/community/foundation/annual-reports/2019.mdx
+++ b/src/pages/community/foundation/annual-reports/2019.mdx
@@ -4,50 +4,99 @@ date: 2020-04-02
# 2019 Annual Report
-The GraphQL Foundation is a neutral foundation founded by global technology and application development companies. The GraphQL Foundation encourages contributions, stewardship, and a shared investment from a broad group in vendor-neutral events, documentation, tools, and support for GraphQL.
-
-The GraphQL Foundation was formed in March 2019 and has now completed one full year of operation. We are pleased to present this annual report detailing the many things we have accomplished in support of this fast growing and broadly adopted platform.
-
-Comments and feedback are welcome at [info@graphql.org](mailto:info@graphql.org).
-
-> "The growth behind the technology and the community supporting GraphQL has been incredible. The GraphQL Foundation has played a critical role in helping to make GraphQL a neutral industry standard and enabling widespread adoption by encouraging contributions, and creating shared tools, and resources."
+The GraphQL Foundation is a neutral foundation founded by global technology and
+application development companies. The GraphQL Foundation encourages
+contributions, stewardship, and a shared investment from a broad group in
+vendor-neutral events, documentation, tools, and support for GraphQL.
+
+The GraphQL Foundation was formed in March 2019 and has now completed one full
+year of operation. We are pleased to present this annual report detailing the
+many things we have accomplished in support of this fast growing and broadly
+adopted platform.
+
+Comments and feedback are welcome at
+[info@graphql.org](mailto:info@graphql.org).
+
+> "The growth behind the technology and the community supporting GraphQL has
+> been incredible. The GraphQL Foundation has played a critical role in helping
+> to make GraphQL a neutral industry standard and enabling widespread adoption
+> by encouraging contributions, and creating shared tools, and resources."
>
-> – _**Lee Byron**, Executive Director, GraphQL Foundation, and GraphQL Co-Creator_
+> – _**Lee Byron**, Executive Director, GraphQL Foundation, and GraphQL
+> Co-Creator_
## Who we are
-The [GraphQL Foundation](/) is a neutral foundation created by the founders of [GraphQL](https://graphql.org), along with many organizations who are using GraphQL in production. The GraphQL Foundation encourages contributions, stewardship, and a shared investment by providing vendor-neutral events, documentation, tools, and support for GraphQL.
+The [GraphQL Foundation](/) is a neutral foundation created by the founders of
+[GraphQL](https://graphql.org), along with many organizations who are using
+GraphQL in production. The GraphQL Foundation encourages contributions,
+stewardship, and a shared investment by providing vendor-neutral events,
+documentation, tools, and support for GraphQL.
## Cultivating projects
-The GraphQL Foundation hosts the [GraphQL specification](https://github.com/graphql/graphql-spec), [GraphQL.js](https://github.com/graphql/graphql-js) reference implementation, [DataLoader](https://github.com/graphql/dataloader) library, and [GraphiQL](https://github.com/graphql/graphiql) developer tool.
-
-GraphQL is a next-generation API technology developed internally by Facebook in 2012 before being publicly [open sourced in 2015](https://code.fb.com/core-data/graphql-a-data-query-language). Unlike REST-based APIs, which take advantage of HTTP and existing protocols, GraphQL APIs provide developers with the flexibility to query the exact data they need from a diverse set of cloud data sources, with less code, greater performance and security, and a faster development cycle. Not only does this enable developers to rapidly build top quality apps, it also helps them achieve consistency and feature parity across multiple platforms such as web, iOS, Android, and embedded and IoT applications.
-
-The GraphQL Foundation also funded community member Ivan Goncharov to work through a variety of GraphQL project issues, from backlog cleanup and more.
+The GraphQL Foundation hosts the
+[GraphQL specification](https://github.com/graphql/graphql-spec),
+[GraphQL.js](https://github.com/graphql/graphql-js) reference implementation,
+[DataLoader](https://github.com/graphql/dataloader) library, and
+[GraphiQL](https://github.com/graphql/graphiql) developer tool.
+
+GraphQL is a next-generation API technology developed internally by Facebook in
+2012 before being publicly
+[open sourced in 2015](https://code.fb.com/core-data/graphql-a-data-query-language).
+Unlike REST-based APIs, which take advantage of HTTP and existing protocols,
+GraphQL APIs provide developers with the flexibility to query the exact data
+they need from a diverse set of cloud data sources, with less code, greater
+performance and security, and a faster development cycle. Not only does this
+enable developers to rapidly build top quality apps, it also helps them achieve
+consistency and feature parity across multiple platforms such as web, iOS,
+Android, and embedded and IoT applications.
+
+The GraphQL Foundation also funded community member Ivan Goncharov to work
+through a variety of GraphQL project issues, from backlog cleanup and more.
## Growing membership
The GraphQL Foundation
-[launched](/news/2019/03/12/the-graphql-foundation-announces-collaboration-with-the-joint-development-foundation-to-drive-open-source-and-open-standards) with 10 [members](/foundation/members), and we wrapped the year with 21 members in total, including Apollo, AWS, Butterfly Network, Dgraph Labs, Facebook, Gatsby, GraphZen, Hasura, IBM, Intuit, Neo4j, Novvum, Pipefy, Salsify, Solo.io and more. [Join](/join) your industry peers in helping to shape the GraphQL ecosystem.
+[launched](/news/2019/03/12/the-graphql-foundation-announces-collaboration-with-the-joint-development-foundation-to-drive-open-source-and-open-standards)
+with 10 [members](/foundation/members), and we wrapped the year with 21 members
+in total, including Apollo, AWS, Butterfly Network, Dgraph Labs, Facebook,
+Gatsby, GraphZen, Hasura, IBM, Intuit, Neo4j, Novvum, Pipefy, Salsify, Solo.io
+and more. [Join](/join) your industry peers in helping to shape the GraphQL
+ecosystem.
-Organizations interested in becoming members of the GraphQL Foundation or the GraphQL Specification can learn more on our [new member page](/foundation/join). If you have questions about membership, please send an email to membership@graphql.org.
+Organizations interested in becoming members of the GraphQL Foundation or the
+GraphQL Specification can learn more on our [new member page](/foundation/join).
+If you have questions about membership, please send an email to
+membership@graphql.org.
## Growing the GraphQL end user community
-We offer multiple opportunities for end users to contribute and have their voices heard. Companies that use GraphQL technologies internally, but do not sell any GraphQL services externally, are eligible to join the end user community.
+We offer multiple opportunities for end users to contribute and have their
+voices heard. Companies that use GraphQL technologies internally, but do not
+sell any GraphQL services externally, are eligible to join the end user
+community.
-Our end user community is growing, and we finished 2019 with 83 top companies and startups that are committed to accelerating the adoption of GraphQL and improving the developer experience. Please email us for more information at membership@graphql.org.
+Our end user community is growing, and we finished 2019 with 83 top companies
+and startups that are committed to accelerating the adoption of GraphQL and
+improving the developer experience. Please email us for more information at
+membership@graphql.org.
## How do I get involved?
-GraphQL is first and foremost an open source project, and developers can contribute to the project at https://github.com/graphql. Organizations interested in becoming members of the GraphQL Foundation or participating in development of the GraphQL Specification can learn more on our [new member page](/join). If you have questions about membership, please send an email to [membership@graphql.org](mailto:membership@graphql.org).
+GraphQL is first and foremost an open source project, and developers can
+contribute to the project at https://github.com/graphql. Organizations
+interested in becoming members of the GraphQL Foundation or participating in
+development of the GraphQL Specification can learn more on our
+[new member page](/join). If you have questions about membership, please send an
+email to [membership@graphql.org](mailto:membership@graphql.org).
## Events 2019
-In addition to multiple community events, GraphQL Summit 2019 was held in San Francisco, and GraphQL Asia 2019 was held in Bangalore.
+In addition to multiple community events, GraphQL Summit 2019 was held in San
+Francisco, and GraphQL Asia 2019 was held in Bangalore.
### Attendee feedback
@@ -96,53 +145,91 @@ export const html = (
## Community updates
-The GraphQL community is fortunate to have an active and engaged group of companies participating in the GraphQL Foundation.
+The GraphQL community is fortunate to have an active and engaged group of
+companies participating in the GraphQL Foundation.
### Why our members use GraphQL
export const style = {
textAlign: "center",
- padding: "40px 0 20px",
+ padding: "40px 0 20px"
}
export const style2 = {
width: 200,
- maxHeight: 150,
+ maxHeight: 150
}
<div className="[&_img]:mx-auto [&_img]:max-h-28">
-"GraphQL is a transformative technology that saves time and money for every team building rich, user-centric applications. **Apollo** is proud to play a central role in its rapid rise and maturation in 2019. Apollo’s industry-leading open source and cloud services power many of the world’s most significant online properties, including Expedia, Airbnb, PayPal, The New York Times, SurveyMonkey and thousands more. Apollo also hosts the world’s largest event dedicated to this technology - GraphQL Summit - which in 2019 featured more than 1,200 attendees and over 60 technical talks from some of the world’s most recognizable brands that are already benefiting from GraphQL."
+"GraphQL is a transformative technology that saves time and money for every team
+building rich, user-centric applications. **Apollo** is proud to play a central
+role in its rapid rise and maturation in 2019. Apollo’s industry-leading open
+source and cloud services power many of the world’s most significant online
+properties, including Expedia, Airbnb, PayPal, The New York Times, SurveyMonkey
+and thousands more. Apollo also hosts the world’s largest event dedicated to
+this technology - GraphQL Summit - which in 2019 featured more than 1,200
+attendees and over 60 technical talks from some of the world’s most recognizable
+brands that are already benefiting from GraphQL."
-"Collaborating with the Open Source community is always special; it has allowed **AWS** to improve and better understand the use cases that customers want to tackle, such as local mocking and testing. In order to move fast and ensure that we were releasing a valuable feature, we worked for several months with community members. We want to give a special thanks to Conduit Ventures for their significant contributions to the new Amplify local mocking environment."
+"Collaborating with the Open Source community is always special; it has allowed
+**AWS** to improve and better understand the use cases that customers want to
+tackle, such as local mocking and testing. In order to move fast and ensure that
+we were releasing a valuable feature, we worked for several months with
+community members. We want to give a special thanks to Conduit Ventures for
+their significant contributions to the new Amplify local mocking environment."
-"GraphQL has been a huge accelerator for how **Expedia Group's** web application and service teams build APIs. Being part of the open source community is a priority for us in how we contribute back and learn from others on the same journey."
+"GraphQL has been a huge accelerator for how **Expedia Group's** web application
+and service teams build APIs. Being part of the open source community is a
+priority for us in how we contribute back and learn from others on the same
+journey."
-"GraphQL is a rare technology that simultaneously improves the communication between _machines_ and between _humans!_ Data becomes easier to explore and consume for humans and GraphQL's spec driven design allows the creation of tools that can automate complex tasks around data fetching on the server and data management on the client. **Hasura's** flagship GraphQL engine automates complex data access work while giving API consumers an API they love using!"
+"GraphQL is a rare technology that simultaneously improves the communication
+between _machines_ and between _humans!_ Data becomes easier to explore and
+consume for humans and GraphQL's spec driven design allows the creation of tools
+that can automate complex tasks around data fetching on the server and data
+management on the client. **Hasura's** flagship GraphQL engine automates complex
+data access work while giving API consumers an API they love using!"
-"**IBM** is pleased to be an active member of the Linux Foundation's GraphQL project by participating on its technical working group and as a founding member of its Governing Board. IBM continued its commitment to innovating on key open technologies such as GraphQL in 2019."
+"**IBM** is pleased to be an active member of the Linux Foundation's GraphQL
+project by participating on its technical working group and as a founding member
+of its Governing Board. IBM continued its commitment to innovating on key open
+technologies such as GraphQL in 2019."
-"At **Novvum**, our team is tiny, but we try to contribute to the foundation and open source community whenever possible. A few projects that come to mind are graphql-playground, graphql-weekly, graphql-birdseye, and the graphql edX course. GraphQL enables teams to focus on their bottom line and less on the nuances of software development. It provides the freedom necessary for frontend devs, UI/UX designers, content marketers, etc. to make incredible stuff without compromising the safety, flexibility, and stability desired by backend teams. It's come a long way since the early days. We are not surprised to see so many big named companies adopting it today."
+"At **Novvum**, our team is tiny, but we try to contribute to the foundation and
+open source community whenever possible. A few projects that come to mind are
+graphql-playground, graphql-weekly, graphql-birdseye, and the graphql edX
+course. GraphQL enables teams to focus on their bottom line and less on the
+nuances of software development. It provides the freedom necessary for frontend
+devs, UI/UX designers, content marketers, etc. to make incredible stuff without
+compromising the safety, flexibility, and stability desired by backend teams.
+It's come a long way since the early days. We are not surprised to see so many
+big named companies adopting it today."
-"GraphQL has been a complete game changer in the way **PayPal** thinks about data, fetch data and build applications."
+"GraphQL has been a complete game changer in the way **PayPal** thinks about
+data, fetch data and build applications."
-"**Salsify** provides a commerce and content platform that enables the world's largest brands to deliver engaging product experiences across the digital shelf. Our GraphQL powered APIs enable us to support a diverse set of integrated use cases on an extensible microservices platform architecture with great developer ergonomics and excellent performance."
+"**Salsify** provides a commerce and content platform that enables the world's
+largest brands to deliver engaging product experiences across the digital shelf.
+Our GraphQL powered APIs enable us to support a diverse set of integrated use
+cases on an extensible microservices platform architecture with great developer
+ergonomics and excellent performance."
---
@@ -150,51 +237,111 @@ export const style2 = {
-**Expedia Group** continues to rapidly adopt GraphQL. Over the last 2 years we have transitioned our REST APIs to GraphQL – and now over 90% of all customer interactions in web and native[vrbo.com](http://vrbo.com) apps are powered by GraphQL APIs and over 30% of all customer interactions on Expedia.com as well as other brands such as Hotels.com.
+**Expedia Group** continues to rapidly adopt GraphQL. Over the last 2 years we
+have transitioned our REST APIs to GraphQL – and now over 90% of all customer
+interactions in web and native[vrbo.com](http://vrbo.com) apps are powered by
+GraphQL APIs and over 30% of all customer interactions on Expedia.com as well as
+other brands such as Hotels.com.
-**Facebook** has used GraphQL to power our production mobile apps for the last 7.5 years, from its creation as an internal API in 2012 to its open sourcing in 2015 and beyond. In 2020, we’re as invested in the community and the technology as ever — we're [discussing our approach to streaming semantics with the GraphQL working group](https://github.com/graphql/graphql-wg/issues/329), and we’re [powering the new Facebook.com with GraphQL and Relay](https://developers.facebook.com/videos/2019/building-the-new-facebookcom-with-react-graphql-and-relay).
+**Facebook** has used GraphQL to power our production mobile apps for the last
+7.5 years, from its creation as an internal API in 2012 to its open sourcing in
+2015 and beyond. In 2020, we’re as invested in the community and the technology
+as ever — we're
+[discussing our approach to streaming semantics with the GraphQL working group](https://github.com/graphql/graphql-wg/issues/329),
+and we’re
+[powering the new Facebook.com with GraphQL and Relay](https://developers.facebook.com/videos/2019/building-the-new-facebookcom-with-react-graphql-and-relay).
-**Novvum** had been deploying graphql into production for the majority of our customers since its inception back in 2015. On any project, we find it extremely beneficial to add GraphQL as the primary communication layer between clients and the data that they need. From building car-sharing platforms on a time crunch to architecting fintech infrastructure to scaffolding MVPs for early-stage startups, we've observed many short- and long-term benefits by introducing GraphQL.
+**Novvum** had been deploying graphql into production for the majority of our
+customers since its inception back in 2015. On any project, we find it extremely
+beneficial to add GraphQL as the primary communication layer between clients and
+the data that they need. From building car-sharing platforms on a time crunch to
+architecting fintech infrastructure to scaffolding MVPs for early-stage
+startups, we've observed many short- and long-term benefits by introducing
+GraphQL.
-**PayPal** uses GraphQL to power many of our products and user experiences including PayPal Checkout, our flagship product that facilitates payments for millions of merchants and users.
+**PayPal** uses GraphQL to power many of our products and user experiences
+including PayPal Checkout, our flagship product that facilitates payments for
+millions of merchants and users.
---
### Member contributions to the GraphQL ecosystem
-Our members have been active and engaged participants in the GraphQL ecosystem. Here are some of the ways in which our ecosystem has been enriched through their participation.
+Our members have been active and engaged participants in the GraphQL ecosystem.
+Here are some of the ways in which our ecosystem has been enriched through their
+participation.
-- **[Apollo Graph Manager](https://apollographql.com/docs/graph-manager):** Tools and services for teams collaborating on a data graph, including a central schema registry, data graph analytics, workflows for developing and maintaining agile schemas, and machinery for managing graph security and policy and operations.
-- **[Federation](https://apollographql.com/docs/apollo-server/federation/introduction):** An open specification for composing multiple GraphQL services into a single data graph. The specification has been widely supported by the GraphQL community, with JavaScript, Kotlin, Java, Go, Python, Ruby, and PHP servers all adopting the federation programming model.
-- **[Apollo Client](https://apollographql.com/docs/react/v3.0-beta):** The industry’s most popular open-source library for connecting application UI to a GraphQL service. The upcoming Apollo Client 3, currently in beta, introduces a flexible data cache and brings many improvements to managing both local state and remote data.
-- **[Apollo Server](https://apollographql.com/docs/apollo-server):** An open-source library for building a data graph in JavaScript that’s incrementally adoptable, production-ready, and compatible with any data source. Apollo Server defines the de-facto standard for GraphQL over HTTP and supports essential features for running GraphQL at scale such as federation, tracing, and caching.
-- **[Apollo developer tooling](https://github.com/apollographql/apollo-tooling):** The Apollo tooling repository is home to several open-source GraphQL developer tools, including the Apollo CLI and VS Code extension. These tools connect to the Apollo registry, a central hub for managing your data graph, in order to provide workflows for an excellent developer experience.
+- **[Apollo Graph Manager](https://apollographql.com/docs/graph-manager):**
+ Tools and services for teams collaborating on a data graph, including a
+ central schema registry, data graph analytics, workflows for developing and
+ maintaining agile schemas, and machinery for managing graph security and
+ policy and operations.
+- **[Federation](https://apollographql.com/docs/apollo-server/federation/introduction):**
+ An open specification for composing multiple GraphQL services into a single
+ data graph. The specification has been widely supported by the GraphQL
+ community, with JavaScript, Kotlin, Java, Go, Python, Ruby, and PHP servers
+ all adopting the federation programming model.
+- **[Apollo Client](https://apollographql.com/docs/react/v3.0-beta):** The
+ industry’s most popular open-source library for connecting application UI to a
+ GraphQL service. The upcoming Apollo Client 3, currently in beta, introduces a
+ flexible data cache and brings many improvements to managing both local state
+ and remote data.
+- **[Apollo Server](https://apollographql.com/docs/apollo-server):** An
+ open-source library for building a data graph in JavaScript that’s
+ incrementally adoptable, production-ready, and compatible with any data
+ source. Apollo Server defines the de-facto standard for GraphQL over HTTP and
+ supports essential features for running GraphQL at scale such as federation,
+ tracing, and caching.
+- **[Apollo developer tooling](https://github.com/apollographql/apollo-tooling):**
+ The Apollo tooling repository is home to several open-source GraphQL developer
+ tools, including the Apollo CLI and VS Code extension. These tools connect to
+ the Apollo registry, a central hub for managing your data graph, in order to
+ provide workflows for an excellent developer experience.
-- **[GraphQL Kotlin](https://github.com/ExpediaGroup/graphql-kotlin):** Continued work on GraphQL Kotlin libraries for running GraphQL Server, including code first-schema generation and a Spring Boot based Kotlin Graphql Server. This technology powers Expedia.com and its fleet of brands like Orbitz, Wotif, & Travelocity
-- **[GraphQL Component](https://github.com/ExpediaGroup/graphql-component):** GraphQL Component is a modular graphql schema framework in javascript being utilized to build APIs for Vrbo travel and owner applications, as well as partner services and public APIs.
+- **[GraphQL Kotlin](https://github.com/ExpediaGroup/graphql-kotlin):**
+ Continued work on GraphQL Kotlin libraries for running GraphQL Server,
+ including code first-schema generation and a Spring Boot based Kotlin Graphql
+ Server. This technology powers Expedia.com and its fleet of brands like
+ Orbitz, Wotif, & Travelocity
+- **[GraphQL Component](https://github.com/ExpediaGroup/graphql-component):**
+ GraphQL Component is a modular graphql schema framework in javascript being
+ utilized to build APIs for Vrbo travel and owner applications, as well as
+ partner services and public APIs.
-- **[GraphQL Engine](https://github.com/hasura/graphql-engine):** An open-source GraphQL engine for Postgres and other data sources.
-- **[GraphQURL](https://github.com/hasura/graphqurl):** A command like utility like curl for GraphQL, with autocomplete and support for subscriptions.
-- **[graphql-bench](https://github.com/hasura/graphql-bench):** A GraphQL benchmarking suite to make it easy for developers to test the performance of their GraphQL servers.
-- **[learn-graphql](https://github.com/hasura/learn-graphql):** Open-source tutorials for almost all frontend application stacks to get started with GraphQL.
+- **[GraphQL Engine](https://github.com/hasura/graphql-engine):** An open-source
+ GraphQL engine for Postgres and other data sources.
+- **[GraphQURL](https://github.com/hasura/graphqurl):** A command like utility
+ like curl for GraphQL, with autocomplete and support for subscriptions.
+- **[graphql-bench](https://github.com/hasura/graphql-bench):** A GraphQL
+ benchmarking suite to make it easy for developers to test the performance of
+ their GraphQL servers.
+- **[learn-graphql](https://github.com/hasura/learn-graphql):** Open-source
+ tutorials for almost all frontend application stacks to get started with
+ GraphQL.
-- **[OpenAPI-to-GraphQL](https://github.com/IBM/openapi-to-graphql):** Released the open-source OpenAPI-to-GraphQL library, which generates GraphQL interfaces on top of existing REST APIs. IBM made numerous other contributions to the open source community.
-- **[libgraphqlparser](https://github.com/graphql/libgraphqlparser):** Delivered improvements to the open source GraphQL C++ library
-- **[Loopback 4 OpenAPI-to-GraphQL](https://loopback.io/doc/en/lb4/exposing-graphql-apis.html):** Released Loopback 4 "OpenAPI-to-GraphQL" module that creates a GraphQL wrapper for REST APIs which are described by an OpenAPI specification
+- **[OpenAPI-to-GraphQL](https://github.com/IBM/openapi-to-graphql):** Released
+ the open-source OpenAPI-to-GraphQL library, which generates GraphQL interfaces
+ on top of existing REST APIs. IBM made numerous other contributions to the
+ open source community.
+- **[libgraphqlparser](https://github.com/graphql/libgraphqlparser):** Delivered
+ improvements to the open source GraphQL C++ library
+- **[Loopback 4 OpenAPI-to-GraphQL](https://loopback.io/doc/en/lb4/exposing-graphql-apis.html):**
+ Released Loopback 4 "OpenAPI-to-GraphQL" module that creates a GraphQL wrapper
+ for REST APIs which are described by an OpenAPI specification
---
@@ -240,8 +387,10 @@ Our members have been active and engaged participants in the GraphQL ecosystem.
-- Co-organized the [GraphQL London Meetup group](https://meetup.com/GraphQL-London)
-- Co-organized the [GraphQL San Francisco Meetup group](https://meetup.com/GraphQL-SF)
+- Co-organized the
+ [GraphQL London Meetup group](https://meetup.com/GraphQL-London)
+- Co-organized the
+ [GraphQL San Francisco Meetup group](https://meetup.com/GraphQL-SF)
- [Archive of Meetup talks](https://youtube.com/c/GraphQLTalks).
- [Building modern APIs with GraphQL](https://youtube.com/watch?v=bRnu7xvU1_Y)
@@ -260,47 +409,106 @@ Our members have been active and engaged participants in the GraphQL ecosystem.
</div>
- [GraphQL sessions at 2019 API Conference, Berlin](https://apiconference.net)
-- Demonstrated GraphQL API Management in IBM API Connect and IBM DataPower® Gateway enabling determination of GraphQL query characteristics, advanced threat protection, customized rate limiting, and API plan configuration
+- Demonstrated GraphQL API Management in IBM API Connect and IBM DataPower®
+ Gateway enabling determination of GraphQL query characteristics, advanced
+ threat protection, customized rate limiting, and API plan configuration
- [Conducted IBM Developer Meetups where GraphQL work was highlighted in talks and technical demonstrations](https://meetup.com/ibmcodenyc/events/266535427)
## Training
-The GraphQL Foundation is proud to offer a new, free course – [Exploring GraphQL: A Query Language for APIs](https://edx.org/course/introduction-to-graphql) – through [edX](https://edx.org) which we have had thousands already sign up for.
+The GraphQL Foundation is proud to offer a new, free course –
+[Exploring GraphQL: A Query Language for APIs](https://edx.org/course/introduction-to-graphql)
+– through [edX](https://edx.org) which we have had thousands already sign up
+for.
-If you are a programmer, this course will help you gain the skills you need to get started using GraphQL for a small project, or professionally in production. We cover a variety of tools to address multiple use cases.
+If you are a programmer, this course will help you gain the skills you need to
+get started using GraphQL for a small project, or professionally in production.
+We cover a variety of tools to address multiple use cases.
-If you are nontechnical, this course will help you communicate with developers and participate in conversations about GraphQL, and understand when and why to use GraphQL for a project.
+If you are nontechnical, this course will help you communicate with developers
+and participate in conversations about GraphQL, and understand when and why to
+use GraphQL for a project.
## Community engagement
-Want to start a meetup? Drop us a line, we’d love to hear your idea: info@graphql.org.
+Want to start a meetup? Drop us a line, we’d love to hear your idea:
+info@graphql.org.
## GraphQL landscape
-The [GraphQL Interactive Landscape](https://landscape.graphql.org) was recently published by the GraphQL Foundation.
+The [GraphQL Interactive Landscape](https://landscape.graphql.org) was recently
+published by the GraphQL Foundation.
-What is an interactive landscape? The concept started when the CNCF began the process of cataloging different types of tools for building out a cloud native architecture. This led to the creation of the CNCF Interactive Landscape. Turns out this tool became very helpful to all of us sorting out this new and exciting space. In the interest of providing a similar reference, the GraphQL Foundation defined their own version of the interactive landscape, including also adopters of GraphQL technology.
+What is an interactive landscape? The concept started when the CNCF began the
+process of cataloging different types of tools for building out a cloud native
+architecture. This led to the creation of the CNCF Interactive Landscape. Turns
+out this tool became very helpful to all of us sorting out this new and exciting
+space. In the interest of providing a similar reference, the GraphQL Foundation
+defined their own version of the interactive landscape, including also adopters
+of GraphQL technology.
-The landscape is open source, and contributions from the community are welcomed. You can find guidelines for updating the landscape at: https://github.com/graphql/graphql-landscape.
+The landscape is open source, and contributions from the community are welcomed.
+You can find guidelines for updating the landscape at:
+https://github.com/graphql/graphql-landscape.
## Devstats
-The [DevStats](https://github.com/cncf/devstats) tool, which is open source, downloads data representing every public GitHub action across GraphQL Foundation projects and stores it in a queryable [Postgres](https://postgresql.org) database. DevStats downloads updated data every hour, and you can check out the tool here: https://devstats.graphql.org.
+The [DevStats](https://github.com/cncf/devstats) tool, which is open source,
+downloads data representing every public GitHub action across GraphQL Foundation
+projects and stores it in a queryable [Postgres](https://postgresql.org)
+database. DevStats downloads updated data every hour, and you can check out the
+tool here: https://devstats.graphql.org.
## A look ahead to 2020
-As the Executive Director of the GraphQL project, I hope I can speak for the whole community when I say we are looking forward to another productive year of GraphQL development. We are putting the final touches on the GraphQL 2020 spec release, and continue to make great progress developing new features, stabilizing existing ones, and exploring beyond core GraphQL.
-
-It has been really encouraging to see GraphQL continue to evolve over the past year as a technology and as a community. GraphQL is being used at scale by not only Facebook but now a great number of organizations large and small. As I said when first introducing the project, GraphQL is unapologetically driven by the needs of the client. This has been a critical aspect of GraphQL's success, and it is great to see this principle reflect itself in our community, where those more interested in consuming APIs than producing them have come together to support the ongoing sustainability of the project.
-
-Since establishing the GraphQL Foundation, we've had an outpouring of support from these companies. This neutral, non-profit home for the GraphQL project has provided a healthy way for users, contributors, and supporters to collaborate and contribute funding in support of our programs and collaborative processes. For example, this support has enabled us to support long-time contributor Ivan Goncharov to focus on crucial development and maintenance of the reference implementation, specification and other community gardening work. It has also allowed us to launch a free GraphQL edX course, and has enabled us to take some first steps toward supporting and producing community events.
-
-Development of the GraphQL spec has remained open to all contributors. Over the last year we've brought more rigor and clarity to the development process. I've found it encouraging that contributions have been a healthy mix of aspirational new features and iterative improvements to the stable base. This demonstrates that GraphQL is evolving in meaningful ways to address exciting new use cases while also building confidence and stability around what thousands of companies use in production every day. Both of these are essential for GraphQL's long term success.
-
-Looking ahead, I have great optimism for GraphQL and see huge opportunities. First, we've been hard at work on the 2020 spec and that release is imminent. Spec development continues to accelerate and exciting advancements and improvements are underway for the 2021 release and beyond. Second, we have been accepted to participate in Google Summer of Code and are looking forward to adding these talented students as project collaborators. Third, the communities around the core GraphQL project are collaborating. For example, GraphiQL and Playground recently announced they will be joining efforts to build better tools for us all.
-
-Thank you again for your involvement in this project and your support of the GraphQL Foundation. I am pleased with our progress and am looking forward to another productive year.
+As the Executive Director of the GraphQL project, I hope I can speak for the
+whole community when I say we are looking forward to another productive year of
+GraphQL development. We are putting the final touches on the GraphQL 2020 spec
+release, and continue to make great progress developing new features,
+stabilizing existing ones, and exploring beyond core GraphQL.
+
+It has been really encouraging to see GraphQL continue to evolve over the past
+year as a technology and as a community. GraphQL is being used at scale by not
+only Facebook but now a great number of organizations large and small. As I said
+when first introducing the project, GraphQL is unapologetically driven by the
+needs of the client. This has been a critical aspect of GraphQL's success, and
+it is great to see this principle reflect itself in our community, where those
+more interested in consuming APIs than producing them have come together to
+support the ongoing sustainability of the project.
+
+Since establishing the GraphQL Foundation, we've had an outpouring of support
+from these companies. This neutral, non-profit home for the GraphQL project has
+provided a healthy way for users, contributors, and supporters to collaborate
+and contribute funding in support of our programs and collaborative processes.
+For example, this support has enabled us to support long-time contributor Ivan
+Goncharov to focus on crucial development and maintenance of the reference
+implementation, specification and other community gardening work. It has also
+allowed us to launch a free GraphQL edX course, and has enabled us to take some
+first steps toward supporting and producing community events.
+
+Development of the GraphQL spec has remained open to all contributors. Over the
+last year we've brought more rigor and clarity to the development process. I've
+found it encouraging that contributions have been a healthy mix of aspirational
+new features and iterative improvements to the stable base. This demonstrates
+that GraphQL is evolving in meaningful ways to address exciting new use cases
+while also building confidence and stability around what thousands of companies
+use in production every day. Both of these are essential for GraphQL's long term
+success.
+
+Looking ahead, I have great optimism for GraphQL and see huge opportunities.
+First, we've been hard at work on the 2020 spec and that release is imminent.
+Spec development continues to accelerate and exciting advancements and
+improvements are underway for the 2021 release and beyond. Second, we have been
+accepted to participate in Google Summer of Code and are looking forward to
+adding these talented students as project collaborators. Third, the communities
+around the core GraphQL project are collaborating. For example, GraphiQL and
+Playground recently announced they will be joining efforts to build better tools
+for us all.
+
+Thank you again for your involvement in this project and your support of the
+GraphQL Foundation. I am pleased with our progress and am looking forward to
+another productive year.
_– Lee Byron, Executive Director, GraphQL Foundation, and GraphQL Co-Creator_
diff --git a/src/pages/community/foundation/community-grant.mdx b/src/pages/community/foundation/community-grant.mdx
index 5bb17964de..2e5e865c4e 100644
--- a/src/pages/community/foundation/community-grant.mdx
+++ b/src/pages/community/foundation/community-grant.mdx
@@ -18,9 +18,9 @@ upon funding that is received as membership dues for the GraphQL Foundation.
This is one way in which the GraphQL Foundation directly supports the ongoing
health of the GraphQL developer ecosystem.
-We encourage you to be creative in your grant application, and
-propose tasks that are straightforward to articulate, achievable in three
-months, and bounded in scope.
+We encourage you to be creative in your grant application, and propose tasks
+that are straightforward to articulate, achievable in three months, and bounded
+in scope.
Examples include:
@@ -33,7 +33,8 @@ Examples include:
- Other user experience improvement ideas for the [graphql.org][] website and/or
[github.com/graphql][]
-We are not funding work on projects outside https://github.com/graphql/ at this time.
+We are not funding work on projects outside https://github.com/graphql/ at this
+time.
## How to apply
@@ -116,4 +117,5 @@ If you have questions, please contact [operations@graphql.org][].
[github.com/graphql]: https://github.com/graphql
[operations@graphql.org]: mailto:operations@graphql.org
[agreement-preview]: https://grantee-agreement-preview.graphql.org
-[application-form]: https://docs.google.com/forms/d/e/1FAIpQLSciopqGoQE2hBhxsb5E6dq12VrD221Zv4dsGWa1nQM35FT1nA/viewform?usp=sf_link
+[application-form]:
+ https://docs.google.com/forms/d/e/1FAIpQLSciopqGoQE2hBhxsb5E6dq12VrD221Zv4dsGWa1nQM35FT1nA/viewform?usp=sf_link
diff --git a/src/pages/community/foundation/contact.mdx b/src/pages/community/foundation/contact.mdx
index 1c89a6c4a7..49ef2c1722 100644
--- a/src/pages/community/foundation/contact.mdx
+++ b/src/pages/community/foundation/contact.mdx
@@ -4,13 +4,16 @@ description: The GraphQL Foundation is here to help.
# Contact the GraphQL Foundation
-The GraphQL Foundation is supported by staff from [The Linux Foundation](https://linuxfoundation.org). If you have questions, please reach out to us using the links below.
+The GraphQL Foundation is supported by staff from
+[The Linux Foundation](https://linuxfoundation.org). If you have questions,
+please reach out to us using the links below.
-import { Callout } from 'nextra/components'
+import { Callout } from "nextra/components"
<Callout type="warning">
- **Please note:** we do not provide user support for GraphQL. If you have an implementation question,
- please use the [relevant community channels](/community).
+ **Please note:** we do not provide user support for GraphQL. If you have an
+ implementation question, please use the [relevant community
+ channels](/community).
</Callout>
## Membership Inquiries
@@ -20,33 +23,47 @@ If you would like to learn more about becoming a GraphQL member, please email
## Membership Support
-If you are already a member of the [GraphQL Foundation](/foundation/) and you need help with your membership, please file an issue with our [member service desk](https://members.graphql.org).
+If you are already a member of the [GraphQL Foundation](/foundation/) and you
+need help with your membership, please file an issue with our
+[member service desk](https://members.graphql.org).
## Meeting Logistics
-Governing board and Working Group members who need help with meeting logistics (setting up a Zoom conference, adding or changing a calendar entry, designating an alternate representative, etc.) can reach out through our [member service desk](https://members.graphql.org).
+Governing board and Working Group members who need help with meeting logistics
+(setting up a Zoom conference, adding or changing a calendar entry, designating
+an alternate representative, etc.) can reach out through our
+[member service desk](https://members.graphql.org).
## Trademark Requests
-For guidance using the GraphQL trademark and brand see our [brand guidelines](/brand). For trademark licensing questions or requests please reach out to [info@graphql.org](mailto:info@graphql.org?subject=Trademark%20Request).
+For guidance using the GraphQL trademark and brand see our
+[brand guidelines](/brand). For trademark licensing questions or requests please
+reach out to
+[info@graphql.org](mailto:info@graphql.org?subject=Trademark%20Request).
## Media Inquiries
-For media inquiries, please reach out to [pr@graphql.org](mailto:pr@graphql.org).
+For media inquiries, please reach out to
+[pr@graphql.org](mailto:pr@graphql.org).
## Meetup Promotion
-If you are interested in hosting a GraphQL meetup, The GraphQL Foundation is happy to promote your GraphQL event through the [official communication channels](/community/#official-channels).
+If you are interested in hosting a GraphQL meetup, The GraphQL Foundation is
+happy to promote your GraphQL event through the
+[official communication channels](/community/#official-channels).
-Please contact us in the `#meetups-admin` channel on [the community Discord channel](/community/#official-channels).
+Please contact us in the `#meetups-admin` channel on
+[the community Discord channel](/community/#official-channels).
## Technical Issues
-To report a technical issue with GraphQL, please use the [community channels](/community/).
+To report a technical issue with GraphQL, please use the
+[community channels](/community/).
## General
-For all other inquiries, please email [info@graphql.org](mailto:info@graphql.org).
+For all other inquiries, please email
+[info@graphql.org](mailto:info@graphql.org).
Our mailing address is:
diff --git a/src/pages/community/foundation/graphql-conf.mdx b/src/pages/community/foundation/graphql-conf.mdx
index c9400e0405..402a57af38 100644
--- a/src/pages/community/foundation/graphql-conf.mdx
+++ b/src/pages/community/foundation/graphql-conf.mdx
@@ -4,27 +4,42 @@ description: The official GraphQL conference, hosted by the GraphQL Foundation.
# GraphQL Conf
-By the community and for the community, GraphQLConf is a vendor-neutral event that brings together core contributors, community members, open source leaders, academics, vendors, and industry practitioners to discuss recent work, share techniques, and plan for the future.
+By the community and for the community, GraphQLConf is a vendor-neutral event
+that brings together core contributors, community members, open source leaders,
+academics, vendors, and industry practitioners to discuss recent work, share
+techniques, and plan for the future.
## GraphQLConf 2024
-We're looking forward to [GraphQLConf 2024](/conf/2024) in SF Bay Area, CA on September 10-12, 2024.
+We're looking forward to [GraphQLConf 2024](/conf/2024) in SF Bay Area, CA on
+September 10-12, 2024.
-Join us by [registering](/conf/2024), consider [submitting a talk](/conf/2024/speak), and help produce an incredible event by [sponsoring us](/conf/2024/sponsor).
+Join us by [registering](/conf/2024), consider
+[submitting a talk](/conf/2024/speak), and help produce an incredible event by
+[sponsoring us](/conf/2024/sponsor).
## GraphQLConf 2023
-GraphQL Conf 2023 marked a major success! [See the recorded sessions](/conf/2023/sessions).
+GraphQL Conf 2023 marked a major success!
+[See the recorded sessions](/conf/2023/sessions).
## GraphQLConf 2022
-The GraphQL Foundation's inaugural GraphQL Conf was co-located with [OpenJS World](https://events.linuxfoundation.org/openjs-world/) and [cdCon](https://events.linuxfoundation.org/cdcon/) in Austin, TX on June 7-8, 2022. This collaborator summit-style event provided an opportunity for core GraphQL spec and implementation developers to meet in-person, discuss recent work, and plan for the future. All attendees of OpenJS World and cdCon were welcome.
+The GraphQL Foundation's inaugural GraphQL Conf was co-located with
+[OpenJS World](https://events.linuxfoundation.org/openjs-world/) and
+[cdCon](https://events.linuxfoundation.org/cdcon/) in Austin, TX on June
+7-8, 2022. This collaborator summit-style event provided an opportunity for core
+GraphQL spec and implementation developers to meet in-person, discuss recent
+work, and plan for the future. All attendees of OpenJS World and cdCon were
+welcome.
Talks covered:
-- Recent activity in the GraphQL specification working group, such as Defer and Stream, Input Unions, and Client-Controlled Nullability.
+- Recent activity in the GraphQL specification working group, such as Defer and
+ Stream, Input Unions, and Client-Controlled Nullability.
- Downstream implementations of GraphQL
- Security considerations
- Common practices and lessons learned
-Recordings of the sessions are available on [our YouTube channel](https://youtube.graphql.org).
+Recordings of the sessions are available on
+[our YouTube channel](https://youtube.graphql.org).
diff --git a/src/pages/community/foundation/index.mdx b/src/pages/community/foundation/index.mdx
index 4a3b9d69fc..259bbf2b78 100644
--- a/src/pages/community/foundation/index.mdx
+++ b/src/pages/community/foundation/index.mdx
@@ -1,16 +1,32 @@
---
-description: An open and neutral home for the GraphQL community, dedicated to promoting widespread adoption and accelerating development of the surrounding ecosystem
+description:
+ An open and neutral home for the GraphQL community, dedicated to promoting
+ widespread adoption and accelerating development of the surrounding ecosystem
---
# What is the GraphQL Foundation?
-The **GraphQL Foundation** is a neutral foundation founded by global technology and application development companies. The GraphQL Foundation encourages contributions, stewardship, and a shared investment from a broad group in vendor-neutral events, documentation, tools, and support for GraphQL.
+The **GraphQL Foundation** is a neutral foundation founded by global technology
+and application development companies. The GraphQL Foundation encourages
+contributions, stewardship, and a shared investment from a broad group in
+vendor-neutral events, documentation, tools, and support for GraphQL.
-GraphQL was created in 2012 and open sourced by Facebook in 2015. In 2019, Facebook and others [created the GraphQL Foundation](https://foundation.graphql.org/news/2019/03/12/the-graphql-foundation-announces-collaboration-with-the-joint-development-foundation-to-drive-open-source-and-open-standards/) as a neutral, non-profit home for the GraphQL assets and ongoing collaboration, and hosted by [The Linux Foundation](https://linuxfoundation.org). The GraphQL Foundation is a fully neutral home for the GraphQL trademark, and provides a means of collecting and distributing membership dues to support core community infrastructure and programs.
+GraphQL was created in 2012 and open sourced by Facebook in 2015. In 2019,
+Facebook and others
+[created the GraphQL Foundation](https://foundation.graphql.org/news/2019/03/12/the-graphql-foundation-announces-collaboration-with-the-joint-development-foundation-to-drive-open-source-and-open-standards/)
+as a neutral, non-profit home for the GraphQL assets and ongoing collaboration,
+and hosted by [The Linux Foundation](https://linuxfoundation.org). The GraphQL
+Foundation is a fully neutral home for the GraphQL trademark, and provides a
+means of collecting and distributing membership dues to support core community
+infrastructure and programs.
## The GraphQL Foundation supports the community
-The primary mission of the GraphQL Foundation is to ensure that the GraphQL community is able to focus on the continued evolution of the [specification](https://spec.graphql.org) and [reference implementations](/code/). We accomplish this through a number of core activities:
+The primary mission of the GraphQL Foundation is to ensure that the GraphQL
+community is able to focus on the continued evolution of the
+[specification](https://spec.graphql.org) and
+[reference implementations](/code/). We accomplish this through a number of core
+activities:
- Funding grants for project maintainers and community gardeners.
- Coordinating and funding mentorship programs.
@@ -19,10 +35,17 @@ The primary mission of the GraphQL Foundation is to ensure that the GraphQL comm
- Providing legal support for projects.
- Operational and logistical support through The Linux Foundation.
-The GraphQL Foundation works in close collaboration with the [GraphQL Working Group](https://github.com/graphql/graphql-wg/) and the [GraphQL TSC](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md).
+The GraphQL Foundation works in close collaboration with the
+[GraphQL Working Group](https://github.com/graphql/graphql-wg/) and the
+[GraphQL TSC](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md).
## Members support the GraphQL Foundation
-The GraphQL Foundation would like to thank [our current members](/foundation/members/) for their ongoing support to ensure the sustainability of the GraphQL ecosystem. Learn more about how your company can demonstrate its commitment to GraphQL by [becoming a member of the GraphQL Foundation](https://graphql.org/foundation/join).
+The GraphQL Foundation would like to thank
+[our current members](/foundation/members/) for their ongoing support to ensure
+the sustainability of the GraphQL ecosystem. Learn more about how your company
+can demonstrate its commitment to GraphQL by
+[becoming a member of the GraphQL Foundation](https://graphql.org/foundation/join).
-If you have questions, you can reach out to [membership@graphql.org](mailto:membership@graphql.org).
+If you have questions, you can reach out to
+[membership@graphql.org](mailto:membership@graphql.org).
diff --git a/src/pages/community/foundation/join.mdx b/src/pages/community/foundation/join.mdx
index a7985b1181..86711b2be4 100644
--- a/src/pages/community/foundation/join.mdx
+++ b/src/pages/community/foundation/join.mdx
@@ -1,59 +1,102 @@
---
-description: GraphQL Foundation members demonstrate their commitment to the ecosystem by providing essential financial support.
+description:
+ GraphQL Foundation members demonstrate their commitment to the ecosystem by
+ providing essential financial support.
---
# Become a Member
-There are two primary ways to support the ongoing development and success of GraphQL.
+There are two primary ways to support the ongoing development and success of
+GraphQL.
-- Developers can [join the GraphQL Specification](#graphql-specification), enabling them to contribute code, time, and talent to GraphQL technical projects. This is free for companies and individuals.
+- Developers can [join the GraphQL Specification](#graphql-specification),
+ enabling them to contribute code, time, and talent to GraphQL technical
+ projects. This is free for companies and individuals.
-- Organizations can [join the GraphQL Foundation](#graphql-foundation), which is the non-profit that supports the sustainability of the GraphQL community. This is accomplished through annual membership fees, which are allocated by the Governing Board for the benefit of the GraphQL ecosystem.
+- Organizations can [join the GraphQL Foundation](#graphql-foundation), which is
+ the non-profit that supports the sustainability of the GraphQL community. This
+ is accomplished through annual membership fees, which are allocated by the
+ Governing Board for the benefit of the GraphQL ecosystem.
-If you have a question about which membership is right for you, please reach out to [membership@graphql.org](mailto:membership@graphql.org).
+If you have a question about which membership is right for you, please reach out
+to [membership@graphql.org](mailto:membership@graphql.org).
## GraphQL Specification
-The GraphQL Specification and its related tools and libraries are developed under the Joint Development Foundation, a non-profit organization focused on open standards that is part of The Linux Foundation family.
+The GraphQL Specification and its related tools and libraries are developed
+under the Joint Development Foundation, a non-profit organization focused on
+open standards that is part of The Linux Foundation family.
-Membership in the GraphQL Specification is free, and is required for all who participate in the development process. This includes direct contributions to the specification, participation in meetings and discussions, and contributions to reference implementations and tooling. Joining is simple and straightforward, and all are welcome as members.
+Membership in the GraphQL Specification is free, and is required for all who
+participate in the development process. This includes direct contributions to
+the specification, participation in meetings and discussions, and contributions
+to reference implementations and tooling. Joining is simple and straightforward,
+and all are welcome as members.
-_Please note that you or your employer must sign a specification membership before you can join GraphQL calls and participate in the technical development process._
+_Please note that you or your employer must sign a specification membership
+before you can join GraphQL calls and participate in the technical development
+process._
### [Corporate specification membership](https://corporate-spec-membership.graphql.org)
-If you are planning to work on GraphQL for your employer, please ask an appropriate person to complete the corporate GraphQL Specification Membership application. ([preview](https://preview-spec-membership.graphql.org))
+If you are planning to work on GraphQL for your employer, please ask an
+appropriate person to complete the corporate GraphQL Specification Membership
+application. ([preview](https://preview-spec-membership.graphql.org))
-To join, please open a PR against a GraphQL repo ([instructions](https://corporate-spec-membership.graphql.org)).
+To join, please open a PR against a GraphQL repo
+([instructions](https://corporate-spec-membership.graphql.org)).
### [Individual specification membership](https://individual-spec-membership.graphql.org)
-If you are planning to work on GraphQL as an individual or if you are a student, please complete the individual GraphQL Specification Membership application. ([preview](https://preview-spec-membership.graphql.org))
+If you are planning to work on GraphQL as an individual or if you are a student,
+please complete the individual GraphQL Specification Membership application.
+([preview](https://preview-spec-membership.graphql.org))
-To join, please open a PR against a GraphQL repo ([instructions](https://individual-spec-membership.graphql.org)).
+To join, please open a PR against a GraphQL repo
+([instructions](https://individual-spec-membership.graphql.org)).
-_Please note: If your employer has already signed a specification membership agreement, you do not need to sign a separate agreement as an individual. If your organization is a member of the GraphQL Foundation, you will still need a valid GraphQL Specification membership in order to contribute._
+_Please note: If your employer has already signed a specification membership
+agreement, you do not need to sign a separate agreement as an individual. If
+your organization is a member of the GraphQL Foundation, you will still need a
+valid GraphQL Specification membership in order to contribute._
## GraphQL Foundation
-The GraphQL Foundation is a member-supported, non-profit organization whose mission is to support the long-term health and viability of the [GraphQL ecosystem](https://graphql.org). The GraphQL Foundation is hosted by [The Linux Foundation](https://linuxfoundation.org), the 501(c)6 non-profit home of Linux and many other open source collaborative projects.
+The GraphQL Foundation is a member-supported, non-profit organization whose
+mission is to support the long-term health and viability of the
+[GraphQL ecosystem](https://graphql.org). The GraphQL Foundation is hosted by
+[The Linux Foundation](https://linuxfoundation.org), the 501(c)6 non-profit home
+of Linux and many other open source collaborative projects.
-The GraphQL Foundation is entirely supported by [end-users, vendors, service providers, and consultants](/foundation/members) who recognize the importance of ensuring the long-term viability of neutral, collaborative development. The GraphQL Foundation is funded through participation fees, which are allocated by the governing board in ways that benefit the development community.
+The GraphQL Foundation is entirely supported by
+[end-users, vendors, service providers, and consultants](/foundation/members)
+who recognize the importance of ensuring the long-term viability of neutral,
+collaborative development. The GraphQL Foundation is funded through
+participation fees, which are allocated by the governing board in ways that
+benefit the development community.
### Benefits of membership
-The GraphQL Foundation Governing Board is responsible for setting high-level policy and allocating the GraphQL Foundation budget in ways that benefit the technical community.
+The GraphQL Foundation Governing Board is responsible for setting high-level
+policy and allocating the GraphQL Foundation budget in ways that benefit the
+technical community.
-The first 20 members of the GraphQL Foundation participate as voting members of the Governing Board. Any additional members vote to select up to five additional seats.
+The first 20 members of the GraphQL Foundation participate as voting members of
+the Governing Board. Any additional members vote to select up to five additional
+seats.
### How to join
-To [join the GraphQL Foundation](https://join.graphql.org), organizations become a member of the Linux Foundation and sign the GraphQL Foundation participation agreement. The GraphQL Foundation annual fee is received into a fund managed by the GraphQL Foundation Governing Board.
+To [join the GraphQL Foundation](https://join.graphql.org), organizations become
+a member of the Linux Foundation and sign the GraphQL Foundation participation
+agreement. The GraphQL Foundation annual fee is received into a fund managed by
+the GraphQL Foundation Governing Board.
- [Preview the Linux Foundation membership application »](/files/LF_Membership-Preview.pdf)
- [Preview the GraphQL Foundation participation agreement »](/files/GraphQL_Foundation-Participation_Agreement-Preview.pdf)
-GraphQL Foundation membership fees and Linux Foundation Silver Membership dues are adjusted according to an organization's number of full-time employees.
+GraphQL Foundation membership fees and Linux Foundation Silver Membership dues
+are adjusted according to an organization's number of full-time employees.
### [GraphQL Foundation Membership](https://join.graphql.org)
@@ -79,10 +122,15 @@ To join, please complete the [membership application](https://join.graphql.org).
To join, please complete the [membership application](https://join.graphql.org).
-The GraphQL Foundation and the Linux Foundation also offer a no-cost associate membership for pre-approved non-profits, open source projects, and government entities. To learn more about Associate membership, please email [membership@graphql.org](mailto:membership@graphql.org).
+The GraphQL Foundation and the Linux Foundation also offer a no-cost associate
+membership for pre-approved non-profits, open source projects, and government
+entities. To learn more about Associate membership, please email
+[membership@graphql.org](mailto:membership@graphql.org).
### Support the GraphQL Foundation
-To become a member and demonstrate your organization's support of GraphQL, please [complete the membership application](https://join.graphql.org).
+To become a member and demonstrate your organization's support of GraphQL,
+please [complete the membership application](https://join.graphql.org).
-If you have questions or issues, please email [membership@graphql.org](mailto:membership@graphql.org).
+If you have questions or issues, please email
+[membership@graphql.org](mailto:membership@graphql.org).
diff --git a/src/pages/community/foundation/local-initiative.mdx b/src/pages/community/foundation/local-initiative.mdx
index 7eb9410a7b..2ba3a88af8 100644
--- a/src/pages/community/foundation/local-initiative.mdx
+++ b/src/pages/community/foundation/local-initiative.mdx
@@ -22,8 +22,8 @@ announce the official **GraphQL Local** initiative. This initiative provides a
framework for organizing local GraphQL user groups and offers support to each
approved group (hereafter, a "Local").
-We're happy to support both new and existing GraphQL meets; here’s what you
-need to know to get involved:
+We're happy to support both new and existing GraphQL meets; here’s what you need
+to know to get involved:
## Requirements
@@ -37,8 +37,8 @@ Organizers of a Local must agree:
- At least one
[GraphQL Technical Steering Committee (TSC) member](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md#tsc-members)
must be granted administrator access to the Local’s online platforms (we
- will assign a TSC member and supply the relevant details on approval of
- your Local).
+ will assign a TSC member and supply the relevant details on approval of your
+ Local).
- In case of a serious Code of Conduct breach, an organizer may be replaced.
- The Local has 1 or more organizer from the area. (We're pretty flexible on the
definition of "from the area", just be reasonable.)
@@ -65,8 +65,7 @@ Guidelines must still be honoured).
## Support
-Each approved Local is entitled to request the following support for each
-event:
+Each approved Local is entitled to request the following support for each event:
- **Sponsorship** up to USD $200 per event (max 1 per quarter) for approved
costs (see below). More sponsorship might be available directly from
@@ -80,8 +79,8 @@ event:
- Schedule
- Speaker/talk introduction
- **Promotion** through GraphQL’s Twitter and LinkedIn channels.
-- **Local artwork** adhering to the GraphQL Brand Guidelines; including
- avatars, event banners, and slide templates. \*\*
+- **Local artwork** adhering to the GraphQL Brand Guidelines; including avatars,
+ event banners, and slide templates. \*\*
\* The content of swag bundles may change from time to time depending on
available inventory.
diff --git a/src/pages/community/foundation/members.mdx b/src/pages/community/foundation/members.mdx
index 7351aaad27..ddd9040a70 100644
--- a/src/pages/community/foundation/members.mdx
+++ b/src/pages/community/foundation/members.mdx
@@ -2,20 +2,17 @@ import IframeResizer from "iframe-resizer-react"
# GraphQL Foundation members
-The [GraphQL Foundation](/foundation) is the primary way
-in which funding is raised and distributed to support essential
-GraphQL community programs. The members listed on this page are
-directly invested in the success and long-term sustainability of the
-GraphQL community.
+The [GraphQL Foundation](/foundation) is the primary way in which funding is
+raised and distributed to support essential GraphQL community programs. The
+members listed on this page are directly invested in the success and long-term
+sustainability of the GraphQL community.
-To learn more about the [GraphQL Foundation](/foundation)
-and becoming a member, please see our
-[FAQ](/faq/foundation/), reach out to
-membership@graphql.org,
-or [complete a membership application](https://join.graphql.org).
+To learn more about the [GraphQL Foundation](/foundation) and becoming a member,
+please see our [FAQ](/faq/foundation/), reach out to membership@graphql.org, or
+[complete a membership application](https://join.graphql.org).
<IframeResizer
- className="w-full mt-6"
+ className="mt-6 w-full"
src="https://landscape.graphql.org/card-mode?category=graph-ql-foundation-member&grouping=category&embed=yes&style=borderless"
heightCalculationMethod="lowestElement"
/>
diff --git a/src/pages/community/resources/blogs-and-newsletters.mdx b/src/pages/community/resources/blogs-and-newsletters.mdx
index 46331f19e2..31c170b240 100644
--- a/src/pages/community/resources/blogs-and-newsletters.mdx
+++ b/src/pages/community/resources/blogs-and-newsletters.mdx
@@ -22,23 +22,41 @@ Popular sources to learn and keep track of the GraphQL Ecosystem.
Here are a list of notable blog posts to help you better understand GraphQL:
- [GraphQL: A data query language](/blog/graphql-a-query-language/) - Lee Byron
-- [Subscriptions in GraphQL and Relay](/blog/subscriptions-in-graphql-and-relay/) - Dan Schafer and Laney Kuenzel
-- [Mocking your server is easy with GraphQL](/blog/mocking-with-graphql/) - Jonas Helfer
-- [Wrapping a REST API in GraphQL](/blog/rest-api-graphql-wrapper/) - Steven Luscher
+- [Subscriptions in GraphQL and Relay](/blog/subscriptions-in-graphql-and-relay/) -
+ Dan Schafer and Laney Kuenzel
+- [Mocking your server is easy with GraphQL](/blog/mocking-with-graphql/) -
+ Jonas Helfer
+- [Wrapping a REST API in GraphQL](/blog/rest-api-graphql-wrapper/) - Steven
+ Luscher
- [Leaving technical preview](/blog/production-ready/) - Lee Byron
-- [Relicensing the GraphQL specification](https://medium.com/@leeb/relicensing-the-graphql-specification-e7d07a52301b) - Lee Byron
-- [GraphQL Introduction](https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html) - Nick Schrock
-- [From REST to GraphQL](https://0x2a.sh/from-rest-to-graphql-b4e95e94c26b#.tag7nzkrb) - Jacob Gillespie
-- [GraphQL Explained](https://medium.com/apollo-stack/graphql-explained-5844742f195e#.zdykxos6i) - Jonas Helfer
-- [GraphQL Concepts Visualized](https://medium.com/apollo-stack/the-concepts-of-graphql-bc68bd819be3#.hfczgtdsj) - Dhaivat Pandya
+- [Relicensing the GraphQL specification](https://medium.com/@leeb/relicensing-the-graphql-specification-e7d07a52301b) -
+ Lee Byron
+- [GraphQL Introduction](https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html) -
+ Nick Schrock
+- [From REST to GraphQL](https://0x2a.sh/from-rest-to-graphql-b4e95e94c26b#.tag7nzkrb) -
+ Jacob Gillespie
+- [GraphQL Explained](https://medium.com/apollo-stack/graphql-explained-5844742f195e#.zdykxos6i) -
+ Jonas Helfer
+- [GraphQL Concepts Visualized](https://medium.com/apollo-stack/the-concepts-of-graphql-bc68bd819be3#.hfczgtdsj) -
+ Dhaivat Pandya
- [Building the f8 App: Using GraphQL & Relay](http://makeitopen.com/docs/en/1-A2-relay.html)
-- [Your First GraphQL Server](https://medium.com/the-graphqlhub/your-first-graphql-server-3c766ab4f0a2#.ovn0y19k4) - Clay Allsopp
-- [Tutorial: Kick start a JS API with Apollo-server, Dataloader and Knex](https://bamtech.gitbook.io/dev-standards/backend/graphql-js/getting-started-with-apollo-server-dataloader-knex.mo) - Thomas Pucci
-- [Tutorial: How to Build a GraphQL Server](https://medium.com/apollo-stack/tutorial-building-a-graphql-server-cddaa023c035#.bu6sdnst4) - Jonas Helfer
-- [Designing Powerful APIs with GraphQL Query Parameters](https://www.graph.cool/docs/tutorials/designing-powerful-apis-with-graphql-query-parameters-aing7uech3/) - Johannes Schickling
-- [GraphQL and the amazing Apollo Client](https://medium.com/google-developer-experts/graphql-and-the-amazing-apollo-client-fe57e162a70c) - Gerard Sans
-- [GraphQL Server Basics (Part I): The Schema](https://www.prisma.io/blog/graphql-server-basics-the-schema-ac5e2950214e) - Nikolas Burk
-- [GraphQL Server Basics (Part II): The Network Layer](https://www.prisma.io/blog/graphql-server-basics-the-network-layer-51d97d21861) - Nikolas Burk
-- [GraphQL Server Basics (Part III): Demystifying the `info` argument in GraphQL resolvers](https://www.prisma.io/blog/graphql-server-basics-demystifying-the-info-argument-in-graphql-resolvers-6f26249f613a) - Nikolas Burk
-- [A Beginner’s Guide to GraphQL](https://www.freecodecamp.org/news/a-beginners-guide-to-graphql-86f849ce1bec/) - Leonardo Maldonado
-- [Architecture of a high performance GraphQL to SQL engine](https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87) - Hasura
+- [Your First GraphQL Server](https://medium.com/the-graphqlhub/your-first-graphql-server-3c766ab4f0a2#.ovn0y19k4) -
+ Clay Allsopp
+- [Tutorial: Kick start a JS API with Apollo-server, Dataloader and Knex](https://bamtech.gitbook.io/dev-standards/backend/graphql-js/getting-started-with-apollo-server-dataloader-knex.mo) -
+ Thomas Pucci
+- [Tutorial: How to Build a GraphQL Server](https://medium.com/apollo-stack/tutorial-building-a-graphql-server-cddaa023c035#.bu6sdnst4) -
+ Jonas Helfer
+- [Designing Powerful APIs with GraphQL Query Parameters](https://www.graph.cool/docs/tutorials/designing-powerful-apis-with-graphql-query-parameters-aing7uech3/) -
+ Johannes Schickling
+- [GraphQL and the amazing Apollo Client](https://medium.com/google-developer-experts/graphql-and-the-amazing-apollo-client-fe57e162a70c) -
+ Gerard Sans
+- [GraphQL Server Basics (Part I): The Schema](https://www.prisma.io/blog/graphql-server-basics-the-schema-ac5e2950214e) -
+ Nikolas Burk
+- [GraphQL Server Basics (Part II): The Network Layer](https://www.prisma.io/blog/graphql-server-basics-the-network-layer-51d97d21861) -
+ Nikolas Burk
+- [GraphQL Server Basics (Part III): Demystifying the `info` argument in GraphQL resolvers](https://www.prisma.io/blog/graphql-server-basics-demystifying-the-info-argument-in-graphql-resolvers-6f26249f613a) -
+ Nikolas Burk
+- [A Beginner’s Guide to GraphQL](https://www.freecodecamp.org/news/a-beginners-guide-to-graphql-86f849ce1bec/) -
+ Leonardo Maldonado
+- [Architecture of a high performance GraphQL to SQL engine](https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87) -
+ Hasura
diff --git a/src/pages/community/resources/books.mdx b/src/pages/community/resources/books.mdx
index ca8486c6ff..d4cd64a151 100644
--- a/src/pages/community/resources/books.mdx
+++ b/src/pages/community/resources/books.mdx
@@ -1,11 +1,20 @@
# Books
-- [The GraphQL Guide](https://graphql.guide) by John Resig and Loren Sands-Ramshaw
-- [Learning GraphQL](https://www.amazon.com/Learning-GraphQL-Declarative-Fetching-Modern/dp/1492030716/) by Eve Porcello and Alex Banks
-- [Fullstack GraphQL](https://www.graphql.college/fullstack-graphql) by Julian Mayorga
-- [Craft GraphQL APIs in Elixir with Absinthe](https://pragprog.com/book/wwgraphql/craft-graphql-apis-in-elixir-with-absinthe) by Bruce Williams and Ben Wilson
-- [Learning GraphQL and Relay](https://www.packtpub.com/web-development/learning-graphql-and-relay) by Samer Buna
-- [Hands-on Full-Stack Web Development with GraphQL and React](https://www.packtpub.com/web-development/hands-full-stack-web-development-graphql-and-react) by Sebastian Grebe
-- [The Road to GraphQL](https://www.robinwieruch.de/the-road-to-graphql-book/) by Robin Wieruch
-- [Production Ready GraphQL](https://book.productionreadygraphql.com/) by Marc-Andre Giroux
-- [GraphQL Best Practices: Hands-on experience with schema design, security, and error handling for developers](https://www.amazon.com/dp/B0D9H7MJQV) by Artur Czemiel, Nov 2024
+- [The GraphQL Guide](https://graphql.guide) by John Resig and Loren
+ Sands-Ramshaw
+- [Learning GraphQL](https://www.amazon.com/Learning-GraphQL-Declarative-Fetching-Modern/dp/1492030716/)
+ by Eve Porcello and Alex Banks
+- [Fullstack GraphQL](https://www.graphql.college/fullstack-graphql) by Julian
+ Mayorga
+- [Craft GraphQL APIs in Elixir with Absinthe](https://pragprog.com/book/wwgraphql/craft-graphql-apis-in-elixir-with-absinthe)
+ by Bruce Williams and Ben Wilson
+- [Learning GraphQL and Relay](https://www.packtpub.com/web-development/learning-graphql-and-relay)
+ by Samer Buna
+- [Hands-on Full-Stack Web Development with GraphQL and React](https://www.packtpub.com/web-development/hands-full-stack-web-development-graphql-and-react)
+ by Sebastian Grebe
+- [The Road to GraphQL](https://www.robinwieruch.de/the-road-to-graphql-book/)
+ by Robin Wieruch
+- [Production Ready GraphQL](https://book.productionreadygraphql.com/) by
+ Marc-Andre Giroux
+- [GraphQL Best Practices: Hands-on experience with schema design, security, and error handling for developers](https://www.amazon.com/dp/B0D9H7MJQV)
+ by Artur Czemiel, Nov 2024
diff --git a/src/pages/community/resources/community-channels.mdx b/src/pages/community/resources/community-channels.mdx
index 8af52f5deb..412bd110cb 100644
--- a/src/pages/community/resources/community-channels.mdx
+++ b/src/pages/community/resources/community-channels.mdx
@@ -2,39 +2,42 @@ import {
RedditIcon,
ReactifluxIcon,
FreenodeIcon,
- StackOverflowIcon,
+ StackOverflowIcon
} from "../../../icons"
import { Cards } from "../../../components/cards"
# Community Channels
-Many GraphQL developers idle in Discord, Slack, and IRC for live communication and can answer quick questions.
+Many GraphQL developers idle in Discord, Slack, and IRC for live communication
+and can answer quick questions.
-Please be patient and polite. These are not explicitly user support channels, although they're likely a good place to find someone who can answer your question if you ask nicely.
+Please be patient and polite. These are not explicitly user support channels,
+although they're likely a good place to find someone who can answer your
+question if you ask nicely.
<Cards
items={[
{
icon: RedditIcon,
title: "GraphQL Reddit Community",
- link: "https://reddit.com/r/graphql",
+ link: "https://reddit.com/r/graphql"
},
{
icon: ReactifluxIcon,
title: "Reactiflux Discord",
link: "https://join.reactiflux.com",
- description: "#help-graphql",
+ description: "#help-graphql"
},
{
icon: FreenodeIcon,
title: "Freenode IRC",
link: "https://freenode.net",
- description: "#graphql",
+ description: "#graphql"
},
{
icon: StackOverflowIcon,
title: "Stack Overflow",
- link: "https://stackoverflow.com/questions/tagged/graphql",
- },
+ link: "https://stackoverflow.com/questions/tagged/graphql"
+ }
]}
/>
diff --git a/src/pages/community/resources/more-resources.mdx b/src/pages/community/resources/more-resources.mdx
index 996b9ea8e3..f42f1cd9e4 100644
--- a/src/pages/community/resources/more-resources.mdx
+++ b/src/pages/community/resources/more-resources.mdx
@@ -1,10 +1,14 @@
# More Resources
-To explore other community-developed resources and content about GraphQL, take a look at these sites:
+To explore other community-developed resources and content about GraphQL, take a
+look at these sites:
-- [awesome-graphql](https://github.com/chentsulin/awesome-graphql): A fantastic community maintained collection of libraries, resources, and more.
-- [graphql-apis](https://github.com/APIs-guru/graphql-apis): A collective list of public GraphQL APIs.
-- [GraphQL Screencasts](https://graphql.wtf): Learn something new with GraphQL, every week.
+- [awesome-graphql](https://github.com/chentsulin/awesome-graphql): A fantastic
+ community maintained collection of libraries, resources, and more.
+- [graphql-apis](https://github.com/APIs-guru/graphql-apis): A collective list
+ of public GraphQL APIs.
+- [GraphQL Screencasts](https://graphql.wtf): Learn something new with GraphQL,
+ every week.
## Community Meetups
@@ -25,10 +29,15 @@ Please contact us in the `#meetups-admin` channel on
## GraphQL Logo & Trademark
-The GraphQL name and logo are registered trademarks, and are neutrally held by The Linux Foundation. You may use the GraphQL mark so long as you adhere to the [trademark policy](https://lfprojects.org/policies/trademark-policy/).
+The GraphQL name and logo are registered trademarks, and are neutrally held by
+The Linux Foundation. You may use the GraphQL mark so long as you adhere to the
+[trademark policy](https://lfprojects.org/policies/trademark-policy/).
-Download the GraphQL logo and find guidelines for its use in the [brand guidelines](/brand).
+Download the GraphQL logo and find guidelines for its use in the
+[brand guidelines](/brand).
## Code of Conduct
-The [GraphQL Code of Conduct](/codeofconduct/) applies both within project spaces and in public spaces when an individual is representing the project or its community.
+The [GraphQL Code of Conduct](/codeofconduct/) applies both within project
+spaces and in public spaces when an individual is representing the project or
+its community.
diff --git a/src/pages/community/resources/official-channels.mdx b/src/pages/community/resources/official-channels.mdx
index 16825e8452..d2bbd41bc9 100644
--- a/src/pages/community/resources/official-channels.mdx
+++ b/src/pages/community/resources/official-channels.mdx
@@ -6,13 +6,15 @@ import {
Facebook2Icon,
FileTextIcon,
CodeIcon,
- GraphQLLogo,
+ GraphQLLogo
} from "../../../icons"
import { Cards } from "../../../components/cards"
# Official Channels
-The GraphQL community is active and has created a tremendous amount of valuable content, but we maintain a number of primary collaboration channels for the project.
+The GraphQL community is active and has created a tremendous amount of valuable
+content, but we maintain a number of primary collaboration channels for the
+project.
Please follow these channels for updates and information:
@@ -22,45 +24,45 @@ Please follow these channels for updates and information:
icon: TwitterIcon,
title: "X",
link: "https://x.com/graphql",
- description: "@graphql",
+ description: "@graphql"
},
{
icon: GitHubIcon,
title: "GitHub",
- link: "https://github.com/graphql",
+ link: "https://github.com/graphql"
},
{
icon: GoogleCalendarIcon,
title: "Google Calendar",
- link: "https://calendar.graphql.org",
+ link: "https://calendar.graphql.org"
},
{
icon: DiscordIcon,
title: "Discord",
- link: "https://discord.graphql.org",
+ link: "https://discord.graphql.org"
},
{
icon: Facebook2Icon,
title: "Facebook Group",
- link: "https://fb.com/groups/graphql.community",
+ link: "https://fb.com/groups/graphql.community"
},
{
icon: FileTextIcon,
title: "Blog",
link: "/blog",
- description: "graphql.org/blog",
+ description: "graphql.org/blog"
},
{
icon: CodeIcon,
title: "Tools and libraries",
link: "/code",
- description: "graphql.org/code",
+ description: "graphql.org/code"
},
{
icon: GraphQLLogo,
title: "Shop",
link: "https://store.graphql.org/",
- description: "store.graphql.org",
- },
+ description: "store.graphql.org"
+ }
]}
/>
diff --git a/src/pages/community/resources/training-courses.mdx b/src/pages/community/resources/training-courses.mdx
index 74ab38d142..84d856a854 100644
--- a/src/pages/community/resources/training-courses.mdx
+++ b/src/pages/community/resources/training-courses.mdx
@@ -3,6 +3,10 @@
A number of GraphQL training courses are available:
- [GraphQL-JS tutorial](/graphql-js)
-- [Yoga GraphQL Server Tutorial](https://the-guild.dev/graphql/yoga-server/tutorial): Open source tutorial for creating modern GraphQL Servers in Node, CF Workers, Deno and others
-- [Apollo Odyssey](https://apollographql.com/tutorials): Interactive courses for building GraphQL applications with Apollo's toolset
-- [GraphQL Tutorials](https://hasura.io/learn): Real World Fullstack GraphQL tutorials for developers by Hasura
+- [Yoga GraphQL Server Tutorial](https://the-guild.dev/graphql/yoga-server/tutorial):
+ Open source tutorial for creating modern GraphQL Servers in Node, CF Workers,
+ Deno and others
+- [Apollo Odyssey](https://apollographql.com/tutorials): Interactive courses for
+ building GraphQL applications with Apollo's toolset
+- [GraphQL Tutorials](https://hasura.io/learn): Real World Fullstack GraphQL
+ tutorials for developers by Hasura
diff --git a/src/pages/community/resources/vendor-channels.mdx b/src/pages/community/resources/vendor-channels.mdx
index f8d8c347e6..65a093cba6 100644
--- a/src/pages/community/resources/vendor-channels.mdx
+++ b/src/pages/community/resources/vendor-channels.mdx
@@ -2,35 +2,36 @@ import {
StellateIcon,
ChillicreamIcon,
ApolloIcon,
- GraphileIcon,
+ GraphileIcon
} from "../../../icons"
-import { Cards } from '../../../components/cards'
+import { Cards } from "../../../components/cards"
# Vendor Channels
-The following channels are maintained by vendors, and may be a good place to find help on their products.
+The following channels are maintained by vendors, and may be a good place to
+find help on their products.
<Cards
items={[
{
icon: ApolloIcon,
title: "Apollo Discord",
- link: "https://discord.gg/graphos",
+ link: "https://discord.gg/graphos"
},
{
icon: ChillicreamIcon,
title: "ChilliCream Slack",
- link: "https://slack.chillicream.com",
+ link: "https://slack.chillicream.com"
},
{
icon: GraphileIcon,
title: "Graphile Discord",
- link: "https://discord.gg/graphile",
+ link: "https://discord.gg/graphile"
},
{
icon: StellateIcon,
title: "Stellate Discord",
- link: "https://go.stellate.co/community",
- },
+ link: "https://go.stellate.co/community"
+ }
]}
/>
diff --git a/src/pages/community/resources/videos.mdx b/src/pages/community/resources/videos.mdx
index f9a0238554..6547bac79f 100644
--- a/src/pages/community/resources/videos.mdx
+++ b/src/pages/community/resources/videos.mdx
@@ -1,30 +1,57 @@
# Videos
-Developers inside and outside of Facebook have given talks about GraphQL at conferences and meetups around the world. Here are some of our favorites:
+Developers inside and outside of Facebook have given talks about GraphQL at
+conferences and meetups around the world. Here are some of our favorites:
-- [Exploring GraphQL](https://youtube.com/watch?v=WQLzZf34FJ8) - Lee Byron, React Europe 2015
-- [From Zero to GraphQL in 30 Minutes](https://youtube.com/watch?v=UBGzsb2UkeY) - Steve Luscher
-- [Exploring GraphQL](https://youtube.com/watch?v=_9RgHXqH8J0) - Nick Schrock, @Scale 2015
-- [GraphQL Servers](https://www.youtube.com/watch?v=KOudxKJXsjc) - Nick Schrock, React Rally 2015
-- [GraphQL at Facebook](https://youtube.com/watch?v=etax3aEe2dA) - Dan Schafer, React Europe 2016
-- [GraphQL Source Code Overview](https://youtube.com/watch?v=IqtYr6RX32Q) - Lee Byron
-- [GraphQL Future](https://youtube.com/watch?v=ViXL0YQnioU) - Lee Byron & Laney Kuenzel
-- [Apollo Client: Put GraphQL Data in Your UI](https://www.youtube.com/watch?v=u1E0CbGeICo) - Sashko Stubailo
-- [Relay 2 - simpler, faster, and more predictable](https://www.youtube.com/watch?v=OEfUBN9dAI8) - Greg Hurrell
-- [Build a GraphQL server for Node.js, using PostgreSQL/MySQL](https://www.youtube.com/watch?v=DNPVqK_woRQ) - Lee Benson
-- [A GraphQL Framework for Non-JS Servers](https://www.youtube.com/watch?v=RNoyPSrQyPs) - Syrus Akbary
-- [Modernize Your Angular App with GraphQL](https://www.youtube.com/watch?v=E8feZBidZcs) - Uri Goldshtein, AngularCamp 2016
-- [GraphQL server tutorial for Node.js with SQL, MongoDB and REST ](https://www.youtube.com/watch?v=PHabPhgRUuU) - Jonas Helfer
-- [Building Native Mobile Apps with GraphQL](https://www.youtube.com/watch?v=z5rz3saDPJ8) - Martjin Walraven, React Europe 2016
-- [GraphQL in native applications](https://atscaleconference.com/videos/graphql-in-native-applications-at-scale/) - Igor Canadi & Alex Langenfeld, @Scale 2016
-- [Build a GraphQL Backend with the Serverless Framework](https://acloud.guru/learn/serverless-with-graphql) - Ryan Brown
-- [Build a Full GraphQL Backend in Under 5 Minutes](https://www.youtube.com/watch?v=bJ8pnYd6jPQ) - Michael Paris
-- [GraphQL: From Zero to Scala](https://www.youtube.com/watch?v=6ttypoLyRaU) - Jérémie Astori, Northeast Scala Symposium 2017
-- [GraphQL in Production: Backend as a Service](https://www.youtube.com/watch?v=U2NKoStGBvE) - Michael Paris & Vince Ning, GraphQL in Production Meetup SF August 2016
-- [Development of real-time apps with GraphQL Node.js](https://youtu.be/yh_A6CEqsSM) - Vince Ning & Michael Paris, SF Node Meetup February 2017
-- [Unleashing the power of GraphQL using Angular 2](https://www.youtube.com/watch?v=VYpJ9pfugM8) - Gerard Sans, NG-BE 2016
-- [Webinar Series: GraphQL Around The World](https://graphql-world.com/webinar) - Vince Ning & Michael Paris
-- [All Talks from GraphQL Europe](https://www.youtube.com/playlist?list=PLn2e1F9Rfr6n_WFm9fPE-_wYPrYvSTySt) - Lee Byron, Sashko Stubailo, Dan Schafer, Johannes Schickling and many more
-- [Learning GraphQL with React and Relay](https://www.packtpub.com/application-development/learning-graphql-react-and-relay-video) by Divyendu Singh
-- [Hands-on GraphQL for Better RESTful Web Services (Video)](https://www.packtpub.com/application-development/hands-graphql-better-restful-web-services-video) by Ashwin Hegde
-- [A PostgreSQL backed GraphQL BaaS](https://www.youtube.com/watch?v=neIZcc8y3B0) by Tanmai Gopal
+- [Exploring GraphQL](https://youtube.com/watch?v=WQLzZf34FJ8) - Lee Byron,
+ React Europe 2015
+- [From Zero to GraphQL in 30 Minutes](https://youtube.com/watch?v=UBGzsb2UkeY) -
+ Steve Luscher
+- [Exploring GraphQL](https://youtube.com/watch?v=_9RgHXqH8J0) - Nick Schrock,
+ @Scale 2015
+- [GraphQL Servers](https://www.youtube.com/watch?v=KOudxKJXsjc) - Nick Schrock,
+ React Rally 2015
+- [GraphQL at Facebook](https://youtube.com/watch?v=etax3aEe2dA) - Dan Schafer,
+ React Europe 2016
+- [GraphQL Source Code Overview](https://youtube.com/watch?v=IqtYr6RX32Q) - Lee
+ Byron
+- [GraphQL Future](https://youtube.com/watch?v=ViXL0YQnioU) - Lee Byron & Laney
+ Kuenzel
+- [Apollo Client: Put GraphQL Data in Your UI](https://www.youtube.com/watch?v=u1E0CbGeICo) -
+ Sashko Stubailo
+- [Relay 2 - simpler, faster, and more predictable](https://www.youtube.com/watch?v=OEfUBN9dAI8) -
+ Greg Hurrell
+- [Build a GraphQL server for Node.js, using PostgreSQL/MySQL](https://www.youtube.com/watch?v=DNPVqK_woRQ) -
+ Lee Benson
+- [A GraphQL Framework for Non-JS Servers](https://www.youtube.com/watch?v=RNoyPSrQyPs) -
+ Syrus Akbary
+- [Modernize Your Angular App with GraphQL](https://www.youtube.com/watch?v=E8feZBidZcs) -
+ Uri Goldshtein, AngularCamp 2016
+- [GraphQL server tutorial for Node.js with SQL, MongoDB and REST ](https://www.youtube.com/watch?v=PHabPhgRUuU) -
+ Jonas Helfer
+- [Building Native Mobile Apps with GraphQL](https://www.youtube.com/watch?v=z5rz3saDPJ8) -
+ Martjin Walraven, React Europe 2016
+- [GraphQL in native applications](https://atscaleconference.com/videos/graphql-in-native-applications-at-scale/) -
+ Igor Canadi & Alex Langenfeld, @Scale 2016
+- [Build a GraphQL Backend with the Serverless Framework](https://acloud.guru/learn/serverless-with-graphql) -
+ Ryan Brown
+- [Build a Full GraphQL Backend in Under 5 Minutes](https://www.youtube.com/watch?v=bJ8pnYd6jPQ) -
+ Michael Paris
+- [GraphQL: From Zero to Scala](https://www.youtube.com/watch?v=6ttypoLyRaU) -
+ Jérémie Astori, Northeast Scala Symposium 2017
+- [GraphQL in Production: Backend as a Service](https://www.youtube.com/watch?v=U2NKoStGBvE) -
+ Michael Paris & Vince Ning, GraphQL in Production Meetup SF August 2016
+- [Development of real-time apps with GraphQL Node.js](https://youtu.be/yh_A6CEqsSM) -
+ Vince Ning & Michael Paris, SF Node Meetup February 2017
+- [Unleashing the power of GraphQL using Angular 2](https://www.youtube.com/watch?v=VYpJ9pfugM8) -
+ Gerard Sans, NG-BE 2016
+- [Webinar Series: GraphQL Around The World](https://graphql-world.com/webinar) -
+ Vince Ning & Michael Paris
+- [All Talks from GraphQL Europe](https://www.youtube.com/playlist?list=PLn2e1F9Rfr6n_WFm9fPE-_wYPrYvSTySt) -
+ Lee Byron, Sashko Stubailo, Dan Schafer, Johannes Schickling and many more
+- [Learning GraphQL with React and Relay](https://www.packtpub.com/application-development/learning-graphql-react-and-relay-video)
+ by Divyendu Singh
+- [Hands-on GraphQL for Better RESTful Web Services (Video)](https://www.packtpub.com/application-development/hands-graphql-better-restful-web-services-video)
+ by Ashwin Hegde
+- [A PostgreSQL backed GraphQL BaaS](https://www.youtube.com/watch?v=neIZcc8y3B0)
+ by Tanmai Gopal
diff --git a/src/pages/community/tools-and-libraries.mdx b/src/pages/community/tools-and-libraries.mdx
index 500de43d5a..c43a815d5b 100644
--- a/src/pages/community/tools-and-libraries.mdx
+++ b/src/pages/community/tools-and-libraries.mdx
@@ -9,7 +9,8 @@ import { CodePage } from "../../components/tools-and-libraries"
import { getGitHubStats } from "../../../scripts/sort-libraries/get-github-stats"
import githubInfo from "@/github-stats.json"
-{<QueryParamProvider adapter={NextAdapter}><CodePage {...props} /></QueryParamProvider>}
+{<QueryParamProvider adapter={NextAdapter}><CodePage {...props}
+/></QueryParamProvider>}
export const getStaticProps = async () => {
const filePaths = await fg("./src/code/**/*.md")
@@ -32,15 +33,15 @@ export const getStaticProps = async () => {
hasDescription =
tree.children.length > 1 &&
tree.children.some(node => node.type !== "yaml")
- },
- ],
- },
+ }
+ ]
+ }
})
//
for (const tag of segments) {
if (tag.includes("_")) {
throw new Error(
- `Tag ${tag} contains an underscore, which is not allowed.`,
+ `Tag ${tag} contains an underscore, which is not allowed.`
)
}
allTags[tag] ??= 0
@@ -55,7 +56,7 @@ export const getStaticProps = async () => {
.endsWith(frontMatter.github.toLowerCase())
) {
throw new Error(
- `Remove frontmatter.url since URL "${frontMatter.url}" ends with the same slug as the GitHub repo "${frontMatter.github}".`,
+ `Remove frontmatter.url since URL "${frontMatter.url}" ends with the same slug as the GitHub repo "${frontMatter.github}".`
)
}
const stars = githubInfo[frontMatter.github]
@@ -67,9 +68,9 @@ export const getStaticProps = async () => {
stars: stars.stars,
formattedStars: stars.formattedStars,
lastRelease: stars.formattedLastRelease,
- license: stars.license,
+ license: stars.license
}),
- ...(hasDescription && { compiledSource }),
+ ...(hasDescription && { compiledSource })
})
}
//
@@ -77,14 +78,14 @@ export const getStaticProps = async () => {
.map(([tag, count]) => ({
tag,
count,
- name: slugMap[tag] ?? tag,
+ name: slugMap[tag] ?? tag
}))
.sort((a, b) => b.count - a.count || a.tag.localeCompare(b.tag))
//
return {
props: {
data: results.sort((a, b) => (b.stars ?? 0) - (a.stars ?? 0)),
- allTags: allTagsList,
- },
+ allTags: allTagsList
+ }
}
}
diff --git a/src/pages/faq/best-practices.mdx b/src/pages/faq/best-practices.mdx
index 46efd039c0..6b74639993 100644
--- a/src/pages/faq/best-practices.mdx
+++ b/src/pages/faq/best-practices.mdx
@@ -2,54 +2,108 @@
## Is GraphQL scalable?
-Yes, GraphQL is designed to be scalable and is used by many companies in production under a very high load.
+Yes, GraphQL is designed to be scalable and is used by many companies in
+production under a very high load.
-GraphQL comes with some [built-in performance boosts](#how-does-graphql-affect-my-product-s-performance) that can help. But once you push it to production, you're responsible for scaling it across instances and monitoring performance.
+GraphQL comes with some
+[built-in performance boosts](#how-does-graphql-affect-my-product-s-performance)
+that can help. But once you push it to production, you're responsible for
+scaling it across instances and monitoring performance.
## Does GraphQL support offline usage?
-No, or at least not natively. But there are [GraphQL clients](#what-is-a-graphql-client-and-why-would-i-need-one) that enable you to build offline-first. They use features designed to perform data operations while offline, such as caching and service workers.
+No, or at least not natively. But there are
+[GraphQL clients](#what-is-a-graphql-client-and-why-would-i-need-one) that
+enable you to build offline-first. They use features designed to perform data
+operations while offline, such as caching and service workers.
-You can find a list of GraphQL clients in various languages on our [Code page](/code/).
+You can find a list of GraphQL clients in various languages on our
+[Code page](/code/).
## What are the security concerns with GraphQL?
-Most of the security concerns associated with GraphQL are typical for any API or service. A few examples: SQL injections, Denial of Service (DoS) attacks, or someone abusing flawed authentication. But there are also some attacks specific to GraphQL. For instance, [batching attacks](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#batching-attacks). These attacks can happen as a result of GraphQL allowing you to batch multiple queries (or requests for multiple object instances) in a single network call.
-
-No matter the concern, it’s important to be proactive. There are many ways to securing your GraphQL server. Using a timeout, setting a maximum depth for queries, and throttling queries based on the server time it needs to complete are all potential approaches.
-
-For an overview of common security concerns and how to address them, check out the [Security tutorial on How to GraphQL](https://www.howtographql.com/advanced/4-security/) and [OWASP’s GraphQL Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html).
+Most of the security concerns associated with GraphQL are typical for any API or
+service. A few examples: SQL injections, Denial of Service (DoS) attacks, or
+someone abusing flawed authentication. But there are also some attacks specific
+to GraphQL. For instance,
+[batching attacks](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#batching-attacks).
+These attacks can happen as a result of GraphQL allowing you to batch multiple
+queries (or requests for multiple object instances) in a single network call.
+
+No matter the concern, it’s important to be proactive. There are many ways to
+securing your GraphQL server. Using a timeout, setting a maximum depth for
+queries, and throttling queries based on the server time it needs to complete
+are all potential approaches.
+
+For an overview of common security concerns and how to address them, check out
+the
+[Security tutorial on How to GraphQL](https://www.howtographql.com/advanced/4-security/)
+and
+[OWASP’s GraphQL Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html).
## How can I set up authorization with GraphQL?
-We recommend enforcing authorization behavior in the [business logic layer](/learn/thinking-in-graphs/#business-logic-layer). That way, you have a single source of truth for authorization.
+We recommend enforcing authorization behavior in the
+[business logic layer](/learn/thinking-in-graphs/#business-logic-layer). That
+way, you have a single source of truth for authorization.
-For a more detailed explanation, go to our [Authorization documentation](/learn/authorization/).
+For a more detailed explanation, go to our
+[Authorization documentation](/learn/authorization/).
## How does authentication work with GraphQL?
-You can implement authentication with common patterns, such as [OAuth](https://oauth.net/) or [JWT](https://jwt.io/). There’s nothing special about authentication within the GraphQL specification.
+You can implement authentication with common patterns, such as
+[OAuth](https://oauth.net/) or [JWT](https://jwt.io/). There’s nothing special
+about authentication within the GraphQL specification.
-Some [GraphQL libraries](/code/#language-support) include a specific protocol for authentication as well. Although if you’re working with a pipeline model, we recommend that [GraphQL be placed after all authentication middleware](/learn/serving-over-http/#web-request-pipeline).
+Some [GraphQL libraries](/code/#language-support) include a specific protocol
+for authentication as well. Although if you’re working with a pipeline model, we
+recommend that
+[GraphQL be placed after all authentication middleware](/learn/serving-over-http/#web-request-pipeline).
-If you’re using [GraphQL.js](/graphql-js/) to build your API server, we have documentation on [handling authentication with Express middleware](/graphql-js/authentication-and-express-middleware/).
+If you’re using [GraphQL.js](/graphql-js/) to build your API server, we have
+documentation on
+[handling authentication with Express middleware](/graphql-js/authentication-and-express-middleware/).
## Is GraphQL the right fit for designing a microservice architecture?
-Yes, it can be. If you’re integrating GraphQL into your microservice architecture, we’d recommend having one GraphQL schema as an API gateway rather than having your client talk to multiple GraphQL services. This way, you can split your backend into microservices, but then still aggregate all your data to the frontend from a single API.
+Yes, it can be. If you’re integrating GraphQL into your microservice
+architecture, we’d recommend having one GraphQL schema as an API gateway rather
+than having your client talk to multiple GraphQL services. This way, you can
+split your backend into microservices, but then still aggregate all your data to
+the frontend from a single API.
-There are many ways to create an API gateway. The benefit of using GraphQL is that you can take advantage of features like [caching](/learn/caching/), request budgeting, and planning out query schedules.
+There are many ways to create an API gateway. The benefit of using GraphQL is
+that you can take advantage of features like [caching](/learn/caching/), request
+budgeting, and planning out query schedules.
## How does versioning work in GraphQL?
-There’s nothing that will prevent a GraphQL service from being versioned like any other REST API. That said, GraphQL avoids versioning by design.
+There’s nothing that will prevent a GraphQL service from being versioned like
+any other REST API. That said, GraphQL avoids versioning by design.
-Instead, GraphQL provides the tools to continually build and evolve your schema. For example, GraphQL only returns the data that’s explicitly requested. This means that you can add new features (and all the associated types and fields) without creating a breaking change or bloating results for existing queries.
+Instead, GraphQL provides the tools to continually build and evolve your schema.
+For example, GraphQL only returns the data that’s explicitly requested. This
+means that you can add new features (and all the associated types and fields)
+without creating a breaking change or bloating results for existing queries.
-You can read more about [how versioning works in GraphQL](/learn/best-practices/#versioning) in our Best Practices section.
+You can read more about
+[how versioning works in GraphQL](/learn/best-practices/#versioning) in our Best
+Practices section.
## How can I document my GraphQL API?
-One of the benefits of GraphQL is that it's inherently self-documenting. This means that when you use an interactive tool like [GraphiQL](https://github.com/graphql/graphiql), you’re able to explore what data is exposed by your GraphQL API. This includes the [fields](/learn/queries/#fields), [types](/learn/schema/#type-system), and more. You can also add a [description field](https://spec.graphql.org/draft/#sec-Documentation) to provide supplementary notes about your endpoint. This description field supports strings and Markdown.
-
-For many, this provides enough API reference documentation. But it doesn’t reduce the need for other forms of documentation. You'll likely still need to create guides that explain how the general concepts tie into your specific use case.
+One of the benefits of GraphQL is that it's inherently self-documenting. This
+means that when you use an interactive tool like
+[GraphiQL](https://github.com/graphql/graphiql), you’re able to explore what
+data is exposed by your GraphQL API. This includes the
+[fields](/learn/queries/#fields), [types](/learn/schema/#type-system), and more.
+You can also add a
+[description field](https://spec.graphql.org/draft/#sec-Documentation) to
+provide supplementary notes about your endpoint. This description field supports
+strings and Markdown.
+
+For many, this provides enough API reference documentation. But it doesn’t
+reduce the need for other forms of documentation. You'll likely still need to
+create guides that explain how the general concepts tie into your specific use
+case.
diff --git a/src/pages/faq/foundation.mdx b/src/pages/faq/foundation.mdx
index 94a2e827f7..219ddec98f 100644
--- a/src/pages/faq/foundation.mdx
+++ b/src/pages/faq/foundation.mdx
@@ -2,48 +2,75 @@
## What does the GraphQL Foundation do?
-The primary responsibility of the Foundation is to set policy and allocate the budget to maximize the sustainability of the GraphQL community. Members participate on a governing board that meets monthly and decides how to allocate its funding.
+The primary responsibility of the Foundation is to set policy and allocate the
+budget to maximize the sustainability of the GraphQL community. Members
+participate on a governing board that meets monthly and decides how to allocate
+its funding.
## Where does the funding go when I become a member?
-The GraphQL Foundation is funded exclusively through the support of our members. The governing board sets an annual budget to use the dues to the maximum benefit of the community.
-Ways the Foundation distributes the money raised through memberships include:
+The GraphQL Foundation is funded exclusively through the support of our members.
+The governing board sets an annual budget to use the dues to the maximum benefit
+of the community. Ways the Foundation distributes the money raised through
+memberships include:
-- Providing grants and sponsorship to core community developers who are working in neutral roles.
+- Providing grants and sponsorship to core community developers who are working
+ in neutral roles.
- Funding core community IT infrastructure.
-- Funding coordination, financial, and legal support programs for the Foundation and the GraphQL project ecosystem.
+- Funding coordination, financial, and legal support programs for the Foundation
+ and the GraphQL project ecosystem.
- Other community and developer support programs.
The GraphQL Foundation budget is realigned as the needs of the community change.
## How are decisions made?
-As with other Linux Foundation projects, the governing board makes decisions through votes. Every vote is equal and no members have special voting rights or privileges. The charter currently limits the governing board to 25 members.
+As with other Linux Foundation projects, the governing board makes decisions
+through votes. Every vote is equal and no members have special voting rights or
+privileges. The charter currently limits the governing board to 25 members.
## Who can join the GraphQL Foundation?
-GraphQL Foundation membership is open to companies who wish to support the GraphQL ecosystem. As the GraphQL Foundation is hosted at the [Linux Foundation](https://linuxfoundation.org), members must also join the Linux Foundation.
+GraphQL Foundation membership is open to companies who wish to support the
+GraphQL ecosystem. As the GraphQL Foundation is hosted at the
+[Linux Foundation](https://linuxfoundation.org), members must also join the
+Linux Foundation.
## Do I need to join the Foundation to participate in GraphQL development?
-No, Foundation membership is separate from the technical development community. There is no cost to participate in GraphQL development, although you must sign the [free GraphQL Specification membership agreement](https://github.com/graphql/graphql-wg/tree/main/membership) in order to participate. These two things are different from each other.
+No, Foundation membership is separate from the technical development community.
+There is no cost to participate in GraphQL development, although you must sign
+the
+[free GraphQL Specification membership agreement](https://github.com/graphql/graphql-wg/tree/main/membership)
+in order to participate. These two things are different from each other.
-Members join the Foundation in order to provide essential funding and participate in the decisions on how it is used. Developers join the GraphQL Specification in order to contribute ideas, code, and other content. Many companies do both.
+Members join the Foundation in order to provide essential funding and
+participate in the decisions on how it is used. Developers join the GraphQL
+Specification in order to contribute ideas, code, and other content. Many
+companies do both.
## How do I participate in technical development?
-We would love to have you! The best place to get started is the [GraphQL Working Group](https://github.com/graphql/graphql-wg/tree/HEAD/membership), which meets monthly. Open a PR to add yourself to the agenda, and you are welcome to join.
+We would love to have you! The best place to get started is the
+[GraphQL Working Group](https://github.com/graphql/graphql-wg/tree/HEAD/membership),
+which meets monthly. Open a PR to add yourself to the agenda, and you are
+welcome to join.
-Otherwise, you can get involved in [any of our other projects](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md#about-the-graphql-specification-project).
+Otherwise, you can get involved in
+[any of our other projects](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md#about-the-graphql-specification-project).
## Who founded the organization?
-The GraphQL Foundation was founded by Apollo, AWS, Butterfly Network, Dgraph Labs, Facebook, Gatsby, GraphZen, Hasura, IBM, Intuit, Neo4j, Novvum, Pipefy, Salsify, Solo.io and Thicit.
+The GraphQL Foundation was founded by Apollo, AWS, Butterfly Network, Dgraph
+Labs, Facebook, Gatsby, GraphZen, Hasura, IBM, Intuit, Neo4j, Novvum, Pipefy,
+Salsify, Solo.io and Thicit.
## Who is currently a member?
-You can learn more about our membership on the [GraphQL Foundation membership page](/foundation/members).
+You can learn more about our membership on the
+[GraphQL Foundation membership page](/foundation/members).
## How do we join?
-You can become a member of GraphQL Foundation and the Linux Foundation by completing our [membership application form](https://join.graphql.org).
+You can become a member of GraphQL Foundation and the Linux Foundation by
+completing our [membership application form](https://join.graphql.org).
diff --git a/src/pages/faq/frontend.mdx b/src/pages/faq/frontend.mdx
index 7a89ca2704..0f9b56ff4a 100644
--- a/src/pages/faq/frontend.mdx
+++ b/src/pages/faq/frontend.mdx
@@ -2,6 +2,15 @@
## Does GraphQL replace Redux or other state management libraries?
-No, GraphQL isn’t a state management library - but it can reduce the need for one.
+No, GraphQL isn’t a state management library - but it can reduce the need for
+one.
-One benefit of state management libraries like Redux is that they can manipulate API responses into a format that your application understands. With GraphQL, you have control over [what data you request](/learn/queries/#fields) and typically results are formatted in a client-friendly way by the graph design. So this benefit is already built-in. Many [client libraries](#what-is-a-graphql-client-and-why-would-i-need-one) can also be used to manage state and have features like caching built-in. You may still decide to implement a state management library, but using it to format response data is generally not necessary.
+One benefit of state management libraries like Redux is that they can manipulate
+API responses into a format that your application understands. With GraphQL, you
+have control over [what data you request](/learn/queries/#fields) and typically
+results are formatted in a client-friendly way by the graph design. So this
+benefit is already built-in. Many
+[client libraries](#what-is-a-graphql-client-and-why-would-i-need-one) can also
+be used to manage state and have features like caching built-in. You may still
+decide to implement a state management library, but using it to format response
+data is generally not necessary.
diff --git a/src/pages/faq/general.mdx b/src/pages/faq/general.mdx
index 0ea713eea9..cc8deb545d 100644
--- a/src/pages/faq/general.mdx
+++ b/src/pages/faq/general.mdx
@@ -2,52 +2,125 @@
## Is GraphQL frontend or backend?
-Both. GraphQL specifies how you can [exchange information between client and server](https://www.howtographql.com/basics/3-big-picture/). This includes how the server can indicate [what data and operations are available](/learn/introspection/), how the client should [format requests](/learn/queries/), how the server should [execute these queries](/learn/execution/), and what the client will [receive in response](/learn/serving-over-http/#response).
+Both. GraphQL specifies how you can
+[exchange information between client and server](https://www.howtographql.com/basics/3-big-picture/).
+This includes how the server can indicate
+[what data and operations are available](/learn/introspection/), how the client
+should [format requests](/learn/queries/), how the server should
+[execute these queries](/learn/execution/), and what the client will
+[receive in response](/learn/serving-over-http/#response).
## Does GraphQL use HTTP?
-Yes, [GraphQL is typically served over HTTP](/learn/best-practices/#http). This is largely due to how pervasive the HTTP protocol is in our industry. But it helps that you can try out GraphQL by creating [a single HTTP request](#why-should-i-use-graphql). Guidelines for setting up a GraphQL server to operate over HTTP are available in our [Serving over HTTP](/learn/serving-over-http/) documentation.
+Yes, [GraphQL is typically served over HTTP](/learn/best-practices/#http). This
+is largely due to how pervasive the HTTP protocol is in our industry. But it
+helps that you can try out GraphQL by creating
+[a single HTTP request](#why-should-i-use-graphql). Guidelines for setting up a
+GraphQL server to operate over HTTP are available in our
+[Serving over HTTP](/learn/serving-over-http/) documentation.
-While HTTP is the most common choice for client-server protocol, it’s not the only one. GraphQL is agnostic to the transport layer. So, for example, you could use [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) for GraphQL subscriptions instead of HTTP to consume realtime data.
+While HTTP is the most common choice for client-server protocol, it’s not the
+only one. GraphQL is agnostic to the transport layer. So, for example, you could
+use
+[WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API)
+for GraphQL subscriptions instead of HTTP to consume realtime data.
## How does GraphQL affect my product’s performance?
-On a typical GraphQL backend, every field on every type has a focused, single-purpose function for resolving that value. Also, instead of trying to handle data batching on the client, [GraphQL moves that logic to the server](/learn/best-practices/#server-side-batching-caching). As a result, there are some inherent performance benefits. Minimizing over-fetching and making [fewer roundtrips to the server](/learn/queries/#fields) are two of them.
+On a typical GraphQL backend, every field on every type has a focused,
+single-purpose function for resolving that value. Also, instead of trying to
+handle data batching on the client,
+[GraphQL moves that logic to the server](/learn/best-practices/#server-side-batching-caching).
+As a result, there are some inherent performance benefits. Minimizing
+over-fetching and making
+[fewer roundtrips to the server](/learn/queries/#fields) are two of them.
-Other performance factors should be considered when building out your GraphQL implementation. For example, it’s possible for a GraphQL service to be ‘chatty’ and repeatedly load data from your database. This is commonly solved by [implementing a batching technique](/learn/best-practices/#server-side-batching-caching) or [utilizing a tool like DataLoader](https://github.com/graphql/dataloader).
+Other performance factors should be considered when building out your GraphQL
+implementation. For example, it’s possible for a GraphQL service to be ‘chatty’
+and repeatedly load data from your database. This is commonly solved by
+[implementing a batching technique](/learn/best-practices/#server-side-batching-caching)
+or [utilizing a tool like DataLoader](https://github.com/graphql/dataloader).
## What is a GraphQL client and why would I use one?
-GraphQL clients can help you handle [queries, mutations,](/learn/queries/) and [subscriptions](https://spec.graphql.org/draft/#sec-Subscription) to a [GraphQL server](https://www.howtographql.com/advanced/1-server/). They use the underlying structure of a GraphQL API to automate certain processes. This includes batching, UI updates, build-time schema validation, and more.
+GraphQL clients can help you handle [queries, mutations,](/learn/queries/) and
+[subscriptions](https://spec.graphql.org/draft/#sec-Subscription) to a
+[GraphQL server](https://www.howtographql.com/advanced/1-server/). They use the
+underlying structure of a GraphQL API to automate certain processes. This
+includes batching, UI updates, build-time schema validation, and more.
-A list of GraphQL clients in various languages is available on our [Code page](/code/). There’s also an [in-depth explanation of their benefits](https://www.howtographql.com/advanced/0-clients/) on How To GraphQL.
+A list of GraphQL clients in various languages is available on our
+[Code page](/code/). There’s also an
+[in-depth explanation of their benefits](https://www.howtographql.com/advanced/0-clients/)
+on How To GraphQL.
-You don't need a specific client to work with GraphQL, though. You might want to start out by [issuing GraphQL results with a regular HTTP client](/learn/serving-over-http/). Then later switch to a GraphQL-optimized client as your application grows in complexity.
+You don't need a specific client to work with GraphQL, though. You might want to
+start out by
+[issuing GraphQL results with a regular HTTP client](/learn/serving-over-http/).
+Then later switch to a GraphQL-optimized client as your application grows in
+complexity.
## Does GraphQL replace ORMs?
-No, GraphQL is a specification typically used for remote client-server communications. It's [agnostic to the data source(s) used](#is-graphql-a-database-language-like-sql) and doesn't implement an object-relational mapping technique. But there are ORMs built specifically for GraphQL. A few of those are listed under the [Services section of our Code page](/code/?tags=services).
+No, GraphQL is a specification typically used for remote client-server
+communications. It's
+[agnostic to the data source(s) used](#is-graphql-a-database-language-like-sql)
+and doesn't implement an object-relational mapping technique. But there are ORMs
+built specifically for GraphQL. A few of those are listed under the
+[Services section of our Code page](/code/?tags=services).
## Is GraphQL owned by Facebook?
-No, GraphQL is governed by the [GraphQL Foundation](#what-is-the-graphql-foundation).
+No, GraphQL is governed by the
+[GraphQL Foundation](#what-is-the-graphql-foundation).
-That said, the specification was originally developed at Facebook and [Facebook is a member](https://foundation.graphql.org/members/) of the GraphQL Foundation. You might notice that some of our [GitHub repositories](https://github.com/graphql/) still have the license listed under Facebook Inc. We're updating those and have already converted major projects, like [GraphiQL](https://github.com/graphql/graphiql/blob/main/LICENSE) and [DataLoader](https://github.com/graphql/dataloader/blob/master/LICENSE), to the new copyright: "Copyright (c) {new Date().getFullYear()} GraphQL Contributors."
+That said, the specification was originally developed at Facebook and
+[Facebook is a member](https://foundation.graphql.org/members/) of the GraphQL
+Foundation. You might notice that some of our
+[GitHub repositories](https://github.com/graphql/) still have the license listed
+under Facebook Inc. We're updating those and have already converted major
+projects, like [GraphiQL](https://github.com/graphql/graphiql/blob/main/LICENSE)
+and [DataLoader](https://github.com/graphql/dataloader/blob/master/LICENSE), to
+the new copyright: "Copyright (c) {new Date().getFullYear()} GraphQL
+Contributors."
## Who is behind GraphQL?
-Many people! The [GraphQL specification and all related projects](http://github.com/graphql/) are open source, so anyone is welcome to [contribute](#how-can-i-contribute-to-the-specification). That said, there is a structure in place behind the repositories. This exists to resolve conflicts within the community and guiding technical decisions.
-
-The [GraphQL Foundation](#what-is-the-graphql-foundation) provides most of the oversight for GraphQL. It's made up of [representatives from dozens of different companies](https://foundation.graphql.org/members/).
-
-There are also monthly virtual [GraphQL Working Group (WG)](https://github.com/graphql/graphql-wg) meetings managed by the GraphQL Foundation. These meetings are designed to bring together maintainers of commonly used GraphQL libraries and tools, as well as significant contributors to the GraphQL community. The WG meetings are completely open. Anyone is able to join and [propose items to the agenda](https://github.com/graphql/graphql-wg/blob/main/agendas/).
-
-In the [November 2020 WG meeting](https://www.youtube.com/watch?v=UybZp9O24Ow), it was announced that GraphQL will have a Technical Steering Committee (TSC) going forward. More on that coming soon.
-
-If this is confusing, don’t worry - there’s a lot going on. To get a more visual, high-level overview, check out the [GraphQL Landscape](https://landscape.graphql.org/).
+Many people! The
+[GraphQL specification and all related projects](http://github.com/graphql/) are
+open source, so anyone is welcome to
+[contribute](#how-can-i-contribute-to-the-specification). That said, there is a
+structure in place behind the repositories. This exists to resolve conflicts
+within the community and guiding technical decisions.
+
+The [GraphQL Foundation](#what-is-the-graphql-foundation) provides most of the
+oversight for GraphQL. It's made up of
+[representatives from dozens of different companies](https://foundation.graphql.org/members/).
+
+There are also monthly virtual
+[GraphQL Working Group (WG)](https://github.com/graphql/graphql-wg) meetings
+managed by the GraphQL Foundation. These meetings are designed to bring together
+maintainers of commonly used GraphQL libraries and tools, as well as significant
+contributors to the GraphQL community. The WG meetings are completely open.
+Anyone is able to join and
+[propose items to the agenda](https://github.com/graphql/graphql-wg/blob/main/agendas/).
+
+In the [November 2020 WG meeting](https://www.youtube.com/watch?v=UybZp9O24Ow),
+it was announced that GraphQL will have a Technical Steering Committee (TSC)
+going forward. More on that coming soon.
+
+If this is confusing, don’t worry - there’s a lot going on. To get a more
+visual, high-level overview, check out the
+[GraphQL Landscape](https://landscape.graphql.org/).
## What is the GraphQL Foundation?
-The [GraphQL Foundation](https://foundation.graphql.org/faq/) is a neutral foundation that provides governance for GraphQL. This includes vendor-neutral oversight of open-source repositories, funding, events, and more. It's hosted under the [Linux Foundation](https://www.linuxfoundation.org/) and consists of [representatives from dozens of different companies](https://foundation.graphql.org/members/). The idea is that it’s an impartial and open home for the GraphQL community.
+The [GraphQL Foundation](https://foundation.graphql.org/faq/) is a neutral
+foundation that provides governance for GraphQL. This includes vendor-neutral
+oversight of open-source repositories, funding, events, and more. It's hosted
+under the [Linux Foundation](https://www.linuxfoundation.org/) and consists of
+[representatives from dozens of different companies](https://foundation.graphql.org/members/).
+The idea is that it’s an impartial and open home for the GraphQL community.
-You can find out more by visiting [foundation.graphql.org](https://foundation.graphql.org/).
+You can find out more by visiting
+[foundation.graphql.org](https://foundation.graphql.org/).
diff --git a/src/pages/faq/getting-started.mdx b/src/pages/faq/getting-started.mdx
index 76b09cd11f..d180014bf2 100644
--- a/src/pages/faq/getting-started.mdx
+++ b/src/pages/faq/getting-started.mdx
@@ -2,44 +2,90 @@
## Why should I use GraphQL?
-It depends on your use case, but in general, GraphQL has a few key features that stand out. For example, GraphQL enables you to:
+It depends on your use case, but in general, GraphQL has a few key features that
+stand out. For example, GraphQL enables you to:
- Aggregate data from [multiple UI components](/learn/queries/#fragments).
-- Create a representation of your data that feels familiar and natural ([a graph](/learn/thinking-in-graphs/#it-s-graphs-all-the-way-down)).
-- Ensure that all of your data is [statically typed](/learn/schema/) and these types inform [what queries the schema supports](/learn/introspection/).
-- [Reduce the need for breaking changes](/learn/best-practices/#versioning), but utilize a [built-in mechanism for deprecations](https://spec.graphql.org/draft/#sec--deprecated) when you need to.
-- Access to a [powerful tooling ecosystem](/code/#generic-tools) with GUIs, editor integrations, code generation, linting, analytics, and more.
+- Create a representation of your data that feels familiar and natural
+ ([a graph](/learn/thinking-in-graphs/#it-s-graphs-all-the-way-down)).
+- Ensure that all of your data is [statically typed](/learn/schema/) and these
+ types inform [what queries the schema supports](/learn/introspection/).
+- [Reduce the need for breaking changes](/learn/best-practices/#versioning), but
+ utilize a
+ [built-in mechanism for deprecations](https://spec.graphql.org/draft/#sec--deprecated)
+ when you need to.
+- Access to a [powerful tooling ecosystem](/code/#generic-tools) with GUIs,
+ editor integrations, code generation, linting, analytics, and more.
[Our homepage](/) outlines even more reasons to use GraphQL.
-You can try out GraphQL without rewriting your entire application. For instance, starting with a single HTTP request that wraps an existing REST call. Your [GraphQL schema](/learn/thinking-in-graphs/#shared-language) and [business domain model](/learn/thinking-in-graphs/#business-logic-layer) can expand gradually. We recommend focusing on one use case at first and only building the part of the schema needed for that.
+You can try out GraphQL without rewriting your entire application. For instance,
+starting with a single HTTP request that wraps an existing REST call. Your
+[GraphQL schema](/learn/thinking-in-graphs/#shared-language) and
+[business domain model](/learn/thinking-in-graphs/#business-logic-layer) can
+expand gradually. We recommend focusing on one use case at first and only
+building the part of the schema needed for that.
## Does GraphQL replace REST?
-No, not necessarily. They both handle APIs and can [serve similar purposes](/learn/thinking-in-graphs/#business-logic-layer) from a business perspective. GraphQL is often considered an alternative to REST, but it’s not a definitive replacement.
+No, not necessarily. They both handle APIs and can
+[serve similar purposes](/learn/thinking-in-graphs/#business-logic-layer) from a
+business perspective. GraphQL is often considered an alternative to REST, but
+it’s not a definitive replacement.
-GraphQL and REST can actually co-exist in your stack. For example, you can abstract REST APIs behind a [GraphQL server](https://www.howtographql.com/advanced/1-server/). This can be done by masking your REST endpoint into a GraphQL endpoint using [root resolvers](/learn/execution/#root-fields-resolvers).
+GraphQL and REST can actually co-exist in your stack. For example, you can
+abstract REST APIs behind a
+[GraphQL server](https://www.howtographql.com/advanced/1-server/). This can be
+done by masking your REST endpoint into a GraphQL endpoint using
+[root resolvers](/learn/execution/#root-fields-resolvers).
-For an opinionated perspective on how GraphQL compares to REST, check out [How To GraphQL](https://www.howtographql.com/basics/1-graphql-is-the-better-rest/).
+For an opinionated perspective on how GraphQL compares to REST, check out
+[How To GraphQL](https://www.howtographql.com/basics/1-graphql-is-the-better-rest/).
## Is GraphQL a database language like SQL?
No, but this is a common misconception.
-GraphQL is a specification typically used for remote client-server communications. Unlike SQL, GraphQL is agnostic to the data source(s) used to retrieve data and persist changes. Accessing and manipulating data is performed with arbitrary functions called [resolvers](/learn/execution/). GraphQL coordinates and aggregates the data from these resolver functions, then returns the result to the client. Generally, these resolver functions should delegate to a [business logic layer](/learn/thinking-in-graphs/#business-logic-layer) responsible for communicating with the various underlying data sources. These data sources could be remote APIs, databases, [local cache](/learn/caching/), and nearly anything else your programming language can access.
+GraphQL is a specification typically used for remote client-server
+communications. Unlike SQL, GraphQL is agnostic to the data source(s) used to
+retrieve data and persist changes. Accessing and manipulating data is performed
+with arbitrary functions called [resolvers](/learn/execution/). GraphQL
+coordinates and aggregates the data from these resolver functions, then returns
+the result to the client. Generally, these resolver functions should delegate to
+a [business logic layer](/learn/thinking-in-graphs/#business-logic-layer)
+responsible for communicating with the various underlying data sources. These
+data sources could be remote APIs, databases, [local cache](/learn/caching/),
+and nearly anything else your programming language can access.
-For more information on how to get GraphQL to interact with your database, check out our [documentation on resolvers](/learn/execution/#root-fields-resolvers).
+For more information on how to get GraphQL to interact with your database, check
+out our [documentation on resolvers](/learn/execution/#root-fields-resolvers).
## How can I learn GraphQL?
-There are many resources available to help you learn GraphQL, including this website. In [our documentation](/learn/), you’ll find a series of articles that explain essential GraphQL concepts and how they work. Our [Community page](/community) is full of resources to reference and groups to join.
+There are many resources available to help you learn GraphQL, including this
+website. In [our documentation](/learn/), you’ll find a series of articles that
+explain essential GraphQL concepts and how they work. Our
+[Community page](/community) is full of resources to reference and groups to
+join.
-For more practical guides, visit the [How to GraphQL](https://www.howtographql.com/) fullstack tutorial website. We also have a free online course with edX, [Exploring GraphQL: A Query Language for APIs](https://www.edx.org/course/exploring-graphql-a-query-language-for-apis).
+For more practical guides, visit the
+[How to GraphQL](https://www.howtographql.com/) fullstack tutorial website. We
+also have a free online course with edX,
+[Exploring GraphQL: A Query Language for APIs](https://www.edx.org/course/exploring-graphql-a-query-language-for-apis).
-Before you start your learning journey, make sure you know [what an API is](https://www.codenewbie.org/blogs/an-intro-to-apis) and how communication generally works between client and server.
+Before you start your learning journey, make sure you know
+[what an API is](https://www.codenewbie.org/blogs/an-intro-to-apis) and how
+communication generally works between client and server.
## Is GraphQL only for React or JavaScript developers?
-No, not at all. [GraphQL is a specification](https://spec.graphql.org/) that can be [implemented in any language](/learn/schema/#type-language). Our [Code page](/code/) contains a long list of libraries in many different programming languages to help with that.
+No, not at all. [GraphQL is a specification](https://spec.graphql.org/) that can
+be [implemented in any language](/learn/schema/#type-language). Our
+[Code page](/code/) contains a long list of libraries in many different
+programming languages to help with that.
-It’s understandable why you’d think this, though. GraphQL was introduced at a [React conference](https://www.youtube.com/watch?v=9sc8Pyc51uU) and [GraphQL.js](/graphql-js/) is one of the most widely used implementations to date. We know this can be confusing, so we’re working to improve our documentation and add more code samples that aren’t written in JavaScript.
+It’s understandable why you’d think this, though. GraphQL was introduced at a
+[React conference](https://www.youtube.com/watch?v=9sc8Pyc51uU) and
+[GraphQL.js](/graphql-js/) is one of the most widely used implementations to
+date. We know this can be confusing, so we’re working to improve our
+documentation and add more code samples that aren’t written in JavaScript.
diff --git a/src/pages/faq/index.mdx b/src/pages/faq/index.mdx
index 2a0a6574ef..f13b1568c4 100644
--- a/src/pages/faq/index.mdx
+++ b/src/pages/faq/index.mdx
@@ -1,14 +1,20 @@
-import { Cards } from 'nextra/components'
-import metaFile from './_meta'
+import { Cards } from "nextra/components"
+import metaFile from "./_meta"
# Frequently Asked Questions (FAQ)
<Cards>
- {Object.entries(metaFile).slice(1).map(([key]) => (
- <Cards.Card
- key={key}
- title={key.split('-').map(word => word[0].toUpperCase() + word.slice(1)).join(' ')}
- href={`/faq/${key}`} arrow
- />
- ))}
+ {Object.entries(metaFile)
+ .slice(1)
+ .map(([key]) => (
+ <Cards.Card
+ key={key}
+ title={key
+ .split("-")
+ .map(word => word[0].toUpperCase() + word.slice(1))
+ .join(" ")}
+ href={`/faq/${key}`}
+ arrow
+ />
+ ))}
</Cards>
diff --git a/src/pages/faq/specification.mdx b/src/pages/faq/specification.mdx
index f0b48fdb64..d6f1f2a8a9 100644
--- a/src/pages/faq/specification.mdx
+++ b/src/pages/faq/specification.mdx
@@ -2,26 +2,58 @@
## What is the best way to follow specification releases?
-The latest working draft release of the GraphQL specification can be found at [spec.graphql.org/draft](https://spec.graphql.org/draft/). Previous editions are also available at permalinks that match their [release tag](https://github.com/graphql/graphql-spec/releases).
-
-The entire process behind each release is open source. You can monitor specification proposals by following [pull requests in the graphql-spec repository](https://github.com/graphql/graphql-spec/pulls). You can also watch past GraphQL Working Group discussions about various proposals on [YouTube](https://www.youtube.com/channel/UCERcwLeheOXp_u61jEXxHMA).
+The latest working draft release of the GraphQL specification can be found at
+[spec.graphql.org/draft](https://spec.graphql.org/draft/). Previous editions are
+also available at permalinks that match their
+[release tag](https://github.com/graphql/graphql-spec/releases).
+
+The entire process behind each release is open source. You can monitor
+specification proposals by following
+[pull requests in the graphql-spec repository](https://github.com/graphql/graphql-spec/pulls).
+You can also watch past GraphQL Working Group discussions about various
+proposals on
+[YouTube](https://www.youtube.com/channel/UCERcwLeheOXp_u61jEXxHMA).
## How can I contribute to the GraphQL specification?
-GraphQL is still evolving and contributions are very welcome! The specification (including the [latest working draft](https://spec.graphql.org/)) is open source. [Contributor guidelines](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) are available on GitHub.
-
-There are more ways to get involved with GraphQL beyond the specification though. Updating the content on [this website and the documentation](https://github.com/graphql/graphql.github.io), for example. Or contributing to [graphql-js](https://github.com/graphql/graphql-js), [graphql-http](https://github.com/graphql/graphql-http), [GraphiQL](https://github.com/graphql/graphiql), or [one of the many other projects](https://github.com/graphql/) maintained by the [GraphQL Foundation](#what-is-the-graphql-foundation).
+GraphQL is still evolving and contributions are very welcome! The specification
+(including the [latest working draft](https://spec.graphql.org/)) is open
+source.
+[Contributor guidelines](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md)
+are available on GitHub.
+
+There are more ways to get involved with GraphQL beyond the specification
+though. Updating the content on
+[this website and the documentation](https://github.com/graphql/graphql.github.io),
+for example. Or contributing to
+[graphql-js](https://github.com/graphql/graphql-js),
+[graphql-http](https://github.com/graphql/graphql-http),
+[GraphiQL](https://github.com/graphql/graphiql), or
+[one of the many other projects](https://github.com/graphql/) maintained by the
+[GraphQL Foundation](#what-is-the-graphql-foundation).
## What is GraphQL Specification membership?
-The [GraphQL Specification](https://specification.graphql.org) and the associated reference implementations are a Joint Development Foundation project (also part of the Linux Foundation family). Individual or corporate contributors sign a document at no cost that they agree their contributions are under the open source licenses of the project. Because this is not GraphQL Foundation membership, specification members do not decide how to spend the budget.
+The [GraphQL Specification](https://specification.graphql.org) and the
+associated reference implementations are a Joint Development Foundation project
+(also part of the Linux Foundation family). Individual or corporate contributors
+sign a document at no cost that they agree their contributions are under the
+open source licenses of the project. Because this is not GraphQL Foundation
+membership, specification members do not decide how to spend the budget.
-To sign the [GraphQL Specification membership document](https://github.com/graphql/graphql-wg/tree/HEAD/membership), open a PR against any [GraphQL repo on GitHub](https://github.com/graphql).
+To sign the
+[GraphQL Specification membership document](https://github.com/graphql/graphql-wg/tree/HEAD/membership),
+open a PR against any [GraphQL repo on GitHub](https://github.com/graphql).
-If your organization uses and benefits from GraphQL, please consider becoming a member of both by opening a PR on behalf of your company and [joining the GraphQL Foundation](https://join.graphql.org).
+If your organization uses and benefits from GraphQL, please consider becoming a
+member of both by opening a PR on behalf of your company and
+[joining the GraphQL Foundation](https://join.graphql.org).
## Where is the documentation for subscriptions?
-It's not on this website yet, but we're working on it. If you'd like to help write guides on subscriptions, please [let us know](https://github.com/graphql/graphql.github.io/issues/993).
+It's not on this website yet, but we're working on it. If you'd like to help
+write guides on subscriptions, please
+[let us know](https://github.com/graphql/graphql.github.io/issues/993).
-For now, the specification includes details for [how to write and execute subscriptions](https://spec.graphql.org/draft/#sec-Subscription).
+For now, the specification includes details for
+[how to write and execute subscriptions](https://spec.graphql.org/draft/#sec-Subscription).
diff --git a/src/pages/graphql-js/authentication-and-express-middleware.mdx b/src/pages/graphql-js/authentication-and-express-middleware.mdx
index 617eb0fa05..6f532aaaf8 100644
--- a/src/pages/graphql-js/authentication-and-express-middleware.mdx
+++ b/src/pages/graphql-js/authentication-and-express-middleware.mdx
@@ -3,11 +3,17 @@ title: Authentication and Express Middleware
sidebarTitle: Authentication & Middleware
---
-It's simple to use any Express middleware in conjunction with `graphql-http`. In particular, this is a great pattern for handling authentication.
+It's simple to use any Express middleware in conjunction with `graphql-http`. In
+particular, this is a great pattern for handling authentication.
-To use middleware with a GraphQL resolver, just use the middleware like you would with a normal Express app. The `request` object is then available as the second argument in any resolver.
+To use middleware with a GraphQL resolver, just use the middleware like you
+would with a normal Express app. The `request` object is then available as the
+second argument in any resolver.
-For example, let's say we wanted our server to log the IP address of every request, and we also want to write an API that returns the IP address of the caller. We can do the former with middleware, and the latter by accessing the `request` object in a resolver. Here's server code that implements this:
+For example, let's say we wanted our server to log the IP address of every
+request, and we also want to write an API that returns the IP address of the
+caller. We can do the former with middleware, and the latter by accessing the
+`request` object in a resolver. Here's server code that implements this:
```js
var express = require("express")
@@ -28,7 +34,7 @@ function loggingMiddleware(req, res, next) {
var root = {
ip(args, context) {
return context.ip
- },
+ }
}
var app = express()
@@ -39,16 +45,26 @@ app.all(
schema: schema,
rootValue: root,
context: req => ({
- ip: req.raw.ip,
- }),
+ ip: req.raw.ip
+ })
})
)
app.listen(4000)
console.log("Running a GraphQL API server at localhost:4000/graphql")
```
-In a REST API, authentication is often handled with a header, that contains an auth token which proves what user is making this request. Express middleware processes these headers and puts authentication data on the Express `request` object. Some middleware modules that handle authentication like this are [Passport](http://passportjs.org/), [express-jwt](https://github.com/auth0/express-jwt), and [express-session](https://github.com/expressjs/session). Each of these modules works with `graphql-http`.
+In a REST API, authentication is often handled with a header, that contains an
+auth token which proves what user is making this request. Express middleware
+processes these headers and puts authentication data on the Express `request`
+object. Some middleware modules that handle authentication like this are
+[Passport](http://passportjs.org/),
+[express-jwt](https://github.com/auth0/express-jwt), and
+[express-session](https://github.com/expressjs/session). Each of these modules
+works with `graphql-http`.
-If you aren't familiar with any of these authentication mechanisms, we recommend using `express-jwt` because it's simple without sacrificing any future flexibility.
+If you aren't familiar with any of these authentication mechanisms, we recommend
+using `express-jwt` because it's simple without sacrificing any future
+flexibility.
-If you've read through the docs linearly to get to this point, congratulations! You now know everything you need to build a practical GraphQL API server.
+If you've read through the docs linearly to get to this point, congratulations!
+You now know everything you need to build a practical GraphQL API server.
diff --git a/src/pages/graphql-js/basic-types.mdx b/src/pages/graphql-js/basic-types.mdx
index 37339d0f9c..309f0ccba7 100644
--- a/src/pages/graphql-js/basic-types.mdx
+++ b/src/pages/graphql-js/basic-types.mdx
@@ -2,15 +2,24 @@
title: Basic Types
---
-In most situations, all you need to do is to specify the types for your API using the GraphQL schema language, taken as an argument to the `buildSchema` function.
+In most situations, all you need to do is to specify the types for your API
+using the GraphQL schema language, taken as an argument to the `buildSchema`
+function.
-The GraphQL schema language supports the scalar types of `String`, `Int`, `Float`, `Boolean`, and `ID`, so you can use these directly in the schema you pass to `buildSchema`.
+The GraphQL schema language supports the scalar types of `String`, `Int`,
+`Float`, `Boolean`, and `ID`, so you can use these directly in the schema you
+pass to `buildSchema`.
-By default, every type is nullable - it's legitimate to return `null` as any of the scalar types. Use an exclamation point to indicate a type cannot be nullable, so `String!` is a non-nullable string.
+By default, every type is nullable - it's legitimate to return `null` as any of
+the scalar types. Use an exclamation point to indicate a type cannot be
+nullable, so `String!` is a non-nullable string.
-To use a list type, surround the type in square brackets, so `[Int]` is a list of integers.
+To use a list type, surround the type in square brackets, so `[Int]` is a list
+of integers.
-Each of these types maps straightforwardly to JavaScript, so you can just return plain old JavaScript objects in APIs that return these types. Here's an example that shows how to use some of these basic types:
+Each of these types maps straightforwardly to JavaScript, so you can just return
+plain old JavaScript objects in APIs that return these types. Here's an example
+that shows how to use some of these basic types:
```js
var express = require("express")
@@ -36,7 +45,7 @@ var root = {
},
rollThreeDice() {
return [1, 2, 3].map(_ => 1 + Math.floor(Math.random() * 6))
- },
+ }
}
var app = express()
@@ -44,13 +53,16 @@ app.all(
"/graphql",
createHandler({
schema: schema,
- rootValue: root,
+ rootValue: root
})
)
app.listen(4000)
console.log("Running a GraphQL API server at localhost:4000/graphql")
```
-If you run this code with `node server.js` and browse to http://localhost:4000/graphql you can try out these APIs.
+If you run this code with `node server.js` and browse to
+http://localhost:4000/graphql you can try out these APIs.
-These examples show you how to call APIs that return different types. To send different types of data into an API, you will also need to learn about [passing arguments to a GraphQL API](/graphql-js/passing-arguments/).
+These examples show you how to call APIs that return different types. To send
+different types of data into an API, you will also need to learn about
+[passing arguments to a GraphQL API](/graphql-js/passing-arguments/).
diff --git a/src/pages/graphql-js/constructing-types.mdx b/src/pages/graphql-js/constructing-types.mdx
index 1352adfbc9..21ac5516ce 100644
--- a/src/pages/graphql-js/constructing-types.mdx
+++ b/src/pages/graphql-js/constructing-types.mdx
@@ -2,11 +2,18 @@
title: Constructing Types
---
-For many apps, you can define a fixed schema when the application starts, and define it using GraphQL schema language. In some cases, it's useful to construct a schema programmatically. You can do this using the `GraphQLSchema` constructor.
+For many apps, you can define a fixed schema when the application starts, and
+define it using GraphQL schema language. In some cases, it's useful to construct
+a schema programmatically. You can do this using the `GraphQLSchema`
+constructor.
-When you are using the `GraphQLSchema` constructor to create a schema, instead of defining `Query` and `Mutation` types solely using schema language, you create them as separate object types.
+When you are using the `GraphQLSchema` constructor to create a schema, instead
+of defining `Query` and `Mutation` types solely using schema language, you
+create them as separate object types.
-For example, let's say we are building a simple API that lets you fetch user data for a few hardcoded users based on an id. Using `buildSchema` we could write a server with:
+For example, let's say we are building a simple API that lets you fetch user
+data for a few hardcoded users based on an id. Using `buildSchema` we could
+write a server with:
```js
var express = require("express")
@@ -28,18 +35,18 @@ var schema = buildSchema(`
var fakeDatabase = {
a: {
id: "a",
- name: "alice",
+ name: "alice"
},
b: {
id: "b",
- name: "bob",
- },
+ name: "bob"
+ }
}
var root = {
user({ id }) {
return fakeDatabase[id]
- },
+ }
}
var app = express()
@@ -47,7 +54,7 @@ app.all(
"/graphql",
createHandler({
schema: schema,
- rootValue: root,
+ rootValue: root
})
)
app.listen(4000)
@@ -65,12 +72,12 @@ var graphql = require("graphql")
var fakeDatabase = {
a: {
id: "a",
- name: "alice",
+ name: "alice"
},
b: {
id: "b",
- name: "bob",
- },
+ name: "bob"
+ }
}
// Define the User type
@@ -78,8 +85,8 @@ var userType = new graphql.GraphQLObjectType({
name: "User",
fields: {
id: { type: graphql.GraphQLString },
- name: { type: graphql.GraphQLString },
- },
+ name: { type: graphql.GraphQLString }
+ }
})
// Define the Query type
@@ -90,13 +97,13 @@ var queryType = new graphql.GraphQLObjectType({
type: userType,
// `args` describes the arguments that the `user` query accepts
args: {
- id: { type: graphql.GraphQLString },
+ id: { type: graphql.GraphQLString }
},
resolve: (_, { id }) => {
return fakeDatabase[id]
- },
- },
- },
+ }
+ }
+ }
})
var schema = new graphql.GraphQLSchema({ query: queryType })
@@ -105,13 +112,18 @@ var app = express()
app.all(
"/graphql",
createHandler({
- schema: schema,
+ schema: schema
})
)
app.listen(4000)
console.log("Running a GraphQL API server at localhost:4000/graphql")
```
-When we use this method of creating the API, the root level resolvers are implemented on the `Query` and `Mutation` types rather than on a `root` object.
+When we use this method of creating the API, the root level resolvers are
+implemented on the `Query` and `Mutation` types rather than on a `root` object.
-This is particularly useful if you want to create a GraphQL schema automatically from something else, like a database schema. You might have a common format for something like creating and updating database records. This is also useful for implementing features like union types which don't map cleanly to ES6 classes and schema language.
+This is particularly useful if you want to create a GraphQL schema automatically
+from something else, like a database schema. You might have a common format for
+something like creating and updating database records. This is also useful for
+implementing features like union types which don't map cleanly to ES6 classes
+and schema language.
diff --git a/src/pages/graphql-js/error.mdx b/src/pages/graphql-js/error.mdx
index d946d61a90..2a56fda365 100644
--- a/src/pages/graphql-js/error.mdx
+++ b/src/pages/graphql-js/error.mdx
@@ -6,8 +6,9 @@ title: graphql/error
# `graphql/error`
-The `graphql/error` module is responsible for creating and formatting
-GraphQL errors. You can import either from the `graphql/error` module, or from the root `graphql` module. For example:
+The `graphql/error` module is responsible for creating and formatting GraphQL
+errors. You can import either from the `graphql/error` module, or from the root
+`graphql` module. For example:
```js
import { GraphQLError } from "graphql" // ES6
@@ -19,22 +20,26 @@ var { GraphQLError } = require("graphql") // CommonJS
<ul className="apiIndex">
<li>
<a href="#graphqlerror">
- `class GraphQLError` A representation of an error that occurred within GraphQL.
+ `class GraphQLError` A representation of an error that occurred within
+ GraphQL.
</a>
</li>
<li>
<a href="#syntaxerror">
- `function syntaxError` Produces a GraphQLError representing a syntax error.
+ `function syntaxError` Produces a GraphQLError representing a syntax
+ error.
</a>
</li>
<li>
<a href="#locatedError">
- `function locatedError` Produces a new GraphQLError aware of the location responsible for the error.
+ `function locatedError` Produces a new GraphQLError aware of the location
+ responsible for the error.
</a>
</li>
<li>
<a href="#formaterror">
- `function formatError` Format an error according to the rules described by the Response Format.
+ `function formatError` Format an error according to the rules described by
+ the Response Format.
</a>
</li>
</ul>
@@ -45,21 +50,21 @@ var { GraphQLError } = require("graphql") // CommonJS
```ts
class GraphQLError extends Error {
- constructor(
- message: string,
- nodes?: any[],
- stack?: string,
- source?: Source,
- positions?: number[],
- originalError?: Error,
- extensions?: { [key: string]: mixed }
- )
+ constructor(
+ message: string,
+ nodes?: any[],
+ stack?: string,
+ source?: Source,
+ positions?: number[],
+ originalError?: Error,
+ extensions?: { [key: string]: mixed }
+ )
}
```
-A representation of an error that occurred within GraphQL. Contains
-information about where in the query the error occurred for debugging. Most
-commonly constructed with `locatedError` below.
+A representation of an error that occurred within GraphQL. Contains information
+about where in the query the error occurred for debugging. Most commonly
+constructed with `locatedError` below.
### `syntaxError`
@@ -90,15 +95,15 @@ document responsible for the original Error.
function formatError(error: GraphQLError): GraphQLFormattedError
type GraphQLFormattedError = {
- message: string,
+ message: string
locations: GraphQLErrorLocation[]
-};
+}
type GraphQLErrorLocation = {
- line: number,
+ line: number
column: number
-};
+}
```
-Given a GraphQLError, format it according to the rules described by the
-Response Format, Errors section of the GraphQL Specification.
+Given a GraphQLError, format it according to the rules described by the Response
+Format, Errors section of the GraphQL Specification.
diff --git a/src/pages/graphql-js/execution.mdx b/src/pages/graphql-js/execution.mdx
index 58fd4e54c9..013ed4989b 100644
--- a/src/pages/graphql-js/execution.mdx
+++ b/src/pages/graphql-js/execution.mdx
@@ -7,7 +7,8 @@ title: graphql/execution
# `graphql/execution`
The `graphql/execution` module is responsible for the execution phase of
-fulfilling a GraphQL request. You can import either from the `graphql/execution` module, or from the root `graphql` module. For example:
+fulfilling a GraphQL request. You can import either from the `graphql/execution`
+module, or from the root `graphql` module. For example:
```js
import { execute } from "graphql" // ES6
@@ -34,15 +35,15 @@ export function execute(
documentAST: Document,
rootValue?: mixed,
contextValue?: mixed,
- variableValues?: {[key: string]: mixed},
+ variableValues?: { [key: string]: mixed },
operationName?: string
): MaybePromise<ExecutionResult>
-type MaybePromise<T> = Promise<T> | T;
+type MaybePromise<T> = Promise<T> | T
type ExecutionResult = {
- data: Object;
- errors?: GraphQLError[];
+ data: Object
+ errors?: GraphQLError[]
}
```
@@ -50,9 +51,9 @@ Implements the "Evaluating requests" section of the GraphQL specification.
Returns a Promise that will eventually be resolved and never rejected.
-If the arguments to this function do not result in a legal execution context,
-a GraphQLError will be thrown immediately explaining the invalid input.
+If the arguments to this function do not result in a legal execution context, a
+GraphQLError will be thrown immediately explaining the invalid input.
`ExecutionResult` represents the result of execution. `data` is the result of
-executing the query, `errors` is null if no errors occurred, and is a
-non-empty array if an error occurred.
+executing the query, `errors` is null if no errors occurred, and is a non-empty
+array if an error occurred.
diff --git a/src/pages/graphql-js/graphql-clients.mdx b/src/pages/graphql-js/graphql-clients.mdx
index b97162a037..1300aa0b92 100644
--- a/src/pages/graphql-js/graphql-clients.mdx
+++ b/src/pages/graphql-js/graphql-clients.mdx
@@ -2,9 +2,18 @@
title: GraphQL Clients
---
-Since a GraphQL API has more underlying structure than a REST API, there are more powerful clients like [Relay](https://facebook.github.io/relay/) which can automatically handle batching, caching, and other features. But you don't need a complex client to call a GraphQL server. With `graphql-http`, you can just send an HTTP POST request to the endpoint you mounted your GraphQL server on, passing the GraphQL query as the `query` field in a JSON payload.
-
-For example, let's say we mounted a GraphQL server on http://localhost:4000/graphql as in the example code for [running an Express GraphQL server](/graphql-js/running-an-express-graphql-server/), and we want to send the GraphQL query `{ hello }`. We can do this from the command line with `curl`. If you paste this into a terminal:
+Since a GraphQL API has more underlying structure than a REST API, there are
+more powerful clients like [Relay](https://facebook.github.io/relay/) which can
+automatically handle batching, caching, and other features. But you don't need a
+complex client to call a GraphQL server. With `graphql-http`, you can just send
+an HTTP POST request to the endpoint you mounted your GraphQL server on, passing
+the GraphQL query as the `query` field in a JSON payload.
+
+For example, let's say we mounted a GraphQL server on
+http://localhost:4000/graphql as in the example code for
+[running an Express GraphQL server](/graphql-js/running-an-express-graphql-server/),
+and we want to send the GraphQL query `{ hello }`. We can do this from the
+command line with `curl`. If you paste this into a terminal:
```bash
curl -X POST \
@@ -16,21 +25,25 @@ http://localhost:4000/graphql
You should see the output returned as JSON:
```json
-{"data":{"hello":"Hello world!"}}
+{ "data": { "hello": "Hello world!" } }
```
-If you prefer to use a graphical user interface to send a test query, you can use clients such as [GraphiQL](https://github.com/graphql/graphiql), [Insomnia](https://github.com/getinsomnia/insomnia), and [Postman](https://www.postman.com/product/graphql-client/).
+If you prefer to use a graphical user interface to send a test query, you can
+use clients such as [GraphiQL](https://github.com/graphql/graphiql),
+[Insomnia](https://github.com/getinsomnia/insomnia), and
+[Postman](https://www.postman.com/product/graphql-client/).
-It's also simple to send GraphQL from the browser. Open up http://localhost:4000/graphql, open a developer console, and paste in:
+It's also simple to send GraphQL from the browser. Open up
+http://localhost:4000/graphql, open a developer console, and paste in:
```js
fetch("/graphql", {
method: "POST",
headers: {
"Content-Type": "application/json",
- Accept: "application/json",
+ Accept: "application/json"
},
- body: JSON.stringify({ query: "{ hello }" }),
+ body: JSON.stringify({ query: "{ hello }" })
})
.then(r => r.json())
.then(data => console.log("data returned:", data))
@@ -42,9 +55,15 @@ You should see the data returned, logged in the console:
data returned: Object { hello: "Hello world!" }
```
-In this example, the query was just a hardcoded string. As your application becomes more complex, and you add GraphQL endpoints that take arguments as described in [Passing Arguments](/graphql-js/passing-arguments/), you will want to construct GraphQL queries using variables in client code. You can do this by including a keyword prefixed with a dollar sign in the query, and passing an extra `variables` field on the payload.
+In this example, the query was just a hardcoded string. As your application
+becomes more complex, and you add GraphQL endpoints that take arguments as
+described in [Passing Arguments](/graphql-js/passing-arguments/), you will want
+to construct GraphQL queries using variables in client code. You can do this by
+including a keyword prefixed with a dollar sign in the query, and passing an
+extra `variables` field on the payload.
-For example, let's say you're running the example server from [Passing Arguments](/graphql-js/passing-arguments/) that has a schema of
+For example, let's say you're running the example server from
+[Passing Arguments](/graphql-js/passing-arguments/) that has a schema of
```graphql
type Query {
@@ -57,27 +76,35 @@ You could access this from JavaScript with the code:
```js
var dice = 3
var sides = 6
-var query = /* GraphQL */`query RollDice($dice: Int!, $sides: Int) {
- rollDice(numDice: $dice, numSides: $sides)
-}`
+var query = /* GraphQL */ `
+ query RollDice($dice: Int!, $sides: Int) {
+ rollDice(numDice: $dice, numSides: $sides)
+ }
+`
fetch("/graphql", {
method: "POST",
headers: {
"Content-Type": "application/json",
- Accept: "application/json",
+ Accept: "application/json"
},
body: JSON.stringify({
query,
- variables: { dice, sides },
- }),
+ variables: { dice, sides }
+ })
})
.then(r => r.json())
.then(data => console.log("data returned:", data))
```
-Using this syntax for variables is a good idea because it automatically prevents bugs due to escaping, and it makes it easier to monitor your server.
+Using this syntax for variables is a good idea because it automatically prevents
+bugs due to escaping, and it makes it easier to monitor your server.
-In general, it will take a bit more time to set up a GraphQL client like Relay, but it's worth it to get more features as your application grows. You might want to start out just using HTTP requests as the underlying transport layer, and switching to a more complex client as your application gets more complex.
+In general, it will take a bit more time to set up a GraphQL client like Relay,
+but it's worth it to get more features as your application grows. You might want
+to start out just using HTTP requests as the underlying transport layer, and
+switching to a more complex client as your application gets more complex.
-At this point you can write a client and server in GraphQL for an API that receives a single string. To do more, you will want to [learn how to use the other basic data types](/graphql-js/basic-types/).
+At this point you can write a client and server in GraphQL for an API that
+receives a single string. To do more, you will want to
+[learn how to use the other basic data types](/graphql-js/basic-types/).
diff --git a/src/pages/graphql-js/graphql-http.mdx b/src/pages/graphql-js/graphql-http.mdx
index 000f64f4a8..89e2e0a6a7 100644
--- a/src/pages/graphql-js/graphql-http.mdx
+++ b/src/pages/graphql-js/graphql-http.mdx
@@ -6,7 +6,13 @@ title: graphql-http
# `graphql-http`
-The [official `graphql-http` package](https://github.com/graphql/graphql-http) provides a simple way to create a fully compliant GraphQL server. It has a handler for Node.js native [`http`](https://nodejs.org/api/http.html), together with handlers for well-known frameworks like [Express](https://expressjs.com/), [Fastify](https://www.fastify.io/) and [Koa](https://koajs.com/); as well as handlers for different runtimes like [Deno](https://deno.land/) and [Bun](https://bun.sh/).
+The [official `graphql-http` package](https://github.com/graphql/graphql-http)
+provides a simple way to create a fully compliant GraphQL server. It has a
+handler for Node.js native [`http`](https://nodejs.org/api/http.html), together
+with handlers for well-known frameworks like [Express](https://expressjs.com/),
+[Fastify](https://www.fastify.io/) and [Koa](https://koajs.com/); as well as
+handlers for different runtimes like [Deno](https://deno.land/) and
+[Bun](https://bun.sh/).
## Express
@@ -23,17 +29,20 @@ function createHandler({
rootValue,
context,
formatError,
- validationRules,
+ validationRules
}: {
- rootValue?: any,
- context?: any,
- formatError?: Function,
- validationRules?: any[],
+ rootValue?: any
+ context?: any
+ formatError?: Function
+ validationRules?: any[]
}): Handler
```
Constructs an Express handler based on a GraphQL schema.
-See the [tutorial](/graphql-js/running-an-express-graphql-server/) for sample usage.
+See the [tutorial](/graphql-js/running-an-express-graphql-server/) for sample
+usage.
-See the [GitHub README](https://github.com/graphql/graphql-http) for more extensive documentation, including how to use `graphql-http` with other server frameworks and runtimes.
+See the [GitHub README](https://github.com/graphql/graphql-http) for more
+extensive documentation, including how to use `graphql-http` with other server
+frameworks and runtimes.
diff --git a/src/pages/graphql-js/graphql.mdx b/src/pages/graphql-js/graphql.mdx
index 97606a2fc6..1d14d883de 100644
--- a/src/pages/graphql-js/graphql.mdx
+++ b/src/pages/graphql-js/graphql.mdx
@@ -141,15 +141,15 @@ function graphql(
requestString: string,
rootValue?: any,
contextValue?: any,
- variableValues?: {[key: string]: any},
+ variableValues?: { [key: string]: any },
operationName?: string
): Promise<GraphQLResult>
```
The `graphql` function lexes, parses, validates and executes a GraphQL request.
It requires a `schema` and a `requestString`. Optional arguments include a
-`rootValue`, which will get passed as the root value to the executor, a `contextValue`,
-which will get passed to all resolve functions,
+`rootValue`, which will get passed as the root value to the executor, a
+`contextValue`, which will get passed to all resolve functions,
`variableValues`, which will get passed to the executor to provide values for
any variables in `requestString`, and `operationName`, which allows the caller
to specify which operation in `requestString` will be run, in cases where
diff --git a/src/pages/graphql-js/index.mdx b/src/pages/graphql-js/index.mdx
index 86b2bfff55..9a22c45af7 100644
--- a/src/pages/graphql-js/index.mdx
+++ b/src/pages/graphql-js/index.mdx
@@ -9,7 +9,15 @@ sidebarTitle: Getting Started
## Prerequisites
-Before getting started, you should have Node v6 installed, although the examples should mostly work in previous versions of Node as well. For this guide, we won't use any language features that require transpilation, but we will use some ES6 features like [Promises](http://www.html5rocks.com/en/tutorials/es6/promises/), [classes](http://javascriptplayground.com/blog/2014/07/introduction-to-es6-classes-tutorial/), and [fat arrow functions](https://strongloop.com/strongblog/an-introduction-to-javascript-es6-arrow-functions/), so if you aren't familiar with them you might want to read up on them first.
+Before getting started, you should have Node v6 installed, although the examples
+should mostly work in previous versions of Node as well. For this guide, we
+won't use any language features that require transpilation, but we will use some
+ES6 features like
+[Promises](http://www.html5rocks.com/en/tutorials/es6/promises/),
+[classes](http://javascriptplayground.com/blog/2014/07/introduction-to-es6-classes-tutorial/),
+and
+[fat arrow functions](https://strongloop.com/strongblog/an-introduction-to-javascript-es6-arrow-functions/),
+so if you aren't familiar with them you might want to read up on them first.
To create a new project and install GraphQL.js in your current directory:
@@ -20,7 +28,10 @@ npm install graphql --save
## Writing Code
-To handle GraphQL queries, we need a schema that defines the `Query` type, and we need an API root with a function called a “resolver” for each API endpoint. For an API that just returns “Hello world!”, we can put this code in a file named `server.js`:
+To handle GraphQL queries, we need a schema that defines the `Query` type, and
+we need an API root with a function called a “resolver” for each API endpoint.
+For an API that just returns “Hello world!”, we can put this code in a file
+named `server.js`:
```javascript
var { graphql, buildSchema } = require("graphql")
@@ -67,4 +78,7 @@ You should see the GraphQL response printed out:
Congratulations - you just executed a GraphQL query!
-For practical applications, you'll probably want to run GraphQL queries from an API server, rather than executing GraphQL with a command line tool. To use GraphQL for an API server over HTTP, check out [Running an Express GraphQL Server](/graphql-js/running-an-express-graphql-server/).
+For practical applications, you'll probably want to run GraphQL queries from an
+API server, rather than executing GraphQL with a command line tool. To use
+GraphQL for an API server over HTTP, check out
+[Running an Express GraphQL Server](/graphql-js/running-an-express-graphql-server/).
diff --git a/src/pages/graphql-js/language.mdx b/src/pages/graphql-js/language.mdx
index b1bb642e1d..96bbad4e7e 100644
--- a/src/pages/graphql-js/language.mdx
+++ b/src/pages/graphql-js/language.mdx
@@ -6,7 +6,9 @@ title: graphql/language
# `graphql/language`
-The `graphql/language` module is responsible for parsing and operating on the GraphQL language. You can import either from the `graphql/language` module, or from the root `graphql` module. For example:
+The `graphql/language` module is responsible for parsing and operating on the
+GraphQL language. You can import either from the `graphql/language` module, or
+from the root `graphql` module. For example:
```js
import { Source } from "graphql" // ES6
@@ -25,7 +27,8 @@ var { Source } = require("graphql") // CommonJS
</li>
<li>
<a href="#getlocation">
- `function getLocation` Converts a character offset to a row and column in the Source
+ `function getLocation` Converts a character offset to a row and column in
+ the Source
</a>
</li>
</ul>
@@ -65,7 +68,8 @@ var { Source } = require("graphql") // CommonJS
<ul className="apiIndex">
<li>
<a href="#visit">
- `function visit` A general-purpose visitor to traverse a parsed GraphQL AST
+ `function visit` A general-purpose visitor to traverse a parsed GraphQL
+ AST
</a>
</li>
<li>
@@ -79,9 +83,7 @@ var { Source } = require("graphql") // CommonJS
<ul className="apiIndex">
<li>
- <a href="#print">
- `function print` Prints an AST in a standard format.
- </a>
+ <a href="#print">`function print` Prints an AST in a standard format.</a>
</li>
</ul>
@@ -95,10 +97,10 @@ export class Source {
}
```
-A representation of source input to GraphQL. The name is optional,
-but is mostly useful for clients who store GraphQL documents in
-source files; for example, if the GraphQL input is in a file Foo.graphql,
-it might be useful for name to be "Foo.graphql".
+A representation of source input to GraphQL. The name is optional, but is mostly
+useful for clients who store GraphQL documents in source files; for example, if
+the GraphQL input is in a file Foo.graphql, it might be useful for name to be
+"Foo.graphql".
### getLocation
@@ -106,50 +108,46 @@ it might be useful for name to be "Foo.graphql".
function getLocation(source: Source, position: number): SourceLocation
type SourceLocation = {
- line: number;
- column: number;
+ line: number
+ column: number
}
```
-Takes a Source and a UTF-8 character offset, and returns the corresponding
-line and column as a SourceLocation.
+Takes a Source and a UTF-8 character offset, and returns the corresponding line
+and column as a SourceLocation.
## Lexer
### `lex`
```ts
-function lex(source: Source): Lexer;
+function lex(source: Source): Lexer
-type Lexer = (resetPosition?: number) => Token;
+type Lexer = (resetPosition?: number) => Token
export type Token = {
- kind: number;
- start: number;
- end: number;
- value: string;
-};
+ kind: number
+ start: number
+ end: number
+ value: string
+}
```
-Given a Source object, this returns a Lexer for that source.
-A Lexer is a function that acts like a generator in that every time
-it is called, it returns the next token in the Source. Assuming the
-source lexes, the final Token emitted by the lexer will be of kind
-EOF, after which the lexer will repeatedly return EOF tokens whenever
-called.
+Given a Source object, this returns a Lexer for that source. A Lexer is a
+function that acts like a generator in that every time it is called, it returns
+the next token in the Source. Assuming the source lexes, the final Token emitted
+by the lexer will be of kind EOF, after which the lexer will repeatedly return
+EOF tokens whenever called.
-The argument to the lexer function is optional, and can be used to
-rewind or fast forward the lexer to a new position in the source.
+The argument to the lexer function is optional, and can be used to rewind or
+fast forward the lexer to a new position in the source.
## Parser
### `parse`
```ts
-export function parse(
- source: Source | string,
- options?: ParseOptions
-): Document
+export function parse(source: Source | string, options?: ParseOptions): Document
```
Given a GraphQL source, parses it into a Document.
@@ -169,8 +167,8 @@ Given a string containing a GraphQL value, parse the AST for that value.
Throws GraphQLError if a syntax error is encountered.
-This is useful within tools that operate upon GraphQL Values directly and
-in isolation of complete GraphQL documents.
+This is useful within tools that operate upon GraphQL Values directly and in
+isolation of complete GraphQL documents.
### `Kind`
@@ -184,18 +182,18 @@ An enum that describes the different kinds of AST nodes.
function visit(root, visitor, keyMap)
```
-visit() will walk through an AST using a depth first traversal, calling
-the visitor's enter function at each node in the traversal, and calling the
-leave function after visiting that node and all of its child nodes.
+visit() will walk through an AST using a depth first traversal, calling the
+visitor's enter function at each node in the traversal, and calling the leave
+function after visiting that node and all of its child nodes.
-By returning different values from the enter and leave functions, the
-behavior of the visitor can be altered, including skipping over a sub-tree of
-the AST (by returning false), editing the AST by returning a value or null
-to remove the value, or to stop the whole traversal by returning BREAK.
+By returning different values from the enter and leave functions, the behavior
+of the visitor can be altered, including skipping over a sub-tree of the AST (by
+returning false), editing the AST by returning a value or null to remove the
+value, or to stop the whole traversal by returning BREAK.
-When using visit() to edit an AST, the original AST will not be modified, and
-a new version of the AST with the changes applied will be returned from the
-visit function.
+When using visit() to edit an AST, the original AST will not be modified, and a
+new version of the AST with the changes applied will be returned from the visit
+function.
```js
var editedAST = visit(ast, {
@@ -214,14 +212,13 @@ var editedAST = visit(ast, {
// visitor.BREAK: stop visiting altogether
// null: delete this node
// any value: replace this node with the returned value
- },
+ }
})
```
-Alternatively to providing enter() and leave() functions, a visitor can
-instead provide functions named the same as the kinds of AST nodes, or
-enter/leave visitors at a named key, leading to four permutations of
-visitor API:
+Alternatively to providing enter() and leave() functions, a visitor can instead
+provide functions named the same as the kinds of AST nodes, or enter/leave
+visitors at a named key, leading to four permutations of visitor API:
1. Named visitors triggered when entering a node a specific kind.
@@ -229,12 +226,12 @@ visitor API:
visit(ast, {
Kind(node) {
// enter the "Kind" node
- },
+ }
})
```
-2. Named visitors that trigger upon entering and leaving a node of
- a specific kind.
+2. Named visitors that trigger upon entering and leaving a node of a specific
+ kind.
```js
visit(ast, {
@@ -258,7 +255,7 @@ visit(ast, {
},
leave(node) {
// leave any node
- },
+ }
})
```
@@ -269,13 +266,13 @@ visit(ast, {
enter: {
Kind(node) {
// enter the "Kind" node
- },
+ }
},
leave: {
Kind(node) {
// leave the "Kind" node
- },
- },
+ }
+ }
})
```
@@ -291,5 +288,4 @@ The sentinel `BREAK` value described in the documentation of `visitor`.
function print(ast): string
```
-Converts an AST into a string, using one set of reasonable
-formatting rules.
+Converts an AST into a string, using one set of reasonable formatting rules.
diff --git a/src/pages/graphql-js/mutations-and-input-types.mdx b/src/pages/graphql-js/mutations-and-input-types.mdx
index 2b61c733bf..d122f6990c 100644
--- a/src/pages/graphql-js/mutations-and-input-types.mdx
+++ b/src/pages/graphql-js/mutations-and-input-types.mdx
@@ -2,9 +2,14 @@
title: Mutations and Input Types
---
-If you have an API endpoint that alters data, like inserting data into a database or altering data already in a database, you should make this endpoint a `Mutation` rather than a `Query`. This is as simple as making the API endpoint part of the top-level `Mutation` type instead of the top-level `Query` type.
+If you have an API endpoint that alters data, like inserting data into a
+database or altering data already in a database, you should make this endpoint a
+`Mutation` rather than a `Query`. This is as simple as making the API endpoint
+part of the top-level `Mutation` type instead of the top-level `Query` type.
-Let's say we have a “message of the day” server, where anyone can update the message of the day, and anyone can read the current one. The GraphQL schema for this is simply:
+Let's say we have a “message of the day” server, where anyone can update the
+message of the day, and anyone can read the current one. The GraphQL schema for
+this is simply:
```graphql
type Mutation {
@@ -16,9 +21,13 @@ type Query {
}
```
-It's often convenient to have a mutation that maps to a database create or update operation, like `setMessage`, return the same thing that the server stored. That way, if you modify the data on the server, the client can learn about those modifications.
+It's often convenient to have a mutation that maps to a database create or
+update operation, like `setMessage`, return the same thing that the server
+stored. That way, if you modify the data on the server, the client can learn
+about those modifications.
-Both mutations and queries can be handled by root resolvers, so the root that implements this schema can simply be:
+Both mutations and queries can be handled by root resolvers, so the root that
+implements this schema can simply be:
```js
var fakeDatabase = {}
@@ -29,13 +38,21 @@ var root = {
},
getMessage() {
return fakeDatabase.message
- },
+ }
}
```
-You don't need anything more than this to implement mutations. But in many cases, you will find a number of different mutations that all accept the same input parameters. A common example is that creating an object in a database and updating an object in a database often take the same parameters. To make your schema simpler, you can use “input types” for this, by using the `input` keyword instead of the `type` keyword.
+You don't need anything more than this to implement mutations. But in many
+cases, you will find a number of different mutations that all accept the same
+input parameters. A common example is that creating an object in a database and
+updating an object in a database often take the same parameters. To make your
+schema simpler, you can use “input types” for this, by using the `input` keyword
+instead of the `type` keyword.
-For example, instead of a single message of the day, let's say we have many messages, indexed in a database by the `id` field, and each message has both a `content` string and an `author` string. We want a mutation API both for creating a new message and for updating an old message. We could use the schema:
+For example, instead of a single message of the day, let's say we have many
+messages, indexed in a database by the `id` field, and each message has both a
+`content` string and an `author` string. We want a mutation API both for
+creating a new message and for updating an old message. We could use the schema:
```graphql
input MessageInput {
@@ -59,13 +76,19 @@ type Mutation {
}
```
-Here, the mutations return a `Message` type, so that the client can get more information about the newly-modified `Message` in the same request as the request that mutates it.
+Here, the mutations return a `Message` type, so that the client can get more
+information about the newly-modified `Message` in the same request as the
+request that mutates it.
-Input types can't have fields that are other objects, only basic scalar types, list types, and other input types.
+Input types can't have fields that are other objects, only basic scalar types,
+list types, and other input types.
-Naming input types with `Input` on the end is a useful convention, because you will often want both an input type and an output type that are slightly different for a single conceptual object.
+Naming input types with `Input` on the end is a useful convention, because you
+will often want both an input type and an output type that are slightly
+different for a single conceptual object.
-Here's some runnable code that implements this schema, keeping the data in memory:
+Here's some runnable code that implements this schema, keeping the data in
+memory:
```js
var express = require("express")
@@ -73,7 +96,7 @@ var { createHandler } = require("graphql-http/lib/use/express")
var { buildSchema } = require("graphql")
// Construct a schema, using GraphQL schema language
-var schema = buildSchema(/* GraphQL */`
+var schema = buildSchema(/* GraphQL */ `
input MessageInput {
content: String
author: String
@@ -128,7 +151,7 @@ var root = {
// This replaces all old data, but some apps might want partial update.
fakeDatabase[id] = input
return new Message(id, input)
- },
+ }
}
var app = express()
@@ -136,7 +159,7 @@ app.all(
"/graphql",
createHandler({
schema: schema,
- rootValue: root,
+ rootValue: root
})
)
app.listen(4000, () => {
@@ -144,48 +167,55 @@ app.listen(4000, () => {
})
```
-To call a mutation, you must use the keyword `mutation` before your GraphQL query. To pass an input type, provide the data written as if it's a JSON object. For example, with the server defined above, you can create a new message and return the `id` of the new message with this operation:
+To call a mutation, you must use the keyword `mutation` before your GraphQL
+query. To pass an input type, provide the data written as if it's a JSON object.
+For example, with the server defined above, you can create a new message and
+return the `id` of the new message with this operation:
```graphql
mutation {
- createMessage(input: {
- author: "andy",
- content: "hope is a good thing",
- }) {
+ createMessage(input: { author: "andy", content: "hope is a good thing" }) {
id
}
}
```
-You can use variables to simplify mutation client logic just like you can with queries. For example, some JavaScript code that calls the server to execute this mutation is:
+You can use variables to simplify mutation client logic just like you can with
+queries. For example, some JavaScript code that calls the server to execute this
+mutation is:
```js
var author = "andy"
var content = "hope is a good thing"
-var query = /* GraphQL */`mutation CreateMessage($input: MessageInput) {
- createMessage(input: $input) {
- id
+var query = /* GraphQL */ `
+ mutation CreateMessage($input: MessageInput) {
+ createMessage(input: $input) {
+ id
+ }
}
-}`
+`
fetch("/graphql", {
method: "POST",
headers: {
"Content-Type": "application/json",
- Accept: "application/json",
+ Accept: "application/json"
},
body: JSON.stringify({
query,
variables: {
input: {
author,
- content,
- },
- },
- }),
+ content
+ }
+ }
+ })
})
.then(r => r.json())
.then(data => console.log("data returned:", data))
```
-One particular type of mutation is operations that change users, like signing up a new user. While you can implement this using GraphQL mutations, you can reuse many existing libraries if you learn about [GraphQL with authentication and Express middleware](/graphql-js/authentication-and-express-middleware/).
+One particular type of mutation is operations that change users, like signing up
+a new user. While you can implement this using GraphQL mutations, you can reuse
+many existing libraries if you learn about
+[GraphQL with authentication and Express middleware](/graphql-js/authentication-and-express-middleware/).
diff --git a/src/pages/graphql-js/object-types.mdx b/src/pages/graphql-js/object-types.mdx
index e54439ea91..14ac4513ae 100644
--- a/src/pages/graphql-js/object-types.mdx
+++ b/src/pages/graphql-js/object-types.mdx
@@ -2,9 +2,15 @@
title: Object Types
---
-In many cases, you don't want to return a number or a string from an API. You want to return an object that has its own complex behavior. GraphQL is a perfect fit for this.
+In many cases, you don't want to return a number or a string from an API. You
+want to return an object that has its own complex behavior. GraphQL is a perfect
+fit for this.
-In GraphQL schema language, the way you define a new object type is the same way we have been defining the `Query` type in our examples. Each object can have fields that return a particular type, and methods that take arguments. For example, in the [Passing Arguments](/graphql-js/passing-arguments/) documentation, we had a method to roll some random dice:
+In GraphQL schema language, the way you define a new object type is the same way
+we have been defining the `Query` type in our examples. Each object can have
+fields that return a particular type, and methods that take arguments. For
+example, in the [Passing Arguments](/graphql-js/passing-arguments/)
+documentation, we had a method to roll some random dice:
```graphql
type Query {
@@ -12,7 +18,8 @@ type Query {
}
```
-If we wanted to have more and more methods based on a random die over time, we could implement this with a `RandomDie` object type instead.
+If we wanted to have more and more methods based on a random die over time, we
+could implement this with a `RandomDie` object type instead.
```graphql
type RandomDie {
@@ -24,7 +31,9 @@ type Query {
}
```
-Instead of a root-level resolver for the `RandomDie` type, we can instead use an ES6 class, where the resolvers are instance methods. This code shows how the `RandomDie` schema above can be implemented:
+Instead of a root-level resolver for the `RandomDie` type, we can instead use an
+ES6 class, where the resolvers are instance methods. This code shows how the
+`RandomDie` schema above can be implemented:
```js
class RandomDie {
@@ -48,11 +57,14 @@ class RandomDie {
var root = {
getDie({ numSides }) {
return new RandomDie(numSides || 6)
- },
+ }
}
```
-For fields that don't use any arguments, you can use either properties on the object or instance methods. So for the example code above, both `numSides` and `rollOnce` can actually be used to implement GraphQL fields, so that code also implements the schema of:
+For fields that don't use any arguments, you can use either properties on the
+object or instance methods. So for the example code above, both `numSides` and
+`rollOnce` can actually be used to implement GraphQL fields, so that code also
+implements the schema of:
```graphql
type RandomDie {
@@ -66,7 +78,8 @@ type Query {
}
```
-Putting this all together, here is some sample code that runs a server with this GraphQL API:
+Putting this all together, here is some sample code that runs a server with this
+GraphQL API:
```js
var express = require("express")
@@ -74,7 +87,7 @@ var { createHandler } = require("graphql-http/lib/use/express")
var { buildSchema } = require("graphql")
// Construct a schema, using GraphQL schema language
-var schema = buildSchema(/* GraphQL */`
+var schema = buildSchema(/* GraphQL */ `
type RandomDie {
numSides: Int!
rollOnce: Int!
@@ -109,7 +122,7 @@ class RandomDie {
var root = {
getDie({ numSides }) {
return new RandomDie(numSides || 6)
- },
+ }
}
var app = express()
@@ -117,14 +130,17 @@ app.all(
"/graphql",
createHandler({
schema: schema,
- rootValue: root,
+ rootValue: root
})
)
app.listen(4000)
console.log("Running a GraphQL API server at localhost:4000/graphql")
```
-When you issue a GraphQL query against an API that returns object types, you can call multiple methods on the object at once by nesting the GraphQL field names. For example, if you wanted to call both `rollOnce` to roll a die once, and `roll` to roll a die three times, you could do it with this query:
+When you issue a GraphQL query against an API that returns object types, you can
+call multiple methods on the object at once by nesting the GraphQL field names.
+For example, if you wanted to call both `rollOnce` to roll a die once, and
+`roll` to roll a die three times, you could do it with this query:
```graphql
{
@@ -135,8 +151,17 @@ When you issue a GraphQL query against an API that returns object types, you can
}
```
-If you run this code with `node server.js` and browse to http://localhost:4000/graphql you can try out these APIs with [GraphiQL](https://github.com/graphql/graphiql).
+If you run this code with `node server.js` and browse to
+http://localhost:4000/graphql you can try out these APIs with
+[GraphiQL](https://github.com/graphql/graphiql).
-This way of defining object types often provides advantages over a traditional REST API. Instead of doing one API request to get basic information about an object, and then multiple subsequent API requests to find out more information about that object, you can get all of that information in one API request. That saves bandwidth, makes your app run faster, and simplifies your client-side logic.
+This way of defining object types often provides advantages over a traditional
+REST API. Instead of doing one API request to get basic information about an
+object, and then multiple subsequent API requests to find out more information
+about that object, you can get all of that information in one API request. That
+saves bandwidth, makes your app run faster, and simplifies your client-side
+logic.
-So far, every API we've looked at is designed for returning data. In order to modify stored data or handle complex input, it helps to [learn about mutations and input types](/graphql-js/mutations-and-input-types/).
+So far, every API we've looked at is designed for returning data. In order to
+modify stored data or handle complex input, it helps to
+[learn about mutations and input types](/graphql-js/mutations-and-input-types/).
diff --git a/src/pages/graphql-js/passing-arguments.mdx b/src/pages/graphql-js/passing-arguments.mdx
index 4878410b0c..4fc399e39e 100644
--- a/src/pages/graphql-js/passing-arguments.mdx
+++ b/src/pages/graphql-js/passing-arguments.mdx
@@ -2,7 +2,11 @@
title: Passing Arguments
---
-Just like a REST API, it's common to pass arguments to an endpoint in a GraphQL API. By defining the arguments in the schema language, typechecking happens automatically. Each argument must be named and have a type. For example, in the [Basic Types documentation](/graphql-js/basic-types/) we had an endpoint called `rollThreeDice`:
+Just like a REST API, it's common to pass arguments to an endpoint in a GraphQL
+API. By defining the arguments in the schema language, typechecking happens
+automatically. Each argument must be named and have a type. For example, in the
+[Basic Types documentation](/graphql-js/basic-types/) we had an endpoint called
+`rollThreeDice`:
```graphql
type Query {
@@ -10,7 +14,9 @@ type Query {
}
```
-Instead of hardcoding “three”, we might want a more general function that rolls `numDice` dice, each of which have `numSides` sides. We can add arguments to the GraphQL schema language like this:
+Instead of hardcoding “three”, we might want a more general function that rolls
+`numDice` dice, each of which have `numSides` sides. We can add arguments to the
+GraphQL schema language like this:
```graphql
type Query {
@@ -18,9 +24,13 @@ type Query {
}
```
-The exclamation point in `Int!` indicates that `numDice` can't be null, which means we can skip a bit of validation logic to make our server code simpler. We can let `numSides` be null and assume that by default a die has 6 sides.
+The exclamation point in `Int!` indicates that `numDice` can't be null, which
+means we can skip a bit of validation logic to make our server code simpler. We
+can let `numSides` be null and assume that by default a die has 6 sides.
-So far, our resolver functions took no arguments. When a resolver takes arguments, they are passed as one “args” object, as the first argument to the function. So rollDice could be implemented as:
+So far, our resolver functions took no arguments. When a resolver takes
+arguments, they are passed as one “args” object, as the first argument to the
+function. So rollDice could be implemented as:
```javascript
var root = {
@@ -30,11 +40,14 @@ var root = {
output.push(1 + Math.floor(Math.random() * (args.numSides || 6)))
}
return output
- },
+ }
}
```
-It's convenient to use [ES6 destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) for these parameters, since you know what format they will be. So we can also write `rollDice` as
+It's convenient to use
+[ES6 destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment)
+for these parameters, since you know what format they will be. So we can also
+write `rollDice` as
```javascript
var root = {
@@ -44,11 +57,12 @@ var root = {
output.push(1 + Math.floor(Math.random() * (numSides || 6)))
}
return output
- },
+ }
}
```
-If you're familiar with destructuring, this is a bit nicer because the line of code where `rollDice` is defined tells you about what the arguments are.
+If you're familiar with destructuring, this is a bit nicer because the line of
+code where `rollDice` is defined tells you about what the arguments are.
The entire code for a server that hosts this `rollDice` API is:
@@ -58,7 +72,7 @@ var { createHandler } = require("graphql-http/lib/use/express")
var { buildSchema } = require("graphql")
// Construct a schema, using GraphQL schema language
-var schema = buildSchema(/* GraphQL */`
+var schema = buildSchema(/* GraphQL */ `
type Query {
rollDice(numDice: Int!, numSides: Int): [Int]
}
@@ -72,7 +86,7 @@ var root = {
output.push(1 + Math.floor(Math.random() * (numSides || 6)))
}
return output
- },
+ }
}
var app = express()
@@ -80,14 +94,15 @@ app.all(
"/graphql",
createHandler({
schema: schema,
- rootValue: root,
+ rootValue: root
})
)
app.listen(4000)
console.log("Running a GraphQL API server at localhost:4000/graphql")
```
-When you call this API, you have to pass each argument by name. So for the server above, you could issue this GraphQL query to roll three six-sided dice:
+When you call this API, you have to pass each argument by name. So for the
+server above, you could issue this GraphQL query to roll three six-sided dice:
```graphql
{
@@ -95,34 +110,43 @@ When you call this API, you have to pass each argument by name. So for the serve
}
```
-If you run this code with `node server.js` and browse to http://localhost:4000/graphql you can try out this API.
+If you run this code with `node server.js` and browse to
+http://localhost:4000/graphql you can try out this API.
-When you're passing arguments in code, it's generally better to avoid constructing the whole query string yourself. Instead, you can use `$` syntax to define variables in your query, and pass the variables as a separate map.
+When you're passing arguments in code, it's generally better to avoid
+constructing the whole query string yourself. Instead, you can use `$` syntax to
+define variables in your query, and pass the variables as a separate map.
For example, some JavaScript code that calls our server above is:
```js
var dice = 3
var sides = 6
-var query = /* GraphQL */`query RollDice($dice: Int!, $sides: Int) {
- rollDice(numDice: $dice, numSides: $sides)
-}`
+var query = /* GraphQL */ `
+ query RollDice($dice: Int!, $sides: Int) {
+ rollDice(numDice: $dice, numSides: $sides)
+ }
+`
fetch("/graphql", {
method: "POST",
headers: {
"Content-Type": "application/json",
- Accept: "application/json",
+ Accept: "application/json"
},
body: JSON.stringify({
query,
- variables: { dice, sides },
- }),
+ variables: { dice, sides }
+ })
})
.then(r => r.json())
.then(data => console.log("data returned:", data))
```
-Using `$dice` and `$sides` as variables in GraphQL means we don't have to worry about escaping on the client side.
+Using `$dice` and `$sides` as variables in GraphQL means we don't have to worry
+about escaping on the client side.
-With basic types and argument passing, you can implement anything you can implement in a REST API. But GraphQL supports even more powerful queries. You can replace multiple API calls with a single API call if you learn how to [define your own object types](/graphql-js/object-types/).
+With basic types and argument passing, you can implement anything you can
+implement in a REST API. But GraphQL supports even more powerful queries. You
+can replace multiple API calls with a single API call if you learn how to
+[define your own object types](/graphql-js/object-types/).
diff --git a/src/pages/graphql-js/running-an-express-graphql-server.mdx b/src/pages/graphql-js/running-an-express-graphql-server.mdx
index c73b403198..c376d5c395 100644
--- a/src/pages/graphql-js/running-an-express-graphql-server.mdx
+++ b/src/pages/graphql-js/running-an-express-graphql-server.mdx
@@ -3,13 +3,19 @@ title: Running an Express GraphQL Server
sidebarTitle: Running Express + GraphQL
---
-The simplest way to run a GraphQL API server is to use [Express](https://expressjs.com), a popular web application framework for Node.js. You will need to install two additional dependencies:
+The simplest way to run a GraphQL API server is to use
+[Express](https://expressjs.com), a popular web application framework for
+Node.js. You will need to install two additional dependencies:
```bash
npm install express graphql-http graphql --save
```
-Let's modify our “hello world” example so that it's an API server rather than a script that runs a single query. We can use the 'express' module to run a webserver, and instead of executing a query directly with the `graphql` function, we can use the `graphql-http` library to mount a GraphQL API server on the “/graphql” HTTP endpoint:
+Let's modify our “hello world” example so that it's an API server rather than a
+script that runs a single query. We can use the 'express' module to run a
+webserver, and instead of executing a query directly with the `graphql`
+function, we can use the `graphql-http` library to mount a GraphQL API server on
+the “/graphql” HTTP endpoint:
```js
var express = require("express")
@@ -27,7 +33,7 @@ var schema = buildSchema(`
var root = {
hello() {
return "Hello world!"
- },
+ }
}
var app = express()
@@ -37,7 +43,7 @@ app.all(
"/graphql",
createHandler({
schema: schema,
- rootValue: root,
+ rootValue: root
})
)
@@ -54,9 +60,13 @@ node server.js
## Using GraphiQL
-[GraphiQL](https://github.com/graphql/graphiql) is GraphQL's IDE; a great way of querying and exploring your GraphQL API.
-One easy way to add it to your server is via the MIT-licensed [ruru](https://github.com/graphile/crystal/blob/main/grafast/ruru/README.md) package which bundles a prebuilt GraphiQL with some popular enhancements.
-To do so, install the `ruru` module with `npm install --save ruru` and then add the following to your `server.js` file, then restart the `node server.js` command:
+[GraphiQL](https://github.com/graphql/graphiql) is GraphQL's IDE; a great way of
+querying and exploring your GraphQL API. One easy way to add it to your server
+is via the MIT-licensed
+[ruru](https://github.com/graphile/crystal/blob/main/grafast/ruru/README.md)
+package which bundles a prebuilt GraphiQL with some popular enhancements. To do
+so, install the `ruru` module with `npm install --save ruru` and then add the
+following to your `server.js` file, then restart the `node server.js` command:
```js
var { ruruHTML } = require("ruru/server")
@@ -68,7 +78,10 @@ app.get("/", (_req, res) => {
})
```
-If you navigate to [http://localhost:4000](http://localhost:4000), you should see an interface that lets you enter queries;
-now you can use the GraphiQL IDE tool to issue GraphQL queries directly in the browser.
+If you navigate to [http://localhost:4000](http://localhost:4000), you should
+see an interface that lets you enter queries; now you can use the GraphiQL IDE
+tool to issue GraphQL queries directly in the browser.
-At this point you have learned how to run a GraphQL server. The next step is to learn how to [issue GraphQL queries from client code](/graphql-js/graphql-clients/).
+At this point you have learned how to run a GraphQL server. The next step is to
+learn how to
+[issue GraphQL queries from client code](/graphql-js/graphql-clients/).
diff --git a/src/pages/graphql-js/type.mdx b/src/pages/graphql-js/type.mdx
index d3cc9619ad..1d335c2169 100644
--- a/src/pages/graphql-js/type.mdx
+++ b/src/pages/graphql-js/type.mdx
@@ -6,7 +6,9 @@ title: graphql/type
# `graphql/type`
-The `graphql/type` module is responsible for defining GraphQL types and schema. You can import either from the `graphql/type` module, or from the root `graphql` module. For example:
+The `graphql/type` module is responsible for defining GraphQL types and schema.
+You can import either from the `graphql/type` module, or from the root `graphql`
+module. For example:
```js
import { GraphQLSchema } from "graphql" // ES6
@@ -19,7 +21,10 @@ var { GraphQLSchema } = require("graphql") // CommonJS
<ul className="apiIndex">
<li>
- <a href="#graphqlschema">`class GraphQLSchema` A representation of the capabilities of a GraphQL Server.</a>
+ <a href="#graphqlschema">
+ `class GraphQLSchema` A representation of the capabilities of a GraphQL
+ Server.
+ </a>
</li>
</ul>
@@ -27,76 +32,125 @@ var { GraphQLSchema } = require("graphql") // CommonJS
<ul className="apiIndex">
<li>
- <a href="#graphqlscalartype">`class GraphQLScalarType` A scalar type within GraphQL.</a>
+ <a href="#graphqlscalartype">
+ `class GraphQLScalarType` A scalar type within GraphQL.
+ </a>
</li>
<li>
- <a href="#graphqlobjecttype">`class GraphQLObjectType` An object type within GraphQL that contains fields.</a>
-</li>
+ <a href="#graphqlobjecttype">
+ `class GraphQLObjectType` An object type within GraphQL that contains
+ fields.
+ </a>
+ </li>
<li>
- <a href="#graphqlinterfacetype">`class GraphQLInterfaceType` An interface type within GraphQL that defines fields implementations will contain.</a>
-</li>
+ <a href="#graphqlinterfacetype">
+ `class GraphQLInterfaceType` An interface type within GraphQL that defines
+ fields implementations will contain.
+ </a>
+ </li>
<li>
- <a href="#graphqluniontype">`class GraphQLUnionType` A union type within GraphQL that defines a list of implementations.</a>
-</li>
+ <a href="#graphqluniontype">
+ `class GraphQLUnionType` A union type within GraphQL that defines a list
+ of implementations.
+ </a>
+ </li>
<li>
- <a href="#graphqlenumtype">`class GraphQLEnumType` An enum type within GraphQL that defines a list of valid values.</a>
-</li>
+ <a href="#graphqlenumtype">
+ `class GraphQLEnumType` An enum type within GraphQL that defines a list of
+ valid values.
+ </a>
+ </li>
<li>
- <a href="#graphqlinputobjecttype">`class GraphQLInputObjectType` An input object type within GraphQL that represents structured inputs.</a>
-</li>
+ <a href="#graphqlinputobjecttype">
+ `class GraphQLInputObjectType` An input object type within GraphQL that
+ represents structured inputs.
+ </a>
+ </li>
<li>
- <a href="#graphqllist">`class GraphQLList` A type wrapper around other types that represents a list of those types.</a>
-</li>
+ <a href="#graphqllist">
+ `class GraphQLList` A type wrapper around other types that represents a
+ list of those types.
+ </a>
+ </li>
<li>
- <a href="#graphqlnonnull">`class GraphQLNonNull` A type wrapper around other types that represents a non-null version of those types.</a>
-</li>
+ <a href="#graphqlnonnull">
+ `class GraphQLNonNull` A type wrapper around other types that represents a
+ non-null version of those types.
+ </a>
+ </li>
</ul>
### Predicates
<ul className="apiIndex">
<li>
- <a href="#isinputtype">`function isInputType` Returns if a type can be used as input types for arguments and directives.</a>
-</li>
+ <a href="#isinputtype">
+ `function isInputType` Returns if a type can be used as input types for
+ arguments and directives.
+ </a>
+ </li>
<li>
- <a href="#isoutputtype">`function isOutputType` Returns if a type can be used as output types as the result of fields.</a>
-</li>
+ <a href="#isoutputtype">
+ `function isOutputType` Returns if a type can be used as output types as
+ the result of fields.
+ </a>
+ </li>
<li>
- <a href="#isleaftype">`function isLeafType` Returns if a type can be a leaf value in a response.</a>
-</li>
+ <a href="#isleaftype">
+ `function isLeafType` Returns if a type can be a leaf value in a response.
+ </a>
+ </li>
<li>
- <a href="#iscompositetype">`function isCompositeType` Returns if a type can be the parent context of a selection set.</a>
-</li>
+ <a href="#iscompositetype">
+ `function isCompositeType` Returns if a type can be the parent context of
+ a selection set.
+ </a>
+ </li>
<li>
- <a href="#isabstracttype">`function isAbstractType` Returns if a type is a combination of object types.</a>
-</li>
+ <a href="#isabstracttype">
+ `function isAbstractType` Returns if a type is a combination of object
+ types.
+ </a>
+ </li>
</ul>
### Un-modifiers
<ul className="apiIndex">
<li>
- <a href="#getnullabletype">`function getNullableType` Strips any non-null wrappers from a type.</a>
-</li>
+ <a href="#getnullabletype">
+ `function getNullableType` Strips any non-null wrappers from a type.
+ </a>
+ </li>
<li>
- <a href="#getnamedtype">`function getNamedType` Strips any non-null or list wrappers from a type.</a>
-</li>
+ <a href="#getnamedtype">
+ `function getNamedType` Strips any non-null or list wrappers from a type.
+ </a>
+ </li>
</ul>
### Scalars
<ul className="apiIndex">
<li>
- <a href="#graphqlint">`var GraphQLInt` A scalar type representing integers.</a>
+ <a href="#graphqlint">
+ `var GraphQLInt` A scalar type representing integers.
+ </a>
</li>
<li>
- <a href="#graphqlfloat">`var GraphQLFloat` A scalar type representing floats.</a>
+ <a href="#graphqlfloat">
+ `var GraphQLFloat` A scalar type representing floats.
+ </a>
</li>
<li>
- <a href="#graphqlstring">`var GraphQLString` A scalar type representing strings.</a>
+ <a href="#graphqlstring">
+ `var GraphQLString` A scalar type representing strings.
+ </a>
</li>
<li>
- <a href="#graphqlboolean">`var GraphQLBoolean` A scalar type representing booleans.</a>
+ <a href="#graphqlboolean">
+ `var GraphQLBoolean` A scalar type representing booleans.
+ </a>
</li>
<li>
<a href="#graphqlid">`var GraphQLID` A scalar type representing IDs.</a>
@@ -113,14 +167,14 @@ class GraphQLSchema {
}
type GraphQLSchemaConfig = {
- query: GraphQLObjectType;
- mutation?: GraphQLObjectType;
+ query: GraphQLObjectType
+ mutation?: GraphQLObjectType
}
```
-A Schema is created by supplying the root types of each type of operation,
-query and mutation (optional). A schema definition is then supplied to the
-validator and executor.
+A Schema is created by supplying the root types of each type of operation, query
+and mutation (optional). A schema definition is then supplied to the validator
+and executor.
#### Example
@@ -128,7 +182,7 @@ validator and executor.
var MyAppSchema = new GraphQLSchema({
query: MyAppQueryRootType,
mutation: MyAppMutationRootType
-});
+})
```
## Definitions
@@ -141,17 +195,17 @@ class GraphQLScalarType<InternalType> {
}
type GraphQLScalarTypeConfig<InternalType> = {
- name: string;
- description?: string;
- serialize: (value: mixed) => InternalType;
- parseValue?: (value: mixed) => InternalType;
- parseLiteral?: (valueAST: Value) => InternalType;
+ name: string
+ description?: string
+ serialize: (value: mixed) => InternalType
+ parseValue?: (value: mixed) => InternalType
+ parseLiteral?: (valueAST: Value) => InternalType
}
```
-The leaf values of any request and input values to arguments are
-Scalars (or Enums) and are defined with a name and a series of serialization
-functions used to ensure validity.
+The leaf values of any request and input values to arguments are Scalars (or
+Enums) and are defined with a name and a series of serialization functions used
+to ensure validity.
#### Example
@@ -181,72 +235,72 @@ class GraphQLObjectType {
}
type GraphQLObjectTypeConfig = {
- name: string;
- interfaces?: GraphQLInterfacesThunk | GraphQLInterfaceType[];
- fields: GraphQLFieldConfigMapThunk | GraphQLFieldConfigMap;
- isTypeOf?: (value: any, info?: GraphQLResolveInfo) => boolean;
+ name: string
+ interfaces?: GraphQLInterfacesThunk | GraphQLInterfaceType[]
+ fields: GraphQLFieldConfigMapThunk | GraphQLFieldConfigMap
+ isTypeOf?: (value: any, info?: GraphQLResolveInfo) => boolean
description?: string
}
-type GraphQLInterfacesThunk = () => Array<GraphQLInterfaceType>;
+type GraphQLInterfacesThunk = () => Array<GraphQLInterfaceType>
-type GraphQLFieldConfigMapThunk = () => GraphQLFieldConfigMap;
+type GraphQLFieldConfigMapThunk = () => GraphQLFieldConfigMap
// See below about resolver functions.
type GraphQLFieldResolveFn = (
source?: any,
- args?: {[argName: string]: any},
+ args?: { [argName: string]: any },
context?: any,
info?: GraphQLResolveInfo
) => any
type GraphQLResolveInfo = {
- fieldName: string,
- fieldNodes: Array<Field>,
- returnType: GraphQLOutputType,
- parentType: GraphQLCompositeType,
- schema: GraphQLSchema,
- fragments: { [fragmentName: string]: FragmentDefinition },
- rootValue: any,
- operation: OperationDefinition,
- variableValues: { [variableName: string]: any },
+ fieldName: string
+ fieldNodes: Array<Field>
+ returnType: GraphQLOutputType
+ parentType: GraphQLCompositeType
+ schema: GraphQLSchema
+ fragments: { [fragmentName: string]: FragmentDefinition }
+ rootValue: any
+ operation: OperationDefinition
+ variableValues: { [variableName: string]: any }
}
type GraphQLFieldConfig = {
- type: GraphQLOutputType;
- args?: GraphQLFieldConfigArgumentMap;
- resolve?: GraphQLFieldResolveFn;
- deprecationReason?: string;
- description?: string;
+ type: GraphQLOutputType
+ args?: GraphQLFieldConfigArgumentMap
+ resolve?: GraphQLFieldResolveFn
+ deprecationReason?: string
+ description?: string
}
type GraphQLFieldConfigArgumentMap = {
- [argName: string]: GraphQLArgumentConfig;
-};
+ [argName: string]: GraphQLArgumentConfig
+}
type GraphQLArgumentConfig = {
- type: GraphQLInputType;
- defaultValue?: any;
- description?: string;
+ type: GraphQLInputType
+ defaultValue?: any
+ description?: string
}
type GraphQLFieldConfigMap = {
- [fieldName: string]: GraphQLFieldConfig;
-};
+ [fieldName: string]: GraphQLFieldConfig
+}
```
Almost all of the GraphQL types you define will be object types. Object types
have a name, but most importantly describe their fields.
-When two types need to refer to each other, or a type needs to refer to
-itself in a field, you can use a function expression (aka a closure or a
-thunk) to supply the fields lazily.
+When two types need to refer to each other, or a type needs to refer to itself
+in a field, you can use a function expression (aka a closure or a thunk) to
+supply the fields lazily.
-Note that resolver functions are provided the `source` object as the first parameter.
-However, if a resolver function is not provided, then the default resolver is
-used, which looks for a method on `source` of the same name as the field. If found,
-the method is called with `(args, context, info)`. Since it is a method on `source`,
-that value can always be referenced with `this`.
+Note that resolver functions are provided the `source` object as the first
+parameter. However, if a resolver function is not provided, then the default
+resolver is used, which looks for a method on `source` of the same name as the
+field. If found, the method is called with `(args, context, info)`. Since it is
+a method on `source`, that value can always be referenced with `this`.
#### Examples
@@ -282,17 +336,17 @@ class GraphQLInterfaceType {
}
type GraphQLInterfaceTypeConfig = {
- name: string,
- fields: GraphQLFieldConfigMapThunk | GraphQLFieldConfigMap,
- resolveType?: (value: any, info?: GraphQLResolveInfo) => GraphQLObjectType,
+ name: string
+ fields: GraphQLFieldConfigMapThunk | GraphQLFieldConfigMap
+ resolveType?: (value: any, info?: GraphQLResolveInfo) => GraphQLObjectType
description?: string
-};
+}
```
-When a field can return one of a heterogeneous set of types, a Interface type
-is used to describe what types are possible, what fields are in common across
-all types, as well as a function to determine which type is actually used
-when the field is resolved.
+When a field can return one of a heterogeneous set of types, a Interface type is
+used to describe what types are possible, what fields are in common across all
+types, as well as a function to determine which type is actually used when the
+field is resolved.
#### Example
@@ -313,18 +367,18 @@ class GraphQLUnionType {
}
type GraphQLUnionTypeConfig = {
- name: string,
- types: GraphQLObjectsThunk | GraphQLObjectType[],
- resolveType?: (value: any, info?: GraphQLResolveInfo) => GraphQLObjectType;
- description?: string;
-};
+ name: string
+ types: GraphQLObjectsThunk | GraphQLObjectType[]
+ resolveType?: (value: any, info?: GraphQLResolveInfo) => GraphQLObjectType
+ description?: string
+}
-type GraphQLObjectsThunk = () => GraphQLObjectType[];
+type GraphQLObjectsThunk = () => GraphQLObjectType[]
```
-When a field can return one of a heterogeneous set of types, a Union type
-is used to describe what types are possible as well as providing a function
-to determine which type is actually used when the field is resolved.
+When a field can return one of a heterogeneous set of types, a Union type is
+used to describe what types are possible as well as providing a function to
+determine which type is actually used when the field is resolved.
### Example
@@ -339,7 +393,7 @@ var PetType = new GraphQLUnionType({
if (value instanceof Cat) {
return CatType
}
- },
+ }
})
```
@@ -351,32 +405,32 @@ class GraphQLEnumType {
}
type GraphQLEnumTypeConfig = {
- name: string;
- values: GraphQLEnumValueConfigMap;
- description?: string;
+ name: string
+ values: GraphQLEnumValueConfigMap
+ description?: string
}
type GraphQLEnumValueConfigMap = {
- [valueName: string]: GraphQLEnumValueConfig;
-};
+ [valueName: string]: GraphQLEnumValueConfig
+}
type GraphQLEnumValueConfig = {
- value?: any;
- deprecationReason?: string;
- description?: string;
+ value?: any
+ deprecationReason?: string
+ description?: string
}
type GraphQLEnumValueDefinition = {
- name: string;
- value?: any;
- deprecationReason?: string;
- description?: string;
+ name: string
+ value?: any
+ deprecationReason?: string
+ description?: string
}
```
-Some leaf values of requests and input values are Enums. GraphQL serializes
-Enum values as strings, however internally Enums can be represented by any
-kind of type, often integers.
+Some leaf values of requests and input values are Enums. GraphQL serializes Enum
+values as strings, however internally Enums can be represented by any kind of
+type, often integers.
Note: If a value is not provided in a definition, the name of the enum value
will be used as its internal value.
@@ -389,8 +443,8 @@ var RGBType = new GraphQLEnumType({
values: {
RED: { value: 0 },
GREEN: { value: 1 },
- BLUE: { value: 2 },
- },
+ BLUE: { value: 2 }
+ }
})
```
@@ -402,37 +456,40 @@ class GraphQLInputObjectType {
}
type GraphQLInputObjectConfig = {
- name: string;
- fields: GraphQLInputObjectConfigFieldMapThunk | GraphQLInputObjectConfigFieldMap;
- description?: string;
+ name: string
+ fields:
+ | GraphQLInputObjectConfigFieldMapThunk
+ | GraphQLInputObjectConfigFieldMap
+ description?: string
}
-type GraphQLInputObjectConfigFieldMapThunk = () => GraphQLInputObjectConfigFieldMap;
+type GraphQLInputObjectConfigFieldMapThunk =
+ () => GraphQLInputObjectConfigFieldMap
type GraphQLInputObjectFieldConfig = {
- type: GraphQLInputType;
- defaultValue?: any;
- description?: string;
+ type: GraphQLInputType
+ defaultValue?: any
+ description?: string
}
type GraphQLInputObjectConfigFieldMap = {
- [fieldName: string]: GraphQLInputObjectFieldConfig;
-};
+ [fieldName: string]: GraphQLInputObjectFieldConfig
+}
type GraphQLInputObjectField = {
- name: string;
- type: GraphQLInputType;
- defaultValue?: any;
- description?: string;
+ name: string
+ type: GraphQLInputType
+ defaultValue?: any
+ description?: string
}
type GraphQLInputObjectFieldMap = {
- [fieldName: string]: GraphQLInputObjectField;
-};
+ [fieldName: string]: GraphQLInputObjectField
+}
```
-An input object defines a structured collection of fields which may be
-supplied to a field argument.
+An input object defines a structured collection of fields which may be supplied
+to a field argument.
Using `NonNull` will ensure that a value must be provided by the query
@@ -444,8 +501,8 @@ var GeoPoint = new GraphQLInputObjectType({
fields: {
lat: { type: new GraphQLNonNull(GraphQLFloat) },
lon: { type: new GraphQLNonNull(GraphQLFloat) },
- alt: { type: GraphQLFloat, defaultValue: 0 },
- },
+ alt: { type: GraphQLFloat, defaultValue: 0 }
+ }
})
```
@@ -457,9 +514,9 @@ class GraphQLList {
}
```
-A list is a kind of type marker, a wrapping type which points to another
-type. Lists are often created within the context of defining the fields of
-an object type.
+A list is a kind of type marker, a wrapping type which points to another type.
+Lists are often created within the context of defining the fields of an object
+type.
#### Example
@@ -468,8 +525,8 @@ var PersonType = new GraphQLObjectType({
name: "Person",
fields: () => ({
parents: { type: new GraphQLList(PersonType) },
- children: { type: new GraphQLList(PersonType) },
- }),
+ children: { type: new GraphQLList(PersonType) }
+ })
})
```
@@ -482,10 +539,10 @@ class GraphQLNonNull {
```
A non-null is a kind of type marker, a wrapping type which points to another
-type. Non-null types enforce that their values are never null and can ensure
-an error is raised if this ever occurs during a request. It is useful for
-fields which you can make a strong guarantee on non-nullability, for example
-usually the id field of a database row will never be null.
+type. Non-null types enforce that their values are never null and can ensure an
+error is raised if this ever occurs during a request. It is useful for fields
+which you can make a strong guarantee on non-nullability, for example usually
+the id field of a database row will never be null.
#### Example
@@ -493,8 +550,8 @@ usually the id field of a database row will never be null.
var RowType = new GraphQLObjectType({
name: "Row",
fields: () => ({
- id: { type: new GraphQLNonNull(String) },
- }),
+ id: { type: new GraphQLNonNull(String) }
+ })
})
```
@@ -548,8 +605,8 @@ These types may describe a combination of object types
function getNullableType(type: GraphQLType): GraphQLNullableType
```
-If a given type is non-nullable, this strips the non-nullability and
-returns the underlying type.
+If a given type is non-nullable, this strips the non-nullability and returns the
+underlying type.
### getNamedType
diff --git a/src/pages/graphql-js/utilities.mdx b/src/pages/graphql-js/utilities.mdx
index ed8f5cb229..a6c29bd761 100644
--- a/src/pages/graphql-js/utilities.mdx
+++ b/src/pages/graphql-js/utilities.mdx
@@ -7,7 +7,8 @@ title: graphql/utilities
# `graphql/utilities`
The `graphql/utilities` module contains common useful computations to use with
-the GraphQL language and type objects. You can import either from the `graphql/utilities` module, or from the root `graphql` module. For example:
+the GraphQL language and type objects. You can import either from the
+`graphql/utilities` module, or from the root `graphql` module. For example:
```js
import { introspectionQuery } from "graphql" // ES6
@@ -21,12 +22,14 @@ var { introspectionQuery } = require("graphql") // CommonJS
<ul className="apiIndex">
<li>
<a href="#introspectionquery">
- `var introspectionQuery` A GraphQL introspection query containing enough information to reproduce a type system.
+ `var introspectionQuery` A GraphQL introspection query containing enough
+ information to reproduce a type system.
</a>
</li>
<li>
<a href="#buildclientschema">
- `function buildClientSchema` Produces a client schema given the result of querying a schema with `introspectionQuery`.
+ `function buildClientSchema` Produces a client schema given the result of
+ querying a schema with `introspectionQuery`.
</a>
</li>
</ul>
@@ -36,7 +39,8 @@ var { introspectionQuery } = require("graphql") // CommonJS
<ul className="apiIndex">
<li>
<a href="#buildschema">
- `function buildSchema` Builds a Schema object from GraphQL schema language.
+ `function buildSchema` Builds a Schema object from GraphQL schema
+ language.
</a>
</li>
<li>
@@ -46,7 +50,8 @@ var { introspectionQuery } = require("graphql") // CommonJS
</li>
<li>
<a href="#printintrospectionschema">
- `function printIntrospectionSchema` Prints the introspection features of the schema in a standard format.
+ `function printIntrospectionSchema` Prints the introspection features of
+ the schema in a standard format.
</a>
</li>
<li>
@@ -56,12 +61,14 @@ var { introspectionQuery } = require("graphql") // CommonJS
</li>
<li>
<a href="#typefromast">
- `function typeFromAST` Looks up a type referenced in an AST in the GraphQLSchema.
+ `function typeFromAST` Looks up a type referenced in an AST in the
+ GraphQLSchema.
</a>
</li>
<li>
<a href="#astfromvalue">
- `function astFromValue` Produces a GraphQL Input Value AST given a JavaScript value.
+ `function astFromValue` Produces a GraphQL Input Value AST given a
+ JavaScript value.
</a>
</li>
</ul>
@@ -71,7 +78,8 @@ var { introspectionQuery } = require("graphql") // CommonJS
<ul className="apiIndex">
<li>
<a href="#typeinfo">
- `class TypeInfo` Tracks type and field definitions during a visitor AST traversal..
+ `class TypeInfo` Tracks type and field definitions during a visitor AST
+ traversal..
</a>
</li>
</ul>
@@ -81,12 +89,14 @@ var { introspectionQuery } = require("graphql") // CommonJS
<ul className="apiIndex">
<li>
<a href="#isvalidjsvalue">
- `function isValidJSValue` Determines if a JavaScript value is valid for a GraphQL type.
+ `function isValidJSValue` Determines if a JavaScript value is valid for a
+ GraphQL type.
</a>
</li>
<li>
<a href="#isvalidliteralvalue">
- `function isValidLiteralValue` Determines if a literal value from an AST is valid for a GraphQL type.
+ `function isValidLiteralValue` Determines if a literal value from an AST
+ is valid for a GraphQL type.
</a>
</li>
</ul>
@@ -105,9 +115,7 @@ information to reproduce that server's type system.
### `buildClientSchema`
```ts
-function buildClientSchema(
- introspection: IntrospectionQuery
-): GraphQLSchema
+function buildClientSchema(introspection: IntrospectionQuery): GraphQLSchema
```
Build a GraphQLSchema for use by client tools.
@@ -126,7 +134,10 @@ server-internal mechanisms.
function buildSchema(source: string | Source): GraphQLSchema
```
-Creates a GraphQLSchema object from GraphQL schema language. The schema will use default resolvers. For more detail on the GraphQL schema language, see the [schema language docs](/learn/schema/) or this [schema language cheat sheet](https://wehavefaces.net/graphql-shorthand-notation-cheatsheet-17cd715861b6#.9oztv0a7n).
+Creates a GraphQLSchema object from GraphQL schema language. The schema will use
+default resolvers. For more detail on the GraphQL schema language, see the
+[schema language docs](/learn/schema/) or this
+[schema language cheat sheet](https://wehavefaces.net/graphql-shorthand-notation-cheatsheet-17cd715861b6#.9oztv0a7n).
### `printSchema`
@@ -163,10 +174,7 @@ functions or any other server-internal mechanisms.
### `typeFromAST`
```ts
-function typeFromAST(
- schema: GraphQLSchema,
- inputTypeAST: Type
-): GraphQLType
+function typeFromAST(schema: GraphQLSchema, inputTypeAST: Type): GraphQLType
```
Given the name of a Type as it appears in a GraphQL AST and a Schema, return the
@@ -175,16 +183,13 @@ corresponding GraphQLType from that schema.
### `astFromValue`
```ts
-function astFromValue(
- value: any,
- type: GraphQLInputType
-): Value
+function astFromValue(value: any, type: GraphQLInputType): Value
```
Produces a GraphQL Input Value AST given a JavaScript value.
-Optionally, a GraphQL type may be provided, which will be used to
-disambiguate between value primitives.
+Optionally, a GraphQL type may be provided, which will be used to disambiguate
+between value primitives.
## Visitors
@@ -202,9 +207,9 @@ class TypeInfo {
}
```
-TypeInfo is a utility class which, given a GraphQL schema, can keep track
-of the current field and type definitions at any point in a GraphQL document
-AST during a recursive descent by calling `enter(node)` and `leave(node)`.
+TypeInfo is a utility class which, given a GraphQL schema, can keep track of the
+current field and type definitions at any point in a GraphQL document AST during
+a recursive descent by calling `enter(node)` and `leave(node)`.
## Value Validation
@@ -215,20 +220,17 @@ function isValidJSValue(value: any, type: GraphQLInputType): string[]
```
Given a JavaScript value and a GraphQL type, determine if the value will be
-accepted for that type. This is primarily useful for validating the
-runtime values of query variables.
+accepted for that type. This is primarily useful for validating the runtime
+values of query variables.
### `isValidLiteralValue`
```ts
-function isValidLiteralValue(
- type: GraphQLInputType,
- valueAST: Value
-): string[]
+function isValidLiteralValue(type: GraphQLInputType, valueAST: Value): string[]
```
-Utility for validators which determines if a value literal AST is valid given
-an input type.
+Utility for validators which determines if a value literal AST is valid given an
+input type.
-Note that this only validates literal values, variables are assumed to
-provide values of the correct type.
+Note that this only validates literal values, variables are assumed to provide
+values of the correct type.
diff --git a/src/pages/graphql-js/validation.mdx b/src/pages/graphql-js/validation.mdx
index fdcfb21b3d..69f8882819 100644
--- a/src/pages/graphql-js/validation.mdx
+++ b/src/pages/graphql-js/validation.mdx
@@ -7,7 +7,8 @@ title: graphql/validation
# `graphql/validation`
The `graphql/validation` module fulfills the Validation phase of fulfilling a
-GraphQL result. You can import either from the `graphql/validation` module, or from the root `graphql` module. For example:
+GraphQL result. You can import either from the `graphql/validation` module, or
+from the root `graphql` module. For example:
```js
import { validate } from "graphql/validation" // ES6
@@ -24,7 +25,8 @@ var { validate } = require("graphql/validation") // CommonJS
</li>
<li>
<a href="#specifiedrules">
- `var specifiedRules` A list of standard validation rules described in the GraphQL specification.
+ `var specifiedRules` A list of standard validation rules described in the
+ GraphQL specification.
</a>
</li>
</ul>
@@ -43,15 +45,15 @@ function validate(
Implements the "Validation" section of the spec.
-Validation runs synchronously, returning an array of encountered errors, or
-an empty array if no errors were encountered and the document is valid.
+Validation runs synchronously, returning an array of encountered errors, or an
+empty array if no errors were encountered and the document is valid.
A list of specific validation rules may be provided. If not provided, the
default list of rules defined by the GraphQL specification will be used.
-Each validation rules is a function which returns a visitor
-(see the language/visitor API). Visitor methods are expected to return
-GraphQLErrors, or Arrays of GraphQLErrors when invalid.
+Each validation rules is a function which returns a visitor (see the
+language/visitor API). Visitor methods are expected to return GraphQLErrors, or
+Arrays of GraphQLErrors when invalid.
Visitors can also supply `visitSpreadFragments: true` which will alter the
behavior of the visitor to skip over top level defined fragments, and instead
diff --git a/src/pages/index.mdx b/src/pages/index.mdx
index c4d88aed29..9dbfd6e9bf 100644
--- a/src/pages/index.mdx
+++ b/src/pages/index.mdx
@@ -2,4 +2,4 @@
title: GraphQL | A query language for your API
---
-export { IndexPage as default } from '../components/index-page'
+export { IndexPage as default } from "../components/index-page"
diff --git a/src/pages/learn/authorization.mdx b/src/pages/learn/authorization.mdx
index da91da0089..79633d4e30 100644
--- a/src/pages/learn/authorization.mdx
+++ b/src/pages/learn/authorization.mdx
@@ -1,17 +1,30 @@
# Authorization
-<p className="learn-subtitle">Delegate authorization logic to the business logic layer</p>
-
-Most APIs will need to secure access to certain types of data depending on who requested it, and GraphQL is no different. GraphQL execution should begin after [authentication](/graphql-js/authentication-and-express-middleware/) middleware confirms the user's identity and passes that information to the GraphQL layer. But after that, you still need to determine if the authenticated user is allowed to view the data provided by the specific fields that were included in the request. On this page, we'll explore how a GraphQL schema can support authorization.
+<p className="learn-subtitle">
+ Delegate authorization logic to the business logic layer
+</p>
+
+Most APIs will need to secure access to certain types of data depending on who
+requested it, and GraphQL is no different. GraphQL execution should begin after
+[authentication](/graphql-js/authentication-and-express-middleware/) middleware
+confirms the user's identity and passes that information to the GraphQL layer.
+But after that, you still need to determine if the authenticated user is allowed
+to view the data provided by the specific fields that were included in the
+request. On this page, we'll explore how a GraphQL schema can support
+authorization.
## Type and field authorization
-Authorization is a type of business logic that describes whether a given user/session/context has permission to perform an action or see a piece of data. For example:
+Authorization is a type of business logic that describes whether a given
+user/session/context has permission to perform an action or see a piece of data.
+For example:
_"Only authors can see their drafts"_
-Enforcing this behavior should happen in the [business logic layer](/learn/thinking-in-graphs/#business-logic-layer). Let's consider the following `Post` type defined in a schema:
-
+Enforcing this behavior should happen in the
+[business logic layer](/learn/thinking-in-graphs/#business-logic-layer). Let's
+consider the following `Post` type defined in a schema:
+
```graphql
type Post {
authorId: ID!
@@ -19,29 +32,45 @@ type Post {
}
```
-In this example, we can imagine that when a request initially reaches the server, authentication middleware will first check the user's credentials and add information about their identity to the `context` object of the GraphQL request so that this data is available in every field resolver for the duration of its execution.
+In this example, we can imagine that when a request initially reaches the
+server, authentication middleware will first check the user's credentials and
+add information about their identity to the `context` object of the GraphQL
+request so that this data is available in every field resolver for the duration
+of its execution.
-If a post's body should only be visible to the user who authored it, then we will need to check that the authenticated user's ID matches the post's `authorId` value. It may be tempting to place authorization logic in the resolver for the post's `body` field like so:
+If a post's body should only be visible to the user who authored it, then we
+will need to check that the authenticated user's ID matches the post's
+`authorId` value. It may be tempting to place authorization logic in the
+resolver for the post's `body` field like so:
```js
function Post_body(obj, args, context, info) {
// return the post body only if the user is the post's author
- if (context.user && (context.user.id === obj.authorId)) {
+ if (context.user && context.user.id === obj.authorId) {
return obj.body
}
return null
}
```
-Notice that we define "author owns a post" by checking whether the post's `authorId` field equals the current user’s `id`. Can you spot the problem? We would need to duplicate this code for each entry point into the service. Then if the authorization logic is not kept perfectly in sync, users could see different data depending on which API they use. Yikes! We can avoid that by having a [single source of truth](/learn/thinking-in-graphs/#business-logic-layer) for authorization, instead of putting it the GraphQL layer.
+Notice that we define "author owns a post" by checking whether the post's
+`authorId` field equals the current user’s `id`. Can you spot the problem? We
+would need to duplicate this code for each entry point into the service. Then if
+the authorization logic is not kept perfectly in sync, users could see different
+data depending on which API they use. Yikes! We can avoid that by having a
+[single source of truth](/learn/thinking-in-graphs/#business-logic-layer) for
+authorization, instead of putting it the GraphQL layer.
-Defining authorization logic inside the resolver is fine when learning GraphQL or prototyping. However, for a production codebase, delegate authorization logic to the business logic layer. Here’s an example of how authorization of the `Post` type's fields could be implemented separately:
+Defining authorization logic inside the resolver is fine when learning GraphQL
+or prototyping. However, for a production codebase, delegate authorization logic
+to the business logic layer. Here’s an example of how authorization of the
+`Post` type's fields could be implemented separately:
```js
// authorization logic lives inside `postRepository`
export const postRepository = {
getBody({ user, post }) {
- if (user?.id && (user.id === post.authorId)) {
+ if (user?.id && user.id === post.authorId) {
return post.body
}
return null
@@ -49,10 +78,12 @@ export const postRepository = {
}
```
-The resolver function for the post's `body` field would then call a `postRepository` method instead of implementing the authorization logic directly:
+The resolver function for the post's `body` field would then call a
+`postRepository` method instead of implementing the authorization logic
+directly:
```js
-import { postRepository } from 'postRepository'
+import { postRepository } from "postRepository"
function Post_body(obj, args, context, info) {
// return the post body only if the user is the post's author
@@ -60,13 +91,25 @@ function Post_body(obj, args, context, info) {
}
```
-In the example above, we see that the business logic layer requires the caller to provide a user object, which is available in the `context` object for the GraphQL request. We recommend passing a fully-hydrated user object instead of an opaque token or API key to your business logic layer. This way, we can handle the distinct concerns of [authentication](/graphql-js/authentication-and-express-middleware/) and authorization in different stages of the request processing pipeline.
+In the example above, we see that the business logic layer requires the caller
+to provide a user object, which is available in the `context` object for the
+GraphQL request. We recommend passing a fully-hydrated user object instead of an
+opaque token or API key to your business logic layer. This way, we can handle
+the distinct concerns of
+[authentication](/graphql-js/authentication-and-express-middleware/) and
+authorization in different stages of the request processing pipeline.
## Using type system directives
-In the example above, we saw how authorization logic can be delegated to the business logic layer through a function that is called in a field resolver. In general, it is recommended to perform all authorization logic in that layer, but if you decide to implement authorization in the GraphQL layer instead then one approach is to use [type system directives](/learn/schema/#directives).
+In the example above, we saw how authorization logic can be delegated to the
+business logic layer through a function that is called in a field resolver. In
+general, it is recommended to perform all authorization logic in that layer, but
+if you decide to implement authorization in the GraphQL layer instead then one
+approach is to use [type system directives](/learn/schema/#directives).
-For example, a directive such as `@auth` could be defined in the schema with arguments that indicate what roles or permissions a user must have to access the data provided by the types and fields where the directive is applied:
+For example, a directive such as `@auth` could be defined in the schema with
+arguments that indicate what roles or permissions a user must have to access the
+data provided by the types and fields where the directive is applied:
```graphql
directive @auth(rule: Rule) on FIELD_DEFINITION
@@ -81,12 +124,19 @@ type Post {
}
```
-It would be up to the GraphQL implementation to determine how an `@auth` directive affects execution when a client makes a request that includes the `body` field for `Post` type. However, the authorization logic should remain delegated to the business logic layer.
+It would be up to the GraphQL implementation to determine how an `@auth`
+directive affects execution when a client makes a request that includes the
+`body` field for `Post` type. However, the authorization logic should remain
+delegated to the business logic layer.
## Recap
To recap these recommendations for authorization in GraphQL:
-- Authorization logic should be delegated to the business logic layer, not the GraphQL layer
-- After execution begins, a GraphQL server should make decisions about whether the client that made the request is authorized to access data for the included fields
-- Type system directives may be defined and added to the types and fields in a schema to apply generalized authorization rules
+- Authorization logic should be delegated to the business logic layer, not the
+ GraphQL layer
+- After execution begins, a GraphQL server should make decisions about whether
+ the client that made the request is authorized to access data for the included
+ fields
+- Type system directives may be defined and added to the types and fields in a
+ schema to apply generalized authorization rules
diff --git a/src/pages/learn/best-practices.mdx b/src/pages/learn/best-practices.mdx
index 5c9b5527d4..e324069dc7 100644
--- a/src/pages/learn/best-practices.mdx
+++ b/src/pages/learn/best-practices.mdx
@@ -1,57 +1,67 @@
-import { Cards } from '../../components/cards'
+import { Cards } from "../../components/cards"
# GraphQL Best Practices
-The GraphQL specification is intentionally silent on a handful of important issues facing APIs such as dealing with the network, authorization, and pagination. This doesn't mean that there aren't solutions for these issues when using GraphQL, just that they're outside the description about what GraphQL _is_ and instead just common practice.
+The GraphQL specification is intentionally silent on a handful of important
+issues facing APIs such as dealing with the network, authorization, and
+pagination. This doesn't mean that there aren't solutions for these issues when
+using GraphQL, just that they're outside the description about what GraphQL _is_
+and instead just common practice.
-The articles in this section should not be taken as gospel, and in some cases may rightfully be ignored in favor of some other approach. Some articles introduce some of the philosophy developed within Facebook around designing and deploying GraphQL services, while others are more tactical suggestions for solving common problems like serving over HTTP and performing authorization.
+The articles in this section should not be taken as gospel, and in some cases
+may rightfully be ignored in favor of some other approach. Some articles
+introduce some of the philosophy developed within Facebook around designing and
+deploying GraphQL services, while others are more tactical suggestions for
+solving common problems like serving over HTTP and performing authorization.
<Cards
items={[
{
title: "Thinking in Graphs",
link: "/learn/thinking-in-graphs/",
- description: "Model your business domain as a graph",
+ description: "Model your business domain as a graph"
},
{
title: "Serving over HTTP",
link: "/learn/serving-over-http/",
- description: "Handle GraphQL requests on HTTP servers",
+ description: "Handle GraphQL requests on HTTP servers"
},
{
title: "Authorization",
link: "/learn/authorization/",
- description: "Delegate authorization logic to the business logic layer",
+ description: "Delegate authorization logic to the business logic layer"
},
{
title: "Pagination",
link: "/learn/pagination/",
- description: "Allow clients to traverse lists of objects with a consistent field pagination model",
+ description:
+ "Allow clients to traverse lists of objects with a consistent field pagination model"
},
{
title: "Schema Design",
link: "/learn/schema-design/",
- description: "Design and evolve a type system over time without versions",
+ description: "Design and evolve a type system over time without versions"
},
{
title: "Global Object Identification",
link: "/learn/global-object-identification/",
- description: "Consistent object access enables simple caching and object lookups",
- },
+ description:
+ "Consistent object access enables simple caching and object lookups"
+ },
{
title: "Caching",
link: "/learn/caching/",
- description: "Provide Object Identifiers so clients can build rich caches",
+ description: "Provide Object Identifiers so clients can build rich caches"
},
{
title: "Performance",
link: "/learn/performance/",
- description: "Optimize the execution and delivery of GraphQL responses",
+ description: "Optimize the execution and delivery of GraphQL responses"
},
{
title: "Security",
link: "/learn/security/",
- description: "Protect GraphQL APIs from malicious operations",
- },
+ description: "Protect GraphQL APIs from malicious operations"
+ }
]}
/>
diff --git a/src/pages/learn/caching.mdx b/src/pages/learn/caching.mdx
index f5bf3f28db..40b57e153c 100644
--- a/src/pages/learn/caching.mdx
+++ b/src/pages/learn/caching.mdx
@@ -1,16 +1,27 @@
# Caching
-<p className="learn-subtitle">Provide Object Identifiers so clients can build rich caches</p>
+<p className="learn-subtitle">
+ Provide Object Identifiers so clients can build rich caches
+</p>
-In an endpoint-based API, clients can use [HTTP caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching) to avoid refetching resources and to identify when two resources are the same. The URL in these APIs is a _globally unique identifier_ that the client can leverage to build a cache.
+In an endpoint-based API, clients can use
+[HTTP caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching) to
+avoid refetching resources and to identify when two resources are the same. The
+URL in these APIs is a _globally unique identifier_ that the client can leverage
+to build a cache.
-In GraphQL, there's no URL-like primitive that provides this globally unique identifier for a given object. Hence, it's a best practice for the API to expose such an identifier for clients to use as a prerequisite for certain types of caching.
+In GraphQL, there's no URL-like primitive that provides this globally unique
+identifier for a given object. Hence, it's a best practice for the API to expose
+such an identifier for clients to use as a prerequisite for certain types of
+caching.
## Globally unique IDs
### Standardize how objects are identified in a schema
-One possible pattern for this is reserving a field, like `id`, to be a globally unique identifier. The example schema used throughout these docs uses this approach:
+One possible pattern for this is reserving a field, like `id`, to be a globally
+unique identifier. The example schema used throughout these docs uses this
+approach:
```graphql
# { "graphiql": true }
@@ -30,29 +41,53 @@ query {
}
```
-This is a powerful tool for client developers. In the same way that the URLs of a resource-based API provide a globally unique key, the `id` field in this system provides a globally unique key.
+This is a powerful tool for client developers. In the same way that the URLs of
+a resource-based API provide a globally unique key, the `id` field in this
+system provides a globally unique key.
-If the backend uses something like UUIDs for identifiers, then exposing this globally unique ID may be very straightforward! If the backend doesn't have a globally unique ID for every object already, the GraphQL layer might have to construct one. Oftentimes, that's as simple as appending the name of the type to the ID and using that as the identifier. The server might then make that ID opaque by base64-encoding it.
+If the backend uses something like UUIDs for identifiers, then exposing this
+globally unique ID may be very straightforward! If the backend doesn't have a
+globally unique ID for every object already, the GraphQL layer might have to
+construct one. Oftentimes, that's as simple as appending the name of the type to
+the ID and using that as the identifier. The server might then make that ID
+opaque by base64-encoding it.
-Optionally, this ID can then be used to work with the `node` pattern when using [global object identification](/learn/global-object-identification).
+Optionally, this ID can then be used to work with the `node` pattern when using
+[global object identification](/learn/global-object-identification).
### Compatibility with existing APIs
-One concern with using the `id` field for this purpose is how a client using the GraphQL API would work with existing APIs. For example, if our existing API accepted a type-specific ID, but our GraphQL API uses globally unique IDs, then using both at once can be tricky.
+One concern with using the `id` field for this purpose is how a client using the
+GraphQL API would work with existing APIs. For example, if our existing API
+accepted a type-specific ID, but our GraphQL API uses globally unique IDs, then
+using both at once can be tricky.
-In these cases, the GraphQL API can expose the previous API's IDs in a separate field. This gives us the best of both worlds:
+In these cases, the GraphQL API can expose the previous API's IDs in a separate
+field. This gives us the best of both worlds:
-- GraphQL clients can continue to rely on a consistent mechanism to get a globally unique ID.
-- Clients that need to work with our previous API can also fetch `previousApiId` from the object, and use that.
+- GraphQL clients can continue to rely on a consistent mechanism to get a
+ globally unique ID.
+- Clients that need to work with our previous API can also fetch `previousApiId`
+ from the object, and use that.
### Alternatives
-While globally unique IDs have proven to be a powerful pattern in the past, they are not the only pattern that can be used, nor are they right for every situation. The critical functionality that the client needs is the ability to derive a globally unique identifier for their caching. While having the server derive that ID simplifies the client, the client can also derive the identifier. This could be as simple as combining the type of the object (queried with `__typename`) with some type-unique identifier.
+While globally unique IDs have proven to be a powerful pattern in the past, they
+are not the only pattern that can be used, nor are they right for every
+situation. The critical functionality that the client needs is the ability to
+derive a globally unique identifier for their caching. While having the server
+derive that ID simplifies the client, the client can also derive the identifier.
+This could be as simple as combining the type of the object (queried with
+`__typename`) with some type-unique identifier.
-Additionally, if replacing an existing API with a GraphQL API, then it may be confusing if all of the fields in GraphQL are the same **except** `id`, which changed to be globally unique. This would be another reason why one might choose not to use `id` as the globally unique field.
+Additionally, if replacing an existing API with a GraphQL API, then it may be
+confusing if all of the fields in GraphQL are the same **except** `id`, which
+changed to be globally unique. This would be another reason why one might choose
+not to use `id` as the globally unique field.
## Recap
To recap these recommendations for using caching with GraphQL APIs:
-- Defining a globally unique ID field for an Object type can facilitate various types of caching
\ No newline at end of file
+- Defining a globally unique ID field for an Object type can facilitate various
+ types of caching
diff --git a/src/pages/learn/execution.mdx b/src/pages/learn/execution.mdx
index 5fca44a03a..88ee52eb24 100644
--- a/src/pages/learn/execution.mdx
+++ b/src/pages/learn/execution.mdx
@@ -2,13 +2,22 @@ import { Callout } from "nextra/components"
# Execution
-<p className="learn-subtitle">Learn how GraphQL provides data for requested fields</p>
+<p className="learn-subtitle">
+ Learn how GraphQL provides data for requested fields
+</p>
-After a parsed document is [validated](/learn/validation/), a client's request will be [executed](https://spec.graphql.org/draft/#sec-Execution) by the GraphQL server and the returned result will mirror the shape of the requested query. On this page, you'll learn about the execution phase of GraphQL operations where data is read from or written to an existing source depending on what fields are requested by a client.
+After a parsed document is [validated](/learn/validation/), a client's request
+will be [executed](https://spec.graphql.org/draft/#sec-Execution) by the GraphQL
+server and the returned result will mirror the shape of the requested query. On
+this page, you'll learn about the execution phase of GraphQL operations where
+data is read from or written to an existing source depending on what fields are
+requested by a client.
## Field resolvers
-GraphQL cannot execute operations without a type system, so let's use an example type system to illustrate executing a query. This is a part of the same type system used throughout the examples in this guide:
+GraphQL cannot execute operations without a type system, so let's use an example
+type system to illustrate executing a query. This is a part of the same type
+system used throughout the examples in this guide:
```graphql
type Query {
@@ -32,7 +41,8 @@ type Starship {
}
```
-To describe what happens when a query is executed, let's walk through an example:
+To describe what happens when a query is executed, let's walk through an
+example:
```graphql
# { "graphiql": true }
@@ -47,33 +57,60 @@ query {
}
```
-You can think of each field in a GraphQL query as a function or method of the previous type which returns the next type. This is exactly how GraphQL works—each field on each type is backed by a _resolver function_ that is written by the GraphQL server developer. When a field is executed, the corresponding resolver is called to produce the next value.
+You can think of each field in a GraphQL query as a function or method of the
+previous type which returns the next type. This is exactly how GraphQL
+works—each field on each type is backed by a _resolver function_ that is written
+by the GraphQL server developer. When a field is executed, the corresponding
+resolver is called to produce the next value.
-If a field produces a scalar value like a string or number, then the execution completes. However, if a field produces an object value then the query will contain another selection of fields that apply to that object. This continues until the leaf values are reached. GraphQL queries always end at Scalar or Enum types.
+If a field produces a scalar value like a string or number, then the execution
+completes. However, if a field produces an object value then the query will
+contain another selection of fields that apply to that object. This continues
+until the leaf values are reached. GraphQL queries always end at Scalar or Enum
+types.
## Root fields and resolvers
-At the top level of every GraphQL server is an Object type that represents the possible entry points into the GraphQL API, it's often called "the `query` root operation type" or the `Query` type. If the API supports mutations to write data and subscriptions to fetch real-time data as well, then it will have `Mutation` and `Subscription` types that expose fields to perform these kinds of operations too. You can learn more about these types on the [Schema and Types page](/learn/schema/#the-query-mutation-and-subscription-types).
+At the top level of every GraphQL server is an Object type that represents the
+possible entry points into the GraphQL API, it's often called "the `query` root
+operation type" or the `Query` type. If the API supports mutations to write data
+and subscriptions to fetch real-time data as well, then it will have `Mutation`
+and `Subscription` types that expose fields to perform these kinds of operations
+too. You can learn more about these types on the
+[Schema and Types page](/learn/schema/#the-query-mutation-and-subscription-types).
-In this example, our `Query` type provides a field called `human` which accepts the argument `id`. The resolver function for this field likely accesses a database and then constructs and returns a `Human` type:
+In this example, our `Query` type provides a field called `human` which accepts
+the argument `id`. The resolver function for this field likely accesses a
+database and then constructs and returns a `Human` type:
```js
function Query_human(obj, args, context, info) {
- return context.db.loadHumanByID(args.id).then(
- userData => new Human(userData)
- )
+ return context.db.loadHumanByID(args.id).then(userData => new Human(userData))
}
```
-This example is written in JavaScript, however GraphQL servers can be built in [many different languages](/code/). In the reference implementation, a resolver function receives four arguments:
+This example is written in JavaScript, however GraphQL servers can be built in
+[many different languages](/code/). In the reference implementation, a resolver
+function receives four arguments:
-- `obj`: The previous object (for a field on the root `Query` type, this argument is often not used).
+- `obj`: The previous object (for a field on the root `Query` type, this
+ argument is often not used).
- `args`: The arguments provided to the field in the GraphQL operation.
-- `context`: A value provided to every resolver that may hold important contextual information like the currently logged in user, or access to a database.
-- `info`: generally only used in advanced use-cases, this is a value holding field-specific information relevant to the current operation as well as the schema details; refer to [type GraphQLResolveInfo](/graphql-js/type/#graphqlobjecttype) for more details.
+- `context`: A value provided to every resolver that may hold important
+ contextual information like the currently logged in user, or access to a
+ database.
+- `info`: generally only used in advanced use-cases, this is a value holding
+ field-specific information relevant to the current operation as well as the
+ schema details; refer to
+ [type GraphQLResolveInfo](/graphql-js/type/#graphqlobjecttype) for more
+ details.
<Callout type="info">
-Note that while a query operation could technically write data to the underlying data system during its execution, mutation operations are conventionally used for requests that produce side effects during their execution. And because mutation operations produce side effects, GraphQL implementations can be expected to execute these fields serially.
+ Note that while a query operation could technically write data to the
+ underlying data system during its execution, mutation operations are
+ conventionally used for requests that produce side effects during their
+ execution. And because mutation operations produce side effects, GraphQL
+ implementations can be expected to execute these fields serially.
</Callout>
## Asynchronous resolvers
@@ -82,19 +119,30 @@ Let's take a closer look at what's happening in this resolver function:
```js
function Query_human(obj, args, context, info) {
- return context.db.loadHumanByID(args.id).then(
- userData => new Human(userData)
- )
+ return context.db.loadHumanByID(args.id).then(userData => new Human(userData))
}
```
-The `id` argument in the GraphQL query specifies the user whose data is requested, while `context` provides access to retrieve this data from a database. Since loading from a database is an asynchronous operation, this returns a [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise). In JavaScript, Promises are used to work with asynchronous values, but the same concept exists in many languages, often called _Futures_, _Tasks_, or _Deferred_. When the database returns the data, we can construct and return a new `Human` object.
-
-Notice that while the resolver function needs to be aware of Promises, the GraphQL query does not. It simply expects the `human` field to return something that can be further resolved to a scalar `name` value. During execution, GraphQL will wait for Promises, Futures, and Tasks to be completed before continuing and will do so with optimal concurrency.
+The `id` argument in the GraphQL query specifies the user whose data is
+requested, while `context` provides access to retrieve this data from a
+database. Since loading from a database is an asynchronous operation, this
+returns a
+[Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise).
+In JavaScript, Promises are used to work with asynchronous values, but the same
+concept exists in many languages, often called _Futures_, _Tasks_, or
+_Deferred_. When the database returns the data, we can construct and return a
+new `Human` object.
+
+Notice that while the resolver function needs to be aware of Promises, the
+GraphQL query does not. It simply expects the `human` field to return something
+that can be further resolved to a scalar `name` value. During execution, GraphQL
+will wait for Promises, Futures, and Tasks to be completed before continuing and
+will do so with optimal concurrency.
## Trivial resolvers
-Now that a `Human` object is available, GraphQL execution can continue with the fields requested for this type:
+Now that a `Human` object is available, GraphQL execution can continue with the
+fields requested for this type:
```js
function Human_name(obj, args, context, info) {
@@ -102,15 +150,25 @@ function Human_name(obj, args, context, info) {
}
```
-A GraphQL server is powered by a type system that is used to determine what to do next. Even before the `human` field returns anything, GraphQL knows the next step will be to resolve fields on the `Human` type since the type system tells it that the `human` field will return this output type.
+A GraphQL server is powered by a type system that is used to determine what to
+do next. Even before the `human` field returns anything, GraphQL knows the next
+step will be to resolve fields on the `Human` type since the type system tells
+it that the `human` field will return this output type.
-Resolving the name in this case is straightforward. The name resolver function is called and the `obj` argument is the new `Human` object returned from the previous field. In this case, we expect this object to have a `name` property, which we can read and return directly.
+Resolving the name in this case is straightforward. The name resolver function
+is called and the `obj` argument is the new `Human` object returned from the
+previous field. In this case, we expect this object to have a `name` property,
+which we can read and return directly.
-Many GraphQL libraries let you omit resolvers this simple, assuming that if a resolver isn't provided for a field, a property of the same name should be read and returned.
+Many GraphQL libraries let you omit resolvers this simple, assuming that if a
+resolver isn't provided for a field, a property of the same name should be read
+and returned.
## Scalar coercion
-While the `name` field is being resolved, the `appearsIn` and `starships` fields can be resolved concurrently. The `appearsIn` field could also have a trivial resolver, but let's take a closer look:
+While the `name` field is being resolved, the `appearsIn` and `starships` fields
+can be resolved concurrently. The `appearsIn` field could also have a trivial
+resolver, but let's take a closer look:
```js
Human: {
@@ -120,33 +178,52 @@ Human: {
}
```
-Notice that our type system claims `appearsIn` will return Enum types with known values, however, this function is returning numbers! Indeed if we look up at the result we'll see that the appropriate values for the Enum type are being returned. What's going on?
+Notice that our type system claims `appearsIn` will return Enum types with known
+values, however, this function is returning numbers! Indeed if we look up at the
+result we'll see that the appropriate values for the Enum type are being
+returned. What's going on?
-This is an example of _scalar coercion_. The type system knows what to expect and will convert the values returned by a resolver function into something that upholds the API contract. In this case, there may be an Enum type defined on our server that uses numbers like `4`, `5`, and `6` internally, but represents them as the expected values in the GraphQL type system.
+This is an example of _scalar coercion_. The type system knows what to expect
+and will convert the values returned by a resolver function into something that
+upholds the API contract. In this case, there may be an Enum type defined on our
+server that uses numbers like `4`, `5`, and `6` internally, but represents them
+as the expected values in the GraphQL type system.
## List resolvers
-We've already seen some of what happens when a field returns a list of things with the `appearsIn` field above. It returned a [List type](/learn/schema/#lists) containing Enum type values, and since that's what the type system expected, each item in the list was coerced to the appropriate value. What happens when the `starships` field is resolved?
+We've already seen some of what happens when a field returns a list of things
+with the `appearsIn` field above. It returned a
+[List type](/learn/schema/#lists) containing Enum type values, and since that's
+what the type system expected, each item in the list was coerced to the
+appropriate value. What happens when the `starships` field is resolved?
```js
-function Human_starships (obj, args, context, info) {
- return obj.starshipIDs.map(
- id => context.db.loadStarshipByID(id).then(
- shipData => new Starship(shipData)
- )
+function Human_starships(obj, args, context, info) {
+ return obj.starshipIDs.map(id =>
+ context.db.loadStarshipByID(id).then(shipData => new Starship(shipData))
)
}
```
-The resolver for this field is not just returning a Promise, it's returning a _list_ of Promises. The `Human` object had a list of IDs of the `Starships` they piloted, but we need to load all of those IDs to get real Starship objects.
+The resolver for this field is not just returning a Promise, it's returning a
+_list_ of Promises. The `Human` object had a list of IDs of the `Starships` they
+piloted, but we need to load all of those IDs to get real Starship objects.
-GraphQL will wait for all of these Promises concurrently before continuing, and when left with a list of objects, it will continue yet again to load the `name` field on each of these items concurrently.
+GraphQL will wait for all of these Promises concurrently before continuing, and
+when left with a list of objects, it will continue yet again to load the `name`
+field on each of these items concurrently.
## Producing the result
-As each field is resolved, the resulting value is placed into a key-value map with the field name (or alias) as the key and the resolved value as the value. This continues from the bottom leaf fields of the query back up to the original field on the root `Query` type. Collectively these produce a structure that mirrors the original query which can then be sent (typically as JSON) to the client that requested it.
+As each field is resolved, the resulting value is placed into a key-value map
+with the field name (or alias) as the key and the resolved value as the value.
+This continues from the bottom leaf fields of the query back up to the original
+field on the root `Query` type. Collectively these produce a structure that
+mirrors the original query which can then be sent (typically as JSON) to the
+client that requested it.
-Let's take one last look at the original query to see how all these resolving functions produce a result:
+Let's take one last look at the original query to see how all these resolving
+functions produce a result:
```graphql
# { "graphiql": true }
@@ -161,17 +238,26 @@ query {
}
```
-As we can see, each field in the nested selection sets resolves to a scalar leaf value during execution of the query.
+As we can see, each field in the nested selection sets resolves to a scalar leaf
+value during execution of the query.
## Next steps
To recap what we've learned about execution:
-- Each field in a GraphQL type system will have a corresponding resolver function that provides data for the field from an existing data source
-- Execution begins at the top-level `Query`, `Mutation`, or `Subscription` fields
+- Each field in a GraphQL type system will have a corresponding resolver
+ function that provides data for the field from an existing data source
+- Execution begins at the top-level `Query`, `Mutation`, or `Subscription`
+ fields
- Resolvers may execute asynchronously
- Scalar coercion converts values into the types expected by the schema
-- When a field on an Object type returns a List type of other objects, additional data may need to be fetched from the underlying data source to transform any foreign key-like references (such as IDs) into the related objects
-- Once all of the requested fields have been resolved to the expected leaf values, the result is sent to the client, typically as JSON
-
-Now that we understand how operations are executed, we can move to the last stage of the lifecycle of a GraphQL request where the [response](/learn/response/) is delivered to a client.
\ No newline at end of file
+- When a field on an Object type returns a List type of other objects,
+ additional data may need to be fetched from the underlying data source to
+ transform any foreign key-like references (such as IDs) into the related
+ objects
+- Once all of the requested fields have been resolved to the expected leaf
+ values, the result is sent to the client, typically as JSON
+
+Now that we understand how operations are executed, we can move to the last
+stage of the lifecycle of a GraphQL request where the
+[response](/learn/response/) is delivered to a client.
diff --git a/src/pages/learn/global-object-identification.mdx b/src/pages/learn/global-object-identification.mdx
index 3fbb29920d..d0b47a0803 100644
--- a/src/pages/learn/global-object-identification.mdx
+++ b/src/pages/learn/global-object-identification.mdx
@@ -7,8 +7,8 @@ refetching, GraphQL servers need to expose object identifiers in a standardized
way.
For this to work, a client will need to query via a standard mechanism to
-request an object by ID. Then, in the response, the schema will need to provide a
-standard way of providing these IDs.
+request an object by ID. Then, in the response, the schema will need to provide
+a standard way of providing these IDs.
Because little is known about the object other than its ID, we call these
objects "nodes." Here is an example query for a node:
@@ -24,10 +24,13 @@ objects "nodes." Here is an example query for a node:
}
```
-- The GraphQL schema is formatted to allow fetching any object via the `node` field on the root query object. This
- returns objects which conform to a "Node" [interface](/learn/schema/#interfaces).
-- The `id` field can be extracted out of the response safely, and can be stored for re-use via caching and refetching.
-- Clients can use interface fragments to extract additional information specific to the type which conform to the node interface. In this case a "User".
+- The GraphQL schema is formatted to allow fetching any object via the `node`
+ field on the root query object. This returns objects which conform to a "Node"
+ [interface](/learn/schema/#interfaces).
+- The `id` field can be extracted out of the response safely, and can be stored
+ for re-use via caching and refetching.
+- Clients can use interface fragments to extract additional information specific
+ to the type which conform to the node interface. In this case a "User".
The Node interface looks like:
@@ -51,27 +54,27 @@ type User implements Node {
## Specification
-Everything below describes with more formal requirements a specification around object
-identification in order to conform to ensure consistency across server implementations. These
-specifications are based on how a server can be compliant with the [Relay][relay] API client, but
-can be useful for any client.
+Everything below describes with more formal requirements a specification around
+object identification in order to conform to ensure consistency across server
+implementations. These specifications are based on how a server can be compliant
+with the [Relay][relay] API client, but can be useful for any client.
## Reserved Types
-A GraphQL server compatible with this spec must reserve certain types and type names
-to support the consistent object identification model. In particular, this spec creates
-guidelines for the following types:
+A GraphQL server compatible with this spec must reserve certain types and type
+names to support the consistent object identification model. In particular, this
+spec creates guidelines for the following types:
- An interface named `Node`.
- The `node` field on the root query type.
## Node Interface
-The server must provide an interface called `Node`. That interface
-must include exactly one field, called `id` that returns a non-null `ID`.
+The server must provide an interface called `Node`. That interface must include
+exactly one field, called `id` that returns a non-null `ID`.
-This `id` should be a globally unique identifier for this object, and given
-just this `id`, the server should be able to refetch the object.
+This `id` should be a globally unique identifier for this object, and given just
+this `id`, the server should be able to refetch the object.
### Introspection
@@ -123,24 +126,24 @@ yields
## Node root field
The server must provide a root field called `node` that returns the `Node`
-interface. This root field must take exactly one argument, a non-null ID
-named `id`.
+interface. This root field must take exactly one argument, a non-null ID named
+`id`.
-If a query returns an object that implements `Node`, then this root field
-should refetch the identical object when value returned by the server in the
-`Node`'s `id` field is passed as the `id` parameter to the `node` root field.
+If a query returns an object that implements `Node`, then this root field should
+refetch the identical object when value returned by the server in the `Node`'s
+`id` field is passed as the `id` parameter to the `node` root field.
-The server must make a best effort to fetch this data, but it may not always
-be possible; for example, the server may return a `User` with a valid `id`,
-but when the request is made to refetch that user with the `node` root field,
-the user's database may be unavailable, or the user may have deleted their
-account. In this case, the result of querying this field should be `null`.
+The server must make a best effort to fetch this data, but it may not always be
+possible; for example, the server may return a `User` with a valid `id`, but
+when the request is made to refetch that user with the `node` root field, the
+user's database may be unavailable, or the user may have deleted their account.
+In this case, the result of querying this field should be `null`.
### Introspection
A server that correctly implements the above requirement will accept the
-following introspection query, and return a response that contains the
-provided response.
+following introspection query, and return a response that contains the provided
+response.
```graphql
{
@@ -203,8 +206,8 @@ yields
## Field stability
-If two objects appear in a query, both implementing `Node` with identical
-IDs, then the two objects must be equal.
+If two objects appear in a query, both implementing `Node` with identical IDs,
+then the two objects must be equal.
For the purposes of this definition, object equality is defined as follows:
@@ -274,8 +277,8 @@ guaranteed by the conditions above that `fourNode.name` must be the same as
## Plural identifying root fields
-Imagine a root field named `username`, that takes a user's username and
-returns the corresponding user:
+Imagine a root field named `username`, that takes a user's username and returns
+the corresponding user:
```graphql
{
@@ -295,10 +298,9 @@ might return:
}
```
-Clearly, we can link up the object in the response, the user with ID 4,
-with the request, identifying the object with username "zuck". Now imagine a
-root field named `usernames`, that takes a list of usernames and returns a
-list of objects:
+Clearly, we can link up the object in the response, the user with ID 4, with the
+request, identifying the object with username "zuck". Now imagine a root field
+named `usernames`, that takes a list of usernames and returns a list of objects:
```graphql
{
@@ -323,22 +325,22 @@ might return:
}
```
-For clients to be able to link the usernames to the responses, it needs to
-know that the array in the response will be the same size as the array
-passed as an argument, and that the order in the response will match the
-order in the argument. We call these _plural identifying root fields_, and
-their requirements are described below.
+For clients to be able to link the usernames to the responses, it needs to know
+that the array in the response will be the same size as the array passed as an
+argument, and that the order in the response will match the order in the
+argument. We call these _plural identifying root fields_, and their requirements
+are described below.
### Fields
-A server compliant with this spec may expose root fields that accept a list of input
-arguments, and returns a list of responses. For spec-compliant clients to use these fields,
-these fields must be _plural identifying root fields_, and obey the following
-requirements.
+A server compliant with this spec may expose root fields that accept a list of
+input arguments, and returns a list of responses. For spec-compliant clients to
+use these fields, these fields must be _plural identifying root fields_, and
+obey the following requirements.
NOTE Spec-compliant servers may expose root fields that are not _plural
-identifying root fields_; the spec-compliant client will just be unable to use those
-fields as root fields in its queries.
+identifying root fields_; the spec-compliant client will just be unable to use
+those fields as root fields in its queries.
_Plural identifying root fields_ must have a single argument. The type of that
argument must be a non-null list of non-nulls. In our `usernames` example, the
@@ -347,19 +349,19 @@ system shorthand) would be `[String!]!`.
The return type of a _plural identifying root field_ must be a list, or a
non-null wrapper around a list. The list must wrap the `Node` interface, an
-object that implements the `Node` interface, or a non-null wrapper around
-those types.
-
-Whenever the _plural identifying root field_ is used, the length of the
-list in the response must be the same as the length of the list in the
-arguments. Each item in the response must correspond to its item in the input;
-more formally, if passing the root field an input list `Lin` resulted in output
-value `Lout`, then for an arbitrary permutation `P`, passing the root field
-`P(Lin)` must result in output value `P(Lout)`.
-
-Because of this, servers are advised to not have the response type
-wrap a non-null wrapper, because if it is unable to fetch the object for
-a given entry in the input, it still must provide a value in the output
-for that input entry; `null` is a useful value for doing so.
+object that implements the `Node` interface, or a non-null wrapper around those
+types.
+
+Whenever the _plural identifying root field_ is used, the length of the list in
+the response must be the same as the length of the list in the arguments. Each
+item in the response must correspond to its item in the input; more formally, if
+passing the root field an input list `Lin` resulted in output value `Lout`, then
+for an arbitrary permutation `P`, passing the root field `P(Lin)` must result in
+output value `P(Lout)`.
+
+Because of this, servers are advised to not have the response type wrap a
+non-null wrapper, because if it is unable to fetch the object for a given entry
+in the input, it still must provide a value in the output for that input entry;
+`null` is a useful value for doing so.
[relay]: https://facebook.github.io/relay/
diff --git a/src/pages/learn/index.mdx b/src/pages/learn/index.mdx
index ac6ba9c291..eb92aeac1c 100644
--- a/src/pages/learn/index.mdx
+++ b/src/pages/learn/index.mdx
@@ -2,15 +2,33 @@ import { Callout } from "nextra/components"
# Introduction to GraphQL
-<p className="learn-subtitle">Learn about GraphQL, how it works, and how to use it</p>
+<p className="learn-subtitle">
+ Learn about GraphQL, how it works, and how to use it
+</p>
-GraphQL is a query language for your API, and a server-side runtime for executing queries using a type system you define for your data. The [GraphQL specification](https://spec.graphql.org/) was open-sourced in 2015 and has since been implemented in a variety of programming languages. GraphQL isn't tied to any specific database or storage engine—it is backed by your existing code and data.
+GraphQL is a query language for your API, and a server-side runtime for
+executing queries using a type system you define for your data. The
+[GraphQL specification](https://spec.graphql.org/) was open-sourced in 2015 and
+has since been implemented in a variety of programming languages. GraphQL isn't
+tied to any specific database or storage engine—it is backed by your existing
+code and data.
-<Callout type="info">If you're already familiar with GraphQL and would like to read documentation on how to build a GraphQL service, then there are libraries to help you implement GraphQL in [many different languages](/community/tools-and-libraries/?tags=server). There are also many libraries available that allow [client applications to query existing GraphQL APIs](/community/tools-and-libraries/?tags=client).</Callout>
+<Callout type="info">
+ If you're already familiar with GraphQL and would like to read documentation
+ on how to build a GraphQL service, then there are libraries to help you
+ implement GraphQL in [many different
+ languages](/community/tools-and-libraries/?tags=server). There are also many
+ libraries available that allow [client applications to query existing GraphQL
+ APIs](/community/tools-and-libraries/?tags=client).
+</Callout>
## Describe your API with a type system
-A GraphQL service is created by [defining types and their fields](/learn/schema/), and then writing a function for each field to [provide the required data](/learn/execution/). For example, a GraphQL service that tells you the name of a logged-in user might look like this:
+A GraphQL service is created by
+[defining types and their fields](/learn/schema/), and then writing a function
+for each field to [provide the required data](/learn/execution/). For example, a
+GraphQL service that tells you the name of a logged-in user might look like
+this:
```graphql
type Query {
@@ -36,11 +54,18 @@ function User_name(user, args, context, info) {
}
```
-In the example above, the function that provides data for the `me` field on the `Query` type uses information about the authenticated user who made the request, while the `name` field on the `User` type is populated by using that user's ID to fetch their full name from a database.
+In the example above, the function that provides data for the `me` field on the
+`Query` type uses information about the authenticated user who made the request,
+while the `name` field on the `User` type is populated by using that user's ID
+to fetch their full name from a database.
## Query exactly what you need
-After a GraphQL service is running (typically at a URL on a web service), it can receive [GraphQL queries](/learn/queries/) to validate and execute from clients. The service first checks a query to ensure it only refers to the types and fields defined for the API and then runs the provided functions to produce a result.
+After a GraphQL service is running (typically at a URL on a web service), it can
+receive [GraphQL queries](/learn/queries/) to validate and execute from clients.
+The service first checks a query to ensure it only refers to the types and
+fields defined for the API and then runs the provided functions to produce a
+result.
For example, the query:
@@ -64,11 +89,18 @@ Could produce the following JSON result:
}
```
-With even a simple query, we can see some of the key features that make GraphQL so powerful. The client can make queries to the API that mirror the structure of the data that they need and then receive just that data in the expected shape with a single request—and without having to worry about which underlying data sources provided it.
+With even a simple query, we can see some of the key features that make GraphQL
+so powerful. The client can make queries to the API that mirror the structure of
+the data that they need and then receive just that data in the expected shape
+with a single request—and without having to worry about which underlying data
+sources provided it.
## Evolve your API without versioning
-Client requirements change over time and GraphQL allows your API to evolve in response to those needs and without the overhead of managing different API versions. For example, if a new feature calls for more specific name values to be available, then the `User` type could be updated as follows:
+Client requirements change over time and GraphQL allows your API to evolve in
+response to those needs and without the overhead of managing different API
+versions. For example, if a new feature calls for more specific name values to
+be available, then the `User` type could be updated as follows:
```graphql
type User {
@@ -78,11 +110,16 @@ type User {
}
```
-Client tooling will encourage developers to use the new fields and remove usage of the deprecated `name` field. The field can be removed once it is determined it is no longer used; in the meantime GraphQL will continue to provide its data as expected.
+Client tooling will encourage developers to use the new fields and remove usage
+of the deprecated `name` field. The field can be removed once it is determined
+it is no longer used; in the meantime GraphQL will continue to provide its data
+as expected.
## Try it out!
-The best way to learn GraphQL is to start writing queries. The query editors used throughout this guide are **interactive**, so try adding an `id` and `appearsIn` fields to the `hero` object to see an updated result:
+The best way to learn GraphQL is to start writing queries. The query editors
+used throughout this guide are **interactive**, so try adding an `id` and
+`appearsIn` fields to the `hero` object to see an updated result:
```graphql
# { "graphiql": true }
@@ -95,11 +132,19 @@ The best way to learn GraphQL is to start writing queries. The query editors use
```
<Callout type="info">
-The examples in this guide are based on [a modified version of the SWAPI GraphQL schema](https://github.com/graphql/graphql.github.io/blob/source/src/components/marked/swapi-schema.tsx). Because these queries are designed for illustrative purposes, they will not run on the full version of the SWAPI GraphQL API due to differences between the two schemas. [You can try the full version of the API here.](https://graphql.org/swapi-graphql/)
+ The examples in this guide are based on [a modified version of the SWAPI
+ GraphQL
+ schema](https://github.com/graphql/graphql.github.io/blob/source/src/components/marked/swapi-schema.tsx).
+ Because these queries are designed for illustrative purposes, they will not
+ run on the full version of the SWAPI GraphQL API due to differences between
+ the two schemas. [You can try the full version of the API
+ here.](https://graphql.org/swapi-graphql/)
</Callout>
## Next steps
-Now that you know some key GraphQL concepts, you're ready to learn about all of the different aspects of its [type system](/learn/schema/).
+Now that you know some key GraphQL concepts, you're ready to learn about all of
+the different aspects of its [type system](/learn/schema/).
-For an in-depth learning experience with practical tutorials, see [the available training courses](/community/resources/training-courses).
+For an in-depth learning experience with practical tutorials, see
+[the available training courses](/community/resources/training-courses).
diff --git a/src/pages/learn/introspection.mdx b/src/pages/learn/introspection.mdx
index f7b36e5f4b..11e4a9427c 100644
--- a/src/pages/learn/introspection.mdx
+++ b/src/pages/learn/introspection.mdx
@@ -1,14 +1,25 @@
# Introspection
-<p className="learn-subtitle">Learn how to query information about a GraphQL schema</p>
+<p className="learn-subtitle">
+ Learn how to query information about a GraphQL schema
+</p>
-It's often useful to ask a GraphQL schema for information about what features it supports. GraphQL allows us to do so using the [introspection system](https://spec.graphql.org/draft/#sec-Introspection).
+It's often useful to ask a GraphQL schema for information about what features it
+supports. GraphQL allows us to do so using the
+[introspection system](https://spec.graphql.org/draft/#sec-Introspection).
-Introspection queries are special kinds of queries that allow you to learn about a GraphQL API's schema, and they also help power GraphQL development tools. On this page, we'll learn how to run different queries to learn more about an underlying schema's types, fields, and descriptions.
+Introspection queries are special kinds of queries that allow you to learn about
+a GraphQL API's schema, and they also help power GraphQL development tools. On
+this page, we'll learn how to run different queries to learn more about an
+underlying schema's types, fields, and descriptions.
## Type name introspection
-We have already seen an example of introspection on the [Schemas and Types page](/learn/schema/). When querying a field that returned Union type, we included the `__typename` meta-field directly in a selection set to get the string value of the names of the different types returned by a search query. Let's look at this example again:
+We have already seen an example of introspection on the
+[Schemas and Types page](/learn/schema/). When querying a field that returned
+Union type, we included the `__typename` meta-field directly in a selection set
+to get the string value of the names of the different types returned by a search
+query. Let's look at this example again:
```graphql
# { "graphiql": true }
@@ -25,11 +36,17 @@ query {
}
```
-We didn't add the `__typename` field to our GraphQL API explicitly—the GraphQL specification says that it must be provided to clients by a GraphQL implementation. This field can be queried for any field with an Object, Interface, or Union type as the underlying output type.
+We didn't add the `__typename` field to our GraphQL API explicitly—the GraphQL
+specification says that it must be provided to clients by a GraphQL
+implementation. This field can be queried for any field with an Object,
+Interface, or Union type as the underlying output type.
## Schema introspection
-Introspection can do more than provide type names in a query. If you designed the type system for a GraphQL API, then you'll likely already know what types are available. But if you didn't design it, you can ask GraphQL by querying the `__schema` field, which is always available on the `query` root operation type.
+Introspection can do more than provide type names in a query. If you designed
+the type system for a GraphQL API, then you'll likely already know what types
+are available. But if you didn't design it, you can ask GraphQL by querying the
+`__schema` field, which is always available on the `query` root operation type.
Let's do so now and ask what types are available in the Star Wars schema:
@@ -46,11 +63,18 @@ query {
Wow, that's a lot of types! What are they? Let's group them:
-- Types that we defined in our type system: `Query`, `Mutation`, `Character`, `Human`, `Episode`, `Droid`, `LengthUnit`, `FriendsConnection`, `FriendsEdge`, `PageInfo`, `Review`, `ReviewInput`, `Starship`, and `SearchResult`
-- Built-in scalars that the type system provided: `Boolean`, `Float`, `ID`, `Int`, and `String`
-- Types preceded with a double underscore that are part of the introspection system: `__Schema`, `__Type`, `__TypeKind`, `__Field`, `__InputValue`, `__EnumValue`, `__Directive`, and `__DirectiveLocation`
+- Types that we defined in our type system: `Query`, `Mutation`, `Character`,
+ `Human`, `Episode`, `Droid`, `LengthUnit`, `FriendsConnection`, `FriendsEdge`,
+ `PageInfo`, `Review`, `ReviewInput`, `Starship`, and `SearchResult`
+- Built-in scalars that the type system provided: `Boolean`, `Float`, `ID`,
+ `Int`, and `String`
+- Types preceded with a double underscore that are part of the introspection
+ system: `__Schema`, `__Type`, `__TypeKind`, `__Field`, `__InputValue`,
+ `__EnumValue`, `__Directive`, and `__DirectiveLocation`
-Now, let's try to figure out a good place to start exploring what queries are available. When we designed our type system, we specified what type all queries would start at; let's ask the introspection system about that:
+Now, let's try to figure out a good place to start exploring what queries are
+available. When we designed our type system, we specified what type all queries
+would start at; let's ask the introspection system about that:
```graphql
# { "graphiql": true }
@@ -63,9 +87,15 @@ query {
}
```
-The result matches what we said in the [type system section](/learn/schema/#type-system)—that the `Query` type is where we will start. Note that the naming here was just by convention; we could have named our `Query` type anything else, and it still would have been returned here had we specified it was the starting type for queries. Naming it `Query`, though, is a useful convention.
+The result matches what we said in the
+[type system section](/learn/schema/#type-system)—that the `Query` type is where
+we will start. Note that the naming here was just by convention; we could have
+named our `Query` type anything else, and it still would have been returned here
+had we specified it was the starting type for queries. Naming it `Query`,
+though, is a useful convention.
-It is often useful to examine one specific type. Let's take a look at the `Droid` type:
+It is often useful to examine one specific type. Let's take a look at the
+`Droid` type:
```graphql
# { "graphiql": true }
@@ -76,7 +106,8 @@ query {
}
```
-But what if we want to know more about Droid? For example, is it an Interface or Object type?
+But what if we want to know more about Droid? For example, is it an Interface or
+Object type?
```graphql
# { "graphiql": true }
@@ -88,7 +119,8 @@ query {
}
```
-`kind` returns a `__TypeKind` Enum type, one of whose values is `OBJECT`. If we asked about `Character` instead we'd find that it is an Interface type:
+`kind` returns a `__TypeKind` Enum type, one of whose values is `OBJECT`. If we
+asked about `Character` instead we'd find that it is an Interface type:
```graphql
# { "graphiql": true }
@@ -100,7 +132,8 @@ query {
}
```
-It's useful for an Object type to know what fields are available, so let's ask the introspection system about `Droid`:
+It's useful for an Object type to know what fields are available, so let's ask
+the introspection system about `Droid`:
```graphql
# { "graphiql": true }
@@ -120,9 +153,13 @@ query {
Those are the fields that we defined on `Droid`!
-`id` looks a bit weird there, it has no name for the type. That's because it's a _wrapper type_ of kind `NON_NULL`. If we queried for `ofType` on that field's type, we would find the `ID` type there, telling us this is a non-null ID.
+`id` looks a bit weird there, it has no name for the type. That's because it's a
+_wrapper type_ of kind `NON_NULL`. If we queried for `ofType` on that field's
+type, we would find the `ID` type there, telling us this is a non-null ID.
-Similarly, both `friends` and `appearsIn` have no name, since they are the `LIST` wrapper type. We can query for `ofType` on those types, which will tell us what types are inside the list:
+Similarly, both `friends` and `appearsIn` have no name, since they are the
+`LIST` wrapper type. We can query for `ofType` on those types, which will tell
+us what types are inside the list:
```graphql
# { "graphiql": true }
@@ -144,7 +181,8 @@ query {
}
```
-Let's end with a feature of the introspection system particularly useful for tooling; let's ask the system for documentation:
+Let's end with a feature of the introspection system particularly useful for
+tooling; let's ask the system for documentation:
```graphql
# { "graphiql": true }
@@ -156,24 +194,43 @@ query {
}
```
-As demonstrated above, we can access the documentation about the type system using introspection and create documentation browsers or rich IDE experiences.
+As demonstrated above, we can access the documentation about the type system
+using introspection and create documentation browsers or rich IDE experiences.
-This has just scratched the surface of the introspection system; we can query for Enum type values, what Interface types another type implements, and more. We can even introspect on the introspection system itself.
+This has just scratched the surface of the introspection system; we can query
+for Enum type values, what Interface types another type implements, and more. We
+can even introspect on the introspection system itself.
-To see an example of a specification-compliant GraphQL query introspection system implemented in code, you can view [src/type/introspection.ts](https://github.com/graphql/graphql-js/blob/e9b6b626f6f6aa379bb8f8c48df40d0c02a26082/src/type/introspection.ts) in the reference implementation.
+To see an example of a specification-compliant GraphQL query introspection
+system implemented in code, you can view
+[src/type/introspection.ts](https://github.com/graphql/graphql-js/blob/e9b6b626f6f6aa379bb8f8c48df40d0c02a26082/src/type/introspection.ts)
+in the reference implementation.
## Introspection in production
-Introspection is a useful feature of GraphQL, especially for client developers and tooling. However, for APIs intended only for your own applications, it’s typically not needed in production—required operations are usually baked into these applications at build time, making runtime introspection unnecessary.
+Introspection is a useful feature of GraphQL, especially for client developers
+and tooling. However, for APIs intended only for your own applications, it’s
+typically not needed in production—required operations are usually baked into
+these applications at build time, making runtime introspection unnecessary.
-Disabling introspection in production is common in order to reduce the API’s attack surface. This is often part of a broader API security strategy, which may also include authentication and authorization, operation safe-listing (or a range of alternative protections, such as depth-limiting, breadth-limiting, alias limits, cycle rejection, cost analysis, etc.), execution timeouts, and more.
+Disabling introspection in production is common in order to reduce the API’s
+attack surface. This is often part of a broader API security strategy, which may
+also include authentication and authorization, operation safe-listing (or a
+range of alternative protections, such as depth-limiting, breadth-limiting,
+alias limits, cycle rejection, cost analysis, etc.), execution timeouts, and
+more.
## Next steps
To recap what we've learned about introspection:
-- Type names can be queried in a field selection set for an Object, Interface, or Union type using the `__typename` meta-field
-- Information about the elements of a GraphQL schema can be queried using the `__schema` field on the `query` root operation type
+- Type names can be queried in a field selection set for an Object, Interface,
+ or Union type using the `__typename` meta-field
+- Information about the elements of a GraphQL schema can be queried using the
+ `__schema` field on the `query` root operation type
- Introspection is often disabled in production environments
-Now that you've explored the GraphQL type system, how to query data from an API, and what the lifecycle of a request looks like, head over to the [Best Practices](/learn/best-practices/) section to learn more about running GraphQL in production.
\ No newline at end of file
+Now that you've explored the GraphQL type system, how to query data from an API,
+and what the lifecycle of a request looks like, head over to the
+[Best Practices](/learn/best-practices/) section to learn more about running
+GraphQL in production.
diff --git a/src/pages/learn/mutations.mdx b/src/pages/learn/mutations.mdx
index 641c83c2af..d48c682504 100644
--- a/src/pages/learn/mutations.mdx
+++ b/src/pages/learn/mutations.mdx
@@ -4,19 +4,33 @@ import { Callout } from "nextra/components"
<p className="learn-subtitle">Learn how to modify data with a GraphQL server</p>
-Most discussions of GraphQL focus on data fetching, but any complete data platform needs a way to modify server-side data as well.
-
-In REST, any request might cause some side-effects on the server, but by convention, it's suggested that one doesn't use `GET` requests to modify data. GraphQL is similar—technically any field resolver could be implemented to cause a data write—but the [GraphQL specification states](https://spec.graphql.org/draft/#sel-GANRNDAB6DBmMn6D) that "the resolution of fields other than top-level mutation fields must always be side effect-free and idempotent." Thus, for any spec-compliant GraphQL schemas, only the top-level fields in mutation operations are allowed to cause side effects.
-
-On this page, you'll learn how to use mutation operations to write data using GraphQL, and do so in a way that supports client use cases.
+Most discussions of GraphQL focus on data fetching, but any complete data
+platform needs a way to modify server-side data as well.
+
+In REST, any request might cause some side-effects on the server, but by
+convention, it's suggested that one doesn't use `GET` requests to modify data.
+GraphQL is similar—technically any field resolver could be implemented to cause
+a data write—but the
+[GraphQL specification states](https://spec.graphql.org/draft/#sel-GANRNDAB6DBmMn6D)
+that "the resolution of fields other than top-level mutation fields must always
+be side effect-free and idempotent." Thus, for any spec-compliant GraphQL
+schemas, only the top-level fields in mutation operations are allowed to cause
+side effects.
+
+On this page, you'll learn how to use mutation operations to write data using
+GraphQL, and do so in a way that supports client use cases.
<Callout type="info">
-All of the features of GraphQL operations that apply to queries also apply to mutations, so review the [Queries](/learn/queries/) page first before proceeding.
+ All of the features of GraphQL operations that apply to queries also apply to
+ mutations, so review the [Queries](/learn/queries/) page first before
+ proceeding.
</Callout>
## Add new data
-When creating new data with a REST API, you would send a `POST` request to a specific endpoint and include information about the entities to be created in the body of the request. GraphQL takes a different approach.
+When creating new data with a REST API, you would send a `POST` request to a
+specific endpoint and include information about the entities to be created in
+the body of the request. GraphQL takes a different approach.
Let's look at an example mutation that's defined in our schema:
@@ -37,11 +51,19 @@ type Mutation {
}
```
-Like queries, mutation fields are added to one of the [root operation types](https://spec.graphql.org/draft/#sec-Root-Operation-Types) that provide an entry point to the API. In this case, we define the `createReview` field on the `Mutation` type.
+Like queries, mutation fields are added to one of the
+[root operation types](https://spec.graphql.org/draft/#sec-Root-Operation-Types)
+that provide an entry point to the API. In this case, we define the
+`createReview` field on the `Mutation` type.
-Mutation fields can also accept arguments and you might notice that the `review` argument has an input type set to `ReviewInput`. This is known as [Input Object type](/learn/schema/#input-object-types), which allows us to pass in a structured object containing information the mutation can use instead of individual scalar values only.
+Mutation fields can also accept arguments and you might notice that the `review`
+argument has an input type set to `ReviewInput`. This is known as
+[Input Object type](/learn/schema/#input-object-types), which allows us to pass
+in a structured object containing information the mutation can use instead of
+individual scalar values only.
-Also like just like queries, if the mutation field returns an Object type, then you specify a selection set of its fields in the operation:
+Also like just like queries, if the mutation field returns an Object type, then
+you specify a selection set of its fields in the operation:
```graphql
# { "graphiql": true, "variables": { "ep": "JEDI", "review": { "stars": 5, "commentary": "This is a great movie!" } } }
@@ -53,9 +75,16 @@ mutation CreateReviewForEpisode($ep: Episode!, $review: ReviewInput!) {
}
```
-While the `createReview` field could be defined with any valid output type in the schema, it's conventional to specify an output type that relates to whatever is modified during the mutation—in this case, the `Review` type. This can be useful for clients that need to fetch the new state of an object after an update.
+While the `createReview` field could be defined with any valid output type in
+the schema, it's conventional to specify an output type that relates to whatever
+is modified during the mutation—in this case, the `Review` type. This can be
+useful for clients that need to fetch the new state of an object after an
+update.
-Recall that GraphQL is meant to work with your existing code and data, so the actual creation of the review is up to you when clients send this operation to the GraphQL server. A hypothetical function that writes the new review to a database during a `createReview` mutation might look like this:
+Recall that GraphQL is meant to work with your existing code and data, so the
+actual creation of the review is up to you when clients send this operation to
+the GraphQL server. A hypothetical function that writes the new review to a
+database during a `createReview` mutation might look like this:
```js
Mutation: {
@@ -67,11 +96,15 @@ Mutation: {
}
```
-You can learn more about how GraphQL provides data for fields on the [Execution page](/learn/execution).
+You can learn more about how GraphQL provides data for fields on the
+[Execution page](/learn/execution).
## Update existing data
-Similarly, we use mutations to update existing data. To change a human's name, we'll define a new mutation field and set that field's output type to the `Human` type so we can return the updated human's information to client after the server successfully writes the data:
+Similarly, we use mutations to update existing data. To change a human's name,
+we'll define a new mutation field and set that field's output type to the
+`Human` type so we can return the updated human's information to client after
+the server successfully writes the data:
```graphql
type Mutation {
@@ -83,8 +116,8 @@ This operation will update Luke Skywalker's name:
```graphql
# { "graphiql": true, "variables": { "id": "1000", "name": "Luke Starkiller" } }
-mutation UpdateHumanName($id: ID!, $name: String!) {
- updateHumanName(id: $id, name: $name ) {
+mutation UpdateHumanName($id: ID!, $name: String!) {
+ updateHumanName(id: $id, name: $name) {
id
name
}
@@ -93,15 +126,29 @@ mutation UpdateHumanName($id: ID!, $name: String!) {
## Purpose-built mutations
-The previous example demonstrates an important distinction from REST. To update a human's properties using a REST API, you would likely send any updated data to a generalized endpoint for that resource using a `PATCH` request. With GraphQL, instead of simply creating an `updateHuman` mutation, you can define more specific mutation fields such as `updateHumanName`that are designed for the task at hand.
-
-Purpose-built mutation fields can help make a schema more expressive by allowing the input types for field arguments to be Non-Null types (a generic `updateHuman` mutation would likely need to accept many nullable arguments to handle different update scenarios). Defining this requirement in the schema also eliminates the need for other runtime logic to determine that the appropriate values were submitted to perform the client's desired write operation.
-
-GraphQL also allows us to express relationships between data that would be more difficult to model semantically with a basic CRUD-style request. For example, a user may wish to save a personal rating for a film. While the rating belongs to the user and doesn't modify anything related to a film itself, we can ergonomically associate it with a `Film` object as follows:
+The previous example demonstrates an important distinction from REST. To update
+a human's properties using a REST API, you would likely send any updated data to
+a generalized endpoint for that resource using a `PATCH` request. With GraphQL,
+instead of simply creating an `updateHuman` mutation, you can define more
+specific mutation fields such as `updateHumanName`that are designed for the task
+at hand.
+
+Purpose-built mutation fields can help make a schema more expressive by allowing
+the input types for field arguments to be Non-Null types (a generic
+`updateHuman` mutation would likely need to accept many nullable arguments to
+handle different update scenarios). Defining this requirement in the schema also
+eliminates the need for other runtime logic to determine that the appropriate
+values were submitted to perform the client's desired write operation.
+
+GraphQL also allows us to express relationships between data that would be more
+difficult to model semantically with a basic CRUD-style request. For example, a
+user may wish to save a personal rating for a film. While the rating belongs to
+the user and doesn't modify anything related to a film itself, we can
+ergonomically associate it with a `Film` object as follows:
```graphql
# { "graphiql": true, "variables": { "episode": "EMPIRE", "rating": "THUMBS_UP" } }
-mutation RateFilm($episode: Episode!, $rating: FilmRating!) {
+mutation RateFilm($episode: Episode!, $rating: FilmRating!) {
rateFilm(episode: $episode, rating: $rating) {
episode
viewerRating
@@ -109,11 +156,15 @@ mutation RateFilm($episode: Episode!, $rating: FilmRating!) {
}
```
-As a general rule, a GraphQL API should be designed to help clients get and modify data in a way that makes sense for them, so the fields defined in a schema should be informed by those use cases.
+As a general rule, a GraphQL API should be designed to help clients get and
+modify data in a way that makes sense for them, so the fields defined in a
+schema should be informed by those use cases.
## Remove existing data
-Just as we can send a `DELETE` request to delete a resource with a REST API, we can use mutations to delete some existing data as well by defining another field on the `Mutation` type:
+Just as we can send a `DELETE` request to delete a resource with a REST API, we
+can use mutations to delete some existing data as well by defining another field
+on the `Mutation` type:
```graphql
type Mutation {
@@ -125,16 +176,22 @@ Here's an example of the new mutation field:
```graphql
# { "graphiql": true, "variables": { "id": "3003" } }
-mutation DeleteStarship($id: ID!) {
+mutation DeleteStarship($id: ID!) {
deleteStarship(id: $id)
}
```
-As with mutations that create and update data, the GraphQL specification doesn't indicate what should be returned from a successful mutation operation that deletes data, but we do have to specify some type as an output type for the field in the schema. Commonly, the deleted entity's ID or a payload object containing data about the entity will be used to indicate that the operation was successful.
+As with mutations that create and update data, the GraphQL specification doesn't
+indicate what should be returned from a successful mutation operation that
+deletes data, but we do have to specify some type as an output type for the
+field in the schema. Commonly, the deleted entity's ID or a payload object
+containing data about the entity will be used to indicate that the operation was
+successful.
## Multiple fields in mutations
-A mutation can contain multiple fields, just like a query. There's one important distinction between queries and mutations, other than the name:
+A mutation can contain multiple fields, just like a query. There's one important
+distinction between queries and mutations, other than the name:
**While query fields are executed in parallel, mutation fields run in series.**
@@ -142,22 +199,38 @@ Let's look at an example:
```graphql
# { "graphiql": true }
-mutation {
+mutation {
firstShip: deleteStarship(id: "3001")
secondShip: deleteStarship(id: "3002")
}
```
-[Serial execution](https://spec.graphql.org/draft/#sec-Normal-and-Serial-Execution) of these top-level fields means that if we send two `deleteStarship` mutations in one request, the first is guaranteed to finish before the second begins, ensuring that we don't end up in a race condition with ourselves.
+[Serial execution](https://spec.graphql.org/draft/#sec-Normal-and-Serial-Execution)
+of these top-level fields means that if we send two `deleteStarship` mutations
+in one request, the first is guaranteed to finish before the second begins,
+ensuring that we don't end up in a race condition with ourselves.
-Note that serial execution of top-level `Mutation` fields differs from the notion of a database transaction. Some mutation fields may resolve successfully while others return errors, and there's no way for GraphQL to revert the successful portions of the operation when this happens. So in the previous example, if the first starship is removed successfully but the `secondShip` field raises an error, there is no built-in way for GraphQL to revert the execution of the `firstShip` field afterward.
+Note that serial execution of top-level `Mutation` fields differs from the
+notion of a database transaction. Some mutation fields may resolve successfully
+while others return errors, and there's no way for GraphQL to revert the
+successful portions of the operation when this happens. So in the previous
+example, if the first starship is removed successfully but the `secondShip`
+field raises an error, there is no built-in way for GraphQL to revert the
+execution of the `firstShip` field afterward.
## Next steps
To recap what we've learned about mutations:
-- Clients can create, update, and delete data using a GraphQL API, depending on what capabilities are exposed in the schema
-- Depending on client requirements, mutations can be designed to accommodate granular use cases for write operations
-- Top-level fields on the `Mutation` type will execute serially, unlike fields on other types which are often executed in parallel
-
-Now that we know how to use a GraphQL server to read and write data, we're ready to learn how to fetch data in real time using [subscriptions](/learn/subscriptions). You may also wish to learn more about how GraphQL queries and mutations can be [served over HTTP](/learn/serving-over-http/).
+- Clients can create, update, and delete data using a GraphQL API, depending on
+ what capabilities are exposed in the schema
+- Depending on client requirements, mutations can be designed to accommodate
+ granular use cases for write operations
+- Top-level fields on the `Mutation` type will execute serially, unlike fields
+ on other types which are often executed in parallel
+
+Now that we know how to use a GraphQL server to read and write data, we're ready
+to learn how to fetch data in real time using
+[subscriptions](/learn/subscriptions). You may also wish to learn more about how
+GraphQL queries and mutations can be
+[served over HTTP](/learn/serving-over-http/).
diff --git a/src/pages/learn/pagination.mdx b/src/pages/learn/pagination.mdx
index da8427d50a..274d464775 100644
--- a/src/pages/learn/pagination.mdx
+++ b/src/pages/learn/pagination.mdx
@@ -1,12 +1,20 @@
# Pagination
-<p className="learn-subtitle">Traverse lists of objects with a consistent field pagination model</p>
+<p className="learn-subtitle">
+ Traverse lists of objects with a consistent field pagination model
+</p>
-A common use case in GraphQL is traversing the relationship between sets of objects. There are different ways that these relationships can be exposed in GraphQL, giving a varying set of capabilities to the client developer. On this page, we'll explore how fields may be paginated using a cursor-based connection model.
+A common use case in GraphQL is traversing the relationship between sets of
+objects. There are different ways that these relationships can be exposed in
+GraphQL, giving a varying set of capabilities to the client developer. On this
+page, we'll explore how fields may be paginated using a cursor-based connection
+model.
## Plurals
-The simplest way to expose a connection between objects is with a field that returns a plural [List type](/learn/schema/#list). For example, if we wanted to get a list of R2-D2's friends, we could just ask for all of them:
+The simplest way to expose a connection between objects is with a field that
+returns a plural [List type](/learn/schema/#list). For example, if we wanted to
+get a list of R2-D2's friends, we could just ask for all of them:
```graphql
# { "graphiql": true }
@@ -22,7 +30,10 @@ query {
## Slicing
-Quickly, though, we realize that there are additional behaviors a client might want. A client might want to be able to specify how many friends they want to fetch—maybe they only want the first two. So we'd want to expose something like this:
+Quickly, though, we realize that there are additional behaviors a client might
+want. A client might want to be able to specify how many friends they want to
+fetch—maybe they only want the first two. So we'd want to expose something like
+this:
```graphql
query {
@@ -35,21 +46,41 @@ query {
}
```
-But if we just fetched the first two, we might want to paginate through the list as well; once the client fetches the first two friends, they might want to send a second request to ask for the next two friends. How can we enable that behavior?
+But if we just fetched the first two, we might want to paginate through the list
+as well; once the client fetches the first two friends, they might want to send
+a second request to ask for the next two friends. How can we enable that
+behavior?
## Pagination and edges
There are several ways we could do pagination:
-- We could do something like `friends(first:2 offset:2)` to ask for the next two in the list.
-- We could do something like `friends(first:2 after:$friendId)`, to ask for the next two after the last friend we fetched.
-- We could do something like `friends(first:2 after:$friendCursor)`, where we get a cursor from the last item and use that to paginate.
-
-The approach described in the first bullet is classic _offset-based pagination_. However, this style of pagination can have performance and security downsides, especially for larger data sets. Additionally, if new records are added to the database after the user has made a request for a page of results, then offset calculations for subsequent pages may become ambiguous.
-
-In general, we've found that _cursor-based pagination_ is the most powerful of those designed. Especially if the cursors are opaque, either offset or ID-based pagination can be implemented using cursor-based pagination (by making the cursor the offset or the ID), and using cursors gives additional flexibility if the pagination model changes in the future. As a reminder that the cursors are opaque and their format should not be relied upon, we suggest base64 encoding them.
-
-But that leads us to a problem—how do we get the cursor from the object? We wouldn't want the cursor to live on the `User` type; it's a property of the connection, not of the object. So we might want to introduce a new layer of indirection; our `friends` field should give us a list of edges, and an edge has both a cursor and the underlying node:
+- We could do something like `friends(first:2 offset:2)` to ask for the next two
+ in the list.
+- We could do something like `friends(first:2 after:$friendId)`, to ask for the
+ next two after the last friend we fetched.
+- We could do something like `friends(first:2 after:$friendCursor)`, where we
+ get a cursor from the last item and use that to paginate.
+
+The approach described in the first bullet is classic _offset-based pagination_.
+However, this style of pagination can have performance and security downsides,
+especially for larger data sets. Additionally, if new records are added to the
+database after the user has made a request for a page of results, then offset
+calculations for subsequent pages may become ambiguous.
+
+In general, we've found that _cursor-based pagination_ is the most powerful of
+those designed. Especially if the cursors are opaque, either offset or ID-based
+pagination can be implemented using cursor-based pagination (by making the
+cursor the offset or the ID), and using cursors gives additional flexibility if
+the pagination model changes in the future. As a reminder that the cursors are
+opaque and their format should not be relied upon, we suggest base64 encoding
+them.
+
+But that leads us to a problem—how do we get the cursor from the object? We
+wouldn't want the cursor to live on the `User` type; it's a property of the
+connection, not of the object. So we might want to introduce a new layer of
+indirection; our `friends` field should give us a list of edges, and an edge has
+both a cursor and the underlying node:
```graphql
query {
@@ -67,13 +98,24 @@ query {
}
```
-The concept of an edge also proves useful if there is information that is specific to the edge, rather than to one of the objects. For example, if we wanted to expose "friendship time" in the API, having it live on the edge is a natural place to put it.
+The concept of an edge also proves useful if there is information that is
+specific to the edge, rather than to one of the objects. For example, if we
+wanted to expose "friendship time" in the API, having it live on the edge is a
+natural place to put it.
## End-of-list, counts, and connections
-Now we can paginate through the connection using cursors, but how do we know when we reach the end of the connection? We have to keep querying until we get an empty list back, but we'd like for the connection to tell us when we've reached the end so we don't need that additional request. Similarly, what if we want additional information about the connection itself, for example, how many friends does R2-D2 have in total?
+Now we can paginate through the connection using cursors, but how do we know
+when we reach the end of the connection? We have to keep querying until we get
+an empty list back, but we'd like for the connection to tell us when we've
+reached the end so we don't need that additional request. Similarly, what if we
+want additional information about the connection itself, for example, how many
+friends does R2-D2 have in total?
-To solve both of these problems, our `friends` field can return a connection object. The connection object will be an Object type that has a field for the edges, as well as other information (like total count and information about whether a next page exists). So our final query might look more like this:
+To solve both of these problems, our `friends` field can return a connection
+object. The connection object will be an Object type that has a field for the
+edges, as well as other information (like total count and information about
+whether a next page exists). So our final query might look more like this:
```graphql
query {
@@ -96,18 +138,29 @@ query {
}
```
-Note that we also might include `endCursor` and `startCursor` in this `PageInfo` object. This way, if we don't need any of the additional information that the edge contains, we don't need to query for the edges at all, since we got the cursors needed for pagination from `pageInfo`. This leads to a potential usability improvement for connections; instead of just exposing the `edges` list, we could also expose a dedicated list of just the nodes, to avoid a layer of indirection.
+Note that we also might include `endCursor` and `startCursor` in this `PageInfo`
+object. This way, if we don't need any of the additional information that the
+edge contains, we don't need to query for the edges at all, since we got the
+cursors needed for pagination from `pageInfo`. This leads to a potential
+usability improvement for connections; instead of just exposing the `edges`
+list, we could also expose a dedicated list of just the nodes, to avoid a layer
+of indirection.
## Complete connection model
-Clearly, this is more complex than our original design of just having a plural! But by adopting this design, we've unlocked several capabilities for the client:
+Clearly, this is more complex than our original design of just having a plural!
+But by adopting this design, we've unlocked several capabilities for the client:
- The ability to paginate through the list.
-- The ability to ask for information about the connection itself, like `totalCount` or `pageInfo`.
-- The ability to ask for information about the edge itself, like `cursor` or `friendshipTime`.
-- The ability to change how our backend does pagination, since the user just uses opaque cursors.
+- The ability to ask for information about the connection itself, like
+ `totalCount` or `pageInfo`.
+- The ability to ask for information about the edge itself, like `cursor` or
+ `friendshipTime`.
+- The ability to change how our backend does pagination, since the user just
+ uses opaque cursors.
-To see this in action, there's an additional field in the example schema, called `friendsConnection`, that exposes all of these concepts:
+To see this in action, there's an additional field in the example schema, called
+`friendsConnection`, that exposes all of these concepts:
```graphql
interface Character {
@@ -137,7 +190,11 @@ type PageInfo {
}
```
-You can try it out in the example query. Try removing the `after` argument for the `friendsConnection` field to see how the pagination will be affected. Also, try replacing the `edges` field with the helper `friends` field on the connection, which lets you get directly to the list of friends without the additional edge layer of indirection, when appropriate for clients:
+You can try it out in the example query. Try removing the `after` argument for
+the `friendsConnection` field to see how the pagination will be affected. Also,
+try replacing the `edges` field with the helper `friends` field on the
+connection, which lets you get directly to the list of friends without the
+additional edge layer of indirection, when appropriate for clients:
```graphql
# { "graphiql": true }
@@ -163,12 +220,17 @@ query {
## Connection specification
-To ensure a consistent implementation of this pattern, the Relay project has a formal [specification](https://relay.dev/graphql/connections.htm) you can follow for building GraphQL APIs that use a cursor-based connection pattern - whether or not use you Relay.
+To ensure a consistent implementation of this pattern, the Relay project has a
+formal [specification](https://relay.dev/graphql/connections.htm) you can follow
+for building GraphQL APIs that use a cursor-based connection pattern - whether
+or not use you Relay.
## Recap
To recap these recommendations for paginating fields in a GraphQL schema:
- List fields that may return a lot of data should be paginated
-- Cursor-based pagination provides a stable pagination model for fields in a GraphQL schema
-- The cursor connection specification from the Relay project provides a consistent pattern for paginating the fields in a GraphQL schema
+- Cursor-based pagination provides a stable pagination model for fields in a
+ GraphQL schema
+- The cursor connection specification from the Relay project provides a
+ consistent pattern for paginating the fields in a GraphQL schema
diff --git a/src/pages/learn/performance.mdx b/src/pages/learn/performance.mdx
index 145f4fae2f..071365c295 100644
--- a/src/pages/learn/performance.mdx
+++ b/src/pages/learn/performance.mdx
@@ -1,32 +1,66 @@
# Performance
-<p className="learn-subtitle">Optimize the execution and delivery of GraphQL responses</p>
+<p className="learn-subtitle">
+ Optimize the execution and delivery of GraphQL responses
+</p>
-At first glance, GraphQL requests may seem challenging to cache given that the API is served through a single endpoint and you may not know in advance what fields a client will include in an operation.
+At first glance, GraphQL requests may seem challenging to cache given that the
+API is served through a single endpoint and you may not know in advance what
+fields a client will include in an operation.
-In practice, however, GraphQL is as cacheable as any API that enables parameterized requests, such as a REST API that allows clients to specify different query parameters for a particular endpoint. There are many ways to optimize GraphQL requests on the client and server sides, as well as in the transport layer, and different GraphQL server and client libraries will often have common caching features built directly into them.
+In practice, however, GraphQL is as cacheable as any API that enables
+parameterized requests, such as a REST API that allows clients to specify
+different query parameters for a particular endpoint. There are many ways to
+optimize GraphQL requests on the client and server sides, as well as in the
+transport layer, and different GraphQL server and client libraries will often
+have common caching features built directly into them.
-On this page, we'll explore several different tactics that can be leveraged in GraphQL clients and servers to optimize how data is fetched from the API.
+On this page, we'll explore several different tactics that can be leveraged in
+GraphQL clients and servers to optimize how data is fetched from the API.
## Client-side caching
-There is a range of client-side caching strategies that GraphQL clients may implement to help not only with performance but also to ensure that you render a consistent and responsive interface to your users. [Read more about client-side caching](/learn/caching).
+There is a range of client-side caching strategies that GraphQL clients may
+implement to help not only with performance but also to ensure that you render a
+consistent and responsive interface to your users.
+[Read more about client-side caching](/learn/caching).
## `GET` requests for queries
-GraphQL implementations that adhere to the [GraphQL over HTTP specification](https://graphql.github.io/graphql-over-http/draft/) will support the `POST` HTTP method by default, but may also support `GET` requests for query operations.
+GraphQL implementations that adhere to the
+[GraphQL over HTTP specification](https://graphql.github.io/graphql-over-http/draft/)
+will support the `POST` HTTP method by default, but may also support `GET`
+requests for query operations.
-Using `GET` can improve query performance because requests made with this HTTP method are typically considered cacheable by default and can help facilitate HTTP caching or the use of a content delivery network (CDN) when caching-related headers are provided in the server response.
+Using `GET` can improve query performance because requests made with this HTTP
+method are typically considered cacheable by default and can help facilitate
+HTTP caching or the use of a content delivery network (CDN) when caching-related
+headers are provided in the server response.
-However, because browsers and CDNs impose size limits on URLs, it may not be possible to send a large document for complex operations in the query string of the URL. Using _persisted queries_, either in the form of _trusted documents_ or _automatic persisted queries_, will allow the client to send a hash of the query instead, and the server can look up the full version of the document by looking up the hash in a server-side store before validating and executing the operation.
+However, because browsers and CDNs impose size limits on URLs, it may not be
+possible to send a large document for complex operations in the query string of
+the URL. Using _persisted queries_, either in the form of _trusted documents_ or
+_automatic persisted queries_, will allow the client to send a hash of the query
+instead, and the server can look up the full version of the document by looking
+up the hash in a server-side store before validating and executing the
+operation.
-Sending hashed queries instead of their plaintext versions has the additional benefit of reducing the amount of data sent by the client in the network request.
+Sending hashed queries instead of their plaintext versions has the additional
+benefit of reducing the amount of data sent by the client in the network
+request.
## The N+1 Problem
-GraphQL is designed in a way that allows you to write clean code on the server, where every field on every type has a focused single-purpose function for resolving that value. However, without additional consideration, a naive GraphQL service could be very "chatty" or repeatedly load data from your databases.
+GraphQL is designed in a way that allows you to write clean code on the server,
+where every field on every type has a focused single-purpose function for
+resolving that value. However, without additional consideration, a naive GraphQL
+service could be very "chatty" or repeatedly load data from your databases.
-Consider the following query—to fetch a hero along with a list of their friends, we can imagine that as the field resolvers execute there will be one request to the underlying data source to get the character object, another to fetch their friends, and then three subsequent requests to load the lists of starships for each human friend:
+Consider the following query—to fetch a hero along with a list of their friends,
+we can imagine that as the field resolvers execute there will be one request to
+the underlying data source to get the character object, another to fetch their
+friends, and then three subsequent requests to load the lists of starships for
+each human friend:
```graphql
# { "graphiql": true }
@@ -48,40 +82,77 @@ query HeroWithFriends {
}
```
-This is known as the N+1 problem, where an initial request to an underlying data source (for a hero's friends) leads to N subsequent requests to resolve the data for all of the requested fields (for the friends' starship data).
+This is known as the N+1 problem, where an initial request to an underlying data
+source (for a hero's friends) leads to N subsequent requests to resolve the data
+for all of the requested fields (for the friends' starship data).
-This is commonly solved by a batching technique, where multiple requests for data from a backend are collected over a short period and then dispatched in a single request to an underlying database or microservice by using a tool like Facebook's [DataLoader](https://github.com/facebook/dataloader). Additionally, certain GraphQL implementations may have built-in capabilities that allow you to translate operation selection sets into optimized queries to underlying data sources.
+This is commonly solved by a batching technique, where multiple requests for
+data from a backend are collected over a short period and then dispatched in a
+single request to an underlying database or microservice by using a tool like
+Facebook's [DataLoader](https://github.com/facebook/dataloader). Additionally,
+certain GraphQL implementations may have built-in capabilities that allow you to
+translate operation selection sets into optimized queries to underlying data
+sources.
## Demand control
-Depending on how a GraphQL schema has been designed, it may be possible for clients to request highly complex operations that place excessive load on the underlying data sources during execution. These kinds of operations may be sent inadvertently by an known client, but they may also be sent by malicious actors.
+Depending on how a GraphQL schema has been designed, it may be possible for
+clients to request highly complex operations that place excessive load on the
+underlying data sources during execution. These kinds of operations may be sent
+inadvertently by an known client, but they may also be sent by malicious actors.
-Certain demand control mechanisms can help guard a GraphQL API against these operations, such as paginating list fields, limiting operation depth and breadth, and query complexity analysis. [You can read more about demand control on the Security page](/learn/security/#demand-control).
+Certain demand control mechanisms can help guard a GraphQL API against these
+operations, such as paginating list fields, limiting operation depth and
+breadth, and query complexity analysis.
+[You can read more about demand control on the Security page](/learn/security/#demand-control).
## JSON (with GZIP)
-GraphQL services typically respond using JSON even though the GraphQL spec [does not require it](http://spec.graphql.org/draft/#sec-Serialization-Format). JSON may seem like an odd choice for an API layer promising better network performance, however, because it is mostly text it compresses exceptionally well with algorithms such as GZIP, deflate and brotli.
+GraphQL services typically respond using JSON even though the GraphQL spec
+[does not require it](http://spec.graphql.org/draft/#sec-Serialization-Format).
+JSON may seem like an odd choice for an API layer promising better network
+performance, however, because it is mostly text it compresses exceptionally well
+with algorithms such as GZIP, deflate and brotli.
-It's encouraged that any production GraphQL services enable GZIP and encourage their clients to send the header:
+It's encouraged that any production GraphQL services enable GZIP and encourage
+their clients to send the header:
```text
Accept-Encoding: gzip
```
-JSON is also very familiar to client and API developers, and is easy to read and debug. In fact, the GraphQL syntax is partly inspired by JSON syntax.
+JSON is also very familiar to client and API developers, and is easy to read and
+debug. In fact, the GraphQL syntax is partly inspired by JSON syntax.
## Performance monitoring
-Monitoring a GraphQL API over time can provide insight into how certain operations impact API performance and help you determine what adjustments to make to maintain its health. For example, you may find that certain fields take a long time to resolve due to under-optimized requests to a backing data source, or you may find that other fields routinely raise errors during execution.
+Monitoring a GraphQL API over time can provide insight into how certain
+operations impact API performance and help you determine what adjustments to
+make to maintain its health. For example, you may find that certain fields take
+a long time to resolve due to under-optimized requests to a backing data source,
+or you may find that other fields routinely raise errors during execution.
-Observability tooling can provide insight into where bottlenecks exist in the execution of certain GraphQL operations by allowing you to instrument the API service to collect metrics, traces, and logs during requests. For example, [OpenTelemetry](https://opentelemetry.io/) provides a suite of vendor-agnostic tools that can be used in many different languages to support instrumentation of GraphQL APIs.
+Observability tooling can provide insight into where bottlenecks exist in the
+execution of certain GraphQL operations by allowing you to instrument the API
+service to collect metrics, traces, and logs during requests. For example,
+[OpenTelemetry](https://opentelemetry.io/) provides a suite of vendor-agnostic
+tools that can be used in many different languages to support instrumentation of
+GraphQL APIs.
## Recap
To recap these recommendations for improving GraphQL API performance:
-- Using `GET` for GraphQL query operations can support HTTP caching and CDN usage, particularly when used in conjunction with hashed query documents
-- Because an operation's selection set can express relationships between different kinds of objects, the N+1 problem can be mitigated during field execution by batching and caching requests to underlying data sources
-- Field pagination, limiting operation depth and breadth, and rate-limiting API requests can help prevent individual GraphQL operations from placing excessive load on server resources
-- GZIP can be used to compress the size of GraphQL JSON-formatted responses when servers and clients support it
-- The overall health of a GraphQL API can be maintained over time by using performance monitoring tools like OpenTelemetry to collect metrics, logs, and traces related to request execution
\ No newline at end of file
+- Using `GET` for GraphQL query operations can support HTTP caching and CDN
+ usage, particularly when used in conjunction with hashed query documents
+- Because an operation's selection set can express relationships between
+ different kinds of objects, the N+1 problem can be mitigated during field
+ execution by batching and caching requests to underlying data sources
+- Field pagination, limiting operation depth and breadth, and rate-limiting API
+ requests can help prevent individual GraphQL operations from placing excessive
+ load on server resources
+- GZIP can be used to compress the size of GraphQL JSON-formatted responses when
+ servers and clients support it
+- The overall health of a GraphQL API can be maintained over time by using
+ performance monitoring tools like OpenTelemetry to collect metrics, logs, and
+ traces related to request execution
diff --git a/src/pages/learn/queries.mdx b/src/pages/learn/queries.mdx
index b34e103c07..b4a00e4c1e 100644
--- a/src/pages/learn/queries.mdx
+++ b/src/pages/learn/queries.mdx
@@ -4,11 +4,17 @@ import { Callout } from "nextra/components"
<p className="learn-subtitle">Learn how to fetch data from a GraphQL server</p>
-GraphQL supports three main operation types—queries, mutations, and subscriptions. We have already seen several examples of basic queries in this guide, and on this page, you'll learn in detail how to use the various features of query operations to read data from a server.
+GraphQL supports three main operation types—queries, mutations, and
+subscriptions. We have already seen several examples of basic queries in this
+guide, and on this page, you'll learn in detail how to use the various features
+of query operations to read data from a server.
## Fields
-At its simplest, GraphQL is about asking for specific [fields](https://spec.graphql.org/draft/#sec-Language.Fields) on objects. Let's start by looking at the `hero` field that's defined on the `Query` type in the schema:
+At its simplest, GraphQL is about asking for specific
+[fields](https://spec.graphql.org/draft/#sec-Language.Fields) on objects. Let's
+start by looking at the `hero` field that's defined on the `Query` type in the
+schema:
```graphql
type Query {
@@ -27,11 +33,24 @@ We can see what result we get when we query it:
}
```
-When creating a GraphQL _document_ we always start with a [root operation type](/learn/schema/#the-query-mutation-and-subscription-types) (the `Query` Object type for this example) because it serves as an entry point to the API. From there we must specify the _selection set_ of fields we are interested in, all the way down to their leaf values which will be Scalar or Enum types. The field `name` returns a `String` type, in this case the name of the main hero of Star Wars, `"R2-D2"`.
-
-The GraphQL specification indicates that a request's result will be returned on a top-level `data` key in the response. If the request raised any errors, there will be information about what went wrong on a top-level `errors` key. From there, you can see that the result has the same shape as the query. This is essential to GraphQL, because you always get back what you expect, and the server knows exactly what fields the client is asking for.
-
-In the previous example, we just asked for the name of our hero which returned a `String`, but fields can also return Object types (and lists thereof). In that case, you can make a _sub-selection_ of fields for that Object type:
+When creating a GraphQL _document_ we always start with a
+[root operation type](/learn/schema/#the-query-mutation-and-subscription-types)
+(the `Query` Object type for this example) because it serves as an entry point
+to the API. From there we must specify the _selection set_ of fields we are
+interested in, all the way down to their leaf values which will be Scalar or
+Enum types. The field `name` returns a `String` type, in this case the name of
+the main hero of Star Wars, `"R2-D2"`.
+
+The GraphQL specification indicates that a request's result will be returned on
+a top-level `data` key in the response. If the request raised any errors, there
+will be information about what went wrong on a top-level `errors` key. From
+there, you can see that the result has the same shape as the query. This is
+essential to GraphQL, because you always get back what you expect, and the
+server knows exactly what fields the client is asking for.
+
+In the previous example, we just asked for the name of our hero which returned a
+`String`, but fields can also return Object types (and lists thereof). In that
+case, you can make a _sub-selection_ of fields for that Object type:
```graphql
# { "graphiql": true }
@@ -45,13 +64,21 @@ In the previous example, we just asked for the name of our hero which returned a
}
```
-GraphQL queries can traverse related objects and their fields, letting clients fetch lots of related data in one request, instead of making several roundtrips as one would need in a classic REST architecture.
+GraphQL queries can traverse related objects and their fields, letting clients
+fetch lots of related data in one request, instead of making several roundtrips
+as one would need in a classic REST architecture.
-Note that in this example, the `friends` field returns an array of items. GraphQL queries look the same for single items or lists of items; however, we know which one to expect based on what is indicated in the schema.
+Note that in this example, the `friends` field returns an array of items.
+GraphQL queries look the same for single items or lists of items; however, we
+know which one to expect based on what is indicated in the schema.
## Arguments
-If the only thing we could do was traverse objects and their fields, GraphQL would already be a very useful language for data fetching. But when you add the ability to pass [arguments](https://spec.graphql.org/draft/#sec-Language.Arguments) to fields, things get much more interesting:
+If the only thing we could do was traverse objects and their fields, GraphQL
+would already be a very useful language for data fetching. But when you add the
+ability to pass
+[arguments](https://spec.graphql.org/draft/#sec-Language.Arguments) to fields,
+things get much more interesting:
```graphql
type Query {
@@ -71,9 +98,14 @@ The client must then provide the required `id` value with the query:
}
```
-In a system like REST, you can only pass a single set of arguments—the query parameters and URL segments in your request. But in GraphQL, every field and nested object can get its own set of arguments, making GraphQL a complete replacement for making multiple API fetches.
+In a system like REST, you can only pass a single set of arguments—the query
+parameters and URL segments in your request. But in GraphQL, every field and
+nested object can get its own set of arguments, making GraphQL a complete
+replacement for making multiple API fetches.
-You can even pass arguments into fields that output Scalar types; one use case for this would be to implement data transformations once on the server, instead of on every client separately:
+You can even pass arguments into fields that output Scalar types; one use case
+for this would be to implement data transformations once on the server, instead
+of on every client separately:
```graphql
# { "graphiql": true }
@@ -85,15 +117,25 @@ You can even pass arguments into fields that output Scalar types; one use case f
}
```
-Arguments can be of many different types. In the above example, we have used an Enum type, which represents one of a finite set of options (in this case, units of length, either `METER` or `FOOT`). GraphQL comes with a [default set of types](/learn/schema/#scalar-types), but a GraphQL server can also declare custom types, as long as they can be serialized into your transport format.
+Arguments can be of many different types. In the above example, we have used an
+Enum type, which represents one of a finite set of options (in this case, units
+of length, either `METER` or `FOOT`). GraphQL comes with a
+[default set of types](/learn/schema/#scalar-types), but a GraphQL server can
+also declare custom types, as long as they can be serialized into your transport
+format.
[Read more about the GraphQL type system here.](/learn/schema)
## Operation type and name
-In the examples above we have been using a shorthand syntax where we omit the `query` keyword before the operation's selection set. In addition to specifying the _operation type_ explicitly, we can also add a unique _operation name_, which is useful in production apps because it makes debugging and tracing easier.
+In the examples above we have been using a shorthand syntax where we omit the
+`query` keyword before the operation's selection set. In addition to specifying
+the _operation type_ explicitly, we can also add a unique _operation name_,
+which is useful in production apps because it makes debugging and tracing
+easier.
-Here’s an example that includes the `query` keyword as the operation type and `HeroNameAndFriends` as the operation name:
+Here’s an example that includes the `query` keyword as the operation type and
+`HeroNameAndFriends` as the operation name:
```graphql
# { "graphiql": true }
@@ -107,15 +149,34 @@ query HeroNameAndFriends {
}
```
-The operation type is either `query`, `mutation`, or `subscription` and describes what type of operation you intend to do. This keyword is required unless you're using the shorthand syntax for queries (it is always required for mutations and subscriptions). Additionally, if you wish to provide a name for your operation, then you must specify the operation type as well.
-
-The operation name is an explicit name that you assign to your operation; you should pick a meaningful name. It is required when sending multiple operations in one document, but even if you're only sending one operation it's encouraged because operation names are helpful for debugging and server-side logging. When something goes wrong (you see errors either in your network logs or in the logs of your GraphQL server) it is easier to identify a query in your codebase by name instead of trying to decipher the contents.
-
-Think of this just like a function name in your favorite programming language. For example, in JavaScript, we can easily work only with anonymous functions, but when we give a function a name, it's easier to track it down, debug our code, and log when it's called. In the same way, GraphQL query and mutation names, along with fragment names, can be a useful debugging tool on the server side to identify different GraphQL requests.
+The operation type is either `query`, `mutation`, or `subscription` and
+describes what type of operation you intend to do. This keyword is required
+unless you're using the shorthand syntax for queries (it is always required for
+mutations and subscriptions). Additionally, if you wish to provide a name for
+your operation, then you must specify the operation type as well.
+
+The operation name is an explicit name that you assign to your operation; you
+should pick a meaningful name. It is required when sending multiple operations
+in one document, but even if you're only sending one operation it's encouraged
+because operation names are helpful for debugging and server-side logging. When
+something goes wrong (you see errors either in your network logs or in the logs
+of your GraphQL server) it is easier to identify a query in your codebase by
+name instead of trying to decipher the contents.
+
+Think of this just like a function name in your favorite programming language.
+For example, in JavaScript, we can easily work only with anonymous functions,
+but when we give a function a name, it's easier to track it down, debug our
+code, and log when it's called. In the same way, GraphQL query and mutation
+names, along with fragment names, can be a useful debugging tool on the server
+side to identify different GraphQL requests.
## Aliases
-If you have a sharp eye, you may have noticed that, since the result object fields match the name of the fields in the query but don't include arguments, you can't directly query for the same field with different arguments. That's why you need [aliases](https://spec.graphql.org/draft/#sec-Field-Alias)—they let you rename the result of a field to anything you want.
+If you have a sharp eye, you may have noticed that, since the result object
+fields match the name of the fields in the query but don't include arguments,
+you can't directly query for the same field with different arguments. That's why
+you need [aliases](https://spec.graphql.org/draft/#sec-Field-Alias)—they let you
+rename the result of a field to anything you want.
```graphql
# { "graphiql": true }
@@ -129,19 +190,29 @@ query {
}
```
-In the above example, the two `hero` fields would have conflicted, but since we can alias them to different names, we can get both results in one request.
+In the above example, the two `hero` fields would have conflicted, but since we
+can alias them to different names, we can get both results in one request.
## Variables
-So far, we have been writing all of our arguments inside the query string. But in most applications, the arguments to fields will be dynamic. For example, there might be a dropdown that lets you select which Star Wars episode you are interested in, or a search field, or a set of filters.
+So far, we have been writing all of our arguments inside the query string. But
+in most applications, the arguments to fields will be dynamic. For example,
+there might be a dropdown that lets you select which Star Wars episode you are
+interested in, or a search field, or a set of filters.
-It wouldn't be a good idea to pass these dynamic arguments directly in the query string, because then our client-side code would need to dynamically manipulate the query string at runtime, and serialize it into a GraphQL-specific format. Instead, GraphQL has a first-class way to factor dynamic values out of the query and pass them as a separate dictionary. These values are called [variables](https://spec.graphql.org/draft/#sec-Language.Variables).
+It wouldn't be a good idea to pass these dynamic arguments directly in the query
+string, because then our client-side code would need to dynamically manipulate
+the query string at runtime, and serialize it into a GraphQL-specific format.
+Instead, GraphQL has a first-class way to factor dynamic values out of the query
+and pass them as a separate dictionary. These values are called
+[variables](https://spec.graphql.org/draft/#sec-Language.Variables).
When we start working with variables, we need to do three things:
1. Replace the static value in the query with `$variableName`
2. Declare `$variableName` as one of the variables accepted by the query
-3. Pass `variableName: value` in the separate, transport-specific (usually JSON) variables dictionary
+3. Pass `variableName: value` in the separate, transport-specific (usually JSON)
+ variables dictionary
Here's what it looks like all together:
@@ -158,24 +229,40 @@ query HeroNameAndFriends($episode: Episode) {
```
<Callout type="info">
-You must specify an operation type and name in a GraphQL document to use variables.
+ You must specify an operation type and name in a GraphQL document to use
+ variables.
</Callout>
-Now, in our client code, we can simply pass a different variable rather than needing to construct an entirely new query. In general, this is also a good practice for denoting which arguments in our query are expected to be dynamic—we should never be doing string interpolation to construct queries from user-supplied values.
+Now, in our client code, we can simply pass a different variable rather than
+needing to construct an entirely new query. In general, this is also a good
+practice for denoting which arguments in our query are expected to be dynamic—we
+should never be doing string interpolation to construct queries from
+user-supplied values.
### Variable definitions
-The variable definitions are the part that looks like `($episode: Episode)` in the query above. It works just like the argument definitions for a function in a typed language. It lists all of the variables, prefixed by `$`, followed by their type, in this case, `Episode`.
+The variable definitions are the part that looks like `($episode: Episode)` in
+the query above. It works just like the argument definitions for a function in a
+typed language. It lists all of the variables, prefixed by `$`, followed by
+their type, in this case, `Episode`.
-All declared variables must be either Scalar, Enum, or Input Object types. So if you want to pass a complex object into a field, you need to know what [input type](/learn/schema/#input-object-types) matches it on the server.
+All declared variables must be either Scalar, Enum, or Input Object types. So if
+you want to pass a complex object into a field, you need to know what
+[input type](/learn/schema/#input-object-types) matches it on the server.
-Variable definitions can be optional or required. In the case above, since there isn't an `!` next to the `Episode` type, it's optional. But if the field you are passing the variable into requires a non-null argument, then the variable has to be required as well.
+Variable definitions can be optional or required. In the case above, since there
+isn't an `!` next to the `Episode` type, it's optional. But if the field you are
+passing the variable into requires a non-null argument, then the variable has to
+be required as well.
-To learn more about the syntax for these variable definitions, it's useful to learn schema definition language (SDL), which is explained in detail on [the Schemas and Types page](/learn/schema).
+To learn more about the syntax for these variable definitions, it's useful to
+learn schema definition language (SDL), which is explained in detail on
+[the Schemas and Types page](/learn/schema).
### Default variables
-Default values can also be assigned to the variables in the query by adding the default value after the type declaration:
+Default values can also be assigned to the variables in the query by adding the
+default value after the type declaration:
```graphql
query HeroNameAndFriends($episode: Episode = JEDI) {
@@ -188,13 +275,21 @@ query HeroNameAndFriends($episode: Episode = JEDI) {
}
```
-When default values are provided for all variables, you can call the query without passing any variables. If any variables are passed as part of the variables dictionary, they will override the defaults.
+When default values are provided for all variables, you can call the query
+without passing any variables. If any variables are passed as part of the
+variables dictionary, they will override the defaults.
## Fragments
-Let's say we have a relatively complicated page in our app, which lets us look at two heroes side by side, along with their friends. You can imagine that such a query could quickly get complicated because we would need to repeat the fields at least once—one for each side of the comparison.
+Let's say we have a relatively complicated page in our app, which lets us look
+at two heroes side by side, along with their friends. You can imagine that such
+a query could quickly get complicated because we would need to repeat the fields
+at least once—one for each side of the comparison.
-That's why GraphQL includes reusable units called [fragments](https://spec.graphql.org/draft/#sec-Language.Fragments). Fragments let you construct sets of fields, and then include them in queries where needed. Here's an example of how you could solve the above situation using fragments:
+That's why GraphQL includes reusable units called
+[fragments](https://spec.graphql.org/draft/#sec-Language.Fragments). Fragments
+let you construct sets of fields, and then include them in queries where needed.
+Here's an example of how you could solve the above situation using fragments:
```graphql
# { "graphiql": true }
@@ -216,11 +311,15 @@ fragment comparisonFields on Character {
}
```
-You can see how the above query would be pretty repetitive if we weren't able to use fragments. The concept of fragments is frequently used to split complicated application data requirements into smaller chunks, especially when you need to combine many UI components with different fragments into one initial data fetch.
+You can see how the above query would be pretty repetitive if we weren't able to
+use fragments. The concept of fragments is frequently used to split complicated
+application data requirements into smaller chunks, especially when you need to
+combine many UI components with different fragments into one initial data fetch.
### Using variables inside fragments
-It is possible for fragments to access variables declared in the operation as well:
+It is possible for fragments to access variables declared in the operation as
+well:
```graphql
# { "graphiql": true }
@@ -248,9 +347,13 @@ fragment comparisonFields on Character {
### Inline Fragments
-Like many other type systems, GraphQL schemas include the ability to define Interface and Union types. You can learn more about them on the [Schemas and Types page.](/learn/schema/#interfaces)
+Like many other type systems, GraphQL schemas include the ability to define
+Interface and Union types. You can learn more about them on the
+[Schemas and Types page.](/learn/schema/#interfaces)
-If you are querying a field that returns an Interface or a Union type, you will need to use _inline fragments_ to access data on the underlying concrete type. It's easiest to see with an example:
+If you are querying a field that returns an Interface or a Union type, you will
+need to use _inline fragments_ to access data on the underlying concrete type.
+It's easiest to see with an example:
```graphql
# { "graphiql": true, "variables": { "ep": "JEDI" } }
@@ -267,17 +370,28 @@ query HeroForEpisode($ep: Episode!) {
}
```
-In this query, the `hero` field returns the type `Character`, which might be either a `Human` or a `Droid` depending on the `episode` argument. In the direct selection, you can only ask for fields on the `Character` interface, such as `name`.
+In this query, the `hero` field returns the type `Character`, which might be
+either a `Human` or a `Droid` depending on the `episode` argument. In the direct
+selection, you can only ask for fields on the `Character` interface, such as
+`name`.
-To ask for a field on the concrete type, you need to use an inline fragment with a type condition. Because the first fragment is labeled as `... on Droid`, the `primaryFunction` field will only be executed if the `Character` returned from `hero` is of the `Droid` type. Similarly for the `height` field for the `Human` type.
+To ask for a field on the concrete type, you need to use an inline fragment with
+a type condition. Because the first fragment is labeled as `... on Droid`, the
+`primaryFunction` field will only be executed if the `Character` returned from
+`hero` is of the `Droid` type. Similarly for the `height` field for the `Human`
+type.
-Named fragments can also be used in the same way, since a named fragment always has a type attached.
+Named fragments can also be used in the same way, since a named fragment always
+has a type attached.
### Meta fields
-As we have seen with [Union types](/learn/schema/#union-types), there are some situations where you don't know what type you'll get back from the GraphQL service so you need some way to determine how to handle that data on the client.
+As we have seen with [Union types](/learn/schema/#union-types), there are some
+situations where you don't know what type you'll get back from the GraphQL
+service so you need some way to determine how to handle that data on the client.
-GraphQL allows you to request `__typename`, a meta field, at any point in a query to get the name of the Object type at that point:
+GraphQL allows you to request `__typename`, a meta field, at any point in a
+query to get the name of the Object type at that point:
```graphql
# { "graphiql": true}
@@ -297,13 +411,23 @@ GraphQL allows you to request `__typename`, a meta field, at any point in a quer
}
```
-In the above query, `search` returns a Union type that can be one of three options. Without the `__typename` field, it would be impossible for a client to tell the different types apart.
+In the above query, `search` returns a Union type that can be one of three
+options. Without the `__typename` field, it would be impossible for a client to
+tell the different types apart.
-All field names beginning with two underscores (`__`) are reserved by GraphQL. In addition to `__typename`, GraphQL services provide the `__schema` and `__type` meta-fields which expose the [introspection](/learn/introspection) system.
+All field names beginning with two underscores (`__`) are reserved by GraphQL.
+In addition to `__typename`, GraphQL services provide the `__schema` and
+`__type` meta-fields which expose the [introspection](/learn/introspection)
+system.
## Directives
-We discussed above how variables enable us to avoid doing manual string interpolation to construct dynamic queries. Passing variables in arguments solves a large class of these problems, but we might also need a way to dynamically change the structure and shape of our queries using variables. For example, we can imagine a UI component that has a summarized and detailed view, where one includes more fields than the other.
+We discussed above how variables enable us to avoid doing manual string
+interpolation to construct dynamic queries. Passing variables in arguments
+solves a large class of these problems, but we might also need a way to
+dynamically change the structure and shape of our queries using variables. For
+example, we can imagine a UI component that has a summarized and detailed view,
+where one includes more fields than the other.
Let's construct a query for such a component:
@@ -319,32 +443,57 @@ query Hero($episode: Episode, $withFriends: Boolean!) {
}
```
-Try editing the variables above to instead pass `true` for `withFriends`, and see how the result changes.
+Try editing the variables above to instead pass `true` for `withFriends`, and
+see how the result changes.
-We needed to use a feature in GraphQL called a [directive](https://spec.graphql.org/draft/#sec-Type-System.Directives). Specifically, an _executable directive_ can be attached to a field or fragment inclusion by a client, and can affect execution of the query in any way the server desires. The core GraphQL specification includes exactly two directives, which must be supported by any spec-compliant GraphQL server implementation:
+We needed to use a feature in GraphQL called a
+[directive](https://spec.graphql.org/draft/#sec-Type-System.Directives).
+Specifically, an _executable directive_ can be attached to a field or fragment
+inclusion by a client, and can affect execution of the query in any way the
+server desires. The core GraphQL specification includes exactly two directives,
+which must be supported by any spec-compliant GraphQL server implementation:
-- `@include(if: Boolean)` Only include this field in the result if the argument is `true`.
+- `@include(if: Boolean)` Only include this field in the result if the argument
+ is `true`.
- `@skip(if: Boolean)` Skip this field if the argument is `true`.
-Directives can be useful to get out of situations where you otherwise would need to do string manipulation to add and remove fields in your query. Server implementations may also add experimental features by defining completely new directives.
+Directives can be useful to get out of situations where you otherwise would need
+to do string manipulation to add and remove fields in your query. Server
+implementations may also add experimental features by defining completely new
+directives.
<Callout type="info">
-Looking for information on how to define directives that can be used to annotate the types, fields, or arguments in your GraphQL schema? See the [Schemas and Types page](/learn/schema/#directives) for more information on defining and using type system directives.
+ Looking for information on how to define directives that can be used to
+ annotate the types, fields, or arguments in your GraphQL schema? See the
+ [Schemas and Types page](/learn/schema/#directives) for more information on
+ defining and using type system directives.
</Callout>
## Next steps
To recap what we've learned about queries:
-- A GraphQL operation that reads data starts at the `query` root operation type and traverses the fields in the selection set down to the leaf values, which will be Scalar or Enum types
+- A GraphQL operation that reads data starts at the `query` root operation type
+ and traverses the fields in the selection set down to the leaf values, which
+ will be Scalar or Enum types
- Fields can accept arguments that alter the output of that field
-- Operations can use the `query`, `mutation`, or `subscription` keyword to indicate their type
+- Operations can use the `query`, `mutation`, or `subscription` keyword to
+ indicate their type
- The operation type keyword can be omitted for certain query operations only
-- Operations should be given unique names, which make requests more expressive and help with debugging
-- Field aliases allow you to rename response keys, include the same field multiple times in the same query, and provide different arguments to the aliased fields
-- Variables are preceded by the `$` character and can be used to provide dynamic values to field arguments
-- A fragment is a reusable selection set of fields that can be used as needed in multiple queries
-- Executable directive can be applied to queries to change the result of a GraphQL query when it's executed on the server
-- All spec-compliant GraphQL servers include the `@include` and `@skip` built-in directives
-
-Now that we understand the ins and outs of how to read data from a GraphQL server with query operations, it's time to learn how to change data and trigger side effects using [mutations](/learn/mutations/).
+- Operations should be given unique names, which make requests more expressive
+ and help with debugging
+- Field aliases allow you to rename response keys, include the same field
+ multiple times in the same query, and provide different arguments to the
+ aliased fields
+- Variables are preceded by the `$` character and can be used to provide dynamic
+ values to field arguments
+- A fragment is a reusable selection set of fields that can be used as needed in
+ multiple queries
+- Executable directive can be applied to queries to change the result of a
+ GraphQL query when it's executed on the server
+- All spec-compliant GraphQL servers include the `@include` and `@skip` built-in
+ directives
+
+Now that we understand the ins and outs of how to read data from a GraphQL
+server with query operations, it's time to learn how to change data and trigger
+side effects using [mutations](/learn/mutations/).
diff --git a/src/pages/learn/response.mdx b/src/pages/learn/response.mdx
index d93c1fb855..0e0d4c4f6c 100644
--- a/src/pages/learn/response.mdx
+++ b/src/pages/learn/response.mdx
@@ -4,11 +4,19 @@ import { Callout } from "nextra/components"
<p className="learn-subtitle">Learn how GraphQL returns data to clients</p>
-After a GraphQL document has been [validated](/learn/validation/) and [executed](/learn/execution/), the server will return a [response](https://spec.graphql.org/draft/#sec-Response) to the requesting client. One of GraphQL's strengths is that the server response reflects the shape of the client's original request, but a response may also contain helpful information if something unexpected happened before or during the execution of an operation. On this page, we'll take a deeper exploration of this final phase in the lifecycle of a GraphQL request.
+After a GraphQL document has been [validated](/learn/validation/) and
+[executed](/learn/execution/), the server will return a
+[response](https://spec.graphql.org/draft/#sec-Response) to the requesting
+client. One of GraphQL's strengths is that the server response reflects the
+shape of the client's original request, but a response may also contain helpful
+information if something unexpected happened before or during the execution of
+an operation. On this page, we'll take a deeper exploration of this final phase
+in the lifecycle of a GraphQL request.
## Data
-As we have seen in the examples throughout this guide, when a GraphQL request is executed the response is returned on a top-level `data` key. For example:
+As we have seen in the examples throughout this guide, when a GraphQL request is
+executed the response is returned on a top-level `data` key. For example:
```graphql
# { "graphiql": true }
@@ -23,27 +31,47 @@ query {
}
```
-The inclusion of the `data` key isn't an arbitrary decision made by the underlying GraphQL implementation—it's described by the [GraphQL specification](https://spec.graphql.org/draft/#sec-Data). Under this key, you will find the result of the execution of the requested operation, which may include partial data for the requested fields if errors were raised during the execution of some field resolvers.
+The inclusion of the `data` key isn't an arbitrary decision made by the
+underlying GraphQL implementation—it's described by the
+[GraphQL specification](https://spec.graphql.org/draft/#sec-Data). Under this
+key, you will find the result of the execution of the requested operation, which
+may include partial data for the requested fields if errors were raised during
+the execution of some field resolvers.
-One thing that the GraphQL specification doesn't require is a specific serialization format for the response. That said, responses are typically formatted as JSON, as in the example above.
+One thing that the GraphQL specification doesn't require is a specific
+serialization format for the response. That said, responses are typically
+formatted as JSON, as in the example above.
-Additionally, the GraphQL specification doesn't require the use of a particular transport protocol for requests either, although it is [common for HTTP to be used](/learn/serving-over-http/) for stateless query and mutations operations. Long-lived, stateful subscription operations are often supported by WebSockets or server-sent events instead.
+Additionally, the GraphQL specification doesn't require the use of a particular
+transport protocol for requests either, although it is
+[common for HTTP to be used](/learn/serving-over-http/) for stateless query and
+mutations operations. Long-lived, stateful subscription operations are often
+supported by WebSockets or server-sent events instead.
<Callout type="info">
-There is [a draft GraphQL over HTTP specification](https://graphql.github.io/graphql-over-http/draft/) available with further guidelines for using HTTP with GraphQL clients and servers.
+ There is [a draft GraphQL over HTTP
+ specification](https://graphql.github.io/graphql-over-http/draft/) available
+ with further guidelines for using HTTP with GraphQL clients and servers.
</Callout>
## Errors
-In addition to the `data` key, the GraphQL specification outlines how [errors](https://spec.graphql.org/draft/#sec-Errors) should be formatted in the response. Whether the GraphQL implementation provides partial data with the error information in the response will depend on the type of error that was raised. Let's look at the different kinds of errors that can occur during the lifecycle of a GraphQL request.
+In addition to the `data` key, the GraphQL specification outlines how
+[errors](https://spec.graphql.org/draft/#sec-Errors) should be formatted in the
+response. Whether the GraphQL implementation provides partial data with the
+error information in the response will depend on the type of error that was
+raised. Let's look at the different kinds of errors that can occur during the
+lifecycle of a GraphQL request.
### Request errors
-Request errors typically occur because the client made a mistake. For example, there may be a _syntax error_ in the document, such as a missing bracket or the use of an unknown root operation type keyword:
+Request errors typically occur because the client made a mistake. For example,
+there may be a _syntax error_ in the document, such as a missing bracket or the
+use of an unknown root operation type keyword:
```graphql
# { "graphiql": true }
-operation {
+operation {
updateHumanName(id: "1000", name: "Luke Starkiller" ) {
id
name
@@ -51,11 +79,16 @@ operation {
}
```
-The `message` key inside the `errors` object provides some helpful information for the developer to understand what kind of error was raised, and the `locations` key, if present, indicates where the error occurred in the document.
+The `message` key inside the `errors` object provides some helpful information
+for the developer to understand what kind of error was raised, and the
+`locations` key, if present, indicates where the error occurred in the document.
-Sometimes, a GraphQL request may be syntactically correct, but when the server parses and [validates](/learn/validation/) the document against the schema, it finds an issue with part of the operation and raises a _validation error_.
+Sometimes, a GraphQL request may be syntactically correct, but when the server
+parses and [validates](/learn/validation/) the document against the schema, it
+finds an issue with part of the operation and raises a _validation error_.
-For example, the client may request a field that does not exist on the `Starship` type:
+For example, the client may request a field that does not exist on the
+`Starship` type:
```graphql
# { "graphiql": true }
@@ -66,7 +99,8 @@ query {
}
```
-Validation errors also occur when clients specify incorrect variable types for their corresponding field arguments:
+Validation errors also occur when clients specify incorrect variable types for
+their corresponding field arguments:
```graphql
# { "graphiql": true, "variables": { "ep": "JEDI" } }
@@ -77,13 +111,19 @@ query HeroForEpisode($ep: String!) {
}
```
-In the previous examples, we can see that when a request error occurs the `data` key will not be included because the server returns an error response to the client before the field resolvers are executed.
+In the previous examples, we can see that when a request error occurs the `data`
+key will not be included because the server returns an error response to the
+client before the field resolvers are executed.
### Field errors
-Field errors are raised if something unexpected happens during execution. For example, a resolver may raise an error directly, or may return invalid data such as a null value for a field that has a Non-Null output type.
+Field errors are raised if something unexpected happens during execution. For
+example, a resolver may raise an error directly, or may return invalid data such
+as a null value for a field that has a Non-Null output type.
-In these cases, GraphQL will attempt to continue executing the other fields and return a partial response, with the `data` key appearing alongside the `errors` key.
+In these cases, GraphQL will attempt to continue executing the other fields and
+return a partial response, with the `data` key appearing alongside the `errors`
+key.
Let's look at an example:
@@ -95,28 +135,55 @@ mutation {
}
```
-The mutation above attempts to delete two starships in a single operation, but no starship exists with an ID of `3010` so the server throws an error. In the response, we can see information about the error that occurred for the field that was aliased as `secondShip`. Under the `data` key, we also see that the ID of the first ship was returned to indicate successful deletion, while the second ship produced a null result due to the error raised in its resolver function.
+The mutation above attempts to delete two starships in a single operation, but
+no starship exists with an ID of `3010` so the server throws an error. In the
+response, we can see information about the error that occurred for the field
+that was aliased as `secondShip`. Under the `data` key, we also see that the ID
+of the first ship was returned to indicate successful deletion, while the second
+ship produced a null result due to the error raised in its resolver function.
### Network errors
-As with network calls to any type of API, network errors that are not specific to GraphQL may happen at any point during a request. These kinds of errors will block communication between the client and server before the request is complete, such as an SSL error or a connection timeout. Depending on the GraphQL server and client libraries that you choose, there may be features built into them that support special network error handling such as retries for failed operations.
+As with network calls to any type of API, network errors that are not specific
+to GraphQL may happen at any point during a request. These kinds of errors will
+block communication between the client and server before the request is
+complete, such as an SSL error or a connection timeout. Depending on the GraphQL
+server and client libraries that you choose, there may be features built into
+them that support special network error handling such as retries for failed
+operations.
## Extensions
-The final top-level key allowed by the GraphQL specification in a response is the `extentions` key. This key is reserved for GraphQL implementations to provide additional information about the response and though it must be an object if present, there are no other restrictions on what it may contain.
+The final top-level key allowed by the GraphQL specification in a response is
+the `extentions` key. This key is reserved for GraphQL implementations to
+provide additional information about the response and though it must be an
+object if present, there are no other restrictions on what it may contain.
-For example, some GraphQL servers may include telemetry data or information about rate limit consumption under this key. Note that what data is available in `extensions` and whether this data is available in production or development environments will depend entirely on the specific GraphQL implementation.
+For example, some GraphQL servers may include telemetry data or information
+about rate limit consumption under this key. Note that what data is available in
+`extensions` and whether this data is available in production or development
+environments will depend entirely on the specific GraphQL implementation.
## Next steps
To recap what we've learned about GraphQL response formats:
-- The GraphQL specification allows three top-level keys in a response: `data`, `errors`, and `extensions`
-- At least one of `data` or `errors` will be present on the response (when it contains both it is a "partial response")
+- The GraphQL specification allows three top-level keys in a response: `data`,
+ `errors`, and `extensions`
+- At least one of `data` or `errors` will be present on the response (when it
+ contains both it is a "partial response")
- The `data` key contains the result of the executed operation
-- Information about raised errors is included in the `errors` key of the response
-- Request errors (such as syntax or validation errors) are raised before execution begins so `data` won't be included in the response
-- When a field error occurs during execution, there will be a description of the issue in the `errors` key and there may be partial data included with the `data` key
-- GraphQL implementations may include additional arbitrary information about the response in the `extensions` key
-
-Now that you understand the different phases of a GraphQL request and how responses are provided to clients, head over to the [Introspection](/learn/introspection) page to learn about how a GraphQL server can query information about its own schema.
\ No newline at end of file
+- Information about raised errors is included in the `errors` key of the
+ response
+- Request errors (such as syntax or validation errors) are raised before
+ execution begins so `data` won't be included in the response
+- When a field error occurs during execution, there will be a description of the
+ issue in the `errors` key and there may be partial data included with the
+ `data` key
+- GraphQL implementations may include additional arbitrary information about the
+ response in the `extensions` key
+
+Now that you understand the different phases of a GraphQL request and how
+responses are provided to clients, head over to the
+[Introspection](/learn/introspection) page to learn about how a GraphQL server
+can query information about its own schema.
diff --git a/src/pages/learn/schema-design.mdx b/src/pages/learn/schema-design.mdx
index 43d2de1048..0d8fb4ce8f 100644
--- a/src/pages/learn/schema-design.mdx
+++ b/src/pages/learn/schema-design.mdx
@@ -1,19 +1,46 @@
# Schema Design
-<p className="learn-subtitle">Design and evolve a type system over time without versions</p>
+<p className="learn-subtitle">
+ Design and evolve a type system over time without versions
+</p>
## Versioning
-While there's nothing that prevents a GraphQL service from being versioned just like any other API, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema.
+While there's nothing that prevents a GraphQL service from being versioned just
+like any other API, GraphQL takes a strong opinion on avoiding versioning by
+providing the tools for the continuous evolution of a GraphQL schema.
-Why do most APIs version? When there's limited control over the data that's returned from an API endpoint, _any change_ can be considered a breaking change, and breaking changes require a new version. If adding new features to an API requires a new version, then a tradeoff emerges between releasing often and having many incremental versions versus the understandability and maintainability of the API.
+Why do most APIs version? When there's limited control over the data that's
+returned from an API endpoint, _any change_ can be considered a breaking change,
+and breaking changes require a new version. If adding new features to an API
+requires a new version, then a tradeoff emerges between releasing often and
+having many incremental versions versus the understandability and
+maintainability of the API.
-In contrast, GraphQL only returns the data that's explicitly requested, so new capabilities can be added via new types or new fields on existing types without creating a breaking change. This has led to a common practice of always avoiding breaking changes and serving a versionless API.
+In contrast, GraphQL only returns the data that's explicitly requested, so new
+capabilities can be added via new types or new fields on existing types without
+creating a breaking change. This has led to a common practice of always avoiding
+breaking changes and serving a versionless API.
## Nullability
-Most type systems which recognise "null" provide both the common type and the _nullable_ version of that type, whereby default types do not include "null" unless explicitly declared. However, in a GraphQL type system, every field is _nullable_ by default. This is because there are many things that can go awry in a networked service backed by databases and other services. A database could go down, an asynchronous action could fail, an exception could be thrown. Beyond simply system failures, authorization can often be granular, where individual fields within a request can have different authorization rules.
-
-By defaulting every field to _nullable_, any of these reasons may result in just that field returned "null" rather than having a complete failure for the request. Instead, GraphQL provides [non-null](/learn/schema/#lists-and-non-null) variants of types which make a guarantee to clients that if requested, the field will never return "null". Instead, if an error occurs, the previous parent field will be "null" instead.
-
-When designing a GraphQL schema, it's important to keep in mind all the problems that could go wrong and if "null" is an appropriate value for a failed field. Typically it is, but occasionally, it's not. In those cases, use non-null types to make that guarantee.
\ No newline at end of file
+Most type systems which recognise "null" provide both the common type and the
+_nullable_ version of that type, whereby default types do not include "null"
+unless explicitly declared. However, in a GraphQL type system, every field is
+_nullable_ by default. This is because there are many things that can go awry in
+a networked service backed by databases and other services. A database could go
+down, an asynchronous action could fail, an exception could be thrown. Beyond
+simply system failures, authorization can often be granular, where individual
+fields within a request can have different authorization rules.
+
+By defaulting every field to _nullable_, any of these reasons may result in just
+that field returned "null" rather than having a complete failure for the
+request. Instead, GraphQL provides [non-null](/learn/schema/#lists-and-non-null)
+variants of types which make a guarantee to clients that if requested, the field
+will never return "null". Instead, if an error occurs, the previous parent field
+will be "null" instead.
+
+When designing a GraphQL schema, it's important to keep in mind all the problems
+that could go wrong and if "null" is an appropriate value for a failed field.
+Typically it is, but occasionally, it's not. In those cases, use non-null types
+to make that guarantee.
diff --git a/src/pages/learn/schema.mdx b/src/pages/learn/schema.mdx
index c47a6bf9d7..6ed1ddd590 100644
--- a/src/pages/learn/schema.mdx
+++ b/src/pages/learn/schema.mdx
@@ -2,15 +2,27 @@ import { Callout } from "nextra/components"
# Schemas and Types
-<p className="learn-subtitle">Learn about the different elements of the GraphQL type system</p>
-
-The GraphQL [type system](https://spec.graphql.org/draft/#sec-Type-System) describes what data can be queried from the API. The collection of those capabilities is referred to as the service's _schema_ and clients can use that schema to send queries to the API that return predictable results.
-
-On this page, we'll explore GraphQL's [six kinds of named type definitions](https://spec.graphql.org/draft/#sec-Types) as well as other features of the type system to learn how they may be used to describe your data and the relationships between them. Since GraphQL can be used with any backend framework or programming language, we'll avoid implementation-specific details and talk only about the concepts.
+<p className="learn-subtitle">
+ Learn about the different elements of the GraphQL type system
+</p>
+
+The GraphQL [type system](https://spec.graphql.org/draft/#sec-Type-System)
+describes what data can be queried from the API. The collection of those
+capabilities is referred to as the service's _schema_ and clients can use that
+schema to send queries to the API that return predictable results.
+
+On this page, we'll explore GraphQL's
+[six kinds of named type definitions](https://spec.graphql.org/draft/#sec-Types)
+as well as other features of the type system to learn how they may be used to
+describe your data and the relationships between them. Since GraphQL can be used
+with any backend framework or programming language, we'll avoid
+implementation-specific details and talk only about the concepts.
## Type system
-If you've seen a GraphQL query before, you know that the GraphQL query language is basically about selecting fields on objects. So, for example, in the following query:
+If you've seen a GraphQL query before, you know that the GraphQL query language
+is basically about selecting fields on objects. So, for example, in the
+following query:
```graphql
# { "graphiql": true }
@@ -24,26 +36,47 @@ If you've seen a GraphQL query before, you know that the GraphQL query language
1. We start with a special "root" object
2. We select the `hero` field on that
-3. For the object returned by `hero`, we select the `name` and `appearsIn` fields
+3. For the object returned by `hero`, we select the `name` and `appearsIn`
+ fields
-Because the shape of a GraphQL query closely matches the result, we can predict what the query will return without knowing that much about the server. But it's useful to have an exact description of the data we can request. For example, what fields can we select? What kinds of objects might they return? What fields are available on those sub-objects?
+Because the shape of a GraphQL query closely matches the result, we can predict
+what the query will return without knowing that much about the server. But it's
+useful to have an exact description of the data we can request. For example,
+what fields can we select? What kinds of objects might they return? What fields
+are available on those sub-objects?
-That's where the schema comes in. Every GraphQL service defines a set of types that completely describe the set of possible data we can query on that service. Then, when requests come in, they are validated and executed against that schema.
+That's where the schema comes in. Every GraphQL service defines a set of types
+that completely describe the set of possible data we can query on that service.
+Then, when requests come in, they are validated and executed against that
+schema.
## Type language
-GraphQL services can be written in any language and there are many different approaches you can take when defining the types in a schema:
-
-- Some libraries have you construct the schema types, fields, and resolver functions together using the same programming language that was used to write the GraphQL implementation.
-- Some libraries allow you to define types and fields more ergonomically using what's commonly called the schema definition language (or SDL) and then write the resolver functions for the corresponding fields separately.
-- Some libraries allow you to write and annotate the resolver functions, and then infer the schema from that.
-- Some libraries may even infer both the types and resolver functions for you, based on some underlying data source(s).
-
-Since we can't rely on a specific programming language to discuss GraphQL schemas in this guide, we'll use SDL because it's similar to the query language that we've seen so far and allows us to talk about GraphQL schemas in a language-agnostic way.
+GraphQL services can be written in any language and there are many different
+approaches you can take when defining the types in a schema:
+
+- Some libraries have you construct the schema types, fields, and resolver
+ functions together using the same programming language that was used to write
+ the GraphQL implementation.
+- Some libraries allow you to define types and fields more ergonomically using
+ what's commonly called the schema definition language (or SDL) and then write
+ the resolver functions for the corresponding fields separately.
+- Some libraries allow you to write and annotate the resolver functions, and
+ then infer the schema from that.
+- Some libraries may even infer both the types and resolver functions for you,
+ based on some underlying data source(s).
+
+Since we can't rely on a specific programming language to discuss GraphQL
+schemas in this guide, we'll use SDL because it's similar to the query language
+that we've seen so far and allows us to talk about GraphQL schemas in a
+language-agnostic way.
## Object types and fields
-The most basic components of a GraphQL schema are [Object types](https://spec.graphql.org/draft/#sec-Objects), which just represent a kind of object you can fetch from your service, and what fields it has. In SDL, we represent it like this:
+The most basic components of a GraphQL schema are
+[Object types](https://spec.graphql.org/draft/#sec-Objects), which just
+represent a kind of object you can fetch from your service, and what fields it
+has. In SDL, we represent it like this:
```graphql
type Character {
@@ -52,19 +85,36 @@ type Character {
}
```
-The language is readable, but let's go over it so that we can have a shared vocabulary:
-
-- `Character` is a [GraphQL Object type](#object-types-and-fields), meaning it's a type with some fields. Most of the types in your schema will be Object types.
-- `name` and `appearsIn` are [fields](#object-types-and-fields) on the `Character` type. That means that `name` and `appearsIn` are the only fields that can appear in any part of a GraphQL query that operates on the `Character` type.
-- `String` is one of the built-in [Scalar types](#scalar-types). These are types that resolve to a single scalar value and can't have sub-selections in the query. We'll go over Scalar types more later.
-- `String!` means that the field is a [Non-Null type](#non-null), meaning the GraphQL service promises to give you a value whenever you query this field. In SDL, we represent those with an exclamation mark.
-- `[Episode!]!` represents an [List type](#list) of `Episode` objects. When a List is Non-Null, you can always expect an array (with zero or more items) when you query the `appearsIn` field. In this case, since `Episode!` is also Non-Null within the list, you can always expect every item in the array to be an `Episode` object.
-
-Now you know what a GraphQL Object type looks like and how to read the basics of SDL.
+The language is readable, but let's go over it so that we can have a shared
+vocabulary:
+
+- `Character` is a [GraphQL Object type](#object-types-and-fields), meaning it's
+ a type with some fields. Most of the types in your schema will be Object
+ types.
+- `name` and `appearsIn` are [fields](#object-types-and-fields) on the
+ `Character` type. That means that `name` and `appearsIn` are the only fields
+ that can appear in any part of a GraphQL query that operates on the
+ `Character` type.
+- `String` is one of the built-in [Scalar types](#scalar-types). These are types
+ that resolve to a single scalar value and can't have sub-selections in the
+ query. We'll go over Scalar types more later.
+- `String!` means that the field is a [Non-Null type](#non-null), meaning the
+ GraphQL service promises to give you a value whenever you query this field. In
+ SDL, we represent those with an exclamation mark.
+- `[Episode!]!` represents an [List type](#list) of `Episode` objects. When a
+ List is Non-Null, you can always expect an array (with zero or more items)
+ when you query the `appearsIn` field. In this case, since `Episode!` is also
+ Non-Null within the list, you can always expect every item in the array to be
+ an `Episode` object.
+
+Now you know what a GraphQL Object type looks like and how to read the basics of
+SDL.
### Arguments
-Every field on a GraphQL Object type can have zero or more [arguments](https://spec.graphql.org/draft/#sec-Field-Arguments), for example, the `length` field below:
+Every field on a GraphQL Object type can have zero or more
+[arguments](https://spec.graphql.org/draft/#sec-Field-Arguments), for example,
+the `length` field below:
```graphql
type Starship {
@@ -74,13 +124,21 @@ type Starship {
}
```
-All arguments are named. Unlike languages such as JavaScript and Python where functions take a list of ordered arguments, all arguments in GraphQL are passed by name specifically. In this case, the `length` field has one defined argument called `unit`.
+All arguments are named. Unlike languages such as JavaScript and Python where
+functions take a list of ordered arguments, all arguments in GraphQL are passed
+by name specifically. In this case, the `length` field has one defined argument
+called `unit`.
-Arguments can be either required or optional. When an argument is optional, we can define a _default value_. If the `unit` argument is not passed, then it will be set to `METER` by default.
+Arguments can be either required or optional. When an argument is optional, we
+can define a _default value_. If the `unit` argument is not passed, then it will
+be set to `METER` by default.
### The Query, Mutation, and Subscription types
-Every GraphQL schema must support `query` operations. The _entry point_ for this [root operation type](https://spec.graphql.org/draft/#sec-Root-Operation-Types) is a regular Object type called `Query` by default. So if you see a query that looks like this:
+Every GraphQL schema must support `query` operations. The _entry point_ for this
+[root operation type](https://spec.graphql.org/draft/#sec-Root-Operation-Types)
+is a regular Object type called `Query` by default. So if you see a query that
+looks like this:
```graphql
# { "graphiql": true }
@@ -91,7 +149,8 @@ Every GraphQL schema must support `query` operations. The _entry point_ for this
}
```
-That means that the GraphQL service needs to have a `Query` type with a `droid` field:
+That means that the GraphQL service needs to have a `Query` type with a `droid`
+field:
```graphql
type Query {
@@ -99,11 +158,18 @@ type Query {
}
```
-Schemas may also support `mutation` and `subscription` operations by adding additional `Mutation` and `Subscription` types and then defining fields on the corresponding root operation types.
+Schemas may also support `mutation` and `subscription` operations by adding
+additional `Mutation` and `Subscription` types and then defining fields on the
+corresponding root operation types.
-It's important to remember that other than the special status of being entry points into the schema, the `Query`, `Mutation`, and `Subscription` types are the same as any other GraphQL Object type, and their fields work exactly the same way.
+It's important to remember that other than the special status of being entry
+points into the schema, the `Query`, `Mutation`, and `Subscription` types are
+the same as any other GraphQL Object type, and their fields work exactly the
+same way.
-You can name your root operation types differently too; if you choose to do so then you will need to inform GraphQL of the new names using the `schema` keyword:
+You can name your root operation types differently too; if you choose to do so
+then you will need to inform GraphQL of the new names using the `schema`
+keyword:
```graphql
schema {
@@ -115,9 +181,13 @@ schema {
## Scalar types
-A GraphQL Object type has a name and fields, but at some point, those fields must resolve to some concrete data. That's where the [Scalar types](https://spec.graphql.org/draft/#sec-Scalars) come in: they represent the leaf values of the query.
+A GraphQL Object type has a name and fields, but at some point, those fields
+must resolve to some concrete data. That's where the
+[Scalar types](https://spec.graphql.org/draft/#sec-Scalars) come in: they
+represent the leaf values of the query.
-In the following query, the `name` and `appearsIn` fields will resolve to Scalar types:
+In the following query, the `name` and `appearsIn` fields will resolve to Scalar
+types:
```graphql
# { "graphiql": true }
@@ -129,30 +199,42 @@ In the following query, the `name` and `appearsIn` fields will resolve to Scalar
}
```
-We know this because those fields don't have any sub-fields—they are the leaves of the query.
+We know this because those fields don't have any sub-fields—they are the leaves
+of the query.
-GraphQL comes with a set of [default Scalar types](https://spec.graphql.org/draft/#sec-Scalars.Built-in-Scalars) out of the box:
+GraphQL comes with a set of
+[default Scalar types](https://spec.graphql.org/draft/#sec-Scalars.Built-in-Scalars)
+out of the box:
- `Int`: A signed 32‐bit integer.
- `Float`: A signed double-precision floating-point value.
- `String`: A UTF‐8 character sequence.
- `Boolean`: `true` or `false`.
-- `ID`: A unique identifier, often used to refetch an object or as the key for a cache. The `ID` type is serialized in the same way as a `String`; however, defining it as an `ID` signifies that it is not intended to be human‐readable.
+- `ID`: A unique identifier, often used to refetch an object or as the key for a
+ cache. The `ID` type is serialized in the same way as a `String`; however,
+ defining it as an `ID` signifies that it is not intended to be human‐readable.
-In most GraphQL service implementations, there is also a way to specify custom Scalar types. For example, we could define a `Date` type:
+In most GraphQL service implementations, there is also a way to specify custom
+Scalar types. For example, we could define a `Date` type:
```graphql
scalar Date
```
-Then it's up to our implementation to define how that type should be serialized, deserialized, and validated. For example, you could specify that the `Date` type should always be serialized into an integer timestamp, and your client should know to expect that format for any date fields.
+Then it's up to our implementation to define how that type should be serialized,
+deserialized, and validated. For example, you could specify that the `Date` type
+should always be serialized into an integer timestamp, and your client should
+know to expect that format for any date fields.
## Enum types
-[Enum types](https://spec.graphql.org/draft/#sec-Enums), also known as enumeration types, are a special kind of scalar that is restricted to a particular set of allowed values. This allows you to:
+[Enum types](https://spec.graphql.org/draft/#sec-Enums), also known as
+enumeration types, are a special kind of scalar that is restricted to a
+particular set of allowed values. This allows you to:
1. Validate that any arguments of this type are one of the allowed values
-2. Communicate through the type system that a field will always be one of a finite set of values
+2. Communicate through the type system that a field will always be one of a
+ finite set of values
Here's what an Enum type definition looks like in SDL:
@@ -164,15 +246,30 @@ enum Episode {
}
```
-This means that wherever we use the type `Episode` in our schema, we expect it to be exactly one of `NEWHOPE`, `EMPIRE`, or `JEDI`.
+This means that wherever we use the type `Episode` in our schema, we expect it
+to be exactly one of `NEWHOPE`, `EMPIRE`, or `JEDI`.
-<Callout type="info">GraphQL service implementations in various languages will have a language-specific way of dealing with Enum types. In languages that support enums as a first-class citizen, the implementation might take advantage of that; in a language like JavaScript with no enum support, these values might be internally mapped to a set of integers. However, these details don't leak out to the client, which can operate entirely in terms of the string names of the Enum type's values.</Callout>
+<Callout type="info">
+ GraphQL service implementations in various languages will have a
+ language-specific way of dealing with Enum types. In languages that support
+ enums as a first-class citizen, the implementation might take advantage of
+ that; in a language like JavaScript with no enum support, these values might
+ be internally mapped to a set of integers. However, these details don't leak
+ out to the client, which can operate entirely in terms of the string names of
+ the Enum type's values.
+</Callout>
## Type modifiers
-Types are assumed to be nullable and singular by default in GraphQL. However, when you use these named types in a schema (or in [query variable declarations](/learn/queries/#variables)) you can apply additional _type modifiers_ that will affect the meaning of those values.
+Types are assumed to be nullable and singular by default in GraphQL. However,
+when you use these named types in a schema (or in
+[query variable declarations](/learn/queries/#variables)) you can apply
+additional _type modifiers_ that will affect the meaning of those values.
-As we saw with the Object type example above, GraphQL supports two type modifiers—the [List](https://spec.graphql.org/draft/#sec-List) and [Non-Null](https://spec.graphql.org/draft/#sec-Non-Null) types—and they can be used individually or in combination with each other.
+As we saw with the Object type example above, GraphQL supports two type
+modifiers—the [List](https://spec.graphql.org/draft/#sec-List) and
+[Non-Null](https://spec.graphql.org/draft/#sec-Non-Null) types—and they can be
+used individually or in combination with each other.
### Non-Null
@@ -184,9 +281,15 @@ type Character {
}
```
-Here, we're using a `String` type and marking it as a Non-Null type by adding an exclamation mark (`!`) after the type name. This means that our server always expects to return a non-null value for this field, and if the resolver produces a null value, then that will trigger a GraphQL execution error, letting the client know that something has gone wrong.
+Here, we're using a `String` type and marking it as a Non-Null type by adding an
+exclamation mark (`!`) after the type name. This means that our server always
+expects to return a non-null value for this field, and if the resolver produces
+a null value, then that will trigger a GraphQL execution error, letting the
+client know that something has gone wrong.
-As we saw in an example above, the Non-Null type modifier can also be used when defining arguments for a field, which will cause the GraphQL server to return a validation error if a null value is passed as that argument:
+As we saw in an example above, the Non-Null type modifier can also be used when
+defining arguments for a field, which will cause the GraphQL server to return a
+validation error if a null value is passed as that argument:
```graphql
# { "graphiql": true }
@@ -199,7 +302,11 @@ As we saw in an example above, the Non-Null type modifier can also be used when
### List
-Lists work in a similar way. We can use a type modifier to mark a type as a List type, which indicates that this field will return an array of that type. In SDL, this is denoted by wrapping the type in square brackets, `[` and `]`. It works the same for arguments, where the validation step will expect an array for that value. Here's an example:
+Lists work in a similar way. We can use a type modifier to mark a type as a List
+type, which indicates that this field will return an array of that type. In SDL,
+this is denoted by wrapping the type in square brackets, `[` and `]`. It works
+the same for arguments, where the validation step will expect an array for that
+value. Here's an example:
```graphql
type Character {
@@ -208,13 +315,15 @@ type Character {
}
```
-As we see above, the Non-Null and List modifiers can be combined. For example, you can have a List of Non-Null `String` types:
+As we see above, the Non-Null and List modifiers can be combined. For example,
+you can have a List of Non-Null `String` types:
```graphql
myField: [String!]
```
-This means that the _list itself_ can be null, but it can't have any null members. For example, in JSON:
+This means that the _list itself_ can be null, but it can't have any null
+members. For example, in JSON:
```js
myField: null // valid
@@ -253,15 +362,25 @@ myField: ["a", "b"] // valid
myField: ["a", null, "b"] // error
```
-You can arbitrarily nest any number of Non-Null and List modifiers, according to your needs.
+You can arbitrarily nest any number of Non-Null and List modifiers, according to
+your needs.
-<Callout type="info">In GraphQL, there is no way to define a type so that the field's data will only be considered valid if a non-empty list is provided. In other words, `[]` would still be a valid response for a Non-Null List of a Non-Null type.</Callout>
+<Callout type="info">
+ In GraphQL, there is no way to define a type so that the field's data will
+ only be considered valid if a non-empty list is provided. In other words, `[]`
+ would still be a valid response for a Non-Null List of a Non-Null type.
+</Callout>
## Interface types
-Like many type systems, GraphQL supports _abstract types_. The first of these types that we'll explore is an [Interface type](https://spec.graphql.org/draft/#sec-Interfaces), which defines a certain set of fields that a concrete Object type or other Interface type must also include to implement it.
+Like many type systems, GraphQL supports _abstract types_. The first of these
+types that we'll explore is an
+[Interface type](https://spec.graphql.org/draft/#sec-Interfaces), which defines
+a certain set of fields that a concrete Object type or other Interface type must
+also include to implement it.
-For example, you could have a `Character` Interface type that represents any character in the Star Wars trilogy:
+For example, you could have a `Character` Interface type that represents any
+character in the Star Wars trilogy:
```graphql
interface Character {
@@ -272,7 +391,8 @@ interface Character {
}
```
-This means that any type that _implements_ `Character` needs to have these exact fields as well as the same arguments and return types.
+This means that any type that _implements_ `Character` needs to have these exact
+fields as well as the same arguments and return types.
For example, here are some types that might implement `Character`:
@@ -295,9 +415,13 @@ type Droid implements Character {
}
```
-You can see that both of these types have all of the fields from the `Character` Interface type, but also bring in extra fields—`totalCredits`, `starships` and `primaryFunction`—that are specific to that particular type of character.
+You can see that both of these types have all of the fields from the `Character`
+Interface type, but also bring in extra fields—`totalCredits`, `starships` and
+`primaryFunction`—that are specific to that particular type of character.
-Interface types are useful when you want to return an object or set of objects, but those might be of several different types. For example, note that the following query produces an error:
+Interface types are useful when you want to return an object or set of objects,
+but those might be of several different types. For example, note that the
+following query produces an error:
```graphql
# { "graphiql": true }
@@ -309,9 +433,13 @@ Interface types are useful when you want to return an object or set of objects,
}
```
-The `hero` field returns the type `Character`, which means it might be either a `Human` or a `Droid` depending on the `episode` argument. In the query above, you can only ask for fields that exist on the `Character` Interface type, which doesn't include `primaryFunction`.
+The `hero` field returns the type `Character`, which means it might be either a
+`Human` or a `Droid` depending on the `episode` argument. In the query above,
+you can only ask for fields that exist on the `Character` Interface type, which
+doesn't include `primaryFunction`.
-To ask for a field on a specific Object type, you need to use an [inline fragment](/learn/queries/#inline-fragments):
+To ask for a field on a specific Object type, you need to use an
+[inline fragment](/learn/queries/#inline-fragments):
```graphql
# { "graphiql": true }
@@ -340,13 +468,24 @@ interface Character implements Node {
}
```
-Note that Interface types may not implement themselves or contain any cyclic references to each other.
+Note that Interface types may not implement themselves or contain any cyclic
+references to each other.
-<Callout type="info">While types may share common fields in a GraphQL API, that may not always warrant the use of an Interface type to enforce that those fields remain consistently named. Interface types are a powerful way to indicate shared behavior across the types that implement them. When used, they should be semantically meaningful to client developers, just like `Character` is a useful abstraction for humans and droids.</Callout>
+<Callout type="info">
+ While types may share common fields in a GraphQL API, that may not always
+ warrant the use of an Interface type to enforce that those fields remain
+ consistently named. Interface types are a powerful way to indicate shared
+ behavior across the types that implement them. When used, they should be
+ semantically meaningful to client developers, just like `Character` is a
+ useful abstraction for humans and droids.
+</Callout>
## Union types
-GraphQL supports a second abstract type called a [Union type](https://spec.graphql.org/draft/#sec-Unions). Union types share similarities with Interface types, but they cannot define any shared fields among the constituent types.
+GraphQL supports a second abstract type called a
+[Union type](https://spec.graphql.org/draft/#sec-Unions). Union types share
+similarities with Interface types, but they cannot define any shared fields
+among the constituent types.
A Union type is defined by indicating its member Object types:
@@ -354,9 +493,14 @@ A Union type is defined by indicating its member Object types:
union SearchResult = Human | Droid | Starship
```
-Wherever we return a `SearchResult` type in our schema, we might get a `Human`, a `Droid`, or a `Starship`. Note that members of a Union type need to be concrete Object types; you can't define one using Interface types or other Union types as members.
+Wherever we return a `SearchResult` type in our schema, we might get a `Human`,
+a `Droid`, or a `Starship`. Note that members of a Union type need to be
+concrete Object types; you can't define one using Interface types or other Union
+types as members.
-In this case, if you query a field that returns the `SearchResult` Union type, you need to use an [inline fragment](/learn/queries/#inline-fragments) to be able to query any fields that are defined on the member Object types:
+In this case, if you query a field that returns the `SearchResult` Union type,
+you need to use an [inline fragment](/learn/queries/#inline-fragments) to be
+able to query any fields that are defined on the member Object types:
```graphql
# { "graphiql": true}
@@ -379,9 +523,13 @@ In this case, if you query a field that returns the `SearchResult` Union type, y
}
```
-The `__typename` field is a special _meta-field_ that automatically exists on every Object type and resolves to the name of that type, providing a way to differentiate between data types on the client.
+The `__typename` field is a special _meta-field_ that automatically exists on
+every Object type and resolves to the name of that type, providing a way to
+differentiate between data types on the client.
-Also, in this case, since `Human` and `Droid` share a common interface (`Character`), you can query their common fields in one place and still get the same result:
+Also, in this case, since `Human` and `Droid` share a common interface
+(`Character`), you can query their common fields in one place and still get the
+same result:
```graphql
# { "graphiql": true}
@@ -405,15 +553,26 @@ Also, in this case, since `Human` and `Droid` share a common interface (`Charact
}
```
-Note that `name` is still specified on `Starship` because otherwise it wouldn't show up in the results given that `Starship` is not a `Character`!
+Note that `name` is still specified on `Starship` because otherwise it wouldn't
+show up in the results given that `Starship` is not a `Character`!
## Input Object types
-Most of the examples we've covered on this page demonstrate how Object, Scalar, Enum, Interface, and Union types may be used as _output types_ for the fields in a schema. But we have also seen that field arguments must specify their _input types_.
+Most of the examples we've covered on this page demonstrate how Object, Scalar,
+Enum, Interface, and Union types may be used as _output types_ for the fields in
+a schema. But we have also seen that field arguments must specify their _input
+types_.
-So far, we've only talked about using scalar values (like Enums or String types) as an input type for a field argument. However, you can also pass complex objects as arguments using an [Input Object type](https://spec.graphql.org/draft/#sec-Input-Objects), which is the last kind of named types in GraphQL that we'll explore.
+So far, we've only talked about using scalar values (like Enums or String types)
+as an input type for a field argument. However, you can also pass complex
+objects as arguments using an
+[Input Object type](https://spec.graphql.org/draft/#sec-Input-Objects), which is
+the last kind of named types in GraphQL that we'll explore.
-This is particularly valuable in the case of [mutations](/learn/queries/#mutations), where you might want to pass in a whole object to be created. In SDL, Input Object types look similar to regular Object types, but with the keyword `input` instead of `type`:
+This is particularly valuable in the case of
+[mutations](/learn/queries/#mutations), where you might want to pass in a whole
+object to be created. In SDL, Input Object types look similar to regular Object
+types, but with the keyword `input` instead of `type`:
```graphql
input ReviewInput {
@@ -432,11 +591,8 @@ Here is how you could use the Input Object type in a mutation:
# { "graphiql": true }
mutation {
createReview(
- episode: JEDI,
- review: {
- stars: 5
- commentary: "This is a great movie!"
- }
+ episode: JEDI
+ review: { stars: 5, commentary: "This is a great movie!" }
) {
stars
commentary
@@ -444,19 +600,31 @@ mutation {
}
```
-The fields on an Input Object type can refer to other Input Object types, but you can't mix input and output types in your schema. Input Object types also can't have arguments on their fields.
+The fields on an Input Object type can refer to other Input Object types, but
+you can't mix input and output types in your schema. Input Object types also
+can't have arguments on their fields.
## Directives
-In certain instances where field arguments are insufficient or certain common behaviors must be replicated in multiple locations, [directives](https://spec.graphql.org/draft/#sec-Type-System.Directives) allow us to modify parts of a GraphQL schema or operation by using an `@` character followed by the directive's name.
+In certain instances where field arguments are insufficient or certain common
+behaviors must be replicated in multiple locations,
+[directives](https://spec.graphql.org/draft/#sec-Type-System.Directives) allow
+us to modify parts of a GraphQL schema or operation by using an `@` character
+followed by the directive's name.
-_Type system directives_ allow us to annotate the types, fields, and arguments in a schema so that they may be validated or executed differently.
+_Type system directives_ allow us to annotate the types, fields, and arguments
+in a schema so that they may be validated or executed differently.
<Callout type="info">
-Directives may also be defined for use in GraphQL operations as _executable directives_. [Read more about executable directives on the Queries page.](/learn/queries/#directives)
+ Directives may also be defined for use in GraphQL operations as _executable
+ directives_. [Read more about executable directives on the Queries
+ page.](/learn/queries/#directives)
</Callout>
-The GraphQL specification defines several [built-in directives](https://spec.graphql.org/draft/#sec-Type-System.Directives.Built-in-Directives). For example, for implementations that support SDL, the `@deprecated` directive will be available to annotate deprecated parts of the schema:
+The GraphQL specification defines several
+[built-in directives](https://spec.graphql.org/draft/#sec-Type-System.Directives.Built-in-Directives).
+For example, for implementations that support SDL, the `@deprecated` directive
+will be available to annotate deprecated parts of the schema:
```graphql
type User {
@@ -465,7 +633,9 @@ type User {
}
```
-While you won't need to define the `@deprecated` directive in your schema explicitly if you're using a GraphQL implementation that supports SDL, it's underlying definition would look like this:
+While you won't need to define the `@deprecated` directive in your schema
+explicitly if you're using a GraphQL implementation that supports SDL, it's
+underlying definition would look like this:
```graphql
directive @deprecated(
@@ -473,15 +643,27 @@ directive @deprecated(
) on FIELD_DEFINITION | ENUM_VALUE
```
-Note that, just like fields, directives can accept arguments and those arguments can have default values. The `@deprecated` directive has a nullable `reason` argument that accepts a `String` as an input type and falls back to `"No longer supported"`. And with directives, we must specify where they may be used, such as on a `FIELD_DEFINITION` or `ENUM_VALUE` for the `@deprecated` directive.
+Note that, just like fields, directives can accept arguments and those arguments
+can have default values. The `@deprecated` directive has a nullable `reason`
+argument that accepts a `String` as an input type and falls back to
+`"No longer supported"`. And with directives, we must specify where they may be
+used, such as on a `FIELD_DEFINITION` or `ENUM_VALUE` for the `@deprecated`
+directive.
-In addition to GraphQL's built-in directives, you may define your own _custom directives_. As with custom Scalar types, it's up to your chosen GraphQL implementation to determine how to handle custom directives during query execution.
+In addition to GraphQL's built-in directives, you may define your own _custom
+directives_. As with custom Scalar types, it's up to your chosen GraphQL
+implementation to determine how to handle custom directives during query
+execution.
## Documentation
### Descriptions
-GraphQL allows you to add documentation to the types, fields, and arguments in a schema. In fact, the GraphQL specification encourages you to do this in all cases unless the name of the type, field, or argument is self-descriptive. Schema descriptions are defined using Markdown syntax and can be multiline or single line.
+GraphQL allows you to add documentation to the types, fields, and arguments in a
+schema. In fact, the GraphQL specification encourages you to do this in all
+cases unless the name of the type, field, or argument is self-descriptive.
+Schema descriptions are defined using Markdown syntax and can be multiline or
+single line.
In SDL, they would look like this:
@@ -498,7 +680,7 @@ type Character {
The episodes in the Star Wars trilogy
"""
enum Episode {
- "Star Wars Episode IV: A New Hope, released in 1977."
+ "Star Wars Episode IV: A New Hope, released in 1977."
NEWHOPE
"Star Wars Episode V: The Empire Strikes Back, released in 1980."
EMPIRE
@@ -520,11 +702,17 @@ type Query {
}
```
-In addition to making a GraphQL API schema more expressive, descriptions are helpful to client developers because they are available in [introspection queries](/learn/introspection/) and visible in developer tools such as [GraphiQL](https://github.com/graphql/graphiql).
+In addition to making a GraphQL API schema more expressive, descriptions are
+helpful to client developers because they are available in
+[introspection queries](/learn/introspection/) and visible in developer tools
+such as [GraphiQL](https://github.com/graphql/graphiql).
### Comments
-Occasionally, you may need to add comments in a schema that do not describe types, fields, or arguments, and are not meant to be seen by clients. In those cases, you can add a single-line comment to SDL by preceding the text with a `#` character:
+Occasionally, you may need to add comments in a schema that do not describe
+types, fields, or arguments, and are not meant to be seen by clients. In those
+cases, you can add a single-line comment to SDL by preceding the text with a `#`
+character:
```graphql
# This line is treated like whitespace and ignored by GraphQL
@@ -552,15 +740,27 @@ Comments may also be added to client queries:
To recap what we've learned about schemas and types:
-- Depending on what library is selected to build a GraphQL service, we can define a schema in a language-agnostic way using SDL or by compiling the schema from the code that provides data for its fields
-- There are six kinds of named type definitions in GraphQL: Object, Scalar, Enum, Interface, Union, and Input Object types
-- Object types contain fields that specify output types, and those fields may have arguments that specify input types
-- The `Int`, `Float`, `String`, `Boolean`, and `ID` Scalar types are built into GraphQL, and you can also define your own custom scalars
-- Like Scalar types, Enum types represent leaf values in a GraphQL schema but they are limited to a finite set of values
-- The List (`[]`) and Non-Null (`!`) type modifiers allow you to change the default behavior for a field's output type or argument's input type
-- Interface and Union types are abstract types that allow different concrete Object types to be output from a single field
-- Input Object types allow you to pass more complex values into a field argument or directive argument than Scalar and Enum types allow
-- Type system directives can be applied to the types, fields, and arguments in a schema to alter how they are validated and executed during a query
-- GraphQL supports schema documentation using type, field, and argument descriptions, and it also supports comments that are ignored by the parser
-
-Now that you understand the key features of the type system, you're ready to learn more about how to [query data from a GraphQL API](/learn/queries/).
+- Depending on what library is selected to build a GraphQL service, we can
+ define a schema in a language-agnostic way using SDL or by compiling the
+ schema from the code that provides data for its fields
+- There are six kinds of named type definitions in GraphQL: Object, Scalar,
+ Enum, Interface, Union, and Input Object types
+- Object types contain fields that specify output types, and those fields may
+ have arguments that specify input types
+- The `Int`, `Float`, `String`, `Boolean`, and `ID` Scalar types are built into
+ GraphQL, and you can also define your own custom scalars
+- Like Scalar types, Enum types represent leaf values in a GraphQL schema but
+ they are limited to a finite set of values
+- The List (`[]`) and Non-Null (`!`) type modifiers allow you to change the
+ default behavior for a field's output type or argument's input type
+- Interface and Union types are abstract types that allow different concrete
+ Object types to be output from a single field
+- Input Object types allow you to pass more complex values into a field argument
+ or directive argument than Scalar and Enum types allow
+- Type system directives can be applied to the types, fields, and arguments in a
+ schema to alter how they are validated and executed during a query
+- GraphQL supports schema documentation using type, field, and argument
+ descriptions, and it also supports comments that are ignored by the parser
+
+Now that you understand the key features of the type system, you're ready to
+learn more about how to [query data from a GraphQL API](/learn/queries/).
diff --git a/src/pages/learn/security.mdx b/src/pages/learn/security.mdx
index 77d5764fb7..b2f5b0a7ab 100644
--- a/src/pages/learn/security.mdx
+++ b/src/pages/learn/security.mdx
@@ -2,35 +2,72 @@
<p className="learn-subtitle">Protect GraphQL APIs from malicious operations</p>
-As with any type of API, you will need to consider what security measures should be used to protect a GraphQL implementation's server resources and underlying data sources during request execution.
+As with any type of API, you will need to consider what security measures should
+be used to protect a GraphQL implementation's server resources and underlying
+data sources during request execution.
-Many generalizable API security best practices apply to GraphQL, especially in relation to a given implementation's selected transport protocol. However, there are GraphQL-specific security considerations that will make the API layer more resilient to potential attacks too.
+Many generalizable API security best practices apply to GraphQL, especially in
+relation to a given implementation's selected transport protocol. However, there
+are GraphQL-specific security considerations that will make the API layer more
+resilient to potential attacks too.
-On this page, we'll survey potential attack vectors for GraphQL—many of which are denial of service attacks—along with how a layered security posture can help protect a GraphQL API from malicious operations.
+On this page, we'll survey potential attack vectors for GraphQL—many of which
+are denial of service attacks—along with how a layered security posture can help
+protect a GraphQL API from malicious operations.
## Transport layer security
-The GraphQL specification does not require a specific transport protocol for requests, but [HTTP is a popular choice](/learn/serving-over-http/) for stateless query and mutation operations. For longer-lived subscription operations, WebSockets or server-sent events are often used. Whatever the chosen protocol, security considerations in the transport layer can provide an important first line of defense for a GraphQL API.
+The GraphQL specification does not require a specific transport protocol for
+requests, but [HTTP is a popular choice](/learn/serving-over-http/) for
+stateless query and mutation operations. For longer-lived subscription
+operations, WebSockets or server-sent events are often used. Whatever the chosen
+protocol, security considerations in the transport layer can provide an
+important first line of defense for a GraphQL API.
-The same security measures that would be used for any type of API served with a given transport protocol should typically be used for GraphQL as well. For example, when using HTTP for queries and mutations, you should use HTTPS to encrypt data, set appropriate timeout durations for requests, and, if using HTTP caching, ensure sensitive data is cached privately (or not at all).
+The same security measures that would be used for any type of API served with a
+given transport protocol should typically be used for GraphQL as well. For
+example, when using HTTP for queries and mutations, you should use HTTPS to
+encrypt data, set appropriate timeout durations for requests, and, if using HTTP
+caching, ensure sensitive data is cached privately (or not at all).
## Demand control
### Trusted documents
-For GraphQL APIs that only serve first-party clients, you can write operations as needed in development environments and then lock those operations so that only they may be sent by front-end apps in production. Specifically, using _trusted documents_ will allow you to create an allowlist of operations that can be executed against a schema.
-
-As a build step during development clients may submit their GraphQL documents to the server's allowlist, where each document is stored with a unique ID—usually its hash. At runtime, the client can send a document ID instead of the full GraphQL document, and the server will only execute requests for known document IDs.
-
-Trusted documents are simply _persisted documents_ that are deemed to not be malicious, usually because they were authored by your developers and approved through code review. Efforts are underway to [standardize _persisted documents_ as part of the GraphQL-over-HTTP specification](https://github.com/graphql/graphql-over-http/pull/264)—an increasing number of GraphQL clients and servers already support them (sometimes under their legacy misnomer: _persisted queries_).
-
-Keep in mind that trusted documents can't be used for public APIs because the operations sent by third-party clients won't known in advance. However, the other recommendations that follow can help defend a public GraphQL API from malicious operations.
+For GraphQL APIs that only serve first-party clients, you can write operations
+as needed in development environments and then lock those operations so that
+only they may be sent by front-end apps in production. Specifically, using
+_trusted documents_ will allow you to create an allowlist of operations that can
+be executed against a schema.
+
+As a build step during development clients may submit their GraphQL documents to
+the server's allowlist, where each document is stored with a unique ID—usually
+its hash. At runtime, the client can send a document ID instead of the full
+GraphQL document, and the server will only execute requests for known document
+IDs.
+
+Trusted documents are simply _persisted documents_ that are deemed to not be
+malicious, usually because they were authored by your developers and approved
+through code review. Efforts are underway to
+[standardize _persisted documents_ as part of the GraphQL-over-HTTP specification](https://github.com/graphql/graphql-over-http/pull/264)—an
+increasing number of GraphQL clients and servers already support them (sometimes
+under their legacy misnomer: _persisted queries_).
+
+Keep in mind that trusted documents can't be used for public APIs because the
+operations sent by third-party clients won't known in advance. However, the
+other recommendations that follow can help defend a public GraphQL API from
+malicious operations.
### Paginated fields
-A first step toward implementing demand control for a GraphQL API is limiting the amount of data that can be queried from a single field. When a field outputs a List type and the resulting list could potentially return a lot of data, it should be paginated to limit the maximum number of items that may be returned in a single request.
+A first step toward implementing demand control for a GraphQL API is limiting
+the amount of data that can be queried from a single field. When a field outputs
+a List type and the resulting list could potentially return a lot of data, it
+should be paginated to limit the maximum number of items that may be returned in
+a single request.
-For example, compare the unbounded output of the `friends` field to the limited data returned by the `friendsConnection` field in this operation:
+For example, compare the unbounded output of the `friends` field to the limited
+data returned by the `friendsConnection` field in this operation:
```graphql
# { "graphiql": true }
@@ -51,11 +88,15 @@ query {
}
```
-Read more about the connection-based model for paginating fields on the [Pagination page](/learn/pagination/).
+Read more about the connection-based model for paginating fields on the
+[Pagination page](/learn/pagination/).
### Depth limiting
-One of GraphQL's strengths is that clients can write expressive operations that reflect the relationships between the data exposed in the API. However, some queries may become cyclical when the fields in the selection set are deeply nested:
+One of GraphQL's strengths is that clients can write expressive operations that
+reflect the relationships between the data exposed in the API. However, some
+queries may become cyclical when the fields in the selection set are deeply
+nested:
```graphql
query {
@@ -77,35 +118,60 @@ query {
}
```
-Even when the N+1 problem has been remediated through batched requests to underlying data sources, overly nested fields may still place excessive load on server resources and impact API performance.
+Even when the N+1 problem has been remediated through batched requests to
+underlying data sources, overly nested fields may still place excessive load on
+server resources and impact API performance.
-For this reason, it's a good idea to limit the maximum depth of fields that a single operation can have. Many GraphQL implementations expose configuration options that allow you to specify a maximum depth for a GraphQL document and return an error to the client if a request exceeds this limit before execution begins.
+For this reason, it's a good idea to limit the maximum depth of fields that a
+single operation can have. Many GraphQL implementations expose configuration
+options that allow you to specify a maximum depth for a GraphQL document and
+return an error to the client if a request exceeds this limit before execution
+begins.
-Since nesting list fields can result in exponential increases to the amount of data returned, it's recommended to apply a separate smaller limit to how deeply lists can be nested.
+Since nesting list fields can result in exponential increases to the amount of
+data returned, it's recommended to apply a separate smaller limit to how deeply
+lists can be nested.
-For cases where a client may have a legitimate use case for a deeply nested query and it's impractical to set a low blanket limit on all queries, you may need to rely on techniques such as [rate limiting](/#rate-limiting) or [query complexity analysis](#query-complexity-analysis).
+For cases where a client may have a legitimate use case for a deeply nested
+query and it's impractical to set a low blanket limit on all queries, you may
+need to rely on techniques such as [rate limiting](/#rate-limiting) or
+[query complexity analysis](#query-complexity-analysis).
### Breadth and batch limiting
-In addition to limiting operation depth, there should also be guardrails in place to limit the number of top-level fields and field aliases included in a single operation.
+In addition to limiting operation depth, there should also be guardrails in
+place to limit the number of top-level fields and field aliases included in a
+single operation.
-Consider what would happen during the execution of the following query operation:
+Consider what would happen during the execution of the following query
+operation:
```graphql
query {
viewer {
- friends1: friends(limit: 1) { name }
- friends2: friends(limit: 2) { name }
- friends3: friends(limit: 3) { name }
+ friends1: friends(limit: 1) {
+ name
+ }
+ friends2: friends(limit: 2) {
+ name
+ }
+ friends3: friends(limit: 3) {
+ name
+ }
# ...
- friends100: friends(limit: 100) { name }
+ friends100: friends(limit: 100) {
+ name
+ }
}
}
```
-Even though the overall depth of this query is shallow, the underlying data source for the API will still have to handle a large number of requests to resolve data for the aliased `hero` field.
+Even though the overall depth of this query is shallow, the underlying data
+source for the API will still have to handle a large number of requests to
+resolve data for the aliased `hero` field.
-Similarly, a client may send a GraphQL document with many batched operations in a request:
+Similarly, a client may send a GraphQL document with many batched operations in
+a request:
```graphql
query NewHopeHero {
@@ -126,29 +192,59 @@ query JediHero {
}
```
-Depending on the client implementation, query batching can be a useful strategy for limiting the number of round trips to a server to fetch all of the required data to render a user interface. However, there should be an upper limit on the total number of queries allowed in a single batch.
+Depending on the client implementation, query batching can be a useful strategy
+for limiting the number of round trips to a server to fetch all of the required
+data to render a user interface. However, there should be an upper limit on the
+total number of queries allowed in a single batch.
-As with depth limiting, a GraphQL implementation may have configuration options to restrict operation breadth, field alias usage, and batching.
+As with depth limiting, a GraphQL implementation may have configuration options
+to restrict operation breadth, field alias usage, and batching.
### Rate limiting
-Depth, breadth, and batch limiting help prevent broad categories of malicious operations such as cyclic queries and batching attacks, but they don't provide a way to declare that a particular field is computationally expensive to resolve. So for more advanced demand control requirements, you may wish to implement rate limiting.
-
-Rate limiting may take place in different layers of an application, for example, in the network layer or the business logic layer. Because GraphQL allows clients to specify exactly what data they need in their queries, a server may not be able to know in advance if a request includes fields that will place a higher load on its resources during execution. As a result, applying useful rate limits for a GraphQL API typically requires a different approach than simply keeping track of the total number of incoming requests over a time period in the network layer; therefore applying rate limits within the business logic layer is generally recommended.
+Depth, breadth, and batch limiting help prevent broad categories of malicious
+operations such as cyclic queries and batching attacks, but they don't provide a
+way to declare that a particular field is computationally expensive to resolve.
+So for more advanced demand control requirements, you may wish to implement rate
+limiting.
+
+Rate limiting may take place in different layers of an application, for example,
+in the network layer or the business logic layer. Because GraphQL allows clients
+to specify exactly what data they need in their queries, a server may not be
+able to know in advance if a request includes fields that will place a higher
+load on its resources during execution. As a result, applying useful rate limits
+for a GraphQL API typically requires a different approach than simply keeping
+track of the total number of incoming requests over a time period in the network
+layer; therefore applying rate limits within the business logic layer is
+generally recommended.
### Query complexity analysis
-By applying weights to the types and fields in a schema, you can estimate the cost of incoming requests using the technique known as _query complexity analysis_. If the combination of fields included in a request exceeds a maximum allowable cost per request, you may choose to reject the request outright. The estimated cost can also be factored into rate limiting: if the request proceeds, the total cost of the request can be deducted from the overall query budget allocated to a client for a specific time period.
+By applying weights to the types and fields in a schema, you can estimate the
+cost of incoming requests using the technique known as _query complexity
+analysis_. If the combination of fields included in a request exceeds a maximum
+allowable cost per request, you may choose to reject the request outright. The
+estimated cost can also be factored into rate limiting: if the request proceeds,
+the total cost of the request can be deducted from the overall query budget
+allocated to a client for a specific time period.
-While the GraphQL specification doesn't provide any guidelines on implementing query complexity analysis or rate limits for an API, there is [a community-maintained draft specification](https://ibm.github.io/graphql-specs/cost-spec.html) for implementing custom type system directives that support these calculations.
+While the GraphQL specification doesn't provide any guidelines on implementing
+query complexity analysis or rate limits for an API, there is
+[a community-maintained draft specification](https://ibm.github.io/graphql-specs/cost-spec.html)
+for implementing custom type system directives that support these calculations.
## Schema considerations
### Validating and sanitizing argument values
-GraphQL is strongly typed, and the [validation stage](/learn/validation/) of a request will check a parsed document against the type system to determine its validity. However, for certain cases you may find that the built-in Scalar types aren't enough to make sure that the argument value a client provides is appropriate to execute a field resolver safely.
+GraphQL is strongly typed, and the [validation stage](/learn/validation/) of a
+request will check a parsed document against the type system to determine its
+validity. However, for certain cases you may find that the built-in Scalar types
+aren't enough to make sure that the argument value a client provides is
+appropriate to execute a field resolver safely.
-Consider the following `ReviewInput` type that is used with the `createReview` mutation:
+Consider the following `ReviewInput` type that is used with the `createReview`
+mutation:
```graphql
input ReviewInput {
@@ -161,19 +257,35 @@ type Mutation {
}
```
-Depending on what kind of client application will submit and display the review data, it may be necessary to sanitize the string provided for the `commentary` field in case a user submits unsafe HTML in it.
+Depending on what kind of client application will submit and display the review
+data, it may be necessary to sanitize the string provided for the `commentary`
+field in case a user submits unsafe HTML in it.
-The sanitization step should take place in the business logic layer that is called during execution of the `createReview` resolver function. To surface this to frontend developers, it could also be expressed as a part of the schema using a custom [Scalar type](/learn/schema/#scalar-types).
+The sanitization step should take place in the business logic layer that is
+called during execution of the `createReview` resolver function. To surface this
+to frontend developers, it could also be expressed as a part of the schema using
+a custom [Scalar type](/learn/schema/#scalar-types).
### Introspection
-[Introspection](/learn/introspection/) is a powerful feature of GraphQL that allows you to query a GraphQL API for information about its schema. However, GraphQL APIs that only serve first-party clients may forbid introspection queries in non-development environments.
+[Introspection](/learn/introspection/) is a powerful feature of GraphQL that
+allows you to query a GraphQL API for information about its schema. However,
+GraphQL APIs that only serve first-party clients may forbid introspection
+queries in non-development environments.
-Note that disabling introspection can be used as a form of "security through obscurity," but will not be sufficient to entirely obscure a GraphQL API by itself. It may be used as a part of a broader security strategy to limit the discoverability of API information from potential attackers. For more comprehensive protection of sensitive schema details and user data, trusted documents and authorization should be used.
+Note that disabling introspection can be used as a form of "security through
+obscurity," but will not be sufficient to entirely obscure a GraphQL API by
+itself. It may be used as a part of a broader security strategy to limit the
+discoverability of API information from potential attackers. For more
+comprehensive protection of sensitive schema details and user data, trusted
+documents and authorization should be used.
### Error messages
-On the [Response page](/learn/response/), we saw that a GraphQL implementation may provide developers with useful information about validation errors in a request, along with suggestions for how these errors may be addressed. For example:
+On the [Response page](/learn/response/), we saw that a GraphQL implementation
+may provide developers with useful information about validation errors in a
+request, along with suggestions for how these errors may be addressed. For
+example:
```graphql
# { "graphiql": true }
@@ -184,19 +296,33 @@ query {
}
```
-These hints can be helpful when debugging client-side errors, but they may provide more information about a schema in a production environment than we would like to reveal. Hiding detailed error information in GraphQL responses outside of development environments is important because, even with introspection disabled, an attacker could ultimately infer the shape of an entire schema by running numerous operations with incorrect field names.
+These hints can be helpful when debugging client-side errors, but they may
+provide more information about a schema in a production environment than we
+would like to reveal. Hiding detailed error information in GraphQL responses
+outside of development environments is important because, even with
+introspection disabled, an attacker could ultimately infer the shape of an
+entire schema by running numerous operations with incorrect field names.
-In addition to request errors, details about errors that are raised during field execution should be masked as they may reveal sensitive information about the server or underlying data sources.
+In addition to request errors, details about errors that are raised during field
+execution should be masked as they may reveal sensitive information about the
+server or underlying data sources.
## Authentication and authorization
-Auth-related considerations for GraphQL APIs are discussed in-depth on the [Authorization page](/learn/authorization/).
+Auth-related considerations for GraphQL APIs are discussed in-depth on the
+[Authorization page](/learn/authorization/).
## Recap
To recap these recommendations for securing a GraphQL API:
-- General security considerations for a chosen transport protocol will usually apply to a GraphQL API as well
-- Depending on your requirements, demand control can be implemented in many ways in GraphQL, including trusted documents, pagination of list fields, depth limiting, breadth/batch limiting, and rate limiting
-- A GraphQL schema can help support validation and sanitization of client-provided values
-- Disabling introspection and obscuring error information can make an API's schema less discoverable, but they will typically not be sufficient when used on their own (a document allowlist is likely to be a more effective solution)
\ No newline at end of file
+- General security considerations for a chosen transport protocol will usually
+ apply to a GraphQL API as well
+- Depending on your requirements, demand control can be implemented in many ways
+ in GraphQL, including trusted documents, pagination of list fields, depth
+ limiting, breadth/batch limiting, and rate limiting
+- A GraphQL schema can help support validation and sanitization of
+ client-provided values
+- Disabling introspection and obscuring error information can make an API's
+ schema less discoverable, but they will typically not be sufficient when used
+ on their own (a document allowlist is likely to be a more effective solution)
diff --git a/src/pages/learn/serving-over-http.mdx b/src/pages/learn/serving-over-http.mdx
index 5ed1ff6d33..56dfe965ee 100644
--- a/src/pages/learn/serving-over-http.mdx
+++ b/src/pages/learn/serving-over-http.mdx
@@ -2,45 +2,86 @@ import { Callout } from "nextra/components"
# Serving over HTTP
-<p className="learn-subtitle">Respond to GraphQL requests using an HTTP server</p>
+<p className="learn-subtitle">
+ Respond to GraphQL requests using an HTTP server
+</p>
-The GraphQL specification doesn't require particular client-server protocols when sending API requests and responses, but HTTP is the most common choice because of its ubiquity. On this page, we'll review some key guidelines to follow when setting up a GraphQL server to operate over HTTP.
+The GraphQL specification doesn't require particular client-server protocols
+when sending API requests and responses, but HTTP is the most common choice
+because of its ubiquity. On this page, we'll review some key guidelines to
+follow when setting up a GraphQL server to operate over HTTP.
-Note that the guidelines that follow only apply to stateless query and mutation operations. Visit the [Subscriptions page](/learn/subscriptions) for more information on transport protocols that commonly support these requests.
+Note that the guidelines that follow only apply to stateless query and mutation
+operations. Visit the [Subscriptions page](/learn/subscriptions) for more
+information on transport protocols that commonly support these requests.
<Callout type="info">
-The recommendations on this page align with the detailed [GraphQL-over-HTTP specification](https://graphql.github.io/graphql-over-http/draft/) currently in development. Though not yet finalized, this draft specification acts as a single source of truth for GraphQL client and library maintainers, detailing how to expose and consume a GraphQL API using an HTTP transport. Unlike the language specification, adherence is not mandatory, but most implementations are moving towards these standards to maximize interoperability.
+ The recommendations on this page align with the detailed [GraphQL-over-HTTP
+ specification](https://graphql.github.io/graphql-over-http/draft/) currently
+ in development. Though not yet finalized, this draft specification acts as a
+ single source of truth for GraphQL client and library maintainers, detailing
+ how to expose and consume a GraphQL API using an HTTP transport. Unlike the
+ language specification, adherence is not mandatory, but most implementations
+ are moving towards these standards to maximize interoperability.
</Callout>
## API endpoint
-HTTP is commonly associated with REST, which uses "resources" as its core concept. In contrast, GraphQL's conceptual model is an [entity graph](/learn/thinking-in-graphs/). As a result, entities in GraphQL are not identified by URLs. Instead, a GraphQL server operates on a single URL/endpoint, usually `/graphql`, and all GraphQL requests for a given service should be directed to this endpoint.
+HTTP is commonly associated with REST, which uses "resources" as its core
+concept. In contrast, GraphQL's conceptual model is an
+[entity graph](/learn/thinking-in-graphs/). As a result, entities in GraphQL are
+not identified by URLs. Instead, a GraphQL server operates on a single
+URL/endpoint, usually `/graphql`, and all GraphQL requests for a given service
+should be directed to this endpoint.
## Where auth happens
-Most modern web frameworks use a pipeline model where requests are passed through a stack of _middleware_, also known as _filters_ or _plugins_. As the request flows through the pipeline, it can be inspected, transformed, modified, or terminated with a response. GraphQL should be placed after all authentication middleware so that you have access to the same session and user information you would in your other HTTP endpoint handlers.
-
-After authentication, the server should not make any [authorization](/learn/authorization/) decisions about the request until GraphQL execution begins. Specifically, field-level authorization should be enforced by the business logic called from resolvers during [GraphQL's ExecuteRequest()](https://spec.graphql.org/draft/#ExecuteRequest()), allowing for a partial response to be generated if authorization-related errors are raised.
+Most modern web frameworks use a pipeline model where requests are passed
+through a stack of _middleware_, also known as _filters_ or _plugins_. As the
+request flows through the pipeline, it can be inspected, transformed, modified,
+or terminated with a response. GraphQL should be placed after all authentication
+middleware so that you have access to the same session and user information you
+would in your other HTTP endpoint handlers.
+
+After authentication, the server should not make any
+[authorization](/learn/authorization/) decisions about the request until GraphQL
+execution begins. Specifically, field-level authorization should be enforced by
+the business logic called from resolvers
+during [GraphQL's ExecuteRequest()](<https://spec.graphql.org/draft/#ExecuteRequest()>),
+allowing for a partial response to be generated if authorization-related errors
+are raised.
## Request format
### Headers
-GraphQL clients and servers should support JSON for serialization and may support other formats. Clients should also indicate what media types they support in responses using the `Accept` HTTP header. Specifically, the client should include the `application/graphql-response+json` in the `Accept` header.
+GraphQL clients and servers should support JSON for serialization and may
+support other formats. Clients should also indicate what media types they
+support in responses using the `Accept` HTTP header. Specifically, the client
+should include the `application/graphql-response+json` in the `Accept` header.
-If no encoding information is included with this header, then it will be assumed to be `utf-8`. However, the server may respond with an error if a client doesn't provide the `Accept` header with a request.
+If no encoding information is included with this header, then it will be assumed
+to be `utf-8`. However, the server may respond with an error if a client doesn't
+provide the `Accept` header with a request.
<Callout type="info">
-The `application/graphql-response+json` is described in the draft GraphQL over HTTP specification. To ensure compatibility, if a client sends a request to a legacy GraphQL server before 1st January 2025, the `Accept` header should also include the `application/json` media type as follows: `application/graphql-response+json;charset=utf-8, application/json;charset=utf-8`
+ The `application/graphql-response+json` is described in the draft GraphQL over
+ HTTP specification. To ensure compatibility, if a client sends a request to a
+ legacy GraphQL server before 1st January 2025, the `Accept` header should also
+ include the `application/json` media type as follows:
+ `application/graphql-response+json;charset=utf-8,
+ application/json;charset=utf-8`
</Callout>
### Methods
-Your GraphQL HTTP server must handle the HTTP `POST` method for query and mutation operations, and may also accept the `GET` method for query operations.
+Your GraphQL HTTP server must handle the HTTP `POST` method for query and
+mutation operations, and may also accept the `GET` method for query operations.
#### `POST` request and body
-A standard GraphQL POST request should set `application/json` for its `Content-type` header, and include a JSON-encoded body of the following form:
+A standard GraphQL POST request should set `application/json` for its
+`Content-type` header, and include a JSON-encoded body of the following form:
```json
{
@@ -51,15 +92,24 @@ A standard GraphQL POST request should set `application/json` for its `Content-t
}
```
-The `query` parameter is required and will contain the source text of a GraphQL document. Note that the term `query` here is a misnomer: the document may contain any valid GraphQL operations (and associated fragments).
+The `query` parameter is required and will contain the source text of a GraphQL
+document. Note that the term `query` here is a misnomer: the document may
+contain any valid GraphQL operations (and associated fragments).
-The `operationName`, `variables`, and `extensions` parameters are optional fields. `operationName` is only required if multiple operations are present in the `query` document.
+The `operationName`, `variables`, and `extensions` parameters are optional
+fields. `operationName` is only required if multiple operations are present in
+the `query` document.
-Note that if the `Content-type` header is missing in the client's request, then the server should respond with a `4xx` status code. As with the `Accept` header, `utf-8` encoding is assumed for a request body with an `application/json` media type when this information is not explicitly provided.
+Note that if the `Content-type` header is missing in the client's request, then
+the server should respond with a `4xx` status code. As with the `Accept` header,
+`utf-8` encoding is assumed for a request body with an `application/json` media
+type when this information is not explicitly provided.
#### `GET` request and parameters
-When receiving an HTTP GET request, the GraphQL document should be provided in the `query` parameter of the query string. For example, if we wanted to execute the following GraphQL query:
+When receiving an HTTP GET request, the GraphQL document should be provided in
+the `query` parameter of the query string. For example, if we wanted to execute
+the following GraphQL query:
```graphql
{
@@ -75,27 +125,49 @@ This request could be sent via an HTTP GET like so:
http://myapi/graphql?query={me{name}}
```
-Query variables can be sent as a JSON-encoded string in an additional query parameter called `variables`. If the query contains several named operations, an `operationName` query parameter can be used to control which one should be executed.
+Query variables can be sent as a JSON-encoded string in an additional query
+parameter called `variables`. If the query contains several named operations, an
+`operationName` query parameter can be used to control which one should be
+executed.
#### Choosing an HTTP method
-When choosing an HTTP method for a GraphQL request, there are a few points to consider. First, support for HTTP methods other than `POST` will be at the discretion of the GraphQL server, so a client will be limited to the supported verbs.
+When choosing an HTTP method for a GraphQL request, there are a few points to
+consider. First, support for HTTP methods other than `POST` will be at the
+discretion of the GraphQL server, so a client will be limited to the supported
+verbs.
-Additionally, the `GET` HTTP method may only be used for `query` operations, so if a client requests execution of a `mutation` operation then it must use the `POST` method instead.
+Additionally, the `GET` HTTP method may only be used for `query` operations, so
+if a client requests execution of a `mutation` operation then it must use the
+`POST` method instead.
-When servers do support the `GET` method for query operations, a client may be encouraged to leverage this option to facilitate HTTP caching or edge caching in a content delivery network (CDN). However, because GraphQL documents strings may be quite long for complex operations, the query parameters may exceed the limits that browsers and CDNs impose on URL lengths.
+When servers do support the `GET` method for query operations, a client may be
+encouraged to leverage this option to facilitate HTTP caching or edge caching in
+a content delivery network (CDN). However, because GraphQL documents strings may
+be quite long for complex operations, the query parameters may exceed the limits
+that browsers and CDNs impose on URL lengths.
-In these cases, a common approach is for the server to store identified GraphQL documents using a technique such as [_persisted documents_](https://github.com/graphql/graphql-over-http/pull/264), _automatic persisted queries_, or _trusted documents_. This allows the client to send a short document identifier instead of the full query text.
+In these cases, a common approach is for the server to store identified GraphQL
+documents using a technique such as
+[_persisted documents_](https://github.com/graphql/graphql-over-http/pull/264),
+_automatic persisted queries_, or _trusted documents_. This allows the client to
+send a short document identifier instead of the full query text.
## Response format
### Headers
-The response type should be `application/graphql-response+json` but can be `application/json` to support legacy clients. The server will indicate the media type in the `Content-type` header of the response. It should also indicate the encoding, otherwise `utf-8` will be assumed.
+The response type should be `application/graphql-response+json` but can be
+`application/json` to support legacy clients. The server will indicate the media
+type in the `Content-type` header of the response. It should also indicate the
+encoding, otherwise `utf-8` will be assumed.
### Body
-Regardless of the HTTP method used to send the query and variables, the response should be returned in the body of the request in JSON format. As mentioned in the GraphQL specification, a query might result in some data and some errors, and those should be returned in a JSON object of the form:
+Regardless of the HTTP method used to send the query and variables, the response
+should be returned in the body of the request in JSON format. As mentioned in
+the GraphQL specification, a query might result in some data and some errors,
+and those should be returned in a JSON object of the form:
```json
{
@@ -105,35 +177,65 @@ Regardless of the HTTP method used to send the query and variables, the response
}
```
-If no errors were returned, the `errors` field must not be present in the response. If errors occurred before execution could start, the `errors` field must include these errors and the `data` field must not be present in the response. The `extensions` field is optional and information provided here will be at the discretion of the GraphQL implementation.
+If no errors were returned, the `errors` field must not be present in the
+response. If errors occurred before execution could start, the `errors` field
+must include these errors and the `data` field must not be present in the
+response. The `extensions` field is optional and information provided here will
+be at the discretion of the GraphQL implementation.
-You can read more about GraphQL spec-compliant response formats on the [Response page](/learn/response/).
+You can read more about GraphQL spec-compliant response formats on the
+[Response page](/learn/response/).
### Status Codes
-If a response contains a `data` key and its value is not `null`, then the server should respond with a `2xx` status code for either the `application/graphql-response+json` or `application/json` media types. This is the case even if the response includes errors, since HTTP does not yet have a status code representing "partial success."
+If a response contains a `data` key and its value is not `null`, then the server
+should respond with a `2xx` status code for either the
+`application/graphql-response+json` or `application/json` media types. This is
+the case even if the response includes errors, since HTTP does not yet have a
+status code representing "partial success."
-For validation errors that prevent the execution of a GraphQL operation, the server will typically send a `400` status code, although some legacy servers may return a `2xx` status code when the `application/json` media type is used.
+For validation errors that prevent the execution of a GraphQL operation, the
+server will typically send a `400` status code, although some legacy servers may
+return a `2xx` status code when the `application/json` media type is used.
-For legacy servers that respond with the `application/json` media type, the use of `4xx` and `5xx` status codes for valid GraphQL requests that fail to execute is discouraged but may be used depending on the implementation. Because of potential ambiguities regarding the source of the server-side error, a `2xx` code should be used with this media type instead.
+For legacy servers that respond with the `application/json` media type, the use
+of `4xx` and `5xx` status codes for valid GraphQL requests that fail to execute
+is discouraged but may be used depending on the implementation. Because of
+potential ambiguities regarding the source of the server-side error, a `2xx`
+code should be used with this media type instead.
-However, for responses with the `application/graphql-response+json` media type, the server will reply with a `4xx` or `5xx` status code if a valid GraphQL request fails to execute.
+However, for responses with the `application/graphql-response+json` media type,
+the server will reply with a `4xx` or `5xx` status code if a valid GraphQL
+request fails to execute.
## Server implementations
-If you use Node.js, we recommend looking at the [list of JS server implementations](/community/tools-and-libraries/?tags=javascript_server).
+If you use Node.js, we recommend looking at the
+[list of JS server implementations](/community/tools-and-libraries/?tags=javascript_server).
-You can view a [list of servers written in many other languages here](/community/tools-and-libraries/?tags=server).
+You can view a
+[list of servers written in many other languages here](/community/tools-and-libraries/?tags=server).
## Recap
To recap these recommendations for serving GraphQL over HTTP:
-- The server should handle user authentication before a GraphQL request is validated; authorization should happen within your business logic during GraphQL request execution
-- GraphQL APIs are exposed at a single endpoint, typically ending with `/graphql`
+- The server should handle user authentication before a GraphQL request is
+ validated; authorization should happen within your business logic during
+ GraphQL request execution
+- GraphQL APIs are exposed at a single endpoint, typically ending with
+ `/graphql`
- GraphQL clients and servers should support JSON, but may support other formats
-- Client should indicate a media type on the `Accept` header of `application/graphql-response+json`
-- GraphQL requests are sent using the `POST` HTTP method, but query operations may also be sent using the `GET` method
-- Clients should also provide a `Content-type` header with a value of `application/json` for `POST` requests
-- The full or partial result of an executed GraphQL operation will be available on the `data` key in the JSON-encoded body of the response, while information about any errors raised during validation or execution will be available on the `errors` key
-- Response status codes for valid GraphQL operations that fail may vary depending on the indicated media type of the response, but any GraphQL response with a non-null `data` key will provide a `2xx` response
+- Client should indicate a media type on the `Accept` header of
+ `application/graphql-response+json`
+- GraphQL requests are sent using the `POST` HTTP method, but query operations
+ may also be sent using the `GET` method
+- Clients should also provide a `Content-type` header with a value of
+ `application/json` for `POST` requests
+- The full or partial result of an executed GraphQL operation will be available
+ on the `data` key in the JSON-encoded body of the response, while information
+ about any errors raised during validation or execution will be available on
+ the `errors` key
+- Response status codes for valid GraphQL operations that fail may vary
+ depending on the indicated media type of the response, but any GraphQL
+ response with a non-null `data` key will provide a `2xx` response
diff --git a/src/pages/learn/subscriptions.mdx b/src/pages/learn/subscriptions.mdx
index cabc6cf180..3b1e0e11cc 100644
--- a/src/pages/learn/subscriptions.mdx
+++ b/src/pages/learn/subscriptions.mdx
@@ -2,17 +2,26 @@
import { Callout } from "nextra/components"
-<p className="learn-subtitle">Learn how to get real-time updates from a GraphQL server</p>
+<p className="learn-subtitle">
+ Learn how to get real-time updates from a GraphQL server
+</p>
-In addition to reading and writing data using stateless query and mutation operations, the GraphQL specification also describes how to receive real-time updates via long-lived requests. On this page, we'll explore how clients can subscribe to details of events on a GraphQL server using subscription operations.
+In addition to reading and writing data using stateless query and mutation
+operations, the GraphQL specification also describes how to receive real-time
+updates via long-lived requests. On this page, we'll explore how clients can
+subscribe to details of events on a GraphQL server using subscription
+operations.
<Callout type="info">
-Many of the features of GraphQL operations that apply to queries also apply to subscriptions, so review the [Queries](/learn/queries/) page first before proceeding.
+ Many of the features of GraphQL operations that apply to queries also apply to
+ subscriptions, so review the [Queries](/learn/queries/) page first before
+ proceeding.
</Callout>
## Subscribing to updates
-Subscription fields are defined exactly as `Query` and `Mutation` fields are, but using the `subscription` root operation type instead:
+Subscription fields are defined exactly as `Query` and `Mutation` fields are,
+but using the `subscription` root operation type instead:
```graphql
type Subscription {
@@ -20,7 +29,8 @@ type Subscription {
}
```
-Similarly, a subscription is initiated using the `subscription` keyword as the operation type:
+Similarly, a subscription is initiated using the `subscription` keyword as the
+operation type:
```graphql
subscription NewReviewCreated {
@@ -31,17 +41,36 @@ subscription NewReviewCreated {
}
```
-GraphQL subscriptions are typically backed by a separate pub/sub system so that messages about updated data can be published as needed during runtime and then consumed by the resolver functions for the subscription fields in the API.
+GraphQL subscriptions are typically backed by a separate pub/sub system so that
+messages about updated data can be published as needed during runtime and then
+consumed by the resolver functions for the subscription fields in the API.
-For the previous example, we could imagine publishing a `REVIEW_CREATED` message to a pub/sub system when a client submits a new review with the `createReview` mutation, and then listening for this event in the resolver function for the `reviewCreated` subscription field so that the server may send this data to subscribed clients.
+For the previous example, we could imagine publishing a `REVIEW_CREATED` message
+to a pub/sub system when a client submits a new review with the `createReview`
+mutation, and then listening for this event in the resolver function for the
+`reviewCreated` subscription field so that the server may send this data to
+subscribed clients.
<Callout type="info">
-Note that subscriptions are different from the concept of _live queries_, a loosely defined feature that some GraphQL implementations may offer. [Read more about the ongoing discussion on a formal specification for live queries here.](https://github.com/graphql/graphql-spec/issues/386)
+ Note that subscriptions are different from the concept of _live queries_, a
+ loosely defined feature that some GraphQL implementations may offer. [Read
+ more about the ongoing discussion on a formal specification for live queries
+ here.](https://github.com/graphql/graphql-spec/issues/386)
</Callout>
-As with query and mutation operations, GraphQL doesn't specify what transport protocol to use, so it's up to the server to decide. In practice, you will often see them implemented with WebSockets or server-sent events. Clients that want to send subscription operations will also need to support the chosen protocol. There are community-maintained specifications for implementing GraphQL subscriptions with [WebSockets](https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md) and [server-sent events](https://github.com/enisdenjo/graphql-sse/blob/master/PROTOCOL.md).
+As with query and mutation operations, GraphQL doesn't specify what transport
+protocol to use, so it's up to the server to decide. In practice, you will often
+see them implemented with WebSockets or server-sent events. Clients that want to
+send subscription operations will also need to support the chosen protocol.
+There are community-maintained specifications for implementing GraphQL
+subscriptions with
+[WebSockets](https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md)
+and
+[server-sent events](https://github.com/enisdenjo/graphql-sse/blob/master/PROTOCOL.md).
-One important distinction to make with subscription operations is that a document may contain a number of different subscription operations with different root fields, but each operation must have exactly one root field.
+One important distinction to make with subscription operations is that a
+document may contain a number of different subscription operations with
+different root fields, but each operation must have exactly one root field.
For example, this operation would be invalid:
@@ -79,24 +108,49 @@ subscription FriendListUpdated($id: ID!) {
}
```
-As with query and mutation operations, the document above contains multiple operations so each operation must be named, and the name of the operation to execute must be specified in the request.
+As with query and mutation operations, the document above contains multiple
+operations so each operation must be named, and the name of the operation to
+execute must be specified in the request.
## Using subscriptions at scale
-Subscription operations are a powerful feature of GraphQL, but they are more complicated to implement than queries or mutations because you must maintain the GraphQL document, variables, and other context over the lifetime of the subscription. These requirements can be challenging when scaling GraphQL servers horizontally because each subscribed client must be bound to a specific instance of the server.
-
-Similarly, client libraries will typically need more advanced features to handle these kinds of operations, such as logic to resubscribe to operations if the connection is disrupted or mechanisms to handle potential race conditions between initial queries and updated subscription data.
-
-In practice, a GraphQL API that supports subscriptions will call for a more complicated architecture than one that only exposes query and mutation fields. How this architecture is designed will depend on the specific GraphQL implementation, what pub/sub system supports the subscriptions, and the chosen transport protocol, as well as other requirements related to availability, scalability, and security of the real-time data.
-
-Subscription operations are well suited for data that changes often and incrementally, and for clients that need to receive those incremental updates as close to real-time as possible to deliver the expected user experience. For data with less frequent updates, periodic polling, mobile push notifications, or re-fetching queries based on user interaction may be the better solutions for keeping a client UI up to date.
+Subscription operations are a powerful feature of GraphQL, but they are more
+complicated to implement than queries or mutations because you must maintain the
+GraphQL document, variables, and other context over the lifetime of the
+subscription. These requirements can be challenging when scaling GraphQL servers
+horizontally because each subscribed client must be bound to a specific instance
+of the server.
+
+Similarly, client libraries will typically need more advanced features to handle
+these kinds of operations, such as logic to resubscribe to operations if the
+connection is disrupted or mechanisms to handle potential race conditions
+between initial queries and updated subscription data.
+
+In practice, a GraphQL API that supports subscriptions will call for a more
+complicated architecture than one that only exposes query and mutation fields.
+How this architecture is designed will depend on the specific GraphQL
+implementation, what pub/sub system supports the subscriptions, and the chosen
+transport protocol, as well as other requirements related to availability,
+scalability, and security of the real-time data.
+
+Subscription operations are well suited for data that changes often and
+incrementally, and for clients that need to receive those incremental updates as
+close to real-time as possible to deliver the expected user experience. For data
+with less frequent updates, periodic polling, mobile push notifications, or
+re-fetching queries based on user interaction may be the better solutions for
+keeping a client UI up to date.
## Next steps
To recap what we've learned about subscriptions:
-- GraphQL subscription operations can be used for incremental data updates via long-lived requests
-- Subscription operations are typically supported by a stateful transport protocol, so they will require more effort to implement and support than queries and mutations
-- Data-fetching use cases that require frequent and incremental updates to be streamed to a client are best suited for subscriptions
+- GraphQL subscription operations can be used for incremental data updates via
+ long-lived requests
+- Subscription operations are typically supported by a stateful transport
+ protocol, so they will require more effort to implement and support than
+ queries and mutations
+- Data-fetching use cases that require frequent and incremental updates to be
+ streamed to a client are best suited for subscriptions
-Now that we've covered all three operation types in GraphQL, let's explore how client requests are [validated](/learn/validation/) by a GraphQL server.
+Now that we've covered all three operation types in GraphQL, let's explore how
+client requests are [validated](/learn/validation/) by a GraphQL server.
diff --git a/src/pages/learn/thinking-in-graphs.mdx b/src/pages/learn/thinking-in-graphs.mdx
index bbbf3b3cb1..221d9b723e 100644
--- a/src/pages/learn/thinking-in-graphs.mdx
+++ b/src/pages/learn/thinking-in-graphs.mdx
@@ -4,20 +4,36 @@
> With GraphQL, you model your business domain as a graph
-Graphs are powerful tools for modeling many real-world phenomena because they resemble our natural mental models and verbal descriptions of the underlying process. With GraphQL, you model your business domain as a graph by defining a schema; within your schema, you define different types of nodes and how they connect/relate to one another. On the client, this creates a pattern similar to Object-Oriented Programming: types that reference other types. On the server, since GraphQL only defines the interface, you have the freedom to use it with any backend (new or legacy!).
+Graphs are powerful tools for modeling many real-world phenomena because they
+resemble our natural mental models and verbal descriptions of the underlying
+process. With GraphQL, you model your business domain as a graph by defining a
+schema; within your schema, you define different types of nodes and how they
+connect/relate to one another. On the client, this creates a pattern similar to
+Object-Oriented Programming: types that reference other types. On the server,
+since GraphQL only defines the interface, you have the freedom to use it with
+any backend (new or legacy!).
## Shared Language
> Naming things is a hard but important part of building intuitive APIs
-Think of your GraphQL schema as an expressive shared language for your team and your users. To build a good schema, examine the everyday language you use to describe your business. For example, let's try to describe an email app in plain English:
+Think of your GraphQL schema as an expressive shared language for your team and
+your users. To build a good schema, examine the everyday language you use to
+describe your business. For example, let's try to describe an email app in plain
+English:
- A user can have multiple email accounts
-- Each email account has an address, inbox, drafts, deleted items, and sent items
+- Each email account has an address, inbox, drafts, deleted items, and sent
+ items
- Each email has a sender, receive date, subject, and body
- Users cannot send an email without a recipient address
-Naming things is a hard but important part of building intuitive APIs, so take time to carefully think about what makes sense for your problem domain and users. Your team should develop a shared understanding and consensus of these business domain rules because you will need to choose intuitive, durable names for nodes and relationships in the GraphQL schema. Try to imagine some of the queries you will want to execute:
+Naming things is a hard but important part of building intuitive APIs, so take
+time to carefully think about what makes sense for your problem domain and
+users. Your team should develop a shared understanding and consensus of these
+business domain rules because you will need to choose intuitive, durable names
+for nodes and relationships in the GraphQL schema. Try to imagine some of the
+queries you will want to execute:
Fetch the number of unread emails in my inbox for all my accounts
@@ -50,26 +66,43 @@ fragment previewInfo on Email {
## Business Logic Layer
-> Your business logic layer should act as the single source of truth for enforcing business domain rules
+> Your business logic layer should act as the single source of truth for
+> enforcing business domain rules
-Where should you define the actual business logic? Where should you perform validation and authorization checks? The answer: inside a dedicated business logic layer. Your business logic layer should act as the single source of truth for enforcing business domain rules.
+Where should you define the actual business logic? Where should you perform
+validation and authorization checks? The answer: inside a dedicated business
+logic layer. Your business logic layer should act as the single source of truth
+for enforcing business domain rules.
-In the diagram above, all entry points (REST, GraphQL, and RPC) into the system will be processed with the same validation, authorization, and error handling rules.
+In the diagram above, all entry points (REST, GraphQL, and RPC) into the system
+will be processed with the same validation, authorization, and error handling
+rules.
### Working with Legacy Data
-> Prefer building a GraphQL schema that describes how clients use the data, rather than mirroring the legacy database schema.
+> Prefer building a GraphQL schema that describes how clients use the data,
+> rather than mirroring the legacy database schema.
-Sometimes, you will find yourself working with legacy data sources that do not perfectly reflect how clients consume the data. In these cases, prefer building a GraphQL schema that describes how clients use the data, rather than mirroring the legacy database schema.
+Sometimes, you will find yourself working with legacy data sources that do not
+perfectly reflect how clients consume the data. In these cases, prefer building
+a GraphQL schema that describes how clients use the data, rather than mirroring
+the legacy database schema.
-Build your GraphQL schema to express "how" rather than "what". Then you can improve your implementation details without breaking the interface with older clients.
+Build your GraphQL schema to express "how" rather than "what". Then you can
+improve your implementation details without breaking the interface with older
+clients.
## One Step at a time
> Get validation and feedback more frequently
-Don't try to model your entire business domain in one sitting. Rather, build only the part of the schema that you need for one scenario at a time. By gradually expanding the schema, you will get validation and feedback more frequently to steer you toward building the right solution.
+Don't try to model your entire business domain in one sitting. Rather, build
+only the part of the schema that you need for one scenario at a time. By
+gradually expanding the schema, you will get validation and feedback more
+frequently to steer you toward building the right solution.
-[^1]: ["Turtles all the way down"](https://en.wikipedia.org/wiki/Turtles_all_the_way_down) is an expression of the problem of infinite regress.
+[^1]:
+ ["Turtles all the way down"](https://en.wikipedia.org/wiki/Turtles_all_the_way_down)
+ is an expression of the problem of infinite regress.
diff --git a/src/pages/learn/validation.mdx b/src/pages/learn/validation.mdx
index 7d830c55a4..ed0868a5b1 100644
--- a/src/pages/learn/validation.mdx
+++ b/src/pages/learn/validation.mdx
@@ -1,18 +1,34 @@
# Validation
-<p className="learn-subtitle">Learn how GraphQL validates operations using a schema</p>
-
-On this page, we'll explore an important phase in the lifecycle of a GraphQL request called [validation](https://spec.graphql.org/draft/#sec-Validation). A request must be syntactically correct to run, but it should also be valid when checked against the API's schema.
-
-In practice, when a GraphQL operation reaches the server, the document is first parsed and then validated using the type system. This allows servers and clients to effectively inform developers when an invalid query has been created, without relying on runtime checks. Once the operation is validated, it can be [executed](/learn/execution/) on the server and a response will be delivered to the client.
+<p className="learn-subtitle">
+ Learn how GraphQL validates operations using a schema
+</p>
+
+On this page, we'll explore an important phase in the lifecycle of a GraphQL
+request called [validation](https://spec.graphql.org/draft/#sec-Validation). A
+request must be syntactically correct to run, but it should also be valid when
+checked against the API's schema.
+
+In practice, when a GraphQL operation reaches the server, the document is first
+parsed and then validated using the type system. This allows servers and clients
+to effectively inform developers when an invalid query has been created, without
+relying on runtime checks. Once the operation is validated, it can be
+[executed](/learn/execution/) on the server and a response will be delivered to
+the client.
## Validation examples
-The GraphQL specification describes the detailed conditions that must be satisfied for a request to be considered valid. In the sections that follow, we'll look at a few examples of common validation issues that may occur in GraphQL operations.
+The GraphQL specification describes the detailed conditions that must be
+satisfied for a request to be considered valid. In the sections that follow,
+we'll look at a few examples of common validation issues that may occur in
+GraphQL operations.
### Requesting non-existent fields
-When we query for a field, the field must be defined on the relevant type. As `hero` returns a `Character` type, its selection set may only request the `Character` type's fields; `Character` does not have a `favoriteSpaceship` field, so this query is invalid:
+When we query for a field, the field must be defined on the relevant type. As
+`hero` returns a `Character` type, its selection set may only request the
+`Character` type's fields; `Character` does not have a `favoriteSpaceship`
+field, so this query is invalid:
```graphql
# { "graphiql": true }
@@ -26,7 +42,11 @@ query {
### Selection sets and leaf fields
-Whenever we query for a field and it returns something other than a Scalar or Enum type, we need to specify what data we want to get back from the field (a "selection set"). The `hero` query field returns a `Character`, and we've already seen examples that request fields like `name` and `appearsIn` on it. If we omit those leaf field selections, then the query will not be valid:
+Whenever we query for a field and it returns something other than a Scalar or
+Enum type, we need to specify what data we want to get back from the field (a
+"selection set"). The `hero` query field returns a `Character`, and we've
+already seen examples that request fields like `name` and `appearsIn` on it. If
+we omit those leaf field selections, then the query will not be valid:
```graphql
# { "graphiql": true }
@@ -36,7 +56,8 @@ query {
}
```
-Similarly, querying fields of a scalar or enum doesn’t make sense, therefore adding a selection set to a leaf field will make the query invalid:
+Similarly, querying fields of a scalar or enum doesn’t make sense, therefore
+adding a selection set to a leaf field will make the query invalid:
```graphql
# { "graphiql": true }
@@ -52,7 +73,10 @@ query {
### Missing fragments for fields that output abstract types
-Earlier, it was noted that a query can only ask for fields on the type in question. So when we query for `hero` which returns a `Character`, we can only request fields that exist on the `Character` Interface type. What happens if we want to query for R2-D2's primary function, though?
+Earlier, it was noted that a query can only ask for fields on the type in
+question. So when we query for `hero` which returns a `Character`, we can only
+request fields that exist on the `Character` Interface type. What happens if we
+want to query for R2-D2's primary function, though?
```graphql
# { "graphiql": true }
@@ -65,7 +89,13 @@ query {
}
```
-That query is invalid, because `primaryFunction` is not one of the shared fields defined by the `Character` Interface type. We want some way of indicating that we wish to fetch `primaryFunction` if the `Character` is a `Droid`, and to ignore that field otherwise. We can use the [fragments](/learn/queries/#fragments) to do this. By setting up a fragment defined on `Droid` and including it in the selection set, we ensure that we only query for `primaryFunction` where it is defined:
+That query is invalid, because `primaryFunction` is not one of the shared fields
+defined by the `Character` Interface type. We want some way of indicating that
+we wish to fetch `primaryFunction` if the `Character` is a `Droid`, and to
+ignore that field otherwise. We can use the
+[fragments](/learn/queries/#fragments) to do this. By setting up a fragment
+defined on `Droid` and including it in the selection set, we ensure that we only
+query for `primaryFunction` where it is defined:
```graphql
# { "graphiql": true }
@@ -81,7 +111,11 @@ fragment DroidFields on Droid {
}
```
-This query is valid, but it's a bit verbose; named fragments were valuable above when we used them multiple times, but we're only using this one once. Instead of using a named fragment, we can use an [inline fragment](/learn/queries/#inline-fragments); this still allows us to indicate the type we are querying on, but without naming a separate fragment:
+This query is valid, but it's a bit verbose; named fragments were valuable above
+when we used them multiple times, but we're only using this one once. Instead of
+using a named fragment, we can use an
+[inline fragment](/learn/queries/#inline-fragments); this still allows us to
+indicate the type we are querying on, but without naming a separate fragment:
```graphql
# { "graphiql": true }
@@ -97,7 +131,8 @@ query {
### Cyclic fragment spreads
-To start, let's take a complex valid query. This is a nested query, but with the duplicated fields factored out into a fragment:
+To start, let's take a complex valid query. This is a nested query, but with the
+duplicated fields factored out into a fragment:
```graphql
# { "graphiql": true }
@@ -119,7 +154,10 @@ fragment NameAndAppearances on Character {
}
```
-The following is an alternative to the above query, attempting to use recursion instead of the explicit three levels of nesting. This new query is invalid because a fragment cannot refer to itself (directly or indirectly) since the resulting cycle could create an unbounded result!
+The following is an alternative to the above query, attempting to use recursion
+instead of the explicit three levels of nesting. This new query is invalid
+because a fragment cannot refer to itself (directly or indirectly) since the
+resulting cycle could create an unbounded result!
```graphql
# { "graphiql": true }
@@ -138,20 +176,37 @@ fragment NameAndAppearancesAndFriends on Character {
}
```
-This has just scratched the surface of the validation system; there are a number of validation rules in place to ensure that a GraphQL operation is semantically meaningful. The specification goes into more detail about this topic in the [validation section](https://spec.graphql.org/draft/#sec-Validation), and the [validation directory in the reference implementation](https://github.com/graphql/graphql-js/blob/main/src/validation) contains code implementing a specification-compliant GraphQL validator.
+This has just scratched the surface of the validation system; there are a number
+of validation rules in place to ensure that a GraphQL operation is semantically
+meaningful. The specification goes into more detail about this topic in the
+[validation section](https://spec.graphql.org/draft/#sec-Validation), and the
+[validation directory in the reference implementation](https://github.com/graphql/graphql-js/blob/main/src/validation)
+contains code implementing a specification-compliant GraphQL validator.
## Validation errors
-As we have seen in the examples above, when a GraphQL server encounters a validation error in a request, it will return information about what happened in the `errors` key of the response. Specifically, when GraphQL detects a validation issue in a document, it raises a _request error_ before execution begins, meaning that no partial data will be included in the response.
+As we have seen in the examples above, when a GraphQL server encounters a
+validation error in a request, it will return information about what happened in
+the `errors` key of the response. Specifically, when GraphQL detects a
+validation issue in a document, it raises a _request error_ before execution
+begins, meaning that no partial data will be included in the response.
-And because the GraphQL specification requires all implementations to validate incoming requests against the schema, developers won't need to write specific runtime logic to handle these validation issues manually.
+And because the GraphQL specification requires all implementations to validate
+incoming requests against the schema, developers won't need to write specific
+runtime logic to handle these validation issues manually.
## Next steps
To recap what we've learned about validation:
-- To be executed, requests must include a syntactically correct document that is considered valid when checked against the schema
-- The specification requires implementations check incoming requests contain valid field selections, correct fragment usage, and more
-- When a validation issue occurs, the server will raise a request error and return to the client information about what happened; field execution will not start
-
-Head over to the [Execution](/learn/execution/) page to learn how GraphQL provides data for each field in a request after the validation step successfully completes.
\ No newline at end of file
+- To be executed, requests must include a syntactically correct document that is
+ considered valid when checked against the schema
+- The specification requires implementations check incoming requests contain
+ valid field selections, correct fragment usage, and more
+- When a validation issue occurs, the server will raise a request error and
+ return to the client information about what happened; field execution will not
+ start
+
+Head over to the [Execution](/learn/execution/) page to learn how GraphQL
+provides data for each field in a request after the validation step successfully
+completes.
diff --git a/src/pages/tags/[slug].mdx b/src/pages/tags/[slug].mdx
index 46b8d7c772..1dc23f8ce2 100644
--- a/src/pages/tags/[slug].mdx
+++ b/src/pages/tags/[slug].mdx
@@ -15,14 +15,16 @@ export async function getStaticProps({ params }) {
}
export function getStaticPaths() {
- const items = getPagesUnderRoute("/blog").flatMap(item => item.children || item)
+ const items = getPagesUnderRoute("/blog").flatMap(
+ item => item.children || item
+ )
const tags = items.flatMap(item => item.frontMatter.tags)
return {
fallback: false,
- paths: [...new Set(tags)].map(slug => ({ params: { slug } })),
+ paths: [...new Set(tags)].map(slug => ({ params: { slug } }))
}
}
-import Blog from '../blog.mdx'
+import Blog from "../blog.mdx"
-<Blog/>
+<Blog />
diff --git a/src/pages/users.mdx b/src/pages/users.mdx
index d05affdcdb..68dd889ea5 100644
--- a/src/pages/users.mdx
+++ b/src/pages/users.mdx
@@ -2,15 +2,17 @@ import IframeResizer from "iframe-resizer-react"
# Who's using GraphQL?
-GraphQL is used by teams of all sizes in many different environments
-and languages to power mobile apps, websites, and APIs.
+GraphQL is used by teams of all sizes in many different environments and
+languages to power mobile apps, websites, and APIs.
Is your company using GraphQL?
-Please send a pull request to the [GraphQL Landscape](https://github.com/graphql/graphql-landscape) and follow [instructions](https://github.com/graphql/graphql-landscape#new-entries).
+Please send a pull request to the
+[GraphQL Landscape](https://github.com/graphql/graphql-landscape) and follow
+[instructions](https://github.com/graphql/graphql-landscape#new-entries).
<IframeResizer
- className="w-full mt-6"
+ className="mt-6 w-full"
src="https://landscape.graphql.org/card-mode?category=graph-ql-foundation-member&grouping=category&embed=yes&style=borderless"
heightCalculationMethod="lowestElement"
/>