GoのGraphQLライブラリのgqlgenのGetting startedをやってみた - 寝ても覚めてもこんぴうた
この記事は こちら をなぞってみた記事になります。 GraphQLをこれから始めたいという方におすすめ gqlgenを利用してGraphQLサーバを実装する方法です。 todoのリストを返却する 新しいtodoを作成する 完了したtodoをマークする ちなみにココからの手順はgo moduleを利用した方法になります。 プロジェクトの作成 プロジェクトのディレクトリを作成し、go moduleを初期化します $ mkdir gqlgen-todos $ cd gqlgen-todos $ go mod init # 必要に応じてパスを指定 サーバを構築します スキーマ定義します qglgenはスキーマファーストのライブラリです。 コードを書く前に、GraphQLスキーマ定義言語を使用してAPIを記述します。 以下のようなschema.graphqlというファイルを作成し、initコマンドに
Goでmain関数経由でもベンチマークする - 寝ても覚めてもこんぴうた
Goはテストの機能としてベンチマークを測定する機能が標準で提供されています。 ただ、そのままだとテストコードを実行できる環境でしか実行ができなかったりするため、 main関数から実行したい場合もあるかと思います。 今回はmainからベンチマークを実行できる機能を調べてみました。 Goが標準に提供しており、Appengine上で実行するなどの目的で使えます。 通常のベンチマーク 通常のテストコードから実行するベンチマークは以下のような感じですね package main import ( "testing" "time" ) func Benchmark_Sample(b *testing.B) { b.ResetTimer() for i := 0; i < b.N; i++ { // 遅い処理 time.Sleep(10 * time.Millisecond) } } go test -
今日 (2019/09/10) 現在のGAE/goをUPDATEする際の注意点、俺まとめ - 寝ても覚めてもこんぴうた
Appengine/goが過渡期とでもいいましょうか、 日々変化も目まぐるしく、いろいろ気をつけるべき点もありそうなので雑にまとめました。 ご参考まで。（2019/09/10現在） GAE/go 1.9 は終わり 画像のとおりです。 警告: Go 1.9 ランタイム バージョンは非推奨になりました。2019 年 10 月 1 日以降、新しいデプロイではこのバージョンを使用できなくなります。2019 年 10 月 1 日までに、Go 1.11 または Go 1.12 を使用するようにアプリケーションをアップグレードしてください。 とあるので、今年の10月1日以降はgo1.9でのデプロイは不可能になります。 すでにデプロイしているものは動くんじゃないか（未確認）と思いますが、速やかに移行しましょう。 go1.11 への移行は比較的容易だと思います。（appengineパッケージも利用できるので
モノレポ（mono repository）内でmodで管理しているアプリケーションをGAEにデプロイするために必要な2つのポイント - 寝ても覚めてもこんぴうた
前回は モノレポ（mono repository）内でgoのmoduleを相対パスで利用する方法 という記事を書きましたが、今回はさらにモノレポで管理しているAppengineの複数のサービスをデプロイする方法になります。 なぜGAEのデプロイの記事が必要？ 前回の記事を試した方がいるかいないかは不明ですが、モノレポ内でmodで依存を解決したものをデプロイした場合、modを利用したデプロイ（GO111MODULE=on）ではGCP上のCloudBuild上でコンパイル（依存の解決）を行うため、相対的に管理しているモジュールを取得することができないためエラーになり、デプロイが完了しません。 なので、今回はサンプルも作り、丁寧に説明したいと思います。 サンプルのソースコードはこちらになります。 https://github.com/chidakiyo/benkyo/tree/master/ap
コンテナでgcloudコマンドを実行するとERROR: gcloud crashed (UnicodeDecodeError): 'ascii' codec can't decode byte 0xe8 in position 1: ordinal not in range(128) みたいなエラーが出る - 寝ても覚めてもこんぴうた
タイトルの通りで、 コンテナ環境で gcloud コマンドを実行した際 ERROR: gcloud crashed (UnicodeDecodeError): 'ascii' codec can't decode byte 0xe8 in position 1: ordinal not in range(128) のようなエラーが発生してうまく実行できない。 なぜ glcoudコマンドの中でpythonを実行しているようなのですが、処理するファイルに非asciiな文字列が含まれている場合、pythonのレイヤーでエラーが出ているようです。 これはgcloudコマンド特有の問題ではなく、コンテナ内で各種コマンドを実行した際のあるあるです。 （昔一度ハマったのにまたハマったので記事にしました） 対策 解決方法としては、一番手っ取り早いのは export LANG=C.UTF-8 のような形で環
モノレポ（mono repository）内でgoのmoduleを相対パスで利用する方法 - 寝ても覚めてもこんぴうた
goの依存管理ツールはいろいろありますが、最新はGo Modules(mod)を利用することが多くなってきたと思います。 dep(vendor)を利用した依存解決の場合にはgopath配下にあればある程度柔軟に相対的に依存を解決できましたが、 modは普通に利用するとリポジトリにコミットをした状態を期待しているような振る舞いをします。 モノレポで以下のように複数のモジュールを管理している場合には、modでは利用しづらいように思えましたが、 参照しているモジュールをコミットした状態ではなくとも参照したいという要望があったので解決してみました。 project ├ a_module │ ├ go.mod │ └ main.go ├ b_module │ ├ go.mod │ └ hoge │ └ say.go ... 各モジュールをmod化する 各モジュールをmod化します。 mod init
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
