TypeScriptなGraphQLサーバをGoにリプレースした
TypeScriptなGraphQLサーバをGoにリプレースした 3-shake Advent Calendar 2022の11日目です。 現在携わっているプロダクトではGraphQLを利用してフロント/バックエンドの通信を行っています。 7月に入社した当初はTypeScriptで開発が進んでおり、ある程度の機能が出揃っていましたが、チーム編成が変わったことによりGoが得意なメンバーがバックエンドを担当することになりました。 そこで既存のGraphQLサーバをGoにリプレースしたのでまとめます。 これまで 既存のGraphQLサーバはTypeScriptをベースに構成されており、以下のようなパッケージを採用していました。 NestJS Prisma NestJSの拡張機能でGraphQLを取り扱い、Prismaで定義したスキーマを利用して永続化を行っていました。 これから 技術選定 Goへ
コンテナイメージを使用して Go Lambda 関数をデプロイする - AWS Lambda
provided.al2 AWS ベースイメージの使用 Go は、他のマネージドランタイムとは異なる方法で実装されています。Go はネイティブコードにコンパイルされるため、Lambda は Go をカスタムランタイムとして扱います。カスタムランタイムの用の provided.al2 ベースイメージを使用して、Lambda 用の Go イメージをビルドすることをお勧めします。イメージに Lambda との互換性を持たせるには、イメージに aws-lambda-go/lambda パッケージを含める必要があります。 非 AWS ベースイメージを使用する Alpine Linux や Debian など、別のコンテナレジストリの代替ベースイメージを使用することもできます。組織が作成したカスタムイメージを使用することもできます。イメージに Lambda との互換性を持たせるには、イメージに aws
ruby trunk changes を git notes で閲覧する方法 2022版 - ruby trunk changes
最初に説明抜きで結論を CRuby のリポジトリを git で clone した working copy で以下を実行します。 git remote add ruby-trunk-changes https://github.com/nagachika/ruby.git git config --local remote.ruby-trunk-changes.fetch '+refs/notes/commits:refs/notes/ruby-trunk-changes' git config --local notes.displayRef '*' git fetch ruby-trunk-changes git の使いかたにはいろいろ個人の好みがあったりとか既存の設定との相性があると思うので、よりこまかく設定したい人や背景を知りたい人は以下の説明も読んでみてください。 背景 毎日 C
たのしいコーディングのための「CUPID」特性 - iki-iki
当初はちょっとしたSOLID批判のつもりが、「藪を突ついて蛇を出して」しまったのですが、物事はそこから具体的で目に見えるものへと発展しました。仮に、近頃はSOLID原則が役に立たなくなっているのだとしたら、何に置き換えればよいのでしょう？ あらゆるソフトウェアに通用する原則はあるのでしょうか？ そもそも「原則」とは何を意味するのでしょう？ 私は「仕事がたのしくなるソフトウェアならではの特性や性質がある」ということを確信しています。コードでそのような質が高まれば高まるほど、仕事もどんどんたのしくなります。しかし、何事もトレードオフですから、自分の置かれている状況をつねに考慮する必要があります。 そうした特性はたくさん存在しており、互いに重なりや関連がありますし、説明の仕方もさまざまです。ここでは私がコードで気にかけている要素を強く支えていると思える5つを選びました。選ぶ数はこれぐらいが丁度良
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
