強い思想: Go を Web 開発に採用する上で
Go は Web 開発に向いているか？ 最も向いている領域は「CLI ツール」「ミドルウェア」「マイクロサービス」だと思っている。なぜならそれらはコードベースを比較的小さく抑えることを前提としているからだ。 Go は大きなコードベースを抱えやすい設計の言語になっていない。 ミドルウェアとマイクロサービスに関しては小さく作ることが正義。 CLI ツールに関しては単一責務なツールであれば小さくなるが，複数を束ねるツールであっても Web サービス開発に比べれば考えることは少なくて済む。 Web 業界における「一般的な Web 開発」，すなわちモノリスを基本とした中規模以上の開発にははっきりと 向いていない と言うべきだろう。 フラットパッケージは正義か？ 私が SNS で何度か言及した以下の記事がある。 フラットパッケージ戦略は，確かに Go の文化圏においては一定の支持を集めている。Go の
GoogleAppEngine/GoでCloudStorageのファイルを配信する方法とハマりどころ - tjun月１日記
半年前くらいからGAE/Goを結構触っているので、ちょっと書いておく。 今回は、CloudStorage上のファイルをGAE/Goで配信する方法。 概要 GoogleCloudStorageにおいてるファイル（例えば画像）をWebサービス上でユーザに配信したいということがある。 画像ならブラウザ上で表示させるだけでいいかもしれないし、その他のファイルならダウンロードさせたいし、複数ファイルならzipで固めて配信したい。 イメージ cloud.google.com/go/storageのライブラリを利用する。 以下の例では、エラー処理などは省略する。また、普段はEchoを使ってるので以下のコードは試してないし正しく動かない部分があるかも。 コード例 画像を表示させる 画像をブラウザで表示させるケース。 特に難しい部分はなく、シンプルに書ける。 検索して出て来るサンプルだとioutil.Rea
GAE/Go アプリケーションを Go 1.11 に移行するためにやったこと - えいのうにっき
先日公開した 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/Go 2nd genでのFirebase Authの注意点 – timakin – Medium
これは本当に軽微なメモなんですが、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
Using GraphQL with Microservices in Go - Outcrawl
A few months ago, a really nice Go package vektah/gqlgen for GraphQL became popular. This article describes how GraphQL is implemented in "Spidey", an exemplary microservices based online store. Some parts listed below are missing, but complete source code is available on GitHub. Architecture Spidey encompasses three services that are exposed to the user through a GraphQL gateway. Communication wi
net/httpで作るGo APIサーバー #1
GoにはWebサービスを作るためのフレームワークがそれなりの数存在している。 Awesome Go - Web Frameworks ただ、そこまでデファクトというものがあるわけではなく、他の言語と比べると少々乱立気味なのではないかな、という感想を持っている。この記事ではnet/httpを主軸に据え、取替可能な部品となるライブラリを利用してAPIサーバーを作成する方法を紹介する。 長くなりそうなので記事を分けて紹介する予定だけど、今日はアプリケーショングローバルな値をどのように保持するのが良いのかについて書く。 アプリケーショングローバルな値 APIサーバーにはそのアプリケーションにおいてグローバルな値を保持しておきたいケースが多い。例えばAPIサーバーの設定情報だったり、外部APIにアクセスするクライアントだったり、DBへのコネクションだったり、loggerだったり。そういったものを初期
逆引き cobra & viper - Qiita
はじめに 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)
Goのpackage構成と開発のベタープラクティス
(images: github.com/egonelbre/gophers) こんにちは。 データエンジニアリンググループ（CETチーム）の寺下です。 自分の所属するCETチームでは今まで主にScala、Pythonなどを使ってAPIや基盤を実装してきましたが、最近では徐々にGoによる実装も増えてきており、GAE/GKE上で本番運用を行っています。 本記事ではGoのプロダクトにおいてDDDライクなpackage構成で実装する際の注意点や、汎用的に通用するであろう実装のTipsについて書いていきます。 本記事で紹介する例がベストプラクティスだというわけではありませんので、あくまで実装の一例程度に捉えて頂けると幸いです。 Goのアーキテクチャ Goは言語仕様がシンプルかつフォーマッタが強力なため、syntaxレベルでは開発者によってコードの品質がブレにくいというメリットがあります。 しかしなが
MTC2018 カンファレンスLPの裏話 〜GraphQL編〜 - Mercari Engineering Blog
こんにちは、メルペイのライブラリとか作るおじさんの @vvakame です。 インフラ編に続きGraphQL（API）編です。 MTC2018のカンファレンスLPのGraphQLによるAPI実装について紹介していきます。 リポジトリをこちらで公開しているので気が向いたら見ていってください。 Playgroundもあって、しばらくは生きている状態のままだと思います。 GraphQLやっていき 筆者は最近GraphQL、特にGo言語用のライブラリであるgqlgenに入れ込んでいます。 そこで、APIの実装にGraphQLを使うことによりgqlgenの使い方を社内に示し、ついでクライアント側の人たちにGraphQLの良さを体感してもらおう！という思惑です。 MTCでもCSToolをgqlgenでやっていき！という話題がありましたし！ …と思ったらアプリの人たちはFlutterを選び、Dartには
GoにおけるGraphQLライブラリ大横断 | HiCustomer Tech Blog
この記事は GraphQL Advent Calendar 2018 の22日目です。 どうも、HiCustomerのエンジニアの@m4s4k3xです。 GraphQLが広く使われるようになって久しいですが、弊社でも、以下の理由などからGraphQLを導入することにしました。 BFFを立てるほどのエンジニアリソースを割かなくてよい Union TypesやEnumと言ったスキーマの型表現が可能である エコシステムが豊富 大量のエンドポイントを増やさなくても良い 一度のリクエストでフロントエンドで必要なリソースが取得可能 Goにおいての採用事例もちらほら見かけるようになりました。GoにおけるサーバーサイドにおけるGraphQLライブラリはメジャーなものが5つほどあります。各々のライブラリの横断的に紹介した後、弊社での選定理由を紹介します。 GoにてGraphQLの導入を検討している方への助け
Go + gqlgenを使ったGraphQLアプリケーションサーバーの実装 | Money Forward Kessai TECH BLOG
MF KESSAIでバックエンドのエンジニアをやっている@garsueです。 先日、社内向けサービスの新規開発でGraphQLを採用することになりました。 今回はその経緯や実装方法についていくつか参考記事を交えながら紹介していきます。 なぜGraphQLか 今回新規で開発するサービスは以下のような特徴があります。 MF KESSAIの内部は複数のサービスに分かれていて、それらをふんだんに利用する 社内向けなので直近でそこまで高負荷になる見込みはない フロントエンドとバックエンドのすり合わせにあまり時間をかけたくない（そんなに時間はない） まず複数サービスとの協調という点について、マイクロサービスをベースとしたGraphQLとGoによる開発を紹介した記事Using GraphQL with Microservices in Goにある内容をそのまま適用できそうだなというところからGraphQ
Goのパッケージ構成の失敗遍歴と現状確認
この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
golang-samples/functions at main · GoogleCloudPlatform/golang-samples
もう一度テストパターンを整理しよう(WebApp編)
mtc2018-web/server at master · mercari/mtc2018-web