[Day 1: B-4] SQLQL は GraphQL にとって、何なのか


yhirano55
yhirano55 commented 4 months

登壇者: 小栁 真太

SQL を拗らせている人にとって、1 リクエストを 1 SQL で処理しきるというのは悲願でもあり、強い業(ごう)でもあります。

SQLQL というのは、API のエンドポイントに直接 SQL を送信すると、リクエスト毎の認可を反映した SQL に変換され、それの実行結果をレスポンスとして受け取るという概念です。欠点としては実行して欲しくない SQL 構文を無効化するサンドボックスを作るのが大変なことと、みんなが「すべてを一発で返せる SQL」を書きたいわけではない(書くのはちょっとだけ大変なので)ということと、多分それ以外にもたくさんあります。

一方、GraphQL は、みんなが書けるような簡単さを持っていて使いやすそうです。サーバーサイド実装での悩みがあるとしても、それは GraphQL という言語そのものの問題ではないでしょう。

では、GraphQL のサーバーサイド実装に SQLQL の考え方を取り入れてみたらどうなるか、という発想になるのは自然ですよね。

本講演では、もしも SQLQL の延長線上に GraphQL がいるのだとしたらこういう設計になる、という考えを実験した結果を発表します。


  • このセッションに関する質問を募集中です
  • 事前に聞きたいことがあれば、何でも書き込んでください。
  • 質問への回答はお約束できません。あらかじめご了承ください

Like(0)

Questions and feedbacks (4)

yancya
yancya commented 4 months

SQLQLを利用したRailsアプリとそうでないアプリとで開発時の感触の違いがあれば聞いてみたいです。

SQLQL の API を用意しておきさえすれば、あとはほぼ全てを呼び出す側から SQL で実装することが出来るので、フロントエンドとサーバーサイドを行ったり来たりしなくて済むのが嬉しいポイントです。GraphQL にも同じような特性があるとは思いますが、SQLQL の方が自由度が高いので、その特性が顕著なんじゃないかと思います(自由度が高い分、サンドボックス化するのが大変というトレードオフはあれど)

Like(1)

yancya
yancya commented 4 months

『SQLQL プログラミング』でやりたい事は凄くなるほどーと思ったのですが、それをサーバ内で完結せずにネットワーク越しにも実行したいモチベーションはどのあたりから来たんでしょうか?

基本的には、恐らく、普通の CRUD メインの WEB アプリケーション(OLTP)というより、BI ツールのような分析アプリケーション(OLAP)で生きてくる設計なんじゃないかと思っています。複雑な条件で集約関数を多用するような用途だと、できるだけ DB サーバー側で集約を終えておいて、受け取るデータ量を抑える方が全体のパフォーマンスやコードの簡潔さの面で有利になるのではないかと思っています。 それをふまえて、その考え方を OLTP っぽいアプリにも応用することで、何か役に立つ事があるんじゃないかという知的好奇心を元に取り組んでいます。

Like(1)

hshimoyama
hshimoyama commented 4 months

『SQLQL プログラミング』でやりたい事は凄くなるほどーと思ったのですが、それをサーバ内で完結せずにネットワーク越しにも実行したいモチベーションはどのあたりから来たんでしょうか?

Like(1)

colorbox
colorbox commented 4 months

SQLQLを利用したRailsアプリとそうでないアプリとで開発時の感触の違いがあれば聞いてみたいです。

Like(0)

Create Comment

Please sign in to comment.

Sign in with GitHub
This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano