はじめに

技育CampアドバンスVol.4にて、Graphqlを使用してリアルタイムでスキーマの共同編集を行えるアプリの開発を行いました。

そこで得た気づきや失敗談について書いていきます。
間違いがあればご指摘いただけると幸いです。

Graphqlの特徴

初めにGraphqlの特徴について軽く触れておきます

GraphQLでは、クライアントが必要なデータの構造を指定でき、サーバーは正確にその要求に応じたデータを返します。
これにより、過剰または不足なデータの取得を防ぐことができます。

伝統的なREST APIとは異なり、GraphQL APIは通常単一のエンドポイントを使用します。これによりAPIの設計がシンプルになり、エンドポイントの管理が容易になります。

GraphQLは強力な型システムを持っており、スキーマ定義によりAPIで利用可能な型やクエリを事前に定義できます。
これにより、APIの使用がより明確かつ安全になります。

GraphQLのサブスクリプションを使用すると、リアルタイムでデータの変更を購読することができます。

必要なデータのみを取得することにより、ネットワーク使用量を減らし、パフォーマンスを最適化することができます。

参考記事

今回作成したものの詳細です。
その共同編集部分だけ抜粋して紹介します。

エディター部分に独自のマークアップ言語を記述していくことでデータベースを定義できます。

これをもとにオブジェクトを出力したり、さまざまなsqlでのインポート、エクスポートが行えます
これらを共同編集でリアルタイムに行えるようにしました

((字句解析が死んでます....

発表時に使用したスライド🔽

今回、共同編集部分はこのような構成になっていました

PostEditor(Mutation)
dataが書きかわった時にバックエンドの情報を送信する

Save(Subscription)
dataの変更を検知して変更された際にdataを返す

このような通信を行なってリアルタイム共同編集を実現しています

当初私が考えていたフローは以下のような感じでした。

フロントエンドからeditorのデータを送信　
-> バックエンドで字句解析を行いjsonに整形して返す
-> 受け取ったjsonをそのまま使用してオブジェクトを生成

オブジェクト部分の定義
GraphQLは型の厳密さを重視しているため、標準スキーマ定義には、JSON型は含まれていません。

これに関しては、byte型での通信を行いそれをstring型にキャストしたりjsonに直すなどして対応しました。

大前提として、バックエンドとの話し合いがしっかりできいませんでした。

私が「字句解析はバックがやってくれる」と思い込んだまま進めてしまっていたのです...

これらが発覚したのがアドバンスの前日、朝方でした...
手の震えがとまらなかったです...

どちらの問題もコミュニケーション不足が原因ですね...
話合いは大事！！！
今後もう一度仕様を見直し、今度こそ完成させます。