<div id="readability-page-1" class="page"><article><div><div><div><a rel="noopener follow" href="/?source=post_page-----c843d81203e2--------------------------------"><div aria-hidden="false"><p><img alt="Wynn" src="https://miro.medium.com/v2/resize:fill:88:88/1*LLvV2_vpdgpdIae8DAVKcA.png" width="44" height="44" loading="lazy" data-testid="authorPhoto"></p></div></a></div><figure></figure><p id="cc70">Recently, our team adopted GraphQL schema. So, I decided to cover the benefits of using <code>graphql-codegen</code> in this context.</p><h2 id="401a">Before We Begin</h2><p id="47e7">when developing GraphQL APIs, there are two main methodologies: <strong>Code Frist and Schema First</strong></p><ul><li id="5d59"><strong>Code First</strong>: This approach places the Single source of Truth (SSOT) in the code. For example, in NestJS, the backend developer writes business logic with appropriate decorators, and upon successful compilation, the schema is generated based on the compiled source.</li><li id="8c51"><strong>Schema First</strong>: This method involves writing the Schema Definition Language (SDL) first and then generating types from the schema to ensure that the resolver returns responses that match the strict types defined.</li></ul><p id="84f4">Our team uses the Schema First approach. We chose this because it allows frontend and backend developers to discuss the schema in advance, reducing the cost of future changes. Additionally, our frontend team uses MSW (Mock Service Worker) to assist with development and testing, which further leverages the advantages of the Schema First method.</p><p id="6381">Personally, Schema First allows for pre-designing with business requirements in mind before writing code. It minimize dependency on the code itself, which can be beneficial.</p><p id="13cf">However, this doesn’t mean Code First is bad. For instance, NestJS provides the <code>@nestjs/graphql</code> module, which wraps Appolo Server and offers guides for both Code First and Schema First, although Code First is usually presented first in the documentation.</p><p id="d62d">A notable contributor in the NestJS community prefers the Code First approach. He believes that backend teams can focus solely on the code, leading to better Developer Experience than with Schema First. I agree that developing everything in a familiar programming language can improve productivity. Both approaches have their pros and cons, so choose the one that fits your team’s needs best.</p></div><div><h2 id="6c75">Why Do We Need GraphQL Code Generator?</h2><p id="09f1">Both Code First and Schema First approaches ultimately produce a GraphQL schema. But what can we do with it? Is it just for documentation?</p><p id="07a7">Of course not. Just as the JSON format in REST APIs is simple and intuitive, allowing for serialization/deserialization across the various languages, the GraphQL schema is similarly compatible. Its basic types resemble objects, and scalar types are common in many programming languages.</p><p id="cc68">By using GraphQL, we can strictly define the types of data exchanged between the client and server, minimizing runtime errors. Our team uses TypeScript for both the frontend and BFF servers. Many developers prefer TypeScript over JavaScript due to its static analysis capabilities, which catch errors early.</p></div><div><h2 id="cc69">Setting Up GraphQL Code Generator</h2><p id="ef3b">To generate types with <code>graphql-codegen</code> you first need a configuration file. Here’s how we set it up, along with brief explanations of each setting:</p><pre><span id="dba4">schema: "path/to/schema.graphql" # Specifies where to fetch the GraphQL schema from<br>documents: "src/**/*.graphql" # Files containing GraphQL queries to be processed<br>generates:<br>  src/generated/graphql.tsx:<br>    plugins:<br>      - "typescript"<br>      - "typescript-operations"<br>      - "typescript-react-apollo"</span></pre><ul><li id="bde5"><strong>schema</strong>: Specifies where to fetch the GraphQL schema from. It can be a server URL or a file path if managing client and server in a monorepo (e.g., <code>./typeDefs/*.graphql</code> )</li><li id="cf02"><strong>documents</strong>: indicates where to find the GraphQL query documents.</li><li id="2110"><strong>plugins</strong>: Lists the plugins to use for generating types.</li></ul><p id="88f5">Refer to the <a href="https://www.graphql-code-generator.com/docs/getting-started/installation" rel="noopener ugc nofollow" target="_blank">official documentation</a> for more details on configuration options.</p></div><div><h2 id="c1b7">Generating Types</h2><p id="ad6e">With the configuration file in place, run the GraphQL Code Generator CLI to generate the types:</p><pre><span id="221e">$ graphql-codegen</span></pre><p id="e42b">this command will generate the necessary TypeScript types from the GraphQL schema. You can then use these types in your React components, replacing any manually defined types.</p></div><div><h2 id="9d8b">Creating Custom Hooks</h2><p id="a8d2">Although using the generated types significantly improves type safety, fronten developers might prefer not to write GraphQL queries directly in <code>tsx</code> files. Instead, you can place your queries in <code>.graphql</code> files and have custom hooks generated automatically.</p><p id="90e2"><strong>Example post.graphql</strong></p><pre><span id="f6e9">query GetPost($id: ID!) {<br>  post(id: $id) {<br>    id<br>    title<br>    content<br>  }<br>}</span></pre><p id="7faa">Running the codegen command again will generate custom hooks based on these queries, thanks to the <code>writeHooks</code> option, which is enabled by default.</p><h2 id="7bdb">Using Generated Hooks</h2><p id="ff67">With custom hooks generated, you can simplify your components by using these hooks directly:</p><p id="d7ac"><strong>Example post.tsx</strong></p><pre><span id="5f97">import { useGetPostQuery } from './generated/graphql';<p>const Post = ({ id }) =&gt; {<br>  const { data, loading, error } = useGetPostQuery({ variables: { id } });</p><p>  if (loading) return &lt;p&gt;Loading...&lt;/p&gt;;<br>  if (error) return &lt;p&gt;Error: {error.message}&lt;/p&gt;;</p><p>  return (<br>    &lt;div&gt;<br>      &lt;h1&gt;{data.post.title}&lt;/h1&gt;<br>      &lt;p&gt;{data.post.content}&lt;/p&gt;<br>    &lt;/div&gt;<br>  );<br>};</p></span></pre><p id="fbf5">This approach eliminates the need for manualy type annotations, as TypeScript will automatically infer the types from the generated hooks. This reduces the risk of human error and saves time.</p><p id="fbef">Conclusion</p><p id="8ef8">Effectively using GraphQL requires overcoming a certain learning curve, especially if you’re accustomed to REST APIs. However, tools like <code>grapql-codegen</code> can significantly ease this transition by automating type generation, thereby improving developemnt efficiency and reducing errors.</p><p id="4ceb">Although GraphQL is not yet as widely adopted in some regions, its benefits make it worth considering for projects where strict type safety and efficient data fetching are critical.</p><p id="5775">Thank you for reading this long post. I hope it helps you in your GraphQL journey!</p></div></div></article></div>

Stories by Woosik Kim on Medium

Recently, our team adopted GraphQL schema. So, I decided to cover the benefits of using graphql-codegen in this context.
Before We Begin
when developing GraphQL APIs, there are two main methodologies: Code Frist and Schema First
Code First: This approach places the Single source of Truth (SSOT) in the code. For example, in NestJS, the backend developer writes business logic with appropriate decorators, and upon successful compilation, the schema is generated based on the compiled source.
Schema First: This method involves writing the Schema Definition Language (SDL) first and then generating types from the schema to ensure that the resolver returns responses that match the strict types defined.
Our team uses the Schema First approach. We chose this because it allows frontend and backend developers to discuss the schema in advance, reducing the cost of future changes. Additionally, our frontend team uses MSW (Mock Service Worker) to assist with development and testing, which further leverages the advantages of the Schema First method.
Personally, Schema First allows for pre-designing with business requirements in mind before writing code. It minimize dependency on the code itself, which can be beneficial.
However, this doesn’t mean Code First is bad. For instance, NestJS provides the @nestjs/graphql module, which wraps Appolo Server and offers guides for both Code First and Schema First, although Code First is usually presented first in the documentation.
A notable contributor in the NestJS community prefers the Code First approach. He believes that backend teams can focus solely on the code, leading to better Developer Experience than with Schema First. I agree that developing everything in a familiar programming language can improve productivity. Both approaches have their pros and cons, so choose the one that fits your team’s needs best.
Why Do We Need GraphQL Code Generator?
Both Code First and Schema First approaches ultimately produce a GraphQL schema. But what can we do with it? Is it just for documentation?
Of course not. Just as the JSON format in REST APIs is simple and intuitive, allowing for serialization/deserialization across the various languages, the GraphQL schema is similarly compatible. Its basic types resemble objects, and scalar types are common in many programming languages.
By using GraphQL, we can strictly define the types of data exchanged between the client and server, minimizing runtime errors. Our team uses TypeScript for both the frontend and BFF servers. Many developers prefer TypeScript over JavaScript due to its static analysis capabilities, which catch errors early.
Setting Up GraphQL Code Generator
To generate types with graphql-codegen you first need a configuration file. Here’s how we set it up, along with brief explanations of each setting:
schema: "path/to/schema.graphql" # Specifies where to fetch the GraphQL schema from
documents: "src/**/*.graphql" # Files containing GraphQL queries to be processed
generates:
  src/generated/graphql.tsx:
    plugins:
      - "typescript"
      - "typescript-operations"
      - "typescript-react-apollo"
schema: Specifies where to fetch the GraphQL schema from. It can be a server URL or a file path if managing client and server in a monorepo (e.g., ./typeDefs/*.graphql )
documents: indicates where to find the GraphQL query documents.
plugins: Lists the plugins to use for generating types.
Refer to the official documentation for more details on configuration options.
Generating Types
With the configuration file in place, run the GraphQL Code Generator CLI to generate the types:
$ graphql-codegen
this command will generate the necessary TypeScript types from the GraphQL schema. You can then use these types in your React components, replacing any manually defined types.
Creating Custom Hooks
Although using the generated types significantly improves type safety, fronten developers might prefer not to write GraphQL queries directly in tsx files. Instead, you can place your queries in .graphql files and have custom hooks generated automatically.
Example post.graphql
query GetPost($id: ID!) {
  post(id: $id) {
    id
    title
    content
  }
}
Running the codegen command again will generate custom hooks based on these queries, thanks to the writeHooks option, which is enabled by default.
Using Generated Hooks
With custom hooks generated, you can simplify your components by using these hooks directly:
Example post.tsx
import { useGetPostQuery } from './generated/graphql';
const Post = ({ id }) => {
  const { data, loading, error } = useGetPostQuery({ variables: { id } });
  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;
  return (
    <div>
      <h1>{data.post.title}</h1>
      <p>{data.post.content}</p>
    </div>
  );
};
This approach eliminates the need for manualy type annotations, as TypeScript will automatically infer the types from the generated hooks. This reduces the risk of human error and saves time.
Conclusion
Effectively using GraphQL requires overcoming a certain learning curve, especially if you’re accustomed to REST APIs. However, tools like grapql-codegen can significantly ease this transition by automating type generation, thereby improving developemnt efficiency and reducing errors.
Although GraphQL is not yet as widely adopted in some regions, its benefits make it worth considering for projects where strict type safety and efficient data fetching are critical.
Thank you for reading this long post. I hope it helps you in your GraphQL journey!
References
https://the-guild.dev/graphql/codegen

Using GraphQL Code Generator in React

댓글