ASP.NET Coreを利用してASP.NET Coreを利用しないMiddlewareの作り方
- 2016-12-25
今回の記事はASP.NET Advent Calendar 2016向けのものとなります。最終日！特に書くつもりもなかったのですが、たまたま表題のような機能を持つMiddlewareを作ったので、せっかくなので書いておくか、みたいなみたいな。
.NET 4.6でASP.NET Core
まぁ普通に.NET 4.6でASP.NET Coreのパッケージ入れるだけなんですが。別にASP.NET Coreは.NET Coreでしか動かせないわけではなくて、ちゃんと（？）.NET 4.6でも動きます。如何せん.NET Coreがまだ環境として成熟してはいないので、強くLinuxで動かしたいという欲求がなければ、まだまだWindows/.NET 4.6で動かすほうが無難でしょう。Visual Studioのサポートも2015だとちょっとイマイチだとも思っていて、私的には本格的に作り出していくのはVisual Studio 2017待ちです。脱Windowsとして、Linuxでホスティングするというシナリオ自体にはかなり魅力的に思っていますし、ライブラリを作るのだったら今だと.NET Core対応は必須だと思いますけれど。
Hello Middleware
Middlewareとはなんぞやか、というと、ASP.NET公式のMiddlewareのドキュメントが見れば良いですね。
Httpのリクエストを受けつけて、レスポンスを返す。ASP.NET Core MVCなどのフレームワークも、Middlewareの一種（図で言うところのMiddleware3にあたる、パイプラインの終点に位置する）と見なせます。このパイプラインのチェーンによって、事前に認証を挟んだりロギングを仕込んだりルーティングしたりなど、機能をアプリケーションに足していくことができます。
考え方も、実質的なメソッドシグネチャもASP.NET Coreの前身のOWINと同一です。今ではOWIN自体の機能や周辺フレームワークは完全に整っていて、ASP.NET Coreで全て賄えるようになっているので、新しく作る場合はASP.NET Coreのことだけを考えればいいでしょう。逆に、OWINで構築したものをASP.NET Coreへ移行することはそう難しくないです
ASP.NET Coreのパッケージはいろいろあって、どれを参照すべきか悩ましいのですが、最小のコア部分となるのはMicrosoft.AspNetCore.Http.Abstractionsです。これさえあればMiddlewareが作れます。
では、パイプラインの各部にフックするだけの単純なMiddlewareを作りましょう！
public class HelloMiddleware
{
// RequestDelegate = Func<HttpContext, Task>
readonly RequestDelegate next;
public HelloMiddleware(RequestDelegate next)
{
this.next = next;
}
public async Task Invoke(HttpContext context)
{
try
{
Console.WriteLine("Before Next");
// パイプラインの「次」のミドルウェアを呼ぶ
// 条件を判定して「呼ばない」という選択を取ることもできる
await next.Invoke(context);
Console.WriteLine("After Next");
}
catch (Exception ex)
{
Console.WriteLine("Exception" + ex.ToString());
}
finally
{
Console.WriteLine("Finally");
}
}
}
注意点としては、完全に「規約ベース」です。コンストラクタの第一引数はRequestDelegateを持ち（その他のパラメータが必要な場合は第二引数以降に書く）、public Task Invoke(HttpContext context)メソッドを持つ必要があります。逆に、それを満たしていればどのような形になっていても構いません。
この規約ベースなところは賛否あるかなぁ、というところですが（私はどちらかというと否）、C#の言語機能としてはしょうがない面もあります。（自分でもこの手のフレームワークを何個か作った経験があるところから理解している上で）実装面の話をすると、この規約で最も大事なところは、コンストラクタの第一引数でRequestDelegateを受け入れるところにあります。そして、C#は具象型のコンストラクタの型の制約は入れられないんですよね。なので、MiddlewareBaseとか作ってもあんま意味がなくて、ならもう全部規約ベースで処理しちゃおうって気持ちは分かります。
Invokeのメソッドシグネチャをpublic Task Invoke(HttpContext context, RequestDelegate next)にすることで、そうしたコンストラクタの制約を受ける必要がなくなって、メソッドに対するインターフェイスでC#として綺麗な制約をかけることは可能になるんですが（私も、なので以前はそういうデザインを取っていた）、そうなるとパフォーマンス上の問題を抱えることになります。Invoke(HttpContext context, RequestDelegate next)というメソッドシグネチャだと実行時に"next"を解決していくことになるのですが、これやるとどうしても、nextを解決するための余計なオブジェクト（クロージャを作るかそれ用の管理オブジェクトを新しく作るか）が必要になりますし、呼び出し階層もその中間層を挟むため、どうしても一個深くなってしまいます。
ミドルウェアパイプラインは構築時にnextを解決することができるわけで、そうした実行時のコストを構築時に抑え込むことが原理上可能です。それが、コンストラクタでnextを受け入れることです。C#を活かした設計の美しさ vs パフォーマンス。このMiddlewareチェーンはASP.NET Coreにおける最も最下層のレイヤー。この局面ではパフォーマンスを選ぶべきでしょう。実に良いチョイスだと思います。
最後に、使いやすいように拡張メソッドを用意しましょう。拡張メソッドなのでnamespaceは浅めのところにおいておくと使いやすいので、その辺は適当に気をつけましょう:)
public static class HelloMiddlewareExtensions
{
public static IApplicationBuilder UseHello(this IApplicationBuilder builder)
{
// 規約ベースで実行時にnewされる。パラメータがある場合はparams object[] argsで。
return builder.UseMiddleware<HelloMiddleware>();
}
}
Middlewareを使う
作ったら使わないと動作確認もできません！というわけでホスティングなのですが、これもAspNetCoreのパッケージはいっぱいありすぎてよくわからなかったりしますが、「Microsoft.AspNetCore.Server.*」がサーバーを立てるためのライブラリになってます。IISならIISIntegration、Linuxで動かすならKestrel、コンソールアプリなどでのセルフホストならWebListenerを選べばOK。今回はMicrosoft.AspNetCore.Server.WebListenerで行きましょう。
class Program
{
static void Main(string[] args)
{
var webHost = new WebHostBuilder()
.UseWebListener() // ホスティングサーバーを決める
.UseStartup<Startup>() // サーバー起動時に呼ばれるクラスを指定
.UseUrls("http://localhost:54321") // 立ち上げるアドレスを指定
.Build();
webHost.Run();
}
}
public class Startup
{
// Configure(IApplicationBuilder app)というのも規約ベースで名前固定
public void Configure(IApplicationBuilder app)
{
// さっき作ったMiddlewareを使う
app.UseHello();
// この場で最下層の匿名Middleware(nextがない)を作る
app.Run(async ctx =>
{
var now = DateTime.Now.ToString();
Console.WriteLine("---------" + now + "----------");
await ctx.Response.WriteAsync(DateTime.Now.ToString());
});
}
}
例によって規約ベースなところが多いので、まぁ最初はコピペで行きましょう、しょーがない。これでブラウザでlocalhost:54321を叩いてもらえば、現在時刻が出力されるのと、コンソールにはパイプライン通ってますよーのログが出ます。
基本のHello Worldはこんなところでしょう、後は全部これの応用に過ぎません。
ASP.NET Coreを利用してASP.NET Coreを利用しない
さて、本題（？）。現在、私はMagicOnionというフレームワークを作っていて（まぁまぁ動いてますが、一応alpha段階）、謳い文句は「gRPC based HTTP/2 RPC Streaming Framework for .NET, .NET Core and Unity」。つまり……？gRPCというGoogleの作っている「A high performance, open-source universal RPC framework」を下回りで使います。つまり、ASP.NET Coreは使いません。さよならASP.NET Core……。
gRPCは(.NET以外では)非常に盛り上がりを見せていて、ググればいっぱい日本語でもお話が見つかるので、知らない方は適当に検索を。非常に良いものです。
gRPCはHTTP/2ベースで、しかもデータは基本的にはProtocol Buffersでやり取りされているので、従来のエコシステム(HTTP/1 + JSON)からのアクセスが使えません。そこでgrpc-gatewayというプロキシを間に挟むことで HTTP/1 + JSONで受けてHTTP/2 + Protobuf にルーティングします。それによりSwaggerなどの便利UIも使えて大変捗るという図式です。素晴らしい！
grpc-gatewayは素晴らしいんですが、Pure Windows環境で使うのは恐らく無理があるのと、MagicOnionではデータをZeroFormatterでやり取りするようにしているので、そのまま使えません。残念ながら。しかし、特にSwaggerが使いたいんで絶対にgrpc-gateway的なものは欲しい。と、いうわけで、用意しました。ASP.NET Coreを利用して(HTTP/1 + JSON)、ASP.NET Coreを利用しない(HTTP/2 + gRPC/MagicOnion/ZeroFormatter)。
public class MagicOnionHttpGatewayMiddleware
{
readonly RequestDelegate next;
// MagicOnionのHandler（キニシナイ）
readonly IDictionary<string, MethodHandler> handlers;
// gRPCのコネクション
readonly Channel channel;
public MagicOnionHttpGatewayMiddleware(RequestDelegate next, IReadOnlyList<MethodHandler> handlers, Channel channel)
{
this.next = next;
this.handlers = handlers.ToDictionary(x => "/" + x.ToString());
this.channel = channel;
}
public async Task Invoke(HttpContext httpContext)
{
try
{
var path = httpContext.Request.Path.Value;
// HttpContextのパスをgRPCのパスと適当に照合する
MethodHandler handler;
if (!handlers.TryGetValue(path, out handler))
{
await next(httpContext);
return;
}
// BodyにJSONがやってきてるということにする（実際はFormからの場合など分岐がいっぱいでもっと複雑ですが！）
string body;
using (var sr = new StreamReader(httpContext.Request.Body, Encoding.UTF8))
{
body = sr.ReadToEnd();
}
// JSON -> C# Object
var deserializedObject = Newtonsoft.Json.JsonConvert.DeserializeObject(body, handler.RequestType);
// C# Object -> ZeroFormatter
var requestObject = handler.BoxedSerialize(deserializedObject);
// gRPCのMethodをリクエストを動的に作る
var method = new Method<byte[], byte[]>(MethodType.Unary, handler.ServiceName, handler.MethodInfo.Name, MagicOnionMarshallers.ByteArrayMarshaller, MagicOnionMarshallers.ByteArrayMarshaller);
// gRPCで通信、レスポンスを受け取る(ZeroFormatter)
var rawResponse = await new DefaultCallInvoker(channel)
.AsyncUnaryCall(method, null, default(CallOptions), requestObject);
// ZeroFormatter -> C# Object
var obj = handler.BoxedDeserialize(rawResponse);
// C# Object -> JSON
var v = JsonConvert.SerializeObject(obj, new[] { new Newtonsoft.Json.Converters.StringEnumConverter() });
// で、HttpContext.Responseに書く。
httpContext.Response.ContentType = "application/json";
await httpContext.Response.WriteAsync(v);
}
catch (Exception ex)
{
// とりあえず例外はそのまんまドバーッと出しておいてみる
httpContext.Response.StatusCode = 500;
await httpContext.Response.WriteAsync(ex.ToString());
}
}
}
細かいところはどうでもいいんですが（あと一部端折ってます、実際はもう少し複雑なので）、基本的な流れはJSONをZeroFormatterに変換→内部で動いてるgRPCと通信→ZeroFormatterをJSONに変換。です。見事に左から右にデータを流すだけー、のお仕事、ですね！
MagicOnion本体は限界までボクシングが発生しないように、ラムダのキャプチャなどにも気を使って、ギチギチにパフォーマンスチューニングしてあるんですが、このGatewayはそんなに気を使ってません:) まぁ、もとより複数回の変換が走ってる、パフォーマンス最優先のレイヤーではないから、いっかな、という。どっちかというとデバッグ用途でSwaggerを使いたいがために用意したようなものです。本流の通信はこのレイヤーを通ることはないので。
ちゃんとgRPCでもSwagger使えてめっちゃ捗る。
What is MagicOnion?
gRPCは.protoを記述してサーバーコードの雛形とクライアントコードを生成します。私はこのIDL(Interface Definition Language)の層があまり好きじゃないんですね。そもそも、クライアントもサーバーも、ありとあらゆる層をC#で統一しているので、C#以外を考慮する必要がないというのもあるので。なので、C#自体をIDLとして使えるように調整したり、MVCフレームワークでいうフィルターが標準でないので、それを差し込めるようにしたり、gRPCは(int x, int y, int z)のような引数に並べるような書き方ができない（必ずRequestクラスを要求する！）ので、動的にそれを生成するようにしたりして、より自然にC#で使えるように、かつ、パフォーマンスも一切犠牲にしない（中間層が入ってるからオーバーヘッドと思いきや、むしろプリミティブ型が使えるようになったのでむしろ素のgRPCより速くなる）ようにしています。そもそもそしてUnityでも動作出来るような調整/カスタマイズなどなども込みで、ですね。
それ以外の話はZeroFormatterと謎RPCについて発表してきました。にて少し書いてあります。もう少し詳細な話は、完成した時に……。
まとめ
.NET Coreを本格的に（プロダクション環境で）使うということは、特に開発環境という点でまだ足りないところが多くて(project.json廃止とかゴタついたところもあるし）、VS2017待ちだと判断しています。しかし、ASP.NET Coreのフレームワーク面では十分完成していて、問題ないですね。なので、そちらから随時移行していきたいという気持ちでいます。
まぁ、とはいえ↑で書いたとおり、ほとんどASP.NET Core自体すら使わないんですが。うーん、そうですね、やっぱスタンダードな作り(JSON API)をクロスプラットフォームを紳士に取り組んでます、みたいなことやってる間に、世界は凄いスピードで回ってるんですよね。Microsoftは常に一歩遅いと思っていて、まぁ今回もやっぱそうですよね、という感じで、世間が成熟した頃にやっと乗り出すようなスピード感だと思ってます。ナデラでOSSでスピーディーなのかといったら、別に私はそう思ってないですね、スピードという点では相変わらずだなぁ、と。むしろ「正しくやろうとする」圧力の高さに自分で縛られてしまっている気すらします。スタンダードだからとJSONでコンフィグ頑張ろうとしてやっぱダメでした撤回、みたいな。そういうのあんま良くないし、その辺の束縛から自由になれた時が真のスタートなんじゃないかな。
ともあれ、私はgRPCにベットしてるんで、ASP.NET Core自体は割とどうでも良く思ってます、今のところ。でもそれはそれとして、当然（補助的に）使ってく必要はあるんで、そういう時にちょいちょいと出番はあるでしょう。