今日の内容は、Hasuraの認証回りの設定と、今後のリリース方針についての相談です。今回から新しいお友達が参加しました。Aizackさんです。今回新刊としてHeroku本を書いてらっしゃるというまさかのタイムリーさで、なにとぞーという感じで参加です。いらっしゃいませありがとうございます。
セキュリティ上の観点からConsoleにアクセス制限をつけたところ、未認証ユーザーも見れなくなってしまいました。そこで今日は最初にHasuraの権限回りを整理します。
認証ユーザーにはAuth0などを使って適切な権限をつける必要もありますが、未認証ユーザーにも適切な権限（例えば読み取りのみ）をつける必要があります。
SettingsのConfig varsに環境変数を追加します。
key: HASURA_GRAPHQL_UNAUTHORIZED_ROLE
value: anonymous
次に、Permissionを設定します。
テーブルの中のprofileを開き、ここにPermissionを設定します。
Enter new roleに先ほど設定したanonymousを入力し、読み取り権限であるselectを追加します。
今はidとnameしかありませんが、この後様々なキーが追加されたときに、必要な項目だけに権限をつけるといったことができるはずです。
挙動確認のためにパーミッションを変更してみます。たとえばidは読めますがnameを読めなくしてみましょう。
この時は、クライアント側でエラーが出ますので、正しい挙動です。
確認したら、パーミッションは戻しておきましょう。Vercelにデプロイしてあるページのテストページでデータが呼び出せることを確認して、完成です。さっくりできましたね。
ここで少し、認証回りの話になります。日本で比較的よくつかわれているのはFirebase AuthenticationやAuth0で、このどちらかがよさそうですね、ということで落ち着きます。他にも認証プロバイダはありますが、機能や求めるものによりますがどちらも問題なさそうです。値段に関してはFirebase Authenticationの方が安そうですが、Auth0のフリーでもそこそこ使えそう、だけどちゃんと調べてみましょう、という状況です。
Firebase AuthenticationであろうとAuth0であろうと、Roleを作ってくれるわけではないので、Hasuraの方で様々な条件を作っていくのでしょう。また、データ書き込みはまだできていませんので、アプリ側で認可を実装する必要があります。
とはいえ、まずは、先週の課題解決おめでとうございます！
今回のように、Hasura+GraphQLをHerokuにデプロイするといった実装例を探す際には公式ドキュメントを読むのも良いですが、Youtubeでの情報収集が意外と役に立ちます。
実は、Herokuも下記のような公式Youtubeチャネル1を持っており、今回のアーキテクチャの実装例は日本語の動画が公式からアップロードされています。
今後、Herokuについて何か困ったことがあった場合は、Youtubeで情報収集をしてみるのも良いかもしれません。
マイグレート回りは、本日はお休みのえるきちさんが来た日にやりましょうということになり、今日の宿題を再確認します。
宿題として上がっている中には、マイグレートをGitHubから自動デプロイする方法などがありますが、これはマイグレートに密結合しているので後回しです。そこで、それ以外のところ、自動デプロイ回りの設定を行うことにします。
現在の構造として、GitHubの同じリポジトリの中にHasuraのマイグレートのデータと、アプリケーションが同居しています。アプリケーションの方は、Vercelにより自動的にデプロイされるようになっています。
しかしHerokuはそうはなっていないので、ローカルのHasuraで変更したものを自動的にデプロイしてほしいと考えています。単純にやるだけなら、GitHub連携ができますし、Pipelineを設定することもできます。今回は永続的に立っているHerokuに対して、GitHub Actionsを使ってデプロイするようにしてみます。
HasuraCLIでリモートのHasuraにマイグレートを仕掛けるコマンドが用意されているようですのでこれについても調査します。公式動画で確認します。GitHub Actionsでたたけそうなイメージができたので、とりあえずやってみます。ステージングでマイグレーションファイルを自動で出す設定になっていて、config.ymlでEndPointを本番環境に差し替えて、その状態でHasura CLIを叩いたら本番に適用できたね、といった感じの動きと認識しました。
ここでドライバーを交代し、やってみます。リポジトリをローカルにCloneして、Hasura CLIをインストールして、まず認証エラーが出ることを確認します。
$ hasura migrate status
cannot create maigrate instance: [access-denied] restricted access : admin only($.args)
$ hasura migrate status --admin-secret Password
VERSION NAME SOURCE STATUS
hoge
$ hasura migrate apply --admin-secret Password
INFO migrate appiedmigrate applyで成功したように見えますが、Schemaに反映されていないようです。Untrack of viewsというステータスが付いており、trackをクリックすると取り込まれました。えるきちさんが知っているだろうから参加しているときにということでいったん保留とし、次の作業に進むことにします。
GitHub Actionsは、GitHub上で動くCIです。外部ツールを使わなくてもCIが使え、GUIで作ることもできます。
Hasura CLIもテンプレートがありました。必要に応じてカスタマイズして使うことができます。Marketplaceから導入することができますが、そもそも必要なこととズレるのと、使ったことないのでイチから作ってみることことにします。何をやっているのかよくわかるという大きなメリットがあります。
config.yml内にインストールするツール、アクションを書き加えていくという、CIの一般的な設定方法に則って設定することができます。GUIでも補完が効きます。
本日が2020年8月20日で、この後の技術書同人誌即売会の予定として、9月12日からの技術書典9があります。それに向けて、ギポタル自体のβ版リリースをどうするのか、合わせてギポタル本のリリースをどうするのか、という点についての相談をします。
まずはギポタルのβリリースについてですが、当初に決めたMVP（Minimum Viable Product）として、技術書典に合わせてリリースしたいところです。2技術書典はコロナ影響でオンライン開催となりました。この時期はこの界隈は技術書に関する話題で盛り上がりますから、この時期に向けて実装を進めたい、という話になります。
ここまでのモブワークでほとんどの要素技術についての検討、トライはやったと考えられます。あとは認証だけといえば認証だけですが、運営に関係するサークルだけでも10サークル程度は配置できるでしょう。トップページがあり、サークルのページに本が並び、それをクリックすれば本のページに移動できます。まだRead onlyで書き込み・サークル登録はできませんが、サービスのイメージを掴むには十分でしょう。
お披露目をすれば登録したいというひとはたくさん出てくるでしょう。それは理解するところなのですが、テーブル設計を行い、必要なパーミッションを設計し、認証周りを実装して、情報登録ページを作るなど、かなりのボリュームになります。
したがって、技術書典9（2020年9月12日）に向けては、既存（身内・関係者）サークルの情報を手打ちして行う形をMVPのゴールと定めました。 Hasura Cosoleの手打ちでOKかどうかが第一の判断です。既存のサークルで行うメリットは、全てのサークルは既刊があります。NoImageばかりでは寂しいですしね。
正式リリース版からは、サークルが自分で登録できるところが差になります。
ここまでモブワークで進めてきた実装ですが、そろそろ公開モブやってみたいなー、という話が出ました。
現時点で、みんなでやった方が良いワークとして、本のタグの設計やデータベーステーブルの設計があります。実装そのものというよりも、みんなでわいわい案を出すという形で公開モブワークができないかなー、という思いつきです。
本のタグとは、それぞれの本に数個のタグを設定し、そのタグに含まれる本を一覧ページとして提示することで、類似の本との出会いを呼び起こすというものです。そしてそれとともに、オススメタグとして提示することで、上位概念、下位概念、あるいは類似するタグへのジャンプを可能とし、より広く本を探したり、逆にジャンルを絞ってターゲットを明確にさせることができる機能と考えています。そのためこのタグは自由記述ではなく、運営で準備した（粒度が細かすぎない）タグをつけてもらうのが適当かと考えています。一方で、タグを網羅的に作るためには、色々な人にみてもらうのが良いと考えました。
アンケートをスプレッドシートで募集することも可能ですが、せっかくZoom＋YouTube Live＋MURALというパターンを確立しましたので、このプラットホームでわいわい進められたら、と考えました。また、このイベント自体で進んでいる感も出ますし、イベント化することでプロモーションにもなるでしょう。これを機にギポタルを知ってくれる人が増えてくれればとも考えます。
という思いつきから提案してみましたが、技術書典までにMVPリリースを行うことが優先される気がしました。
露出させるにあたっては、お披露目会的にしたいというところもありますので、一旦は保留としましょう。
技術書典に間にあわせるために、今後もモブを続けるか、という話を相談します。
すでに20日を切っていますので、全てをモブでやる時間がありません。画面はすでに二つほどつくりました。それらのコピーをいちいち全員でやっていく意味もすでに薄れています。随時進捗共有しつつ、ペアプロで進めていくと良いであろう、というあたりで合意が取れました。
残タスクの整理、個別ワークにできる内容の整理を行いましょう。
作らなければいけないものの整理をします。
- トップページ まだ
- サークルページ できているがAPI結合はまだ
- 本のページ
- タグのページ
トップ、サークル詳細、本のページがあり、階層構造をなしつつ、タグのページにより本が横断的に検索できる、というのが基本です。
本の詳細を挟む必要があり、それをモーダルで出す形とします。あとで作るし、今間に合わせのものを作るよりも本物を作ってしまう方が楽であろうということになり、モブではなく個別ワークで進める形となりそうです。ただし、フロントの1ページ作ることより、DB構築の方が大変かつそのDBに密結合した内容であろうということで合意が取れました。
そもそも、このモブの後に、「この本にニーズがあるのか」という話がSlackで生まれます。現状でこの本の95％を書いているおやかたから、ある種とっちらかっている、試行錯誤もあり、でニーズがあるのかわからないというコメントを出しました。著者のみなさんがときどきおちいるかもしれないスランプの状態かと思います。
結果として、話しているうちに、サービスの実装のすべてを要件定義や試行錯誤、実装を全て説明する本は世の中に存在しないので絶対にニーズがある、という話になりました。実際商用サービスでは秘密保持が必須です。またフレームワークや各ツールについての説明があったとしても、それらを横断的に説明する本というものはほとんど存在しません。デモコード的に複数の技術を使うものはあるかもしれません。しかし本書では、都合12以上のサービス、ツールを使っています。それぞれが役割を持ち、実際に動作するモジュールとして組み込まれています。
Hasuraの権限周りと、マイグレーションの自動デプロイのためのGitHub Actionsの設定が主なワークでした。
そして、それとは別に今後のリリース方針やこの本のニーズについても相談した会でした。
Footnotes
-
Heroku公式チャンネル https://www.youtube.com/channel/UCE8rdqp8ZM4kuXj8CwIwZHg ↩
-
いきなりMVPが変わっているような感覚を受ける方もおられるかもしれないので、経緯を説明しておきますね。最初にMVPを決めた際には「直近の技術書同人誌即売会に向けてリリースをしよう！」という話の結果として、その時見えていた直近のイベントが、第4回技術書同人誌博覧会(以下、技書博と記載)でした。(MVPを最初に決めた頃、技書博は2020/11に物理開催を予定していました。) その後、7/10に技術書典9のオンラインでの開催が決定、更に7/30に技書博の2021/6への延期が決まりました。(物理開催を目指しておられたのでこれはやむを得ないですね。) これらの結果として、仮に今回の技術書典に間に合わせなかった場合、次の発表のタイミングがしばらく無いんじゃない？という判断が働いており、技術書典9に合わせてリリースする必要があるね…という話の流れになっています。 ↩