22
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Echo(Go)のMiddlewareを理解する (Recover,CORS)

Last updated at Posted at 2023-12-24

はじめに

こんにちは。TuneCoreJapanでバックエンドエンジニアをしています @masafumi330 です。
この記事はWano Group Advent Calendar2023 最終日の記事です。もう一度言いますよ。最終日の記事です!

今回は、弊社バックエンドアプリケーションの開発でも使用しているGo、 そのフレームワークEchoについて、そのMiddlewareの機能にフォーカスを絞り、

  • Middlewareとは何なのか?
  • Middlewareによってどのような課題を解決できるのか?
  • 実際にどのようにMiddlewareの機能を使うのか?
    をまとめていきたいと思います。

調査の経緯

まずは今回、EchoのMiddleware機能を調査してみるにあたった経緯を話そうと思います。

Wanoに入社して2年間、私はバックエンドチームにてGoを用いたアプリケーション開発を行ってきました。
通常の開発では、Middlewareを特に意識することなく、アプリケーションの核となるビジネスロジックに集中して開発することができています。
これはこれで、「Middlewareを意識することなくアプリケーションを開発できる」 という理想的な状況だと思いますが、一方でMiddlewareの存在や効果を理解せずに使用していることに対する疑問が生まれました。
そこで、Middlewareについて深く理解しようという動機から、今回調べてみようと思った次第です。

Echoとは?

Echoとは、公式サイトより参照すると、GoによるWebアプリケーションを開発するために必要な様々なツールを提供してくれるフレームワークです。

The Echo project is a powerful and versatile web framework for building scalable and high-performance web applications in the Go programming language. It follows the principles of simplicity, flexibility, and performance to provide developers with an efficient toolkit for building robust web applications.
(訳)
Echoプロジェクトは、Goプログラミング言語でスケーラブルで高性能なWebアプリケーションを構築するための強力で多機能なWebフレームワークです。このプロジェクトは、シンプルさ、柔軟性、パフォーマンスの原則に従い、開発者に頑丈なWebアプリケーションを構築するための効果的なツールキットを提供します。

軽量かつ柔軟でありながら、Webアプリケーションに必要なおおよその機能を備えています。

  • ルーティング
  • エラーハンドリング
  • ロギング
  • 認証
  • etc.

EchoのようなWebアプリケーションフレームワークを使う利点は以下にあると思います。

  • 開発速度向上(巨人の肩に乗る)
  • 保守性向上(フレームワークに責務を一部委譲することにより、ビジネスロジックに集中できる)

Middlewareとは?

image.png
Image Credit: Sunrise Integration Blog

この記事を読んで頂いている方ならばWebアプリケーションの世界で「Middleware」という言葉を聞いたことがあると思います。
Middlewareとは、その言葉の通り、様々なアプリケーションのを取り持ち、異なる機能を連携させることを責務とする機構のことを指します。

アプリケーションが機能する上で、リクエストがサーバーに届いてからレスポンスがクライアントに返るまでの一連の流れには多くの処理が含まれます。この処理の中で、セッション管理、エラーハンドリング、ログの取得など、共通の課題を解決するための仕組みがMiddlewareです。

ClientとApplicationの板挟みに合いながら日々奮闘する間取り持ち隊長。それがMiddlewareなのです。

image.png
ClientとApplicationの板挟みで頑張るMiddlewareくん

例えばEchoフレームワークでは、RecoverというMiddlewareの機能を使って、アプリケーション内で発生したエラーをキャッチし、プロセスを停止させないようにエラーから復帰することによって、可用性とその後の原因解析へと役立ちます。
また、Loggerはリクエストやレスポンスに関する情報をログとして残し、デバッグやトラブルシューティングに役立ちます。

外界の複雑さを吸収し、間を取り持ってくれるMiddleware...なんとありがたい機能でしょう。
私も今となっては大人になりましたが、子供の頃身のお世話をしてくれたり、毎日ご飯を作ってくれて学校に行かせてくれた親にはいくら感謝してもしきれません。(大人になって初めて親のありがたみを知る成人男性26歳)

Middlewareを使ってみる

それでは実際に、EchoのMiddlewareツールを使っていきたいと思います。

Recover

Recoverは、アプリケーション内で発生したpanicから復帰し、stack trace(エラー箇所までの経路) とエラーハンドリングまで導き、アプリケーション処理を継続するために使用します。

例として、"Hello World"を返してくれるようなエンドポイントがあるとします。

main.go
func main() {
	e := echo.New()
	e.GET("/", func(c echo.Context) error {
		return c.String(http.StatusOK, "Hello, World!")
	})
	e.Logger.Fatal(e.Start(":8080"))
}

サーバーを起動した状態で、エンドポイントへリクエストを行うと、問題なくレスポンスが返ってきます。

$ go run main.go

$ curl localhost:8080/
Hello, World! 

しかし、処理の途中でpanicを発生させた場合、プロセスは処理継続不可能となりプロセスは停止。レスポンスは返ってこなくなってしまいます。

main.go
func main() {
	e := echo.New()
	e.GET("/", func(c echo.Context) error {
        panic("panic!") // panicを発生させる
		return c.String(http.StatusOK, "Hello, World!")
	})
	e.Logger.Fatal(e.Start(":8080"))
}
$ go run main.go

$ curl localhost:8080/ 
curl: (52) Empty reply from server
$ curl localhost:8080/ 
curl: (52) Empty reply from server

# サーバーが停止したため、応答がなくなる。
実際のサーバーログ
echo: http: panic serving 127.0.0.1:62709: panic
goroutine 19 [running]:
net/http.(*conn).serve.func1()
        /usr/local/go/src/net/http/server.go:1850 +0xb0
panic({0x100c39ca0, 0x100c8c648})
        /usr/local/go/src/runtime/panic.go:890 +0x258
...

この問題を解決するため、実際にRecoverを導入してみましょう。

main.go
func main() {
	e := echo.New()
	e.Use(middleware.Recover()) // Recoverを導入
	e.GET("/", func(c echo.Context) error {
		panic("panic") // panicを発生させる
		return c.String(http.StatusOK, "Hello, World!")
	})
	e.Logger.Fatal(e.Start(":1323"))
}

Echoでは、Middlewareは付け外し可能なブロックのように、

e.Use(/*middleware*/)
e.Use(/*middleware*/)
...

とchainさせることができます。Recoverの場合は、
e.Use(middleware.Recover())とchainするだけで導入が可能です。

再度サーバーを起動してpanicを発生させてみましょう。

$ go run main.go

$ curl localhost:8080/ 
{"message":"Internal Server Error"}
$ curl localhost:8080/ 
{"message":"Internal Server Error"}

panicが発生してもInternal Server Errorとして500HTTPレスポンスで処理し、エラーを返しています。
また、再度リクエストを送ってもレスポンスがあることにより、サーバーが停止していないことが分かります。

サンプルのように、ローカルで起動させている簡単なプログラムであれば、再度サーバーを起動させるだけですが、Webサービスのような大規模なアプリケーションであれば、サーバーが停止してしまうのは重大なインシデントです。

そのために、Recoverのように、panicが起きてもまずは復帰しサービスの継続を計るフェイルセーフ機構があります。

CORS

Cross-Origin Resource Sharing(CORS)は、異なるオリジンからのリクエストを許可するための仕組みです。EchoのCORSミドルウェアを使用することで、セキュアかつ柔軟なAPI通信を実現できます。

下記では、FEサーバーとBEサーバーを立て、FEサーバーからBEサーバーにリクエストを送り、情報の取得を行うような例を考えてみます。

image.png

CORS導入前

GET /hello を送ると、Jsonでhello worldのメッセージを返してくれるようなAPIを定義します。

BEサーバー

main.go
func main() {
	e := echo.New()

	e.GET("/hello", func(c echo.Context) error {
		return c.JSON(http.StatusOK, map[string]string{"message": "Hello World"})
	})
	e.Logger.Fatal(e.Start(":1323"))
}

curlで確認すると、問題ないようです。

APIテスト

$ curl localhost:8080/hello -i 
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Sun, 17 Dec 2023 03:48:09 GMT
Content-Length: 26

{"message":"Hello World"}

次にFEサーバーを立てます。
ユースケースとしては、ボタンを押したら、GET /helloリクエストを送り、返ってきたレスポンスの内容を描画するようなケースを考えてみます。

構築は、Next.jsのボイラーテンプレートから実装します。

FEサーバー

$ npx create-next-app frontend
$ cd frontend
pages/index.js
import { useState } from 'react';

const Home = () => {
  const [response, setResponse] = useState('');

  const fetchData = async () => {
    try {
      const res = await fetch('http://localhost:8080/hello');
      const data = await res.json();
      setResponse(data.message);
    } catch (error) {
      console.error('Error fetching data:', error);
    }
  };

  return (
    <div>
      <h1>CORS Test</h1>
      <button onClick={fetchData}>Send GET /hello Request</button>
      {response && <p>Response from server: {response}</p>}
    </div>
  );
};

export default Home;
package.json
// ポート指定
"scripts": {
    "dev": "next dev -p 8079",
}

実際の画面は以下のようになります。

image.png

早速ボタンを叩いてリクエストを送ってみます。
すると、なにも反応がありません。
検証ツールを確認してみると、どうやら CORSエラー というエラーが発生しています。
image.png

image.png

原因

  • BEサーバーとしてリクエストを許可するオリジンに、FEサーバー (http://localhost:8079) を許可していないため。

CORS導入後

それでは次にCORS Middlewareを導入します。
リクエスト可能なオリジンとして、FEサーバーを許可します。

main.go
func main() {
	e := echo.New()

	// CORS middleware
	e.Use(middleware.CORSWithConfig(middleware.CORSConfig{
		AllowOrigins: []string{"http://localhost:8079"},
		AllowHeaders: []string{echo.HeaderOrigin, echo.HeaderContentType, echo.HeaderAccept},
	}))

	e.GET("/hello", func(c echo.Context) error {
		return c.JSON(http.StatusOK, map[string]string{"message": "Hello World"})
	})
	e.Logger.Fatal(e.Start(":8080"))
}

再度ボタンを押してリクエストを送ってみると、Hello Worldが表示されました!

image.png

image.png

無事、異なるオリジン間のFE<->BEのHTTP通信を疎通することができました。

アプリケーションの処理の前に、CORSのチェックをMiddlewareで行うことで、そもそも意図しないオリジンとの通信を行わない制御が可能になります。

終わりに

EchoのMiddlewareツールを使って開発することで、アプリケーションの可用性やセキュリティを向上させるようなMiddlewareを簡単に実装することができます。これらの機能を活用することで、より効果的なバックエンド開発が可能になります。

EchoのMiddlewareツールだと他にも、Basic AuthやSessionなど興味があるので、こちらも触ってみようとおもいます。
また、弊社では、Middlewareをさらにカスタマイズしていますので、カスタム内容についても深ぼっていきたいと思います。

以上でWanoグループのアドベントカレンダー2023を全て終了します!
今年も皆さんお疲れさまでした!
それでは、良いお年を!!

採用もやっています!

現在、Wanoグループ / TuneCore Japan では人材募集をしています。興味のある方は下記を参照してください。

Wano | Wano Group JOBS
TuneCore Japan | TuneCore Japan JOBS

参考

22
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
22
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?