Gormを使用し、APIを作成した。 前回はAWSとNestJsだったので、今回はGCPを使用してみることにした。 Cloud Run 今回はCloud Runを使用することにした。 そもそもCloud Runとは、 フロントエンド サービスやバックエンド サービス、バッチジョブの実行、ウェブサイトやアプリケーションのデプロイ、処理ワークロードのキューへの追加を行います。インフラストラクチャを管理する必要はありません。 毎月 200 万リクエストは無料です。 Amazon ECSとAWS App Runnerと比較されることが多いらしい。 Amazon ECSとApp RunnerとCloud runの比較 特筆すべきは無料枠があることな気がする。 デプロイ そんなCloud Runにデプロイしていく。 クイックスタート: Cloud Run に Go サービスをデプロイする 公式が丁寧なのでこれに沿っていく。 ちなみに前提は下記の通りになる。 Goで既にAPIを作成している フレームワークは未使用 Goのバージョンはgo 1.21.4 ローカルでサーバーを立ち上げる時はnet/httpを使用した。 アカウント作成 まずはアカウントを作成する必要がある。 アカウントを作成する 作成後、 プロジェクト セレクタ ページで、Google Cloud プロジェクトを作成する。 プロジェクト名を作成するだけで作成が完了する。 次に課金が有効になっていることを確認する必要がある。 課金が有効になっているか確認する 課金が有効になっていない場合は、 「このプロジェクトには請求先アカウントがありません」 というポップアップが表示されるらしい。 Google Cloud CLI をインストール ここで問題がないようであれば、Google Cloud CLI をインストールする。 以下、Windowsでの方法になる。 参考；インストール手順 Google Cloud CLI インストーラをダウンロード。 インストール後は画面の指示に従い、進めていく。 全部、Next☞でやったけど問題なさそうだった。...

Cloud RunにGoで作成したAPIをデプロイしようと思ったところ、うまくいかなかった。 調査してみたところ、データーベースに接続できずに落ちているっぽいとのこと。 ちょっとなんでかわからないけど（今思い返せば、Docker起動していた？ という不安がある）、ローカルのDBに接続できないので、いずれ接続する予定だったので、Cloud SQLに接続し、それでCloud Runにデプロイしてみようという風に思い立った。 Cloud SQLに登録する Cloud Run から Cloud SQL for MySQL に接続するがある。 公式があるので、こちらを参考にする。 なお、今回サーバーはローカル（net/http）で起動することにする。 インスタンスを作成する Google Cloud コンソールで Cloud SQL の [インスタンス] (https://console.cloud.google.com/sql?hl=ja&_ga=2.145632700.968950133.1716041931-758618644.1700836939)ページに移動する。 インスタンスを作成 をクリック。 [MySQL を選択] をクリック。 インスタンスを作成するには、まず Compute Engine API を有効にする必要があります。 という警告が出るので、APIを有効にする。 インスタンスID、パスワード、を登録。 My SQLのバージョンを８にし、Cloud SQL のエディションはEnterpriseにする。 プリセットをいったん開発環境にして、リレージョンを東京、ゾーンをシングルに設定する。 構成オプションを開き、とりあえず一番小さい1 vCPU、3.75 GBを選択してみる。 で、インスタンスを作成する。 構成オプションはとりあえず、最小で不満があればあげていく方法で問題ないらしい。 DBの作成 インスタンスのデータベースにいき、データーベースの作成をクリックする。 今回インスタンスの作成をし、データーベースの作成をしていなかったので、エラーが出続け、悩まされた。 接続を試みる まず接続をしてみたところ、 $ go run main.go 2024/05/26 00:41:05 cloudsqlconn.NewDialer: failed to create default credentials: google: could not find default credentials....

作業中に新しい知識とか詰まった箇所、エラーの記録を取りたいと思うことがある。 今まではブログにずらずら書いていたけれど、結果、まとまりのない文章ができあがり、何にも活用することができないという状況が生まれていた。 ZennのScrapsを活用する？ そこでZennを活用することを考えメリットデメリットを考えてみた。 メリット 公開することができるので、自身のブランディングに活用できる コメント機能で他人の知見をシェアしてもらうことができる 結果的にほかの人のScrapsを見るようになり知見が広まる 他人の助けになることもある デメリット 公開されるので、ソースコードにぼかしを入れる必要がある ScrapsはGitで管理ができない こうやって見るとメリットのほうが多いけど、デメリットが許容できなかった。 ただこれが許容できないとなると、コンテンツの公開がされるサービスは使用できない。 GithubのIssue💡 そこで思いついたのがGithubのIssueだった。 そもそもScrapsもIssueを参考にしているだろうし、機能的には問題ない。 しかもこのブログもGithubで管理されており、同リポジトリ内に作成すれば検索も強い。 そういうことでGithubで管理することにした。 プライベートリポジトリに 公開はしたくなかったので、リポジトリをプライベートに変更した。 そのためGithub Pagesが使えなくなったので、ホスティング先をnetlifyに変更した。 移行はHost on Netlifyの通りやれば難なく完了できる。 https://blog.nove-b.dev/ URLが少しダサくなったけど、カスタムドメインを適用するほどじゃないかなといった感じなので、このままいくことにした。 これで少しでもレベルアップできるといい。 ☆カスタムドメインに対応した Cloudflare Registrarでドメインを登録し、Netlifyのサーバーにサブドメインを当てる

API作成が一段落した Goの勉強でAPIを作成してきたが、やっと一段落した。 そこでアプリ側から叩こうとした結果、エラーが出たので原因を理由を調査してみた。 Goで立ち上げたサーバ http://localhost:8081/api/v1/endpoint のローカルIPアドレス http://172.19.176.1:8081/api/v1/endpoint にReact Nativeで作成したアプリからアクセスしてみる。 ネットワークリクエストが失敗しました 結果、 TypeError: Network request failed というエラーが出力された。 ファイアーウォールが関係している？ 【react-native】シュミレータでAPIアクセスを行う際にnetwork errorの記事を参照するに、CORSかしらって思ったけど、アプリでCORSはちょっと違う気がする。 アプリにドメイン存在しないので、どのドメインを許可すればいいのっていうことになる。 で、色々調査していると、ファイアーウォールが関係している気がしてきた。 Windows向けプログラムに搭載されているファイアウォール（パーソナルファイアウォール）機能は、ネットワークプリンターや他のコンピューターとの通信を遮断する場合があります。その場合は、該当する通信を許可するルールを作成することで、通信ができるようになります。 https://eset-support.canon-its.jp/faq/show/235?site_domain=default ポートを開放すればいける感じかもしれないけど、せっかくだしサーバーにあげてみることにした。 どうせいずれあげる必要があるしね。

PUTとPATCHの違いをあまり気にしてこなかった 基本的にフロントエンドなので、仕様書に書かれているメソッドでAPIと通信してきた。 ただ今回、自身が作る側に回り、PUTとPATCHの違いがいまいちピンとこなかったので、調べてみた。 結論 PUTはリソースの完全な置き換えで、PATCHはリソースの一部分のみを更新する場合とのこと。 例えば、 { "name": "John Doe", "age": 30, "email": "john@example.com" } というデータがあり、31歳に変更する場合を考えてみる。 PUTの場合 PUT /users/123 HTTP/1.1 Host: example.com Content-Type: application/json { "name": "John Doe", "age": 31, "email": "john@example.com" } といった感じに変更した年齢以外もまるっと送る必要がある。 PATCHの場合 対してPATCHの場合は、 PATCH /users/123 HTTP/1.1 Host: example.com Content-Type: application/json { "age": 31 } となる。 どっちを使うべきか まあ、この感じだと一部だけを更新したい場合はPATCHを使用するべきなんだと思うけど、その場合はフォームの一部だけが変更されたという監視が必要になるので、それなりの工数がかかる。そのためPUTでいいかなといった結論になりました。