12日目: Nuxt.jsをLambdaで動かすようにしたい。TypeScriptで。

今日はフロント

前回まではGraphQLでのAPI側を実装してきた。ほとんど機能は無いけど、いったん形だけ作ろうと思い、フロントエンド側を作ってみることにする。

フロントエンドはNuxt.jsでサーバサイドレンダリングをする一方で、インフラはAWS Lambdaというサーバレスアーキテクチャな構成に仕様と思います。

実を言うとNuxt.jsをAWS Lambdaは以前やったことがありそのことをQiita記事にまとめました。

qiita.com

この記事のようにnpx create-nuxt-appをすることで同じようにできるかと思ったのですが、初回の構築時にExpressが選べなくなっていたりと変わっていました。どうやらnuxt.jsの仕様が変わったんですかね？

nuxtでexpress使うって最初のcreate-app時にないなぁって思ったら推奨されなくなったのか?

ちょっと使いたいから色々遣唐使よ。https://t.co/jzJ6iLdAvT

— よこやま (@hiroyky) 2020年8月1日

そういうわけで現時点では最新安定版のnuxt.2.14を使ってAWS Lambdaで動くNuxt.jsを構成していきたいと思う。できればTypeScriptで。ある程度まとまったらQiita記事を更新もしくは、新規作成しようかな。。

先ほどの自分のツイートのリンクにあるgithubイシューでは下記２つが紹介されていますね。ただ、この２つはexpressとnuxt紐付けているとはいえ、大きく違う。前者はexpressをサーバにしてその中でNuxtを動かす。後者はNuxtを動かして、そのミドルウェアとしてexpressを動かす。どっちが親になるかが違う感じ。今回はおそらく前者を採用するのが妥当。

• https://nuxtjs.org/api/nuxt-render
• https://nuxtjs.org/api/configuration-servermiddleware

色々調べた結果、こちらのリポジトリがNuxt.jsをexpress配下で動かしてサーバレスアーキテクチャとして稼働している実装をしているので参考にさせて頂いた。ただ、Vue側はTypeScriptで書けるように設定しているけど、express側はJavaScriptで書いている。

そこで、このリポジトリを参考にしながら作成したあと、express側もTypeScriptで実装できるように変更した。

そんな今回のプルリクはこちら。

github.com

なかなかの保存版では？？

なお、その後ここでの作業を一般化してQiita記事にしました。

qiita.com

11日目: 管理者向けエンドポイントにはBasic認証を

またまた日数経ったけど

お仕事が少し落ち着いてきたので続きを作るよ。 前回では/adminにブログ記事を作成・更新するエンドポイントを作成しました。

忘れていたけど、/admin配下にもかかわらず一切認証機構作っていなかったです。いったんブログ記事は自分だけが更新する予定なので、通常のクッキー等によるセッション管理は無しにして、Basic認証でことをしのごうかと思いました。

今回使っているGoのWebフレームワークではかんたんにBasic認証を導入できるようなので導入。 現時点では、ログインIDとパスワードはローカル開発と言うこともあり.envファイルに書いて、しかもGitで管理してますが実際にはAWS KeyManegement Serviceを使おうと思います。

というわけで

本日のプルリク

github.com

10日目：管理者向けの処理を書く

日数経ったけど。。

前回からかなり日数たったけど、続きです。仕事が忙しいのに加えて、休日はアジサイを撮影したりで。。。

#6月 の #昭和記念公園 に行ってきた。#紫陽花 や #緑の草木 が綺麗でした。在宅勤務で動いてないからか歩いてかなり疲れた。#国立昭和記念公園 #showapark #景色 #カメラ #camera #a7iii #α7iii #tamron2875 #散策 #散歩 #あじさい #アジサイ #立川

#6月 の #昭和記念公園 に行ってきた。#紫陽花 や #緑の草木 が綺麗でした。在宅勤務で動いてないからか歩いてかなり疲れた。#国立昭和記念公園 #showapark #景色 #カメラ #camera #a7iii #α7iii #tamron2875 #散策 #散歩 #あじさい #アジサイ #立川 #hydrangea #日本庭園 #japanesegarden #japangarden

あぁ、もう6月も終わる。最近、めちゃくちゃ忙しい。#井の頭公園 #井の頭恩賜公園 #吉祥寺 #三鷹 #三鷹市 #紫陽花 #あじさい #アジサイ #公園 #散歩 #景色 #カメラ #カメラ女子 #カメラ好きな人と繋がりたい #カメラ男子 #sel55f18z #写真好きな人と繋がりたい #ミラーレス一眼

#散歩 してたら色々見つかりました。明るめにレタッチしてみました。#井の頭公園 #井の頭恩賜公園 #吉祥寺 #三鷹 #三鷹市 #公園 #景色 #花 #sel55f18z #カメラ #カメラ好きな人と繋がりたい #カメラ女子 #カメラ男子 #カメラのある生活

今日は管理者向けの処理

今回は、/adminで記事を作成・更新したり、取得するエンドポイントを作成しました。これでＡＰＩ最低限のことはできるようになってきた。 似たようなコードで一般の人向けの処理も書けばＯＫ！

というわけで本日のプルリクエスト。

github.com

github.com

課題

ちなみに今はサクッとデータを取得している、現時点ではそれで良いんだけど将来的にはDBアクセスで1+N問題が発生するからその対応は必要だよね。そのうち。

以下広告

もののけ姫 [Blu-ray]

9日目: GraphQLスキーマ再設計, gin導入。

設計変更

前回、一応はGraphQLとしてAPIの機能を作ったけど、開発中に清田に設計ミスに気付いたので修正する。

結論としてはエンドポイントを/adminと/viewerの２つに分ける。 実際、ブログサービスを行うなら、管理者(admin)と一般の閲覧者(viewer)が存在する。 adminの方はアクセス制限をつける。一方で、viewerは同然ながらつけない。

また、同じ記事(Article)の値であってもadminでは非公開記事も取得できるようにしたい。

というわけで再設計する。前回まではGraphQLエンドポイントは１つだけであったが、今回は前途の通り/admin, /viewerの２つ作る。裏側のプログラムは共通項は多い物のエンドポイントは別にする。

gin導入

GraphQLはgengqlで実現するけど、HTTP Webサーバはginを導入する。

github.com

上記の通り、adminは認証機構とかをつける。その時にこういうウェブフレームワークがあったほうが手っ取り早いと考えたため。

実装

というわけで今回のプルリク。まだ内容や認証機能はつけてない。

github.com

以下、広告

Goプログラミング実践入門　標準ライブラリでゼロからWebアプリを作る impress top gearシリーズ

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

Go言語による並行処理

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

ファイナルファンタジーVII リメイク - PS4

ファイナルファンタジーVII リメイク アルティマニア (SE-MOOK)

8日目: GraphQLの中身を仮実装

中身を書く

前回、GraphQLのスキーマ設計を行って、それに伴うGo言語のコード生成まで行った。

その後引っ越しやらなんやらで、時間が空いたけど今日から改めて続きを作る。

新居きた pic.twitter.com/ouEQQew5jF

— よこやま (@hiroyky) 2020年6月2日

今回はやったことは以下の通り。

複数取得できる項目を定義

実装の前に、もう一度GraphQLのスキーマ定義を改修。前回はプライマリキーで1件取得するだけの定義だったけど、せっかくなので複数取得できる項目も設ける。 ページネーションや絞り込みをつけるべきなんだけど今回はいったん無し。まずは実装するというところまで持って行きたいから。

あと、一般の読者がリクエストするためのエンドポイントと管理人(筆者)がリクエストためのエンドポイントが別々で必要になりそう。そのため2つスキーマ定義が必要になるような。。（絶対なる）だから今回はホントに仮。（←やる意味あるか？）

ちなみに、ページネーションはGraphQLでよく使われるカーソル式の方法ではなく一般的なlimit, offsetで指定する形式にする。バックエンドのデータベースがMySQLということもありlimit, offsetの方が相性が良いとも思うんだよね。カーソル式はツイッターやfacebookのタイムラインのように常にデータが挿入され流れ続けているような案件には相性良さそうだけど、MySQLのように整形されたデータで全件数も簡単に取得できたり、ソートもできたりするデータベースではせっかくのデータベースのメリットを殺しちゃう気がするんだよね。

あくまでも僕の持論だし、将来的に変わるかもしれないし、意見あったら教えてほしけど。

• いわゆるNoSQL: カーソル式なスキーマ設計
• リレーショナルデータベース: limit, offsetなスキーマ設計

ってかんじかな。

MySQLへの接続口

Go言語のアプリケーションからMySQLへ接続する部分とかを作る。 以前導入したMySQLのORマッパーはMySQLの接続機能を持っているのでそれを利用する。

SQLBoilってやつなんだけどね。設定でadd-global-variants=trueとしたから最後に”G”がつく関数も生成されてる。コレを使うとどこからでもMySQLにアクセスできるようになる。シングルトン的な実装になるのかな。賛否はあるだろうけど毎回データベースのインスタンス変数を持ち歩くのは面倒なのでコレを使う。

接続上を管理するために.envも導入。

GraphQLのResolver

GraphQLで実際の処理を書くresolverを書いた。 ちなみに、GraphQLではIDを「Article-1」や「Article:1」のように「項目名：番号」の形式の文字列のbase64エンコードされた文字列をIDとするのがなぜか一般的なのでその慣例に合わせる。（それ用の関数も書くと）

前述したとおり、多分スキーマ定義自体かあらぶっ壊すことになると思うけどいったんここまで。

今回のプルリク

github.com

github.com

github.com

以下、広告

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

RDB技術者のためのNoSQLガイド

最新モデル Apple iPad Pro (11インチ, Wi-Fi, 256GB) - シルバー (第2世代)

7日目：GraphQLのことはじめ

GraphQL

APIはなぜかGraphQLで実装することにしたので導入する。 GraphQLはこちらのライブラリを使って導入を行う。

公式のGet startedはここ。 gqlgen.com

下記コマンドでスケルトンが生成される。はじめの一歩のためのファイル群が生成。（正直言うと不要なファイルが多い）

go run github.com/99designs/gqlgen init

(生成されたファイルが以前と少し違う期が。。。) 直下に生成された gqlgen.ymlに沿って作られる。

1行目に // Code generated by github.com/99designs/gqlgen, DO NOT EDIT. って書かれてるファイルは文字通り自動生成なので編集はしない。

ここに書かれたとおりの設定ファイルが生成され、これにそってファイルが生成された。 gqlgen.com

以下ファイルが作られたみたい。

• gqlgen.yml
• servier.go
• graph/

このままでも良いけど、ちょっとgqlgen.ymlの設定を変更。

↓のようにしたからgraph-schema/配下に拡張子*.graphqlでGraphQLのスキーマ定義を書く。

schema:
  - graph-schema/*.graphql

また、生成されたGraphQLのモデルファイルはdomain/gqlmodelに設置するのが個人的な好み。

加えてgraph-schema配下にまずは基本的なスキーマ設計を書く。

rm -rf graph
go run github.com/99designs/gqlgen

いったんここまででプルリクエスト： github.com

以下、広告

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

6日目：スキーマ定義を少し変更する

スキーマ定義を少し変更する

前にシンプルなデータベース定義したけど、こんなようなツイートを見かけまして、ちょっとこの3つの項目を追加しようと思った次第。 たしかに、あった方が良い。

status→[下書き、公開、限定公開、ボツ]
description→概要(metaタグにも入れる)
thumbnail_path→サムネのパス

— なりたん＠節約チャレンジ中 (@naritancorp) 2020年5月28日

というわけで追加して改めてモデルを生成。

今回のプルリク： github.com