はじめに
技育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をそのまま使用してオブジェクトを生成
問題1 json型での通信が不可能だった
オブジェクト部分の定義
GraphQLは型の厳密さを重視しているため、標準スキーマ定義には、JSON型は含まれていません。
これに関しては、byte型での通信を行いそれをstring型にキャストしたりjsonに直すなどして対応しました。
問題2 字句解析はフロントで行う想定だった。
大前提として、バックエンドとの話し合いがしっかりできいませんでした。
私が「字句解析はバックがやってくれる」と思い込んだまま進めてしまっていたのです...
これらが発覚したのがアドバンスの前日、朝方でした...
手の震えがとまらなかったです...
まとめ
どちらの問題もコミュニケーション不足が原因ですね...
話合いは大事！！！
今後もう一度仕様を見直し、今度こそ完成させます。