Skip to content
GraphQL

GraphQL Updates- October 2021

Matthew Pagan

Matthew Pagan

Oct 20, 2021

5 min read

GraphQL

State of GraphQL

State of GraphQL brings together core contributors, members of the GraphQL Foundation, and community leaders to talk about the future of GraphQL, and answer audience questions.

Panelists

Sponsors

Shout-out to the sponsors of the event, StepZen and Moon Highway!

  • StepZen

    One GraphQL API. All Your Data. Zero Infrastructure.

StepZen is a GraphQL-as-a-Service provider, even including a FREE forever pricing tier with 300k calls/month included.

  • Moon Highway

    The cutting edge JavaScript training for engineers of all skill levels

Moon Highway is a training company that teaches a lot of courses centered around the JavaScript ecosystem.

Hosts

  • Tracy Lee, CEO, This Dot Labs
  • Eve Porcello, Co-founder & Instructor, Moon Highway

Panelists

GraphQL Updates

The first portion of the State of GraphQL covered updates from each panelist.

The GraphQL Foundation

One of the first topics covered by State of GraphQL was 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.

GraphQL.org

Uri opened up the conversation by emphasizing how open the foundation is. The GraphQL Foundation has always been open, but it's now easier than ever to become part of the community. The true "meat" of where the GraphQL action is though is in the GraphQL Working Group. There, topics such as changes to the GraphQL spec, ideas for new features, and more are discussed. Also, all the meetings are recorded and even summarized by text!

Apollo Odyssey

Odyssey is Apollo's free interactive learning platform.

Janessa from the Apollo team introduced us to Apollo Odyssey. Odyssey is Apollo's official learning platform. It was created to improve the developer experience of learning GraphQL. While some people may be able to learn effectively from docs, others may find different learning styles, like those offered by Odyssey, a more effective way of learning.

Courses offered range from the basics, like what are queries and resolvers, to the more advanced subjects, such as Apollo Federation.

Apollo Odyssey

Hasura

Tanmai from Hasura spoke next about updates done within Hasura. One of the biggest new features is support for cross-database joins over GraphQL. This update allows the developer to retrieve data from any number of data stores with efficient queries. The next thing being worked on now is end-to-end streaming.

PayPal

Joey Nenni of PayPal spoke about PayPal's experience with adopting GraphQL. He mentioned that once PayPal supported developers with tooling and sample apps, GraphQL spread like wildfire. Seeing the potential to do more with GraphQL, especially with sharing components, PayPal looked into Apollo Federation about 9 months ago, and as of about 2 weeks ago, they are now live with millions of requests already going through their gateway.

Joey also spoke about how GraphQL adoption is really about persistence. It's an iterative process. By making small steps, collecting small wins, and repeating that process, it becomes a lot easier to sell GraphQL. Joey coined the term "Guerilla Warfare" when it comes to finding successful implementations for GraphQL solutions.

GraphCMS

GraphCMS gives you instant GraphQL Content APIs to create, enrich, unify, and deliver your content across platforms.

GraphCMS recently hosted GraphQL Conf AND has recently raised $10 million in a Series A funding round. With all of this GraphQL focused momentum, GraphCMS is poising itself as a powerful solution for Headless CMS.

The ultimate content platform that enables you to deliver applications at scale.

Carlos Rufo

Defer and Stream

One important piece of information that Uri brought to the groups' attention was that defer, stream, live queries, and other features in spec proposals, but not in the actual spec, CAN BE USED SAFELY. Uri noticed a patter in production settings: once people have been given the option to use these new features, like defer, they see how valuable those features can be.

If you want to see more information involving these GraphQL directives, you can check out a blog post covering them here.

The Defer Directive

Apollo Federation

Implement a single graph across multiple services

Apollo Documentation

One very popular subject that is commonly brought up in Apollo conversations is Apollo Federation, and the idea of having a unified Graph connecting many services.

For PayPal, they spoke about the experiences encountered while transitioning some of their shared logic to a federated graph, while maintaining developer experience.

Apollo itself had a very positive experience using Apollo Federation. They ran into the need to unite two services, one written in Kotlin, and one in TypeScript, and have them run under a single gateway. This was a very big win and prevented the need for developers to learn additional languages to support a larger graph.

Tanmai had a balanced perspective on Apollo Federation:

Are we federating how the API comes together and presents itself? Or are we federating the execution itself?

He shared his experiences with analyzing where exactly a federated graph could be a good fit.

For Uri, he spoke about how the most important question is, "Are we actually making the product development faster?" Adopting Apollo Federation may give a different answer depending on the team and work being done.

Conclusion

GraphQL is still growing rapidly, and as shown in this State of GraphQL, there is a growing thriving community surrounding it. Continue the conversation, no matter your experience level, and check out the GraphQL Working Group. While this was a quick summary of the things spoken about during the State of GraphQL, you can catch the whole video on YouTube.

Thank you for enjoying the State of GraphQL!

This Dot Labs is a development consultancy that is trusted by top industry companies, including Stripe, Xero, Wikimedia, Docusign, and Twilio. This Dot takes a hands-on approach by providing tailored development strategies to help you approach your most pressing challenges with clarity and confidence. Whether it's bridging the gap between business and technology or modernizing legacy systems, you’ll find a breadth of experience and knowledge you need. Check out how This Dot Labs can empower your tech journey.

Author Matthew Pagan

Matthew Pagan

@mastapegs@mastapegs

You might also like

Leveraging GraphQL Scalars to Enhance Your Schema cover image

Leveraging GraphQL Scalars to Enhance Your Schema

Introduction GraphQL has revolutionized the way developers approach application data and API layers, gaining well-deserved momentum in the tech world. Yet, for all its prowess, there's room for enhancement, especially when it comes to its scalar types. By default, GraphQL offers a limited set of these primitives — Int, Float, String, Boolean, and ID — that underpin every schema. While these types serve most use cases, there are scenarios where they fall short, leading developers to yearn for more specificity in their schemas. Enter graphql-scalars, a library designed to bridge this gap. By supplementing GraphQL with a richer set of scalar types, this tool allows for greater precision and flexibility in data representation. In this post, we'll unpack the potential of enhanced Scalars, delve into the extended capabilities provided by graphql-scalars, and demonstrate its transformative power using an existing starter project. Prepare to redefine the boundaries of what your GraphQL schema can achieve. Benefits of Using Scalars GraphQL hinges on the concept of "types." Scalars, being the foundational units of GraphQL's type system, play a pivotal role. While the default Scalars — Int, Float, String, Boolean, and ID — serve many use cases, there's an evident need for more specialized types in intricate web development scenarios. 1. Precision**: Using default Scalars can sometimes lack specificity. Consider representing a date or time in your application with a String; this might lead to ambiguities in format interpretation and potential inconsistencies. 2. Validation**: Specialized scalar types introduce inherent validation. Instead of using a String for an email or a URL, for example, distinct types ensure the data meets expected formats at the query level itself. 3. Expressiveness**: Advanced Scalars provide clearer intentions. They eliminate ambiguity inherent in generic types, making the schema more transparent and self-explanatory. Acknowledging the limitations of the default Scalars, tools like graphql-scalars have emerged. By broadening the range of available data types, graphql-scalars allows developers to describe their data with greater precision and nuance. Demonstrating Scalars in Action with Our Starter Project To truly grasp the transformative power of enhanced Scalars, seeing them in action is pivotal. For this, we'll leverage a popular starter kit: the Serverless framework with Apollo and Contentful. This kit elegantly blends the efficiency of serverless functions with the power of Apollo's GraphQL and Contentful's content management capabilities. Setting Up the Starter: 1. Initialize the Project: `shell npm create @this-dot/starter -- --kit serverless-framework-apollo-contentful ` 2. When prompted, name your project enhance-with-graphql-scalars`. `shell Welcome to starter.dev! (create-starter) ✔ What is the name of your project? … enhance-with-graphql-scalars > Downloading starter kit... ✔ Done! Next steps: cd enhance-with-graphql-scalars npm install (or pnpm install, yarn, etc) ` 3. For a detailed setup, including integrating with Contentful and deploying your serverless functions, please follow the comprehensive guide provided in the starter kit here. 4. And we add the graphql-scalars` package `shell npm install graphql-scalars ` Enhancing with graphql-scalars: Dive into the technology.typedefs.ts` file, which is the beating heart of our GraphQL type definitions for the project. Initially, these are the definitions we encounter: `javascript export const technologyTypeDefs = gql type Technology { id: ID! displayName: String! description: String url: URL } type Query { "Technology: GET" technology(id: ID!): Technology technologies(offset: Int, limit: Int): [Technology!] } type Mutation { "Technology: create, read and delete operations" createTechnology(displayName: String!, description: String, url: String): Technology updateTechnology(id: ID!, fields: TechnologyUpdateFields): Technology deleteTechnology(id: ID!): ID } input TechnologyUpdateFields { "Mutable fields of a technology entity" displayName: String description: String url: String } ; ` Our enhancement strategy is straightforward: Convert the `url` field from a String to the `URL` scalar type, bolstering field validation to adhere strictly to the URL format. Post-integration of graphql-scalars`, and with our adjustments, the revised type definition emerges as: `javascript export const technologyTypeDefs = gql type Technology { id: ID! displayName: String! description: String url: URL } type Query { "Technology: GET" technology(id: ID!): Technology technologies(offset: Int, limit: Int): [Technology!] } type Mutation { "Technology: create, read and delete operations" createTechnology(displayName: String!, description: String, url: URL): Technology updateTechnology(id: ID!, fields: TechnologyUpdateFields): Technology deleteTechnology(id: ID!): ID } input TechnologyUpdateFields { "Mutable fields of a technology entity" displayName: String description: String url: URL } ; ` To cap it off, we integrate the URL` type definition along with its resolvers (sourced from `graphql-scalars`) in the `schema/index.ts` file: `javascript import { mergeResolvers, mergeTypeDefs } from '@graphql-tools/merge'; import { technologyResolvers, technologyTypeDefs } from './technology'; import { URLResolver, URLTypeDefinition } from 'graphql-scalars'; const graphqlScalars = [URLTypeDefinition]; export const typeDefs = mergeTypeDefs([...graphqlScalars, technologyTypeDefs]); export const resolvers = mergeResolvers([{ URL: URLResolver }, technologyResolvers]); ` This facelift doesn't just refine our GraphQL schema but infuses it with innate validation, acting as a beacon for consistent and accurate data. Testing in the GraphQL Sandbox Time to witness our changes in action within the GraphQL sandbox. Ensure your local server is humming along nicely. Kick off with verifying the list query: ` query { technologies { id displayName url }, } ` Output: `json { "data": { "technologies": [ { "id": "4UXuIqJt75kcaB6idLMz3f", "displayName": "GraphQL", "url": "https://graphql.framework.dev/" }, { "id": "5nOshyir74EmqY4Jtuqk2L", "displayName": "Node.js", "url": "https://nodejs.framework.dev/" }, { "id": "5obCOaxbJql6YBeXmnlb5n", "displayName": "Express", "url": "https://www.npmjs.com/package/express" } ] } } ` Success! Each url` in our dataset adheres to the pristine URL format. Any deviation would've slapped us with a format error. Now, let's court danger. Attempt to update the url` field with a _wonky_ format: ` mutation { updateTechnology(id: "4UXuIqJt75kcaB6idLMz3f", fields: { url: "aFakeURLThatShouldThrowError" }) { id displayName url } } ` As anticipated, the API throws up a validation roadblock: `json { "data": {}, "errors": [ { "message": "Expected value of type \"URL\", found \"aFakeURLThatShouldThrowError\"; Invalid URL", "locations": [ { "line": 18, "column": 65 } ], "extensions": { "code": "GRAPHQLVALIDATION_FAILED", "stacktrace": [ "TypeError [ERRINVALID_URL]: Invalid URL", " at new NodeError (node:internal/errors:399:5)", " at new URL (node:internal/url:560:13)", ... ] } } ] } ` For the final act, re-run the initial query to reassure ourselves that the original dataset remains untarnished. Conclusion Enhancing your GraphQL schemas with custom scalars not only amplifies the robustness of your data structures but also streamlines validation and transformation processes. By setting foundational standards at the schema level, we ensure error-free, consistent, and meaningful data exchanges right from the start. The graphql-scalars` library offers an array of scalars that address common challenges developers face. Beyond the `URL` scalar we explored, consider diving into other commonly used scalars such as: **DateTime**: Represents date and time in the ISO 8601 format. **Email**: Validates strings as email addresses. **PositiveInt**: Ensures integer values are positive. **NonNegativeFloat**: Guarantees float values are non-negative. As a potential next step, consider crafting your own custom scalars tailored to your project's specific requirements. Building a custom scalar not only offers unparalleled flexibility but also provides deeper insights into GraphQL's inner workings and its extensibility. Remember, while GraphQL is inherently powerful, the granular enhancements like scalars truly elevate the data-fetching experience for developers and users alike. Always evaluate your project's needs and lean into enhancements that bring the most value. To richer and more intuitive GraphQL schemas!...

Nov 8, 2023

4 mins

GraphQL
Class and Enum Typings for Handling Data with GraphQL cover image

Class and Enum Typings for Handling Data with GraphQL

Intro Today we’ll talk about class and enum typings for handling more complex data with GraphQL. The typings will be used on class objects to make them easier to read and understand. This blog will build on the concepts of another blog found here, in which I discussed wrapping and enhancing data, which talks about how to create a GraphQL Rest API wrapper, and how to enhance your data. This article assumes you have a basic understanding of classes, typing, and enums. Here is the code repo if you want to review it while reading, or just skip ahead. With that said, we will look at the class structure we’re going to be using, the enums, and the type lookup for our customField enum with our mapper. Class setup This class we’re going to set up will be strictly for typing. We’re going to make a RestaurantGuest class as this data will be restaurant themed. So in our restaurant.ts file, we will name it RestaurantGuest, and include a few different items. __Basic starting class example__* ` class RestaurantGuest { id!: number; name!: string; email!: string; phoneNumber!: string; / foodReservation */ 3249258!: { id: number, value: string } | undefined; } ` After setting that up, we will add a type that will reference the above class. __Type example__* ` type RestaurantGuestResponse= { [g in keyof RestaurantGuest ]: RestaurantGuest [g]; }; ` This type will be used later when we do the type lookup in conjunction with our mapper function. With the above finished, we can now move on to handling our enums. Handling enums We’ll now create our Enum to make dealing with our complex data easier. Since the above 3249258 represents FoodReservation, we will create an enum for it. Now you might be wondering why 3249258 represents FoodReservation. Unfortunately, this is an example of how data can be returned to us from a call. It could be due to the field id established in a CMS such as Contentful, or from another source that we don’t control. This isn’t readable, so we’re creating an Enum for the value. __Enum example__* ` export enum FoodReservation { 'Yes' = 53425867, 'No' = 53425868, } ` This will be used later during our type look-up. Type lookup Now we can start combining the enum from above with our class type, and a look-up type that we’re about to create. So let's make another type called RestaurantGuestFieldLookup, which will have an id and value. __Look-up type example__* ` export type RestaurantGuestFieldLookup = { id: TId; value: TValue; }; ` Perfect, now we’ll swap out ` 3249258?: {id: number, value: string} | undefined; ` to be ` 3249258?: RestaurantGuestFieldLookup; ` We can now move on to creating and using our mapper. In a separate file called mapper.ts, we will create our restaruantGuestMapper function. ` export const restaruantGuestMapper = (guest: RestaurantGuestResponse) => { if (!guest) { return null; } return { id: guest.id, name: guest.name, phoneNumber: guest.phoneNumber, email: guest.email, reservation: guest.3249258.id === FoodReservation.Yes, }; }; ` Tada! Thanks to all the work above, we can easily understand and get back the data we need. Conclusion Today's article covered setting up a typing class, creating an enum, and type lookup with a mapper for more complex data handling with GraphQL. Hopefully, the class structure was straightforward and helpful, along with the enums and type lookup and formatting examples. If you want to learn more about GraphQL, read up on our resources available at graphql.framework.dev....

May 26, 2023

2 mins

GraphQL
React Contributor Days cover image

React Contributor Days

React Contributor Days React Contributor Days was a chance for core React maintainers and contributors to come together and talk about the future of React. From discussions on the future of React with React 18 to discussing core web vitals, this was a chance for experts in the React community to come together, and have an open discussion about the state of the framework. Panelists and Hosts Here were the panelists who joined us for React Contributor Days: - Romello Goodman, @mellogood - Colby Fayock, @colbyfayock - Brandon Bayer, @flybayer - Lenz Weber, @phry - Evan Bacon, @Baconbrix - Jen Luker, @knitcodemonkey - Debbie O'Brien, @debsobrien - Cassidy Williams, @cassidoo - Chantastic, @chantastic - Ben Ilegbodu, @benmvp - James Quick, @jamesqquick - Ryan Burgess, @burgessdryan - Katherine Peterson, @katherinecodes - Tomek Sułkowski, @sulco - Ward Peeters, @wardpeet - Megan Sullivan, @meganesulli - Johnny Burger, @JNYBGR Hosting the Event: - Tracy Lee, @ladyleet - Shaundai Person, @shaundai The React Working Group The React Working Group was one of the biggest takeaways from React Contributor Days. This discussion was born out of an attempt to be as open and inclusive to the ideas and needs of the React community regarding React 18. In the React Working Group, there are brilliant discussions for developers to contribute to: - Explain it to me like I'm 5: A discussion geared towards defining terms used in other discussions. - Introducing React 18: The very first post in the Working Group. - Installing React 18 Alpha: A post introducing users to React 18 Alpha, along with the npm command to install it One thing stressed during contributor days was the importance of including as many voices in the working group as possible. A specific effort was made NOT to include some of the more well-known names in React to ensure the voices of others have a chance to be heard. Click on the link, and check out the React Working Group right now! How to upgrade to React 18 on the Client Here is the post in the Working Group which talks about upgrading to React v18. Since it's pretty quick, I want to include a few of their code snippets here as an additional reference. There are 2 main steps to upgrading to v18: - Install the latest React 18 release - Switch to the new root API Use the following command to install React 18. npm install react@alpha react-dom@alpha` To use the new root API, find the line of code that renders the application component to the DOM. It should look similar to this: `javascript ReactDOM.render(, container); ` Replace that with this: `javascript const root = ReactDOM.createRoot(container); root.render(); ` Check out the discussion for more details! Core Web Vitals Shaundai Person set off the discussion by asking the question, "What are Core Web Vitals, and how does it relate to web performance?" Kristofer Baxter responds, "Core Web Vitals are a set of metrics that were created to try and find a common way to define page experience type metrics across the web." The most common theme among the questions was user experience, and the idea that we develop on machines much more powerful than the average user device. Here were some quotes from a few panelists when they were asked about performance: On the subject of testing web performance: > "Slow everything down" > -- Lenz Weber On the subject of where a developer can start with web performance: > "The generic advice is to start simple. Load your document with emulated slow settings in your local environment. Those emulated slow settings allow you to see things that you normally wouldn't see because your hardware is so powerful. See what your user sees on a lower-end device." > "See what users see, and your metrics will follow." > -- Kristofer Baxter Kristofer went on into more detail on where a developer can start with tackling web vitals. Check out the rest of his details here. Conclusion React Contributor Days allowed maintainers and developers to come together and drive discussion around the growth of React. If you still haven't had the chance to listen to the whole thing, it's jam-packed with more information and advice, suitable for every React dev. Take some time to watch their talk, and visit the React Working Group to stay up-to-date on all things React 18!...

Sep 23, 2021

4 mins

React
Being a CTO at Any Level: A Discussion with Kathy Keating, Co-Founder of CTO Levels cover image

Being a CTO at Any Level: A Discussion with Kathy Keating, Co-Founder of CTO Levels

In this episode of the engineering leadership series, Kathy Keating, co-founder of CTO Levels and CTO Advisor, shares her insights on the role of a CTO and the challenges they face. She begins by discussing her own journey as a technologist and her experience in technology leadership roles, including founding companies and having a recent exit. According to Kathy, the primary responsibility of a CTO is to deliver the technology that aligns with the company's business needs. However, she highlights a concerning statistic that 50% of CTOs have a tenure of less than two years, often due to a lack of understanding and mismatched expectations. She emphasizes the importance of building trust quickly in order to succeed in this role. One of the main challenges CTOs face is transitioning from being a technologist to a leader. Kathy stresses the significance of developing effective communication habits to bridge this gap. She suggests that CTOs create a playbook of best practices to enhance their communication skills and join communities of other CTOs to learn from their experiences. Matching the right CTO to the stage of a company is another crucial aspect discussed in the episode. Kathy explains that different stages of a company require different types of CTOs, and it is essential to find the right fit. To navigate these challenges, Kathy advises CTOs to build a support system of advisors and coaches who can provide guidance and help them overcome obstacles. Additionally, she encourages CTOs to be aware of their own preferences and strengths, as self-awareness can greatly contribute to their success. In conclusion, this podcast episode sheds light on the technical aspects of being a CTO and the challenges they face. Kathy Keating's insights provide valuable guidance for CTOs to build trust, develop effective communication habits, match their skills to the company's stage, and create a support system for their professional growth. By understanding these key technical aspects, CTOs can enhance their leadership skills and contribute to the success of their organizations....

Dec 5, 2023

2 mins

Engineering Leadership