我写了一个干净的应用程序，使用Next.js + 服务器端TypeScript + 函数构造器，并在 Advent Calendar 2022 的第13天分享了实现意图。我是在株式会社mofmof工作的shwld。

昨天我写了有关构建GraphQL服务器的要素的文章。

GraphQL 服务器的构成要素

┣━┳━ modules
┃ ┗━┳━ account // Entityなどに対応するオブジェクト単位でディレクトリをきっている
┃   ┣━┳━ mutation-resolvers
┃   ┃ ┗━┳━ account.create // アクションイベントごとにディレクトリを切る
┃   ┃   ┣━━━ create-account-validation.ts // バリデーションに関するロジック
┃   ┃   ┣━━━ create-account.sdl.graphql // このアクションのスキーマ定義
┃   ┃   ┣━━━ create-account.test.ts // テストロジック
┃   ┃   ┣━━━ create-account.ts // mutation本体
┃   ┃   ┗━━━ index.ts
┃   ┣━┳━ object-resolvers
┃   ┃ ┗━┳━ account // オブジェクトごとにディレクトリを切る
┃   ┃   ┣━━━ account.sdl.graphql // オブジェクトのスキーマ定義
┃   ┃   ┣━━━ account.ts // Entityをオブジェクトに変換するロジック
┃   ┃   ┗━━━ index.ts
┃   ┣━┳━ query-resolvers
┃   ┃ ┗━━━ .gitkeep // root queryはめったに生やさないので空なことが多いです
┃   ┗━ index.ts
┣━ middlewares // GraphQL Shieldなどを格納する場所

/使用情况/graphql解析器/源代码/模块

我們使用類似GraphQL Modules的方式來分隔和管理模組。

考虑要点

将考试放在处理旁边

只剔除测试并将其放置于处理函数旁边的常见模式，或者选择将其放在前端的常用方式，这是一个纠结的问题，但我选择了后者。因为如果修正处理函数，测试也会一同修正，反之亦然，个人而言，这样的开发体验更好。

在决定方面，尽管在层面的角度来看，我曾经有过将测试单独放入一个项目的想法，但我选择优先考虑了开发体验。
所以作为这个痛苦选择的结果，GraphQL解析器层面存在一个模糊点，即它包含了用于测试的依赖项（虽然是作为devDependencies添加，所以请谅解我这么做的意图）。

将模式定义集中在一个地方还是分散在各处？

type AccountEdge implements Edge {
  node: Account
  cursor: String
}

type AccountConnection implements Connection {
  pageInfo: PageInfo
  edges: [AccountEdge]
}

type Account implements Node {
  id: ID!
  createdAt: DateTime!
  updatedAt: DateTime!
  isDeleted: Boolean

  name: String!

  projects: ProjectConnection!
}

这是关于模式定义的样式。
目前，它散布在每个模块的每个元素中存在。
选择GraphQL解析器的制作方式是选择模式优先，但我觉得这与快速编码的方法相当接近。
（切割模块，定义元素，然后决定模式）

當然，由於後續使用plopjs進行程式碼生成（將在此日曆的其他文章中進一步介紹）的緣故，僅需使用yarn g:module命令一次即可在此目錄下一次性建立這個目錄結構和文件。這種配置使得我們可以同時保持基於局部模式定義的程式碼優勢和基於模式的編碼的好處（可能已經不太清楚在寫什麼了，但希望您能理解）。

下一次将会宣布

我明天会写关于“Relay Style页面导航”的内容。