技術書典9（2020年9月12日〜22日）でReact + GraphQLバックエンド（Hasura）な実践プロトタイピング本を出します
今度の技術書典9に、Next.js + Hasura GraphQL Engine （などなど）を使ったフロントエンドとバックエンドにまたがった実践的なプロトタイピングのノウハウをまとめた本を出します。
技術書典9は、9/12〜9/22の間オンラインで開催されます。まだサークルページなどが公開されていませんが、そろそろ公開されるはずです。
特徴としては、物理本は読者側の送料負担が0円なので、うちのサークルに限らず物理としての本が欲しい人は気軽に買えるはずです。（サークル側負担も1冊あたり100円です。この送料が安いからくりは、9/22の技術書典9が終了してから一括で物理本を発送するため、送料を安く抑えられるからということのようです。技術書典運営さまには感謝しかありません）
追記: どうも刷る冊数を11日までに決めておかないといけないっぽくて正直どうしたものか悩んでおります……。刷らないという選択肢も……。刷るとしたら50冊単位はコスト的に見合わないので100とかになるんですが、技術書典9の空気感が分からず、100はチャレンジングだなーという感覚が強いのです……。
今日から少しずつ、執筆中の本の内容を抜粋して記事にしていきます。本の内容としてはまだ未完成なので、今回の記事から、実際の本では色々と変わっているかもしれませんが、大筋は変わらないはずです。
対象読者
TypeScript + React が分かること、もしくは別の本などで React や TypeScript について勉強できるひとを前提とします。本書ではページ数その他の都合で React や TypeScript の詳細には踏み込みません。
そのうえで、プロトタイピングのコツを知りたいひと、フロントエンドプロトタイピング（React/Next.js）を覚えたいひと、バックエンドプロトタピング（Next.js/Hasura GraphQL Engine）を覚えたいひとを対象読者として想定して本書を記述しています。
・ React + TypeScript の開発経験があるか、それらを別の本なりで埋められるひと
・ プロトタイピングのコツを知りたいひと
・ フロントエンドプロトタイピングを覚えたいひと
・ バックエンドプロトタイピングを覚えたいひと
モチベーション
意外にプロトタイピングのコツを知らない人が多いと観測したので、それをまとめたくなったことと、Next.js + Hasura GraphQL Engine が意外に凄いヤツだったので、それを紹介したかたったのが、本書を執筆するモチベーションです。
プロトタイピングとは
プロトタイピングとは、手早く、実際に動く物を作って触りながら、他の人からのフィードバックを得て、よりよい物を設計するという技法なので、開発工程としては設計に該当しますが、やっていることは設計と実装をまたぐものです。
アイデアや機能を机上の上で考えても細部が異なる、様々な制約から思っていたものとは違うものを作らざるをえないこともしばしばです。「○○が欲しい」と口にしている人がいたとしても、実装されたら「実は思ってたのと違った」というようになってしまうケースが多いことを皆さんも体験しているのではないでしょうか？
It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.
[BusinessWeek, May 25, 1998]
これは、スティーブジョブズの名言で、「人は形にして、見せてみないと、本当に欲しいものが何なのか分からない」というものです。さらに源流をたどると、ヘンリーフォードが言った「もし顧客に、彼らの望む物を聞いたら、彼らは『もっと速い馬が欲しい』と応えていただろう」という言葉もあります。
プロトタイピングは、社内の工程として作られるケースもありますし、リーン開発のようにMVP（概念検証ができる最小限のプロダクト）を作り、市場に問うというケースもあります。
人間は言葉だけでやりとりをすると、大抵すれ違うものです。曖昧さによって解釈の余地がそれぞれの人で異なるためです。より具体的になればなるほど、議論は適切になります。
たとえば、言葉だけのやりとりよりは図を交えたやりとりの方がより正確でしょう。さらにいうと、図があっても動きがあるわけではないので、動きも含めたものであればより良いでしょう。
実際に動くアプリがあれば議論の曖昧さをなくせます。
本書の構成
本書は、Next.js + Hasura GraphQL Engine の詳細を必要以上に解説するための本ではありません。プロトタイピングのノウハウを伝えることと、バックエンドに踏み込んだプロトタイピングについて説明することの2点が主目的です。
プロトタイピングをするのに必要な範囲で Next や Hasura GraphQL Engine 以外も含めて要素技術とセットアップについて説明をします。
後はひたすらプロトタイピングについて書いてあります。
プロトタイピングの心得
プロトタイピングは手早くです。またプロトタイピングは容易に捨てられるようにしておくべきでしょう。また人に見せて、改良をする前提のため、容易に変更できるようにしておく必要もあります。
プロトタイピングのやり方
プロトタイピングをするときに、どこを起点にするのか？は、その人が得意なやり方及び、状況に合わせたやり方に合わせるといいでしょう。
・ デザインツールでデザインから作る（Figma など）
・ HTML + CSS で画面モックから作る
・ 動きやパーツから作る
・ 関数から作る（TDDなど）
・ データから作る（SQLやTDDなど）
・ 型定義から作る
二面作戦で作っていくのがいいケースや得意な人もいるでしょう。
デザインから作る
がっつりデザインスキルを持っている人は Figma などのツールを使うといいでしょう。頑張れば Figma で画面遷移なども含めて設計が可能です。場合によっては、Figma で作り上げたものをいじることでプロトタイピングが完了してる可能性もあります。
デザインツールのデータは、そのままではアプリケーションとして動くわけではないため、必ずどこかでアプリケーションに落とし込む必要があります。この落とし込むという工程に罠が潜んでいることもしばしばです。デザインだけでは気づかなかった問題、たとえば、バックエンドとの通信によって生じる問題もあり得るでしょう。
筆者自身があまりデザインツール慣れしていないのもあり、本書では取り上げません。
画面モックから作る
HTML + CSS にある程度慣れているなら、画面モックを作るという選択肢もあります。できあがった HTML+CSS を分割してコンポーネントに落とし込んでいけば、段階的に動きを付けていけます。
動き、パーツから作る
デザインはあまり考えずにコンポーネントから作っていくという考え方もあります。最低限のHTMLだけでコンポーネントを作りそれらを組み合わせて、動きだけを見るようなやり方です。
世の中には便利なUIライブラリもあるのでそういったものを使えば、最低限の見た目も作ることはできます。実際に作りたいアプリと合致するデザインかどうかはわかりませんが、画面遷移や動きに関してはそれでも問題ないでしょう。
たとえば React コンポーネントから作るようなケースです。
トップダウンのアプローチでやる人なら、最初に TodoApp のようなコンポーネントを作り、中では最低限の HTML を表現できるものを作りはじめて、そこから分割をしていくのです。
必要なパーツがある程度見えている人はボトムアップでやってもいいでしょう。パーツを作って、組み合わせて TodoApp を作るのです。
厳密にどこから始めるべきということもないので、自分の手の付けやすいところから始めるといいでしょう。
TDD
TDD（テスト駆動開発）は、開発とは名前が付いていますが、設計手法です。ちょうどプロトタイピングと同じように、実装してみることでその設計が正しいかどうか？を常に問いかけながら、設計をするためのものです。
ビジネスロジックがある程度見えているような場合はTDDのような手法は有効です。データをこう入力すれば、こういう出力が吐き出されるものを組み合わせれば、ビジネスロジックができあがるという風に、ボトムアップから全体像を描ける人に向いているでしょう。
SQL
SQL慣れしてる人は、こういうパターンのアプリケーションならこういうデータが必要だ、というデータモデリングから入るといいでしょう。
特に本書で紹介している Hasura GraphQL Engine ならば、 SQL さえ作ってしまえば、GraphQL API も自動で用意されるため、データ指向のプロトタイピングが行えます。
GraphQL には、GraphiQL という、実際の GraphQL クエリを投げてその結果を受けとるツールがあり、Hasura GraphQL Engine の GUI である Hasura コンソールにも組み込まれています。
型定義から作る
昨今のウェブフロントエンドでは TypeScript が当たり前になりました。そのため、簡単に型から作れるようになりました。
・ React コンポーネント引数（props）の型定義
・ 様々なデータ構造の型定義
・ 関数の型定義
これらを駆使するのです。
型を作ってから作成する、型定義駆動に慣れると、適切な型さえ最初に定義すれば、それらをやりとりするだけで、開発ステップが軽量になっていきます。
これらを組み合わせる
たとえば動き、パーツから作るで紹介したような React コンポーネントを作るところから始めるのであれば、コンポーネント引数の型定義と平行で始めることができます。
型を駆使したプロトタイピングは、精密さと手早さを両立できるため、オススメできるやり方の1つです。
【コラム】プロトタイピングはゼロイチなのか？
プロトタイピングはゼロイチな手法なのでしょうか？
大抵の場合は、新規の設計・実装になるはずですが、必ずしもゼロイチとは限りません。
たとえば、あるプロダクトの新しい機能を作るときに、プロトタイプを作って動きを見てもらうというやり方があります。
プロトタイプを作って、動作検証して、本番コードを作るという工程が、机上設計から実装までの工程と比べて、前者が早いのであればプロトタイピングの出番です。ある程度の規模感だったり、プロトタイピングに慣れていれば、前者の方が開発工数を縮めることができる可能性は高まります。
まっさらな状態で作る場合は、考え方としてはゼロイチかもしれませんが、参考にできるものは多いはずです。プログラミングにおいて真の意味での無からの創造というのはほぼ無いはずです。過去の知識・経験、公式サイト、サンプルコード、GitHubのソース、ブログの記事、何かしら参考にしているはずです。
人によっては、新規コードベースを作成するのが得意な人と、既存のコードを改修するのが得意な人がいます。前者であればプロトタイピングに既に慣れているか、少しの練習でプロトタイピングを物にできるかもしれません。
後者の人が無理をしてプロトタイピングをやるべきだとは限りませんが、何かしら技術の幅は広がることは間違いないでしょう。
フロントエンドとバックエンド
ウェブ技術を使ったプロトタイピングでは、データを決め打ちにする、データは登録はできるが揮発性にする、ローカルストレージに入れるなどといった形にすることで、フロントエンドのみのプロトタイピングを作ることがあります。
とくにフロントエンド開発とバックエンド開発でチームが分かれているような場合は、そういった手法をとることが多いでしょう。
Firebase のような特定の機能を提供してくれるサービスを使うような事例もあります。バックエンドでできることは限定されますが、ある程度実用的なプロトタイピングも可能です。
プロトタイピングをする人は、どういう手段を持っているかが武器となります。プロトタイピングは、手早く、実際に動く物を作る必要があるため、たとえば Firebase を使うならば、ある程度 Firebase について知っていないと手早く作れないためです。
この本で紹介する幾つかのフレームワーク・ライブラリは Firebase 同様にプロトタイピングに向いたものであり、その中でも Next.js と Hasura について詳しく解説します。
バックエンドにも踏み込んだプロトタイピングについて本書で学んでください。
Next.js
Next.js（以後 Next）は React を使う為の軽量フレームワークです。Next にインスパイアを受けて誕生した Nuxt.js は手厚いフレームワークですが、Next はシンプルさ・軽量さが特徴です。
・ ビルドツールである Webpack の面倒を見てくれて、一般的なものは特に設定なしで動く
・ ページルーティングをしてくれる
・ サーバーサイドレンダリング（SSR）や静的サイト生成（SSG）やAMP生成などをしてくれる
・ バックエンドとフロントエンドをユニバーサルに繋ぐ
という機能があり、ある種 JavaScript 環境の基盤となるソフトウェアです。
これらは、SSR/SSG/AMP はともかく他は、プロトタイピングにも向いた機能であり、とくに最後に挙げたユニバーサルというのは、より興味深いものです。
Next では API サーバーなどバックエンドのコードと、フロントエンドのコードを混在して記述ができます。たとえば、バリデーションやビジネスロジックなど、フロントエンドとバックエンドで共有したいコードがあれば、簡単に共有ができるのです。
一般的にウェブフロントエンドは JavaScript（及びTypeScriptや他AltJS）以外に選択肢は、事実上ありません。
WebAssembly はまだ実践に投入するには色々問題がありますし、ある程度熟れてきたとしても、JavaScript/TypeScript を中心としたエコシステムは堅固です。
バックエンドは、Ruby, PHP, Java など様々な選択肢はありますが、こちらでも JavaScript を採用できれば、不要な技術スタックの分散を抑えることができます。
プロトタイピングを作るという観点に戻りますが、複数の言語を使わなければいけないというのはさすがに工数が無駄にかさむ原因になるため、プロトタイピングなら、両方が JavaScript であることが望ましく、Next.js ならそれが可能です。
Hasura GraphQL Engine
Hasura GraphQL Engine は RDB（PostgreSQL）に特化した GraphQL サーバーです。
テーブル構造に合った GraphQL API が自動生成されるため、RDB のテーブル（とリレーションなど）さえあれば、ウェブアプリから簡単に RDB をアクセスできます。
ウェブアプリの API というと REST 思想に基づいた API が一般的でしたが、最近は GraphQL も使われるようになりました。
Rails の ActiveRecord のような ORM は、RDB上のデータ操作をRuby のオブジェクトとメソッドに抽象化したものです。
Hasura GraphQL Engine は RDB の操作を GraphQL という API に抽象化するものだと思えばいいでしょう。
元々 GraphQL 自体 Apollo Server などで、既存の REST API を、クライアントが扱いやすいように抽象化・変換するものとして利用される事例がとても多いです。
Apollo Server は Next と同居して動かすこともできますが、プロトタイピングとして考えるとオーバーキルに近いため、この本では GraphQL server は Hasura GraphQL Engine のみを利用します。
もちろん、Apollo Server + Next + GraphQL という構成もありです。その構成では、もはやバックエンドで出来ないことは皆無になります。
オブジェクトとして直接アクセスするのではなくて API としてアクセスするのは、ワンクッション必要に感じるかもしれませんが、GraphQL API はその API アクセスを、全自動でコード生成可能です。
TypeScript による型も適切に生成されるため、RDBの中のデータは自動生成された型によって保証されます。
JavaScript の API クライアントの多くは、帰ってくるデータには型がありません。エンドポイント、アクセス方法などによって、帰ってくるデータには無限の可能性があるため、型を定義できないためです。そのため、API からのアクセスコード自動生成は、型情報を API 定義から参照できるため、型安全に API アクセスできるという利点があります。
予定
これから数回、本から抜粋して記事を書きます。
・ Next.js
・ Hasura GraphQL Engine
・ プロトタイピングのコツ
紙の本に関しては印刷費と送料負担があるため、どれくらいの部数を刷るかは未定です。9/12・9/13の販売部数を元に、実際の部数を決める予定なので、もし物理本を購入したい人は、9/12・9/13のうちに購入をして頂けると助かります。それ以後は売り切れになる可能性が高いかもしれません。
この記事が気に入ったらサポートをしてみませんか？