docs(blog): add runtime example

uhyo · Oct 9, 2023 · 30cd084 · 30cd084
1 parent 93c7184
commit 30cd084
Showing 1 changed file with 50 additions and 4 deletions.
diff --git a/website/src/app/blog/_articles/release-1.3.tsx b/website/src/app/blog/_articles/release-1.3.tsx
@@ -96,6 +96,51 @@ export default new GraphQLSchema({
         <code>extensions.codegenScalarType</code> metadata. We are not aware of
         any other libraries that provide such metadata though.
       </p>
+      <p>
+        At runtime, you should reuse the <code>GraphQLSchema</code> instance you
+        supplied to nitrogql. To do so, merge that instance with the other parts
+        of your schema and your resolver implementations.{" "}
+        <a
+          href="https://www.npmjs.com/package/@graphql-tools/schema"
+          target="_blank"
+        >
+          @graphql-tools/schema
+        </a>{" "}
+        provides a convenient way to do so. For example:
+      </p>
+      <Highlight language="typescript">
+        {`import { mergeSchemas } from "@graphql-tools/schema";
+
+// GraphQLSchema object for scalars
+import schema from "../../schema/scalar";
+
+// Generated by nitrogql
+import { schema as typeDefs } from "@/generated/graphql";
+import { Resolvers } from "@/generated/resolvers";
+
+type Context = {};
+const resolvers: Resolvers<{}> = {
+  // ...
+};
+
+const server = new ApolloServer({
+  schema: mergeSchemas({
+    schemas: [schema],
+    typeDefs,
+    resolvers,
+  }),
+});`}
+      </Highlight>
+      <p>
+        See{" "}
+        <a
+          href="https://github.com/uhyo/nitrogql/tree/master/examples/nextjs"
+          target="_blank"
+        >
+          our Next.js example
+        </a>{" "}
+        for a working example.
+      </p>
 
       <h3 id="conclusion">Conclusion</h3>
 
@@ -107,10 +152,11 @@ export default new GraphQLSchema({
       </p>
 
       <p>
-        Having a single source of truth for custom scalar types is always a good
-        thing. It is good idea for libraries to provide such metadata so that
-        the runtime implementation and the TypeScript type definition are always
-        in sync. This release is a significant step towards that direction.
+        Having a single source of truth is always preferable. Custom scalar
+        types are no exception. Therefore, it is good idea for libraries to
+        provide such metadata so that the runtime implementation and the
+        TypeScript type definition are always in sync. This release is a
+        significant step towards that direction.
       </p>
 
       <hr />