# Gatsby / GraphQL / Vercel --- # 近況報告 ---- ## ~~同棲はじめました~~ 結婚しました - 5/19に入籍しました。（ガッキー＆星野源と一緒） - 縁もゆかりもない平塚市に本籍をおいてしまったので、早いうちに移したい。 - 指輪はティファニーで買いました。 - ブライダルフェア中に行くとめっっっっちゃいい感じの結婚証明書もらえるのでオススメ。 ---- ## Webstorm使い始めました - 有料IDE試してみるか、と思って、VSCodeからJetBrains社のWebstormに乗り換えてみた。 - 6600円/year = 550円/monthなのでそこまで高くない割に、補完とか型チェックがかなり強い。 - また、git機能もふんだんにあってこれでええやんってなった。 - https://www.jetbrains.com/ja-jp/webstorm/ --- # Gatsby ---- ## ReactとGatsby - この前トリスがReactを紹介していたので、その流れで。。。 - ReactはあくまでWebサイト作成のための「ライブラリ」である。 - この「ライブラリ」を系統立てて活用するための「フレームワーク」としてGatsbyが存在する。 ---- ### ライブラリとフレームワークの違いって？？ - どっちも漠然とエンジニアリングのツールとして使いがちな言葉だが、以下のような特徴がある。 - ライブラリ: システムを作るうえで便利な機能群 - フレームワーク: システムを作るためにあらかじめ定められた大きな枠組み ---- - わかりやすい説明として、「主導権がどちらにあるか」を考えるものがある。 - ライブラリは、プログラマが使いたいときに使いたいように使うため、プログラマに主導権がある。 - 一方で、フレームワークは、どのように書かないといけないかがあらかじめ定められているので、フレームワークに主導権がある（プログラマはそれに従わなければならない）。 ---- ## Gatsbyを使うメリット - 静的なサイトの作成できて速い（SSG） - GraphQLを用いた便利なデータソースへのアクセス - その他諸々（今回は省きたいやね） ---- ## CSR vs SSR vs SSG - Client Side Rendering - クライアント（アクセス元のブラウザとか）でJavascriptを使ってDOMを生成する方式。 - サーバ側はまるっと一つのリソースを返せばいいので楽。ただしクライアント側の負荷がでかい。 - Server Side Rendering - サーバでHTMLとかを都度生成して返す方式。 - サーバ側の豊富なリソースを使えるのでクライアントの環境を選ばない。ただしサーバ側の環境が必要だしレスポンスが悪い。 ---- - Server Side Generation - リクエストが来る前にあらかじめHTMLとかを生成してしまい、それを返す方式。 - 生成はデプロイ時の１回のみなのでめちゃ高速。ただしリクエストに応じた動的なページは返せない。 ---- ### SSGやったら阿部寛公式サイトみたいなホームページしか作れへんやん！！！ - というのは誤解。 - 外部からデータを取ってくる処理が必要なページについては、SSGでHTMLをビルドするタイミングでデータをフェッチしてそれを使ってビルドしてしまう。 - ソースコードの時点でサイトの中身が決まっている、という意味ではなく、ビルドの時点でサイトの中身が決まる。 - 極端な話、５分ごとにビルドしてデプロイすれば、５分ごとに最新の内容のサイトがデプロイされる。 ---- ## Gatsbyのおかげでルーティングも簡単 - ルートディレクトリにpagesというディレクトリを作ってそこに.tsxファイルを置いておけば、そのファイル名で勝手にルーティングしてくれるようになる。 - また、外部データに応じて自動でパスを作成することも可能。 - GatsbyのCreateNodeという機能。例えばDBからブログ記事を取得し、それぞれのデータをあらかじめ用意しておいたテンプレートに流し込むように設定できる。 - テンプレートさえ作ってしまえば、あとはブログ記事を用意するだけで、記事ごとのページを作る必要がない。 ---- ### こんな感じで動的にページを生成 ``` members.data.allGraphCmsMember.nodes.forEach(({name}) => { const page = { component: memberTemplate, path: `/member/${name}`, context: { name: name } } createPage(page) }) ``` - あらかじめ`members`にデータを格納しておけば、その中の`name`に応じたページを作ってくれる。 ---- ## SSGのおかげでデプロイも簡単 - ビルドしてしまえばあとはデプロイするだけなので、ローカルでコマンド一発叩いてビルドした後は、よしなにホスティングサービスにアップロードするだけ。 - ホスティングサービスによっては、Githubなどと連携して、ビルドするところからサポートしてくれるものもある。 --- # GraphQL ---- ## 外部とのデータやり取りにREST APIを使うのはもう古い（暴論） ---- ### REST APIのとき〜 ---- - バックエンド「API仕様書書いておいたから読んどいてやに〜」 - フロントエンド「めんどくせぇ〜〜〜」 - フロントエンド「データ取得するときにいらん項目削りたいから修正してやに〜」 - バックエンド「めんどくせぇ〜〜〜」 - バックエンド「データの型は仕様書見といてやに〜」 - フロントエンド「めんどくせぇ〜〜〜」 ---- ## GraphQLって何？それ使うと何ができる？ - Facebookが開発したクエリ言語。単一のエンドポイントに対してクエリを発行する。 - RESTfulな設計だと、リソースごとにエンドポイントを区切る必要があった。 - クエリを投げる側であるフロントエンドが、必要なデータを自分でクエリを組み立ててリクエストできる。 - [アプリ開発の流れを変える「GraphQL」はRESTとどう違うのか比較してみた](https://www.webprofessional.jp/rest-2-0-graphql/) - [GraphQL 入門ガイド](https://circleci.com/ja/blog/introduction-to-graphql/) - スキーマファーストの開発が可能となる。すなわち、バックエンド側で持っているデータのスキーマを厳密に保持できる。 ---- ## 実際のクエリを見てみましょう ``` query ($name: String!){ graphCmsMember(name: {eq: $name}) { name twitterAccount technicalFields githubAccount birthday description icon { url } cover { url } } allGraphCmsEvent(filter: {member: {name: {eq: $name}}}) { nodes { timelineType eventName date } } } ``` ---- - 何となくわかると思いますが、欲しい項目名をクエリ側で組み立ててるだけ。 - スキーマはバックエンド側で定義している。 - クエリの組み立て方もバックエンド側が定義しているので、ツールを使えばポチポチで作れる。 ---- ### GraphQLの始め方 - まずは扱いたいデータのスキーマを作成する。 - いろんな言語で書けるらしいが、GraphQL用の言語で書くのが通例っぽい。 - クエリに対するリゾルバを作成する。 - リゾルバ＝クエリに対してどんなデータを返すかのロジック。 - リクエストを受け付けるサーバ側を立てる。 - このサーバがスキーマを理解し、リゾルバを実行する。 - 後はサーバ側のエンドポイントをクライアントが叩く。 ---- ### スキーマの書き方 ``` type Book { id: ID name: String pageCount: Int author: Author } type Author { id: ID firstName: String lastName: String } type Query { bookById(id: ID): Book } ``` - 列挙型やリストやオブジェクト（入れ子）も定義できる。 - `Query`の中に、クエリの種類を定義する。 - この例だと、`id`をもとに`Book`を返す`bookById`というクエリが存在する。 - `bookById`がどんな実装かはサーバ側のコードで実装するので、スキーマでは「データモデル」と「インターフェース」を定義する感じ。 ---- ### リゾルバの書き方 ``` bookById: (id) => { //適当にDBに接続したとする Book book = connection.query(`SELECT * from booklist WHERE bookId = ${id};`) return book; } ``` - GraphQLのエンドポイントを持つサーバ外にデータが存在する場合は、そこに取りに行く必要があるので、結局ここでさらにクエリをどこかに飛ばす必要がある。 - そういう意味ではBFF(Backends For Frontends)っぽい使い方になる。 - AWSのAppSyncでは、DynamoDBとよしなに接続してくれるし、リゾルバの指定も簡単に行える。 ---- ### 結局スキーマとかってバックエンドから連携してもらわないと分からないの？ - 実はそう。 - が、バックエンド側はエンドポイントを用意しておき、そこにアクセスすればスキーマをまるっと取れる仕組みになるので、フロントエンド側は特に苦労しない。 - それを自動で行い、型定義を作成するツールがある - クエリを組み立てるツールもその仕組みを使っている。 ---- ## どうやってリクエストを送るのか - 実際の通信はHTTPのPOSTを利用して送信する。 - クライアントライブラリは色々あるので実際はそのメソッドを通じて送信するので意識はあまりしない。 - 前述のGatsbyでは、GraphQLを前提としているので、クエリを書くだけで、ビルド時に勝手にクエリが発行されてデータをフェッチする。 ---- ### GraphQLクライアントとして有名なapollo clientだとこんな感じ ``` const { members }: { members: GetMemberByIdQuery['members'] } = (await this.$apollo.query({ query: GET_MEMBER_BY_ID, variables: { uId: user?.uid } })).data ``` ---- ### クエリの中身はこんな感じ ``` export default gql` query getMemberById($uId: String, $memberId: String) { members(where: { OR: [{uId: $uId}, {memberId: $memberId}]}) { name birthday emailAddress uId point memberId } } ` ``` ---- ## 結局バックエンドでGraphQLの受け口を作らないといけないのか？ - それはそうだけど、逆にいうと一つ受け口を作ってしまえば、後はフロントエンド次第 - スキーマファーストで開発を進めるので、認識の齟齬が起きにくい（はず） - 後述のGraphCMSでは、GraphQLのエンドポイントを自動で作成してくれるので便利 - GraphQLのバックエンド側をどうやって実装するのかによるが、有名なApolloというソフトウェアでは追加で認証情報などをチェックできる --- # Vercel ---- ## 作ったサイトを（簡単に）デプロイしたい！ - サイトを作ったら、それをどこにどうやってデプロイするかを考えないといけない - 最近のアーキテクチャの流行りはやっぱりサーバレス - サーバ（を整備したり設定したりする必要）レス ---- ### （S3じゃ）いかんのか？ - AWSのS3は静的なサイトならindex.htmlとかをアップロードしたら、それをホストして外からアクセスしてくれるようにしてくれる - でも自分でアップロードしないといけないし・・・ - CloudFrontとか自分で設定しないといけないし・・・ ---- ### 設定もしたくないし、いい感じにエッジサーバに置きたいし、Gitと連携させたい！ - Vercelは、面倒な設定いらずにビルドからデプロイまでしてくれる！ - Vercelは、ポチッとエッジサーバを選べばそこに置いてくれる！ - Vercelは、Gitのレポジトリと連携すると、更新が入るたびに勝手にビルドから走らせてくれる！ ---- ### いろんなフレームワークに対応している - 公式HPだとNext.jsが例として挙げられているが、実際はいろんなフレームワークをサポートしている - アプリケーションサーバではないので、SSRがガッツリできるわけではない - が、内部でAWS lambdaを使ったfunctionの作成ができるので、それを使ったSSRはやろうと思えばできる ---- ## はんずお〜ん --- # まとめ - ReactでSSGするならGatsbyを使うのが最近の流行り - Next.jsも有名やけどこれはSSRのフレームワークなん？>とりす - これからのデータフェッチはスキーマファーストかつフロントエンドファーストなGraphQLに置き換わるのかも？ - サクッとWebサイトをデプロイする選択肢として、Vercelがグイグイ来ているらしい