Scribble at 2024-05-31 09:42:13 Last modified: 2024-05-31 10:54:05

これは付け焼き刃でデータベースをいじってるような SE レベルの人々が頻繁に混同して解説しているため、まず最初に注意しておきたいのだが、GraphQL は「グラフ型のデータベース」とは別のものである。GraphQL は API でデータベースを制御し、JSON でクエリや結果をやりとりするのだが、簡単に言えばプラットフォームに依存しない（プログラミング言語や DBMS にすら依存しない）API の仕様のことである。雑に言えば、個々の処理系で使われているデータベース用の抽象レイヤーと呼ばれるライブラリをプラットフォームに依存しないよう設計したものだと言ってもいいだろう。ということなので、処理系と DBMS のあいだにあるミドルウェアとして「サーバ」という扱いになっており、PHP や C# や Python や JavaScript や R といった多くの言語に対応していて、DBMS も従来のリレーショナルなデータベースだろうと NoSQL のデータベースだろうと、色々なバックエンドをサポートしている。

さて、上の記事は GraphQL という API の仕様に従ってクエリを投げたりデータを JSON で受け取るという、柔軟だがどう考えても効率は悪そうな仕様について議論されている。そして、僕はこの手の「ものごとを簡単にする」仕組みというものは、直感的に言って簡単になることと処理性能の低下とがトレード・オフになるだろうと考えているし、たぶん丁寧に教えたら小学生でも分かるような話だと思うから、やはり必要に応じて利用するというのが有効な接し方だろうと思う。なので、著者も手当たり次第に処理系と DMBS とを GraphQL だけで（常にサーバを介入させて）扱っていたわけではないと思うのだが、結論としてはあまりにも平凡な話であって、個々の非機能要件の議論は興味深いものがあるにせよ、エンジニアなりシステム・アーキテクトのスタンスとしては当然のことでしかないと思う。

あとね、こういう中間の仕組みがスタンダードになると、そこが肥大化してくる場合があって、簡単に言うと処理系と DBMS の運用方法なりプログラミングについての学習に加えて、更に大きな負荷がかかってしまう場合があるんだよね。典型的なことを言えば、僕は PHP や Python を既に習得していて、それから MySQL だけでなく標準的なリレーショナル・データベースのクエリを書ける。すると、PHP でデータベースにアクセスするにあたって、それらの技能に追加して GraphQL の仕様を覚えなくてはいけないという積極的な効用があるかというと、はっきり言って殆どないと思う。そして、僕はサーバに DBMS を自分でインストールして運用するレベルのエンジニアでもあるから、未知の DBMS をあてがわれて、それにアクセスして開発するために GraphQL を使えばいいと言われても、そんな仕事はしたくないと思う。仮に、トップ・クライアントから「これを使ってくれ」と Oracle やら SQL Server を指定されたとして、僕はこれらの十分な運用実績をもっていないのだが、運用実績のない DBMS を扱うために GraphQL を導入するかと言われると、それはないと思う。処理系が PHP なら、その案件で利用する DBMS に対応する抽象レイヤーのライブラリを使えばいいだけだと思ってしまうからだ。それらは、大手の DBMS であれば最初からモジュールとして提供されているため、php-fpm の実行に合わせてロードするように設定すれば、いわゆる密結合であるから性能面でも有利だと言える。