Go言語のフレームワークGinをやってみる
チュートリアルっぽいのがあったので、それをやってみます。
最近の心がけとして、なるべく公式コンテンツから着手してみることにしています。
最近もNext.jsを学習していたのですが、今までだったらUdemyで手頃な講座を見繕って進めていたと思うのですが、そういうのって結局公式のチュートリアルを解説しているだけのものだったりするので、だったらまずは公式チュートリアルをやってみようと思った次第です。
講座だと情報が古いし、習得したい技術に必ずしも日本語講座が有るとも限らないので、中長期的に見て公式情報から習得する術を身に着けたいです。
ということで、Ginのチュートリアルっぽいのを公式から見つけました。
これを進めていきます。
終わりました。
RESTfulのルーティング関連をうまく処理できるようにしてくれているのがginっていう認識です。
そんなに多くのことをやっていないような気もしています。まだそこまで踏み込んでいないだけかもしれないですが。
このチュートリアルではメモリでデータの管理をしていたので、DBとデータをやり取りするってなるともう少し量も増えてくるのかなと思います。
とはいえ、そうなってくるとそっちはDB連携用の別のパッケージとかライブラリとか使うことになるのだと思うので、Ginの責務的には、ルーティングして特定の関数を呼び出すこと？だけなのかなっていう感じ。
さて、Ginが何となくわかったので、そろそろ本来やりたいwebサービス開発に着手できるかな？
フロントエンド初心者がNext.jsを習得してみる
チュートリアルをやっていきたいと思います。
https://nextjs.org/learn/basics/create-nextjs-app
しかし、英語しかないのか？
https://nextjs-ja-translation-docs.vercel.app/docs/getting-started
一応非公式日本語翻訳サイトはあったが、これは新鮮なのか？
これは、新鮮かどうか以前にチュートリアルはないっぽい.
本家英語サイトをDeepLを駆使して読んでみるか。
そろそろ日本語やってみた記事を読むレベルから脱却したいので。
ページまるごと翻訳だとDeepLだと有料なので、なくなくGoogle翻訳で対応することにした。
月額750円はちょっと高い、、300円なら考えた、、！
しかし、ぱっと見Google翻訳でも精度悪くなさそう。よし。
チュートリアルを進めていく
全体像把握
ブログアプリを作るチュートリアル
- Next.js アプリを作成する
- ページ間を移動する
- アセット、メタデータ、CSS
- 事前レンダリングとデータ取得
- 動的ルート
- API ルート
- Next.js アプリのデプロイ
このあとも検索エンジン最適化の章もありましたが、そこは一旦保留で良いかなと思います。
Next.js アプリを作成する
前提知識としてJavascriptとReactが必要とのこと。
Reactのチュートリアルやろうっかな。
3年くらい前に一度途中までやった気がする。同じチュートリアルかどうかはわからないけど。
Nextを途中まで進めてみて、React前提の知識が多すぎたら中断してReactのチュートリアルを進めることにする。○×ゲームを作るチュートリアル。面白そうだし、そんな大変でもなさそうなので。
やっちゃうか？2時間くらいで終わりそう。
やっちゃう。
https://ja.reactjs.org/tutorial/tutorial.html
ブラウザ上で実行できるplaygroundが用意されているので、それを使用します。環境構築は別途Next.jsで必要になると思うので。
チュートリアルやった。
最後の「タイムトラベル機能の追加」は流してやった。
いよいよ本番のNext.jsに入る。
Next.js チュートリアル
node.jsの確認
node -v v16.16.0
入っていた。
npx create-next-app nextjs-blog --use-npm --example "https://github.com/vercel/next-learn/tree/master/basics/learn-starter"
開発サーバーを立ち上げる
npm run dev
早っ！
これで
http://localhost:3000/
にアクセスするだけで表示できる。
indexページを変更。
変更がサーバーやブラウザの再起動をせずにすぐにブラウザに反映される。
これがFast Refleshという。ストレスなく開発できそう。
画像はいい感じにリサイズとかして配信してくれる。
ブラウザの表示領域(view-port)に来たときに読み込まれる。
サードパーティーのscriptの読み込みのタイミングも、ブラウザが暇なときにやってくれるオプションとかある。next/scriptでやる
Next.js用のvscode拡張機能を入れたい
JSXの部分を書くときにコード補完がうまく働いてくれない。
JS JSX Snippetsを入れてみる。
効かなさそうだな。。
https://www.servs.jp/emmet-setting-when-html-tags-are-not-completed-by-reacts-jsx-in-vscode-2215/ これだ、最高、ありがとう。
リンクのコードをバックグラウンドで自動的にプリフェッチしてくるので、ページ遷移が一瞬。
プリレンダリング データフェッチについて話す前に、Next.jsの最も重要な概念のひとつについて説明します。プリレンダリングです。
デフォルトでは、Next.jsはすべてのページをプリレンダリングします。これは、クライアントサイドのJavaScriptですべてをおこなうのではなく、Next.jsがあらかじめ各ページのHTMLを生成しておくことを意味します。プリレンダリングは、パフォーマンスとSEOの向上につながります。
生成された各HTMLは、そのページに必要な最小限のJavaScriptコードと関連付けられています。ブラウザがページを読み込むと、そのJavaScriptコードが実行され、ページが完全にインタラクティブになります。(このプロセスをハイドレーションと呼びます）。
メタデータを読み取るためのやつをinstall
npm install gray-matter
ローカルファイルストレージからデータを取得する。
Static Generation
静的生成はビルド時にHTMLをプリレンダリングする。プリレンダリングされたHTMLは、リクエストごとに再利用される。
サーバーサイドレンダリングは、リクエストごとにHTMLを生成するプリレンダリング方式。
ページごとにどちらの方式を使用するか選択することができる。
ユーザーダッシュボードとかはSEO関係ないし、CSRでいい。
クライアントサイトレンダリングは、ビルド済みのHTMLを返して、必要な部分だけクライアントが別途リクエストを送って、レスポンスをHTMLに組み込む。合ってる？
vscodeのdiffを見る拡張機能
https://pa-tu.work/blog/vscode-clipboard-diff
ファイル保存をしないでもdiffが取れる。
ファイル単位じゃなくて、同じファイルの中の選択した部分同士を比較することもできる。
これで正解コードと自分で書いたコードの差分を見てtypoとかをぱっと探せるようになった。
Module not found: Can't resolve 'fs' エラー
https://fullstacklife.net/programming/nextjs/nextjs-module-not-found-cant-resolve-fs/
これをみて、設定ファイル変更するかーと思ったけど、Next.js用のGithub Issueに回答があった。 https://github.com/vercel/next.js/discussions/12124
しかし、結論、チュートリアル内でどうすれば良いのかがわからなかった。
Next.jsにもう少し触れてみたら、ああなるほどねってなるのかもしれないが。
https://gotohayato.com/content/553/ これもちょっと、チュートリアルに当てはめて考えることができていない。全体を理解・把握していないからだ。
remarkのインストール
npm install remark remark-html
date-fnsのインストール
npm install date-fns
GoとNext.jsを使った個人開発アプリケーションの構成を構想する
参考記事①
Next.jsはVercelにデプロイ
GoはCloudRun
RDSはCloudSQL
という構成。うん。これが一番シンプルでいい気がする。
ほかも見てみます。
参考記事②
Go × Next.js × GraphQL というパターン。
これもまあある構成な気がしています。
これの場合、GraphQLってリソースって必要なんでしょうか？
GraphQLの位置づけがまだわかっていないです。
しかし、一度に色んな技術を盛り込みすぎると大変になりそうなので、一旦はGraphQLはなしで開発を進めてみて、リリースした後にGraphQLを入れ込んでみるのがいいかなと思っています。
なにかのつらみがあってGraphQLをみんな導入しているはずなので、そのつらみを一回小規模なサービスで経験しておいてから、だからこれが有るといいんだよと言えるようにしてみたいためです。
参考記事③
GraphQLは後回しにしようと思いましたが、この記事を見て半日ほどで学習したと記載あったので、一度どんなものなのかの概念だけ把握しておくのはありかなと思いした。
と思ったんですが、GraphQLの周辺ツールに1〜2週間くらいかかっていたので、やはり一旦保留です。
いや、GraphQLの雰囲気だけ掴んでおいて、実装はまたの機会ってことにするのが落としどころかな？
結論
ということで、シンプルにGo + Next.jsという構成にしてみたいと思います。 参考記事①の通りに
Next.jsはVercelにデプロイ
GoはCloudRun
RDSはCloudSQL
という構成でやってみようかと思います。
Goのフレームワーク選定
参考記事①
自前でスクラッチで書いてみるのもありか。
しかし、初手でスクラッチで書くのは諸刃の剣だなって気がしています。
挙動を理解できるので良いと思うのですが、いかんせん開発スピードが出ずにモチベーションが下がる可能性があります。
かつ、フレームワークが隠蔽してくれている処理をいちいち書く必要があるので、考えることが多いです。それ故に勉強にはなるのですが。
なので、今回はやはりフレームワークを使用したいと思います。
フレームワークをある程度使えるようになってから、スクラッチで実装してみて、そのときにフレームワークで色んなことをやってくれていたんだなぁとしみじみと感じるスタイルを取ることにします。
参考記事②
以前も調べていてGinが覇権穫りつつあるのかなと思っていましたが、再度確認。
これは思考停止でGinでいい気がします。
一応、Next.jsとGinの組み合わせで罠とかないかなと調べてみます。
APIサーバーとして使うので、サーバーサイドのフレームワークはNext.jsからした関係ないと思いますが。
参考記事③
Gin使ってますね。
というかこれ、開発環境と本番環境のインフラとかも説明してくれているので、すごく良さそうですそのあたりはまだちゃんと見ていないですが、あとで役立ちそうです。
ということで、GoのフレームワークはGinで 進めてみたいと思います。
どういう順番で手を付けるか
自分の現場としては、Goはローカルでスクラッチで簡単なTodoアプリは作ったことある。
Next.jsは全くのはじめまして、Reactはチュートリアルレベルだけかじったことがある、TypeScriptはReactとNestJSをちょっと触ったことがあるので、そのときになんとなく触ってみた。
くらいな感じです。
そもそもの開発の流れとしては、一回Next.jsとGoを疎通だけできるような状態にして、そこからページ単位（API単位）で機能を作っていく感じが正しいのかなって気がしています。
なんとなくフロント側で使いたいAPIを定義（想定）して開発して、それに合うようなAPIをバックエンドで開発するという流れなのかなと言う気がしています。
でも、そうするとフロントの動作確認とかはどうするんだろう？って気もしてます。
モックのデータだけ返すようなAPIを一時的にバックエンドでベタ書きの決め打ちとかで作って動作確認→問題なさそうならバックエンドで実装という流れなのかな？
いや、今回はとりあえず個人開発なので、両方同期的に開発できそうだからそこまで気にしなくてもいいっか。
railsのようなフルスタックフレームワークでもerbとcontrollerも両方いじりながら開発するので、そのノリで。
ただ、フロントとバックエンドでチームが分かれているサービスとかではどう進めていくのか気になるところです。
フロントが先な気がするな。
しかしここにGraphQLとかも入ってくるといよいよわからなくなってくるな。みんなで開発するのって大変だなぁ。
学習方法
Go(Gin)とNext.jsはそれぞれ独立して学習を進めて問題なさそうに思います。
一旦Next.jsを一通りやってみて、その後Ginも触る。
それが終わったらもうサービスの開発に取り掛かりたいと思います。
ようやく進められそうです。
10月末までにリリースを目指して開発を進めていきます！
今後使っていきたい技術
メモ書き程度に。
言葉の粒度はまちまちですが、以下を触ってみたいなと思っています。
どこかのタイミングでプロジェクトに入れ込めれば良いなと構想しています。
- GraphQL
- Firebase
- Go
- React(TypeScript)
- GCP
- テスト
- gRCP
- クリーンアーキテクチャ
- テスト駆動開発
- ドメイン駆動開発
- GithubActions
- k8s
Next.jsってどうなの？ フロントエンド初心者が調べてみた
自分の現在の技術スタック
インフラ: AWSを中心としたクラウドインフラはある程度理解している。GCPもちょっと
サーバーサイド: rails, cakephpなどのフルスタックフレームワークはわかる。言語はpython, ruby, phpなどが多め。
フロントエンド: rails等のテンプレートとしての使い方しか基本的にはわからない。以前ReactとかNustJSとかのUdemy講座はやってみて、なんとなくの書き方等の雰囲気はわかっているけど、具体的にどこで動かすのかとか、サーバーサイドとかとの連携はわかっていない。
背景
という前提で、今回Reactをやってみたいと思って、その中でも色んな求人票を見ているとNext.jsがよく見るので、これを個人開発で使ってみたいなと思った次第です。また、サーバーサイドではGoを使ってみたいという条件もありました。
自分の技術力アップのために、静的型付け言語を一度やってみたいと思っており、サーバーサイド言語としては色々比較検討しましたが、これやっとけば間違いないでしょ的にGo、そしてフロントエンドもわかるようになって、一人で小規模なサービスなら作れるくらいになりたいと思い、何かしらに手を付けようと思いました。
VueかReact（他にもありますかね？）の中の選択肢で、qiitaのタグの数は同じくらいで、stackoverflowのタグの数は、reactが圧倒的に多くて（これはタグが分散されている問題もあるかもしれないです）、GoogleTrendでは2021年末あたりからreactの勢いが増してきているように見えました。
なので、reactを選んでおけば無難かなと思いました。
VueとReactでは、自分の印象ではVueの方がReactよりも習得難易度がちょっと低いという認識でしたが、ReactはReact Native？とかでスマホアプリも作れるとのことで、これを使えるようになったら幅が広がりそうだなと思い、Reactを使ってみる前提で考えました。
そこで、単純に求人票などでよくNext.jsを見るなと思い、これに興味を持ちました。
しかし、そもそもNext.jsってなんなのか？Reactとの違いは？他のどんな技術と組み合わせることができるの？サービス運用のどの部分を担うの？どこで動くものなの？他に勢いのある競合技術はないの？本当にNext.jsの選択でいいの？
と、まだわからないことが多かったため、一度整理しつつ、個人開発にアクセルを踏めるようなところまで調べてみたいと思いました。
参考記事①
Next.jsとは、Reactをベースに開発された、フロントエンドフレームワークです
Next.jsとReactの1番の違いは、サーバー機能の有無です。Next.jsはサーバー機能を持っていますが、Reactにはサーバー機能がありません。つまり、Next.jsは単体でWebアプリを動作させることができますが、Reactは別途サーバーを用意する必要があります。サーバーを用意するということは、サーバー用のモジュールをインストールし、ディレクトリ構成などを検討する必要があるため、Reactのほうが学習コストや難易度が高くなります。
参考記事②
とても良くまとまっていて参考になりました。
Next.jsを使う際のユーザー的なメリットなど理解できました。
高速化とかSEOとかは今回は特にそこまで意識する必要がないので、どちらかというとアーキテクチャ的に作りやすいか、開発を高速にスムーズに行うことができるか？などの観点で見てみたいと思います。
まず、Reactがどういう構成で使われるかの把握からしたほうが良さそうです。
よく見るのはrails + reactという構成です。この場合、どんな計算リソースを用意してどこに何を配置するのかを整理したいと思います。
参考記事③
railsとreactを組み合わせる方法としても構成パターンはいくつか有るみたいです。
ただ、reactもとどのつまりJavascriptなので、クライアントサイド(ブラウザ)上で動きます。
railsのアプリケーションはサーバーにあり、reactをレンダリング？したJavascriptをhtml, cssと一緒にクライアントサイドに送って、その後ユーザーの挙動によってブラウザからreact部分がサーバーにリクエストを送ってサーバーからコンテンツを取得して、随時Javascript？で反映するというのがreactの仕組みのようです。
railsとreactを分割するパターンと分割しないパターンがあるようです。
他のreactを使ったアーキテクチャも見てみましょう。
参考記事④
python + reactを見てみました。
これもrailsと同じ考えですね。そりゃそうだって感じですが。
reactはクライアントサイドで動くものなので、サーバーサイドからAPIを返してくれるものは別途必要になるということですよね。railsなりpythonなりgoなり。(あるいはFirebase?ここの連携イメージが掴めていませんが)
となると、Next.jsはサーバーの機能があるものということで、サーバーサイド言語が別途必要ではないということでしょうか？
参考記事⑤
rails + Next.jsのパターン。
サーバーの機能があるとはいいつつも、Next.jsだけでサーバーサイドを完結させるのはあまり得策では内容です。DBとのやりとりが整備されていないため結構手間になると。なので結局reactと同じようにrails部分ではAPIの提供をして、フロントの描画をNext.jsという分け方にするのが吉のようです。
ここでGraphQLをその間にかませるという方法もあるようなのですが、GraphQL、単語としては頻繁に見かけるんですが、実際なのをやるものなのかわかっていなかったので、GraphQLについても少し調べます。
参考記事⑥
フロントエンドがAPIサーバーからデータを取得するときに、フロントがほしい形でデータを渡してくれるためのインターフェースみたいな役割を果たす、という認識です。
これをかまさないと、毎回全データ？がサーバーサイドから返ってきてしまうのでコストになると。
そのほか参考記事
ちょっと余談気味かつ古い記事ですが、従来の(railsのような)アプリケーション開発と、reactでの開発は頭を切り替えていかないと理解できないとのこと。reactを習得していく上でのつらみとかの雰囲気がわかりました。とはいえ、この記事から4年くらい経過しているので、今は色んな情報が溢れていて、そのあたりの概念の理解の助けになる記事は多くあるかと思います。
結論
このあたりまで自分で調べてみて、友人のフロントエンジニアに聞いてみたところ、やはりNext.jsでいいと思うとの進言をいただいたので、Next.jsで行きたいと思います。
周辺の技術はおいおい調べつつやっていきたいと思います。
goの型の恩恵をちょっとずつ理解してきた
今までは基本的にはPythonメインでやってきて、ruby,phpもやってきたが、それは全部動的型付け言語だった。
goをやってみる前は、型をいちいち書かなきゃいけなかったり、さくっとかけないことが結構めんどくさいんじゃないかと思っていたが、しばらく触ってみてその恩恵がようやくなんとなくわかるようになってきたような気がする。
本当に軽くスクリプトを書くぐらいだったら特に動的片付け言語でも問題はないが、割と軽めに作ったツールだとしても、どんどん自分で改良していくうちに関数内で自分が予期していなかったことが意外と出てくるなと気づいた。
特にこの関数内で自分が何をやろうとしているのか、と言うのを意識して書くように慣れてきた気がする。
関数内で何をやろうとしていると言うよりは、何をやるべきで何をやらないべきなのか、 関数の外の処理あるいは別の関数で処理するべき内容なのかということを意識するようになった。
まだまだチーム開発や大規模な開発で使った事はないが、それが大きくなればなるほどその恩恵を感じられるんだなぁと言うのはなんとなくわかってきた。
と、書いてみてなんとなくとかわかってきたような気がするとかそういった 表現が多いな。つまるところ、まだほんとにわかったとは言いきれてない状態の今日この頃。精進していきます。
自分の考えていることを逐一ひとりslack言語化してみるライフハック、良い。
最近エッセンシャル思考と言う本を読んで、自分のやるべき事が何なのかということを考えるようになった。
やるべきことと言うよりは、本当にやらなければいけないことのニュアンスに近いかもしれない。
コードを書いていると特に、今何やってるんだっけ、何のためにこれ解決しようとしてるんだっけということがよくある。
何も考えないで目の前のことをやっていると、課題Aを解決するための手段Bがあるとして、その手段Bを実現するための課題Cがあったりする。
ほんとに解決したい課題はAなのに、いつの間にかCの課題を解決することを目的としていたりすることがある。
いわゆるyak shavingというもの。
これを解決してみる方法として、ひとりslackチャンネルを作ってそこに書き込むと言うことをやっている。
「まずはデータが揃っているかの検証をやる」
「検証するためのクエリを作る」
「はい実行」
「そろっていなかったので、データを揃えるところから」
「本番DBからコピーしてくる」
「コピーする方法は、単純にAの方法でやってみるか、とりあえず」
「実行！」
「思ったよりも時間かかるかもな」
「どのくらい時間かかるか概算で出してみるか」
「うわ、これ4時間くらいかかるのでは？」
「そしたらちょっと面倒くさいけどBの方法でコピるか」
「はい、実行スクリプト完成、流してみる」
「はい、完了。こっちの方法で良かった」
「再度検証クエリ投げる。」
「はい成功。で、データが用意できたので、機能開発に入るか」
「まずは一番シンプルに全件取得」
「うごかす」
「良さそうなので、次、条件Aを適用する」
「OKそう。」
「次は条件Bを適用する」
「こちら問題なさそう」
「ここらへんの処理まとめられそうだけど、数も多くないし、一旦全部ベタでやってから最後にまとめてみるか、途中ハマる条件もありそうな気もしなくもないので」
「…」
みたいな感じで、誰に報告するのでもなくやっている。
これの良い所としては、あらかじめ自分がやろうとしていることを言語化するので、明確にそれをやろうと言う意思で作業することができること。
結局やろうとしてる事は変わらないのだけれども、そこから派生したタスクとかが出てきそうな時は一旦もともとやろうとしていたことを省みるということもできるので良さそう。
実行したときの条件とかも書いてまとめておく癖をつけておくと、特に問題ないと思って何も 特に何も残さなかった場合に比べて、問題が発生したときに解決できるスピードが上がるかなと思う。
さっきどんな条件で実行したんだっけとか、これは1階試したっけとかがログとして残っているので良い。 もちろん何かを検証するときはそもそもそういったログを残すべきなんだろうが、そうじゃないこと、 ここではつまずかないでしょと言うところではいちいちログを残さないと思うので、ハマったときにあとからこれやっておいて良かったなと思うケースが多い。
後は、slackではタイムスタンプが勝手に押されるので、この作業にどのぐらいの時間がかかっているかというのも特にタスク管理ツールとか時間管理ツールみたいなものを使わなくてもわかる。結構細かくわかる。
今日1日やったことを振り返ってみる時に、出来上がったものを見てみると、全然はかどってないじゃん、全然仕事してないじゃんと思う事はよくあるのが、 こうしてログをとっておくと、 成果物を作るためにいろいろ調べたり、検証したりデータの用意をしたりとかそういった土台とか前段階の部分が意外と多いことに気づく
こうしたログを見た上で、この作業を結局必要なかったなとか、ここに時間かかりすぎてるなとか、これこんなに時間かけるんだったら別の方法でさくっとやればよかったんじゃないかとかそういった反省もすることができる。
ということで、このやり方はしばらく続けてみようと思います。
