【Go言語】 webapp GO Part1 【Golang】 [無断転載禁止]©2ch.net

**nobodyさん** · 2016/07/27(水) 12:46:23.51

Go言語によるWebアプリケーション開発を語るスレです

公式
https://golang.org/
公式日本語訳
http://golang-jp.org/

チュートリアル
https://go-tour-jp.appspot.com/welcome/1

**nobodyさん** · 2017/11/17(金) 01:13:37.80

>>449
winにしか対応してないパッケージがあるの？
そんなんあるんだ。逆じゃなくて？

でもコントリビュートするチャンスじゃん

**nobodyさん** · 2017/11/17(金) 06:33:08.03

例えばコレとか
https://github.com/lxn/walk

**nobodyさん** · 2017/11/17(金) 14:19:54.06

A Windows GUI toolkitだから当たり前じゃね

**nobodyさん** · 2017/12/11(月) 21:42:54.88

GAE/Go　Datastoreライブラリ
https://speakerdeck.com/vvakame/golang-dot-tokyo-number-11
https://medium.com/@timakin/mercari-datastore%E5%AE%9F%E6%88%A6%E6%8A%95%E5%85%A5-a7211c56b77a

良いな
GAE/Goの発展に寄与してくれるメルカリに感謝

**nobodyさん** · 2017/12/11(月) 21:44:30.85

Using GopherJS with gRPC-Web
https://blog.gopheracademy.com/advent-2017/gopherjs-grpc-web/
これもいいな

**nobodyさん** · 2017/12/11(月) 22:05:33.86

インフラエンジニア分の人件費を完全にカットできるからROE高そうだな
10人くらいのチーム規模で月商5億くらいのサービス支えられそう
少数精鋭でいけるのが大きい

**nobodyさん** · 2017/12/12(火) 07:10:14.14

goon と gosto を統一したようなパッケージなのか
便利そうだな
俺も使ってみよう

**nobodyさん** · 2017/12/15(金) 18:12:01.27

インフルエンザ

**nobodyさん** · 2017/12/17(日) 06:40:28.92

https://qiita.com/koki_cheese/items/369cdfc6e3250185ccdb
この記事を見ながらGoogle App Engine上でgRPCを動かすテストをしているのですが
Windows環境だとproto_gen.shが動きません
https://github.com/k2wanko/gae-grpc-web/blob/master/build/proto_gen.sh

--plugin=protoc-gen-go=${GOPATH}/bin/protoc-gen-go \
この部分で指定されたファイルが見つからないエラーが出ているみたいですが
その場所にちゃんとprotoc-gen-go.exeは存在していますし、環境変数にGOPATHもしっかり設定されていました

やっぱりMac買ったほうが良いんでしょうか…
windowsだと本筋とは関係のないエラーに遭遇しまくりで萎えてしまう

**nobodyさん** · 2017/12/17(日) 07:51:55.80

'.' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチファイルとして認識されていません。

あぁ謎…

古いMacbookでテストしたら普通に動作しました…
Windowsで開発はやめときます

**nobodyさん** · 2017/12/30(土) 12:18:41.21

誰でも簡単にネットで稼げる方法など
参考までに、
⇒　『半藤のブブイウイウレレ』というサイトで見ることができます。

グーグル検索⇒『半藤のブブイウイウレレ』

6BTU26N0P5

**nobodyさん** · 2017/12/30(土) 15:35:17.77

保守

**nobodyさん** · 2018/01/19(金) 16:39:42.00

twitchtv/twirp いいよね

**nobodyさん** · 2018/02/19(月) 21:43:19.14

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

**nobodyさん** · 2018/02/24(土) 16:29:29.06

web系じゃなくてすまんが仮想通貨業界ってGoの存在感大きいんだな
東大発のベンチャーAIxブロックチェーン企業の求人がGo言語エンジニア直指定だった

**nobodyさん** · 2018/02/24(土) 16:31:10.03

ちなみにこれな
https://en-gage.net/daisy_hr/work_60316/
<必須要件>
> プログラミング言語
・Go （半年以上の実務経験）

**nobodyさん** · 2018/02/24(土) 19:16:14.65

イーサリアムがgoで実装されてるから。(C++とpythonもあるが)

**nobodyさん** · 2018/02/24(土) 21:18:55.55

skycoinもgolangだった
フィンテック系にも浸透してきてるね

**nobodyさん** · 2018/06/20(水) 22:17:41.57

プログラミングを誰でも習得できる方法は、「前場アキドルのプログラミングマスター方法」というブログで見られるらしいよ。ネットで調べると見られるらしいです。

2C3G9

**nobodyさん** · 2018/07/06(金) 22:21:00.60

progateにメルカリ監修でgoの講座できてる

**nobodyさん** · 2018/07/10(火) 06:57:04.08

>>469
メルカリ相当力入れてるよな

ついでにバンナム＆スマホアプリの採用例も置いておく

https://cloudplatform-jp.googleblog.com/2018/07/google-app-engine-bandainamcostudios.html

**nobodyさん** · 2018/07/10(火) 06:57:39.36

＞GCP の採用においては、エンジニア側の熱意も大きかったようです。
＞「GAE と Datastore、Go 言語でやりたいという思いがエンジニアにすごくあったんです。
お前らがいたぞ

**nobodyさん** · 2018/07/11(水) 03:24:20.83

progateのgo初級編やってみたけどドットインストールと大差ないな
出来ればGAE/Goで作られたカウルをフルスクラッチで作れるくらいの内容を中～上級編として公開して欲しい

**nobodyさん** · 2018/07/11(水) 07:34:18.34

>>472
カウルって何？

**nobodyさん** · 2018/07/11(水) 07:40:55.40

>>473
http://ascii.jp/elem/000/001/499/1499741/
>現在、メルカリ(中略)新規事業として(中略)本やCDなどに特化した「メルカリカウル」を提供している。
＞メルカリカウルにおいては、すべてGAEで構築している。

**nobodyさん** · 2018/07/11(水) 08:03:33.99

>>474
何だ。専門用語かと思ったが略称なのね

**nobodyさん** · 2018/07/12(木) 09:27:47.56

gRPCをGAE/Goで使いたい。

この本の中身ってさ
https://techbooster.booth.pm/items/715936
第3章 Google App EngineでgRPC Webを使う
@k2wanko

この記事とほぼ一緒？
https://qiita.com/koki_cheese/items/369cdfc6e3250185ccdb

**nobodyさん** · 2018/07/12(木) 09:47:16.05

http://nodir.io/post/138899670556/prpc
pRPC: gRPC on Classic AppEngine today

こういうのもあるんだな
色々調べてみるか

**nobodyさん** · 2018/07/14(土) 21:47:15.51

仕事でgoでgRPC使ってるけどさ、正直何がいいのかわからない
JSON返しゃよくねと思ってしまう

**nobodyさん** · 2018/07/14(土) 22:36:12.19

本当に仕事で使ってたらその発想は出ないはずだが・・・
webの相手しかしてないの？スマホアプリのバックエンドとして普通使うよね？

**nobodyさん** · 2018/07/14(土) 22:48:12.16

WebView使った側ネイティブアプリだとJSONしか使えなくね

**nobodyさん** · 2018/07/14(土) 22:58:27.70

マイクロサービス間の通信にgRPC
フロントエンドにはGraphQL

**nobodyさん** · 2018/07/15(日) 00:09:42.15

別にサーバとクライアント間ではjsonでも困らんと思うが。
どっちかというとクライアント内のデータ構造がjsonのままはきつい。

**nobodyさん** · 2018/07/15(日) 04:17:17.60

OpenAPI(Swagger)とgoa使ってる人いる？
webアプリにしか使わないならこっちのほうがいいよね？

**nobodyさん** · 2018/07/15(日) 07:23:26.79

俺は普通のwebアプリでも使ってるけどね。spaなら全然行ける

**nobodyさん** · 2018/07/15(日) 10:04:52.67

>>483
使ってると言いたかった。
マイクロサービスとか言うけど、結局webサーバーとして使えるから

**nobodyさん** · 2018/07/18(水) 01:42:16.47

gRPCあきらめてTwirp使おうぜ

**nobodyさん** · 2018/07/18(水) 02:46:51.88

Twirp良さそうだな
HTTP1.1→2.0の過渡期限定だけどさ
.protoが同じなら生産性も学習コストも同じだし

**nobodyさん** · 2018/07/18(水) 07:56:48.33

Twichもgolang使ってたのか
覇権確定だな…
邪悪なOracleの支配下になったJavaを捨ててgolangに来たかいがあった
技術選定を見誤ると数年以上の遅れに繋がる

**nobodyさん** · 2018/07/25(水) 08:52:33.09

Google、Go Cloudを発表――クラウド開発ツールでGo言語の普及加速を目指す
https://jp.techcrunch.com/2018/07/25/2018-07-24-google-wants-go-to-become-the-go-to-language-for-writing-cloud-apps/

**nobodyさん** · 2018/07/25(水) 12:06:57.03

Googleが用意したGoのライブラリを使うだけで
GCPやAWS等のクラウドプラットフォームを自由に切り替えできる
ポータビリティの高いwebアプリケーションが開発できる、ってことかな？
これは良いね

**nobodyさん** · 2018/07/27(金) 04:35:11.45

ksk

**nobodyさん** · 2018/07/27(金) 17:05:13.99

goでwebサーバ建てる場合ってwebapiサーバだよね。
普通のwebアプリ。html返すようなのにgoを使うメリットってあるかな？

**nobodyさん** · 2018/07/27(金) 17:05:41.88

というか向いてるgoのフレームワークある？

**nobodyさん** · 2018/07/28(土) 11:04:52.11

goでhtmlはやめたほうがいい

**nobodyさん** · 2018/07/28(土) 12:03:01.84

今どきhtml吐き出し系のwebしか見てない設計を選択するのはやめたほうが良いと思うけどな
RESTないしgRPCないしTwirpにしてプラットフォーム共通にすべき
ネイティブスマホアプリ対応が二度手間になる

**nobodyさん** · 2018/07/29(日) 01:09:00.65

>>492
動作が高速

**nobodyさん** · 2018/07/29(日) 10:37:15.36

>>495
俺も最初はそう思ったけど、クライアントサイドのバグ対応を考慮すると、
必ずしもSPAが正解とは言えない気がする。
インスタンスの生存期間が短いほうがシンプル何だよね

**nobodyさん** · 2018/07/29(日) 21:52:18.33

うちはgoやめてrustに移った
えーん

**nobodyさん** · 2018/07/29(日) 22:18:31.50

>>497
requestに対するresponseのみの構成。
ぶっちゃけSSRな方式のほうが

**nobodyさん** · 2018/07/31(火) 19:25:44.62

うちはgoのプロジェクトだらけになってきた。
ちなみに時価総額数千億の大手。

**nobodyさん** · 2018/07/31(火) 19:49:58.35

メルカリか

**nobodyさん** · 2018/07/31(火) 20:08:47.23

ストックオプションうらやましい
俺ならヤングリタイアするわ

**nobodyさん** · 2018/08/01(水) 09:12:16.49

ヤングリタイアならいいけど
仲間数人雇って独立はやめとけよ
人件費だけであっという間に数千万飛んでいくから…
まともに稼げるプロダクトがないのに見切り発車で起業して
自殺してしまった人を知ってる…

1人でも起業できるのがITの良いところなので
自称ニートしながらPeingみたいな小粒サービスを何個も作ってたほうがいい

**nobodyさん** · 2018/08/01(水) 19:45:56.97

>>503
いいね。

**nobodyさん** · 2018/08/01(水) 19:47:35.39

一つ聞きたいんだけどgoでweb apiサーバ建てるとしてwebクライアントはどうしてる？
spaってインスタンスの生存時間が長くなりがちだし、バグったときに全体が止まるから好かんのだけど、どう作るのが一番手軽？

**nobodyさん** · 2018/08/01(水) 20:25:19.37

API次第

**nobodyさん** · 2018/08/02(木) 01:13:03.58

goaを使う

**nobodyさん** · 2018/08/02(木) 01:24:44.70

Twirpを使う

**nobodyさん** · 2018/08/02(木) 17:24:39.39

Visual Studio Code使ってるんだけどさ
ビルドタスクのtasks.jsonの記述冗長すぎないか？
結局make使ってるわ
シンプルで理解しやすいし
やりたいことはprotocくらいだしいいよね？

**nobodyさん** · 2018/08/03(金) 23:12:55.90

goはmakeしか使ったことないわ

**nobodyさん** · 2018/08/04(土) 15:16:59.22

鯖は全部jsonで返して
クライアント側はVueかRiot

**nobodyさん** · 2018/08/04(土) 18:14:26.40

reactっていったい何だったんだろうな
最終的にｖｕｅ．ｊｓの天下になった

**nobodyさん** · 2018/08/04(土) 18:50:16.44

anguler

**nobodyさん** · 2018/08/04(土) 20:07:03.30

VueよりRiotの方が簡単でシンプルで再利用性が高いと思うの

**nobodyさん** · 2018/08/05(日) 15:14:25.11

https://m-fetishism.com/vr/
https://m-fetishism.com/puke/
https://m-fetishism.com/joi_mania/

**nobodyさん** · 2018/08/06(月) 16:49:59.51

reactの方が単価高いけどな

**nobodyさん** · 2018/08/12(日) 18:07:10.40

Vueは結局jQueryと同じになりそうだが...
githubのissueもreactよりずっと少ないし、
npmの週刊ダウンロード数見ても数倍差がある...

結局単価高いのはtypescriptでreact書いてるところだし

**nobodyさん** · 2018/08/12(日) 18:13:32.90

Vueは結局jQueryと同じになりそうだが...
githubのissueもreactよりずっと少ないし、
npmの週刊ダウンロード数見ても数倍差がある...

結局単価高いのはtypescriptでreact書いてるところだし

**nobodyさん** · 2018/08/12(日) 18:30:27.09

vueだとどうしても型で固めきれないよね。
reactはflowとか型付言語と合わせて使うのがほぼ前提になってるから。

**nobodyさん** · 2018/09/06(木) 22:43:29.41

Go言語チームとGoogleが「Go Cloud」プロジェクト発表。同一コードでAWSやGoogle Cloudなどに対応できるポータブルなクラウドアプリの実現へ
https://www.publickey1.jp/blog/18/gogooglego_cloudawsgoogle_cloud.html

**nobodyさん** · 2018/11/02(金) 12:16:01.71

やっときたか

gRPC-Webが正式リリース。WebブラウザからgRPCを直接呼び出し可能に
https://www.publickey1.jp/blog/18/grpc-webwebgrpc.html

**nobodyさん** · 2018/11/03(土) 22:17:53.21

関数の引数にstringを渡しているときは常に値渡しで、
文字列をコピーしているって公式の記載で書いてあるところどこにありますか？
探しているんですが見つからず。arrayは値渡しなのは書いてあるんだけど、、、

**nobodyさん** · 2018/11/04(日) 04:51:58.49

えっと、その情報のソースはどこにあるの？
ソースください（公式に記載があることを断定していることからするとソースがあるんだと思いますが）。

そして、文字列のコピーってのは何を言っているんですか。

Go の文字列は immutable だから、中身のバイト配列をコピーする必要ない。
https://golang.org/ref/spec#String_types
ただ Go の文字列は、配列というよりスライスに近くて、
実際のバイト配列へのポインタをそのサイズを持った構造体である。
https://golang.org/pkg/reflect/#StringHeader

この StringHeader についてはコピー（値渡し）される。
でも中身の Data はコピーされない。
別に、Data もコピーすると思い込みたければ思い込んでもいいけど、
immutable だからコピーしてもしなくても変わらない。

実際に試してみれば：
https://play.golang.org/p/qsaq4AET8ac

**nobodyさん** · 2018/11/04(日) 20:33:58.10

>>523
おーありがとうございます。
https://blog.golang.org/go-slices-usage-and-internals
見ながら文字列=arrayなのかと想像していたんですが
実際には文字列=sliceだったんですね
そのへんの記述が見当たらなくて悩んでたんですが、公式のドキュメントには書いてないんですかね。実験で確かめるしかない感じ？

**nobodyさん** · 2018/11/04(日) 22:21:04.23

>>523
そのページの Related articles に書かれてますよん。
https://blog.golang.org/slices

> Now a brief section about strings in Go in the context of slices.
> Strings are actually very simple: they are just read-only slices of bytes
> with a bit of extra syntactic support from the language.

> An important consequence of this slice-like design for strings is
> that creating a substring is very efficient.
> All that needs to happen is the creation of a two-word string header.
> Since the string is read-only, the original string and
> the string resulting from the slice operation can share the same array safely.

**nobodyさん** · 2018/11/07(水) 09:09:50.89

>>525
亀レスですがありがとうございます。
ところでStringHeaderで言語内部のデータ構造にアクセスできることに感銘を受けたんですが同じようにsliceにもアクセス可能なSliceHeader的なのもあったりしますか？
とおもったらStringHeaderの上にもあったw

**nobodyさん** · 2018/11/09(金) 00:56:02.71

Hugoいい

**nobodyさん** · 2018/11/09(金) 10:44:35.26

【自衛隊内闇組織、別班】　安倍晋三・田茂神俊雄によるクーデター未遂事件、大垣新幹線ボルト抜き事件
http://rosie.5ch.net/test/read.cgi/liveplus/1541727683/l50

**nobodyさん** · 2018/11/21(水) 00:41:26.97

go modulesめっちゃ便利やな
GOPATH関係なく動くのが本当にいい、開発時に嫌だった制限がとうとう無くなってハッピー

**nobodyさん** · 2018/11/21(水) 13:18:13.86

>>529
確かに便利だわ。

**nobodyさん** · 2018/11/25(日) 08:45:28.23

GAEのstandardも1.11からurlfetchとかが消えてハッピー
ベータとれたらやっと人に勧められるわ

**nobodyさん** · 2018/11/25(日) 17:46:50.73

すれち

**nobodyさん** · 2018/11/29(木) 19:57:53.03

ええねん

**nobodyさん** · 2018/12/05(水) 21:37:33.96

GAE/SEのGo言語でgRPCするためのベストプラクティスってある？
それをまとめたWAFがあると理想なんだがなぁ

プロジェクト
└　サービスA：　GAE/SE　Node.js　Nuxt.jsでSSR
└　サービスB：　GAE/SE　Go言語　サービスAからのリクエストを処理するAPIサーバ
　　　gRPC(Twirp)を使いたい

**nobodyさん** · 2018/12/06(木) 16:18:01.66

TwirpってことはHTTP/1.1なREST使いたいんだろ？
双方向通信やストリームを使わないのであればgRPCよりも
GraphQLのほうがいいと思う

nuxt.jsとGraphQLを組み合わせてサービスAに統一するほうがいいぞ
nuxt.jsのserverMiddlewareでフックしてGraphQLのエンドポイント出すだけ
https://qiita.com/takanorip/items/d1e8618800d951780f4b

**nobodyさん** · 2018/12/06(木) 16:35:59.11

https://twitter.com/ydnjp/status/1066529802142674945
参考までに
https://twitter.com/5chan_nel (5ch newer account)

**nobodyさん** · 2018/12/07(金) 16:45:10.06

それならサービスBにプレーンなApollo-server(graphqlサーバ)デプロイして
サービスA(nuxt.js側)からクエリ投げてJSON取得する構成のほうがよくないか

せっかく境界つくるんだから疎結合にしとこうぜ
Microservice化して作業担当者の責任を明確にしたほうがいい
負荷に応じてインスタンスのグレードやインスタンス数を上げたり下げたり出来るメリットも生まれる

フロントエンド(SSR)担当のサービスA
バックエンド(GraphQL)担当のサービスB

スッキリするじゃん

**nobodyさん** · 2018/12/07(金) 16:47:47.49

まぁ例のQiita記事はApollo-clientとNuxt.jsのやり方だから、Serverには触れてないけどな
＞nuxt.jsのserverMiddlewareでフックしてGraphQLのエンドポイント出すだけ
これに対しての意見な
serverまでnuxt.jsに密結合させる必要はない

**nobodyさん** · 2018/12/13(木) 19:15:46.58

GoでGraphQL(GAE)
https://outcrawl.com/graphql-server-go-google-app-engine
https://qiita.com/trrrrrys/items/44e839134af1a0155be2
https://tech.mercari.com/entry/2018/10/24/111227
https://github.com/99designs/gqlgen
>まず個人的な理由から。筆者はGoogle App Engine/Standard Environmentの信者であり、
>それ以外のプラットフォームを使う気は今の所ありません。

いま日本企業で一番、エンジニアの採用に力入れまくってる
最先端ベンチャー企業の社員がここまで言い切るってことは
今後はGAE/Go注目かもしれんな

**nobodyさん** · 2018/12/13(木) 20:10:22.56

俺もGAE/Go信者やで
実はその他のPaaSやIaaSクラウドにはない魅力がGAE/SEにはある。
それは「1日の予算設定」だ。
GAE/SEだけ、EDDoS(エコノミックDDoS)で予期せぬ損害を被るリスクが低いのである。
予算使い果たしたらOver Quotaエラーでて終わり。サービスは停止するが破産は免れる。
他のサービスは予算ライン超えても警告メール出すだけで止まらない。
パケ・ホーダイのないスマホでYoutube動画を見るくらい恐ろしい行為なのだ。
資金力のない零細ベンチャーが、悪意ある競合他者から身を護るために有効な選択である。

**nobodyさん** · 2018/12/13(木) 20:15:00.51

GAE/Node.jsとGAE/Goってどっちがスピンアップ早いのだろう？と思って調べたらこうなった

https://www.bunkei-programmer.net/entry/2018/06/13/232912
Go　平均0.495秒
Node.js 平均0.6516秒

Javaは問題外だな

**nobodyさん** · 2018/12/15(土) 02:50:44.55

JavaScript界隈のエコシステムが羨ましくなってきた…
Nuxt.jsでSSR出来るのNode.js環境だけだし
パッケージマネージャーのYarnは高速かつ進捗表示が親切だし
(go get だと-vオプション付けても分かりにくい…)
GraphQLもApollo Server楽ちんだしドキュメントもわかりやすい

Go言語だとスキーマ定義が冗長だったり(graphql-go)
プレーンで可読性の高い定義ファイルから自動作成できる便利なgqlgenは
gqlgenコマンドバイナリが何かトラブってdeplicatedになってるし
いまいちすっきりしない

**nobodyさん** · 2018/12/18(火) 09:20:26.43

jsみたいなコンパイラ通さない言語はテストが大変すぎて使いたくない
ほんのちょっとしたものを作るのはいいけど規模がでかくなると苦痛のほうが遥かに大きくなると感じてる

**nobodyさん** · 2018/12/18(火) 11:36:20.02

巨大なプログラムを書けない人はセンスが無いだけ
そういう人はコンパイラ使っても破綻する

**nobodyさん** · 2018/12/18(火) 14:35:53.36

頭悪そうなレスだな
出来る出来ない論じゃなくて？

**nobodyさん** · 2018/12/18(火) 14:44:00.82

くゃしぃのぅ

**nobodyさん** · 2018/12/19(水) 08:10:03.07

>>543
Typescriptあるやん

GoにはGoの良いところがあるから心配するな

**nobodyさん** · 2018/12/19(水) 08:26:43.93

https://github.com/prisma/prisma/issues/1708

prisma/prismaはいつGoogle Cloud Datastoreに対応してくれるんだい？

**nobodyさん** · 2018/12/19(水) 13:01:57.24

何事も適材適所