でぃするだいありー?

そんな気はないんだれど、でぃすっちゃってる。 でぃすでれ?

GraphQL備忘録 Pagination編

GraphQLについて実装サンプルから入り、概念的なものについて学んでおらず、そのまま今、活用するケースについて考えている。

目にしていても理解していなかったのだが、数例をこなすうちにGraphQLのクエリにもいろいろあり、Paginationをサポートする形式もあると悟ったことがきっかけだ。

WEB APIは実務経験がなく、数年前から私的に試しているくらいで世間の時流に乗れていない。Paginationの意味は漠然と知っていても実装について全く考えが及ばない。
そんな立場から、GraphQLにPaginationが必要かどうか、検討してみようと思い至った。

Python django

djangoがPagination対応で、GraphQLと無縁に機能する。
graphene_djangoでPagination対応クエリを実装した(grapheneのConnectionを使用)が、遅い。公式のサンプルを参考に実装したのだが、他にやり方があるのかもしれない。
対照として、ORMにSQLAlchemyを使用した非djangoのgraphene_sqlalchemyでPaginationを実装した(SQLAlchemyConnectionField)が、こちらは非常に高速である。
2019/11/15追記:
GraphQLは使用せず、クライアント側で無限スクロール機能を試行した。djangoでの実装となったが、無限スクロールは jquery.infinitescroll.min.js による。
下記railsでの実装経験によって勘所を得ていたため問題の解決がはかどったが、django の設定やモノの配置にはやはり悩まされた。参考にした実装例は不完全な抜粋であるか、コピペによって動作しないコードになってしまったかで動かず、noobにはキツい仕打ちとなった。
WebプログラミングはCによるCGIの時代はまあ好きで、PerlによるHTML生成の時代に嫌いになり、Javascriptの緩さがどうにも慣れないというか好ましく思えないまま現在に至るが、今回改めてそれを痛感した次第。Javascript のタグドリブンなカンジがGOTO文を想起させるからかもしれない。

Ruby on Rails

railsがPagination対応で、GraphQLとは無縁に機能する。
GraphQLのPagination対応クエリは高速である。
2019/11/14追記:
GraphQLは使用せず、クライアント側で無限スクロール機能を試行した。kaminari と pagy を使用したが、pagy の方が高速という評を受けており、その通りであった。
rails に限らずではあると思うが、フレームワークは覚えることが多く、また、Webで公開されているサンプルは環境について多く語ってはおらず、またバージョンの壁もあり、容易に再現・流用できない。今回は webpacker と turbolinks と jquery のコンボが大きな障害となった。

まとめ

データが自前なサービスで、フレームワークを使用しているなら、GraphQLにPaginationは不要という印象である。上記二例とも、特に低速だとは感じない(17000件程度のデータを10件ずつ表示する例において)。ラズパイでも問題なく特に不可もなく動作している。
データを提供する場合は負荷減少のためにあったほうがよかろうという印象である。