GraphQLって何?

周りはGraphQLの話をたくさん聞きました.プロジェクト発表と面接でGraphQLについて質問を受けました...この間ずっとプロジェクトをしていて、新しい技術を勉強する時間がありません.GraphQLが何なのか勉強しなければなりません.
GraphQL docsが提供してくれた「実習医」を真似する前に、まずコンセプトをつかむべきだと思います.ちょうどいいです!kakotechで整理したブログ記事を見つけました.
ココア技術リファレンスリンク
GraphQL(以下gql)は、フェイスブック上で作成されたクエリー言語で、デビューして間もない新しい友人であるが2016年から急激にユーザーが増加している.
上述したように、gqlはsqlと同様に、データを効率的に要求するための言語であるが、構造的に大きく異なり、使用目的も異なる.
sql文がデータベースから効率的にデータを取得するために使用される場合、gqlはWebクライアントがサーバから効率的なデータを取得するために作成したクエリー言語です.

sql:主にバックエンドシステムによって作成され、呼び出される

gql:クライアントシステム上で

を作成して呼び出す.
Webクライアントがサーバからデータを受信するクエリー言語?ここから概念が混同される.以前知っていたクエリー言語は、バックエンドサーバがクライアントリクエストを受信し、データベースにアクセスして適切なデータを検索するために使用されていました.クライアントにクエリーを記入しますか?
例を用いて既存のRestAPIと比較し,いくつかの疑問を少し解消した.

REST APIのどのような面を解決したいですか?

REST APIと比較すると、REST APIはURL、METHODなどを組み合わせているため、複数の端点が存在する.逆にgqlには端点が1つしかありません.
ソース:KakaoTechRest APIと比較

🤔 Rest APIには複数のEndpointがありますが、gqlには1つのEndpointしかありませんか?

既存のRestAPIメソッド論を使用してapiを設計する場合、必要なリソース(すなわち、クライアント上で必要なデータセット)に基づいて、各データセットに個別のエンドポイントが提供されます.最近行われたUFOプロジェクトのapiドキュメントを見てみましょう.

/free/post

/free/post/:post_id

/free/post/:post_id/view_count

/free/post/:post_id (delete)

/free/post/:post_id (put)

/free/post/:post_id/like

このようにして類似しているが異なるAPIが作成され、サービスがより大きくなると、管理が必要なエンドポイントはN(リソース)+1に増加する.

🤔 OverFetching & UnderFetching

既存のRestAPIでは「overfehing」と「Under ftching」の問題も存在する.例えば、以下のデータは、UFOプロジェクトがユーザ情報を要求したときに受信した値である.

{
ok: true,
result: {
user_id: 1,
email: "[email protected]",
nickname: "user1
password: "1234",
school_auth: null,
school_email: null,
country_id: null,
univ_id: null,
createdAt: "2021-07-26T10:35:39.000Z",
updatedAt: "2021-07-26T10:35:39.000Z",
university: null,
country: null
}}

何か問題がありますか?OverFetchingですユーザー情報が必要な部分もありますが、ログインユーザーのネット名を頭に表示するためにデータを要求する場合、ユーザーのネット名を使用するために他の不要なデータを受け取ることになります.

GraphQLによるデータ受信

逆にgqlではこのような取得問題は発生しない.データを要求する際に必要な情報を制御できます.

요청 쿼리
query{
	user(user:1){
    nickname
    }
}

반환 쿼리
{
"data":{
	"user":
    {
      "nickname: "jane",
    }
}

UnderFetchingもgqlで簡単に解決できます.特定のデータを取得する前に、underfetchinは複数のデータ要求を必要とします.

/feed/ --> /notify/ --> /user/1

このようにして重要な情報を受信するために、毎回複数のapi要求が連続的に呼び出される.単純なリクエストフェーズが多くなるという問題もありますが、非同期処理も難しくなります.

요청:
query {
 feed {
  comments
  likeNumber
 }
 notifications {
  isRead
 }
 user {
  username
  profilePit
 }
}

응답:
{
 feed: [
  {
   comments:1,
   likeNumber: 20
  }
 ],
 notifications: [
  {
    isRead: true
  },
 {
 ,....

逆に、gqlの利点は、1回のクエリが所望の情報を正確に受信できるため、複数のエンドポイントを必要とせずに複数のAPIを呼び出す必要がないことである.