フラットパッケージは正義か？ 私が SNS で何度か言及した以下の記事がある。 フラットパッケージ戦略は，確かに Go の文化圏においては一定の支持を集めている。Go の公式リポジトリや有名ライブラリなんかも，Java などの言語に比べたらずっとパッケージ階層が浅く，ネストしていないものが多いと思う。 しかし，それも 「コードベースを小さく保つ」 を大前提としていることを忘れてはならない。 DDD やクリーンアーキテクチャといった言葉が飛び交うぐらいの規模であれば，パッケージを切ることに関して後ろめたさを感じる必要はない。 むしろ，大きなコードベースが誕生することが開発初期から簡単に予見できるような状況で， YAGNI という言葉に甘んじて設計を放棄するのは極めて悪手であると私は断言する。身を以て失敗を経験した私の口から伝えたい。
半年前くらいからGAE/Goを結構触っているので、ちょっと書いておく。 今回は、CloudStorage上のファイルをGAE/Goで配信する方法。 概要 GoogleCloudStorageにおいてるファイル（例えば画像）をWebサービス上でユーザに配信したいということがある。 画像ならブラウザ上で表示させるだけでいいかもしれないし、その他のファイルならダウンロードさせたいし、複数ファイルならzipで固めて配信したい。 イメージ cloud.google.com/go/storageのライブラリを利用する。 以下の例では、エラー処理などは省略する。また、普段はEchoを使ってるので以下のコードは試してないし正しく動かない部分があるかも。 コード例 画像を表示させる 画像をブラウザで表示させるケース。 特に難しい部分はなく、シンプルに書ける。 検索して出て来るサンプルだとioutil.Rea
先日公開した Web API サービス Pixelaは、Google App Engine 上で Go Web Application として動いている。Go のバージョンには特に気を使わずに開発をしてたんだけど、GAE で Go の 1.11 がサポート（まだ β だけど）されたこと、そして Go 1.11 であれば GAE Standard Environment で System Package として imagemagick が使えそう（svg → png 変換がしたい）ということもあって、Go 1.11 へのモチベーションが俄然上がったので、今回移行してみた。このエントリは、その際にやったことのまとめメモ。 Before Go 1.9.4 パッケージ管理はなにもしてない状態（ひどい） After Go 1.11.1 パッケージ管理に Modules を使用 やったこと goenv
これは本当に軽微なメモなんですが、GAEでGo1.11を使うために移行をしたことで、認証が動かなくなっていることに気づくのが遅れてしまいました。他の人がそうならないように記録しておきます。 これまで仮にGAE/GoでFirebaseの認証機構を使っていたとして、今までだとGAE/GoでのFirebaseクライアントの初期化はこのようにすればよかった。 もっと詳細に書くと、AppEngineのcontextを含んだ状態でurlfetchを呼び出してさえいれば、Firebaseのサービスアカウントの情報を明示的に指定しなくてもよかった。 opt := option.WithHTTPClient(urlfetch.Client(ctx)) app, err := firebase.NewApp(ctx, nil, opt) if err != nil { ... }これからGAE/Goが2nd
Working with Rust, TypeScript, React.js. Focusing on distributed systems, microservices, AI, CUDA, graphics programming, osdev, and no-code.
GoにはWebサービスを作るためのフレームワークがそれなりの数存在している。 Awesome Go - Web Frameworks ただ、そこまでデファクトというものがあるわけではなく、他の言語と比べると少々乱立気味なのではないかな、という感想を持っている。この記事ではnet/httpを主軸に据え、取替可能な部品となるライブラリを利用してAPIサーバーを作成する方法を紹介する。 長くなりそうなので記事を分けて紹介する予定だけど、今日はアプリケーショングローバルな値をどのように保持するのが良いのかについて書く。 アプリケーショングローバルな値 APIサーバーにはそのアプリケーションにおいてグローバルな値を保持しておきたいケースが多い。例えばAPIサーバーの設定情報だったり、外部APIにアクセスするクライアントだったり、DBへのコネクションだったり、loggerだったり。そういったものを初期
はじめに Go 言語の CLI フレームワークである cobra と設定ファイル導入支援ライブラリ viper を組み合わせて利用すると CLI ツール作成が大変楽になる。 本家のドキュメントは充実したものではあるが簡単な Example があると嬉しいと感じたので、cobra と viper を連携させて利用する方法について逆引き形式でまとめてみた。 cobra で hello world cobra で "hello world" を出力するだけの最小構成のコマンドを実装する。 package main import ( "fmt" "github.com/spf13/cobra" "os" ) func main() { rootCmd := &cobra.Command{ Use: "app", Run: func(c *cobra.Command, args []string)
(images: github.com/egonelbre/gophers) こんにちは。 データエンジニアリンググループ（CETチーム）の寺下です。 自分の所属するCETチームでは今まで主にScala、Pythonなどを使ってAPIや基盤を実装してきましたが、最近では徐々にGoによる実装も増えてきており、GAE/GKE上で本番運用を行っています。 本記事ではGoのプロダクトにおいてDDDライクなpackage構成で実装する際の注意点や、汎用的に通用するであろう実装のTipsについて書いていきます。 本記事で紹介する例がベストプラクティスだというわけではありませんので、あくまで実装の一例程度に捉えて頂けると幸いです。 Goのアーキテクチャ Goは言語仕様がシンプルかつフォーマッタが強力なため、syntaxレベルでは開発者によってコードの品質がブレにくいというメリットがあります。 しかしなが
こんにちは、メルペイのライブラリとか作るおじさんの @vvakame です。 インフラ編に続きGraphQL（API）編です。 MTC2018のカンファレンスLPのGraphQLによるAPI実装について紹介していきます。 リポジトリをこちらで公開しているので気が向いたら見ていってください。 Playgroundもあって、しばらくは生きている状態のままだと思います。 GraphQLやっていき 筆者は最近GraphQL、特にGo言語用のライブラリであるgqlgenに入れ込んでいます。 そこで、APIの実装にGraphQLを使うことによりgqlgenの使い方を社内に示し、ついでクライアント側の人たちにGraphQLの良さを体感してもらおう！という思惑です。 MTCでもCSToolをgqlgenでやっていき！という話題がありましたし！ …と思ったらアプリの人たちはFlutterを選び、Dartには
この記事は GraphQL Advent Calendar 2018 の22日目です。 どうも、HiCustomerのエンジニアの@m4s4k3xです。 GraphQLが広く使われるようになって久しいですが、弊社でも、以下の理由などからGraphQLを導入することにしました。 BFFを立てるほどのエンジニアリソースを割かなくてよい Union TypesやEnumと言ったスキーマの型表現が可能である エコシステムが豊富 大量のエンドポイントを増やさなくても良い 一度のリクエストでフロントエンドで必要なリソースが取得可能 Goにおいての採用事例もちらほら見かけるようになりました。GoにおけるサーバーサイドにおけるGraphQLライブラリはメジャーなものが5つほどあります。各々のライブラリの横断的に紹介した後、弊社での選定理由を紹介します。 GoにてGraphQLの導入を検討している方への助け
MF KESSAIでバックエンドのエンジニアをやっている@garsueです。 先日、社内向けサービスの新規開発でGraphQLを採用することになりました。 今回はその経緯や実装方法についていくつか参考記事を交えながら紹介していきます。 なぜGraphQLか 今回新規で開発するサービスは以下のような特徴があります。 MF KESSAIの内部は複数のサービスに分かれていて、それらをふんだんに利用する 社内向けなので直近でそこまで高負荷になる見込みはない フロントエンドとバックエンドのすり合わせにあまり時間をかけたくない（そんなに時間はない） まず複数サービスとの協調という点について、マイクロサービスをベースとしたGraphQLとGoによる開発を紹介した記事Using GraphQL with Microservices in Goにある内容をそのまま適用できそうだなというところからGraphQ
この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
