ASP.NET Core使用GraphQL第二章之中间件

前言

在开始本文之前,对GraphQL不熟悉的朋友们,可以看下下面这篇文章:

前文:ASP.NET Core中使用GraphQL - 第一章 Hello World

看完上面的文章,下面话不多说了,来一起看看详细的介绍吧

中间件

如果你熟悉ASP.NET Core的中间件,你可能会注意到之前的博客中我们已经使用了一个中间件,

app.Run(async (context) =>
{
 var result = await new DocumentExecuter()
 .ExecuteAsync(doc =>
 {
 doc.Schema = schema;
 doc.Query = @"
 query {
  hello
 }
 ";
 }).ConfigureAwait(false);

 var json = new DocumentWriter(indent: true)
 .Write(result)
 await context.Response.WriteAsync(json);
});

这个中间件负责输出了当前查询的结果。

中间件的定义:

中间件是装载在应用程序管道中的组件,负责处理请求和响应,每一个中间件

可以选择是否传递请求到应用程序管道中的下一个组件
        可以在应用程序管道中下一个组件运行前和运行后进行一些操作

来源: Microsoft Documentation

实际上中间件是一个委托,或者更精确的说是一个请求委托(Request Delegate)。 正如他的名字一样,中间件会处理请求,并决定是否将他委托到应用程序管道中的下一个中间件中。在我们前面的例子中,我们使用IApplicationBuilder类的Run()方法配置了一个请求委托。

使用动态查询体替换硬编码查询体

在我们之前的例子中,中间件中的代码非常简单,它仅是返回了一个固定查询的结果。然而在现实场景中,查询应该是动态的,因此我们必须从请求中读取查询体。

在服务器端,每一个请求委托都可以接受一个HttpContext参数。如果一个查询体是通过POST请求发送到服务器的,你可以很容易的使用如下代码获取到请求体中的内容。

string body;
using (var streamReader = new StreamReader(httpContext.Request.Body))
{
 body = await streamReader.ReadToEndAsync();
}

在获取请求体内容之前,为了不引起任何问题,我们需要先检测一些当前请求

  • 是否是一个POST请求
  • 是否使用了特定的Url, 例如 /api/graphql

因此我们需要对代码进行调整。

if(context.Request.Path.StartsWithSegments("/api/graphql")
 && string.Equals(context.Request.Method,
   "POST",
   StringComparison.OrdinalIgnoreCase))
{
 string body;
 using (var streamReader = new StreamReader(context.Request.Body))
 {
 body = await streamReader.ReadToEndAsync();
 }

....
....
....

一个请求体可以包含很多字段,这里我们约定传入graphql查询体字段名称是query。因此我们可以将请求体中的JSON字符串转换成一个包含Query属性的复杂类型。

这个复杂类型代码如下:

public class GraphQLRequest
{
 public string Query { get; set; }
}

下一步我们要做的就是,反序列化当前请求体的内容为一个GraphQLRequest类型的实例。这里我们需要使用Json.Net中的静态方法JsonConvert.DeserializeObjct来替换之前的硬编码的查询体。

var request = JsonConvert.DeserializeObject<GraphQLRequest>(body);

var result = await new DocumentExecuter().ExecuteAsync(doc =>
{
 doc.Schema = schema;
 doc.Query = request.Query;
}).ConfigureAwait(false);

在完成以上修改之后,Startup.cs文件的Run方法应该是这个样子的。

app.Run(async (context) =>
{
 if (context.Request.Path.StartsWithSegments("/api/graphql")
 && string.Equals(context.Request.Method,
    "POST",
    StringComparison.OrdinalIgnoreCase))
 {
 string body;
 using (var streamReader = new StreamReader(context.Request.Body))
 {
  body = await streamReader.ReadToEndAsync();

  var request = JsonConvert.DeserializeObject<GraphQLRequest>(body);
  var schema = new Schema { Query = new HelloWorldQuery() };

  var result = await new DocumentExecuter()
  .ExecuteAsync(doc =>
  {
  doc.Schema = schema;
  doc.Query = request.Query;
  }).ConfigureAwait(false);

  var json = new DocumentWriter(indent: true)
  .Write(result);
  await context.Response.WriteAsync(json);
 }
 }
});

最终效果

现在我们可以使用POSTMAN来创建一个POST请求, 请求结果如下:

结果正确返回了。

本篇源代码: https://github.com/lamondlu/GraphQL_Blogs/tree/master/Part%20II

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对我们的支持。

(0)

相关推荐

  • ASP.NET Core使用GraphQL第一章之Hello World

    前言 你是否已经厌倦了REST风格的API? 让我们来聊一下GraphQL.  下面是GraphQL的定义: GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查询的运行时. GraphQL 对你的 API 中的数据提供了一套易于理解的完整描述,使得客户端能够准确地获得它需要的数据,而且没有任何冗余,也让 API 更容易地随着时间推移而演进,还能用于构建强大的开发者工具. GraphQL由Facebook开发,始于2012年,2015年公开. GraphQL牛逼之处是它可以让客户

  • ASP.NET Core使用GraphQL第二章之中间件

    前言 在开始本文之前,对GraphQL不熟悉的朋友们,可以看下下面这篇文章: 前文:ASP.NET Core中使用GraphQL - 第一章 Hello World 看完上面的文章,下面话不多说了,来一起看看详细的介绍吧 中间件 如果你熟悉ASP.NET Core的中间件,你可能会注意到之前的博客中我们已经使用了一个中间件, app.Run(async (context) => { var result = await new DocumentExecuter() .ExecuteAsync(d

  • 详解在ASP.NET Core中如何编写合格的中间件

    这篇文章探讨了让不同的请求去使用不同的中间件,那么我们应该如何配置ASP.NET Core中间件?其实中间件只是在ASP.NET Core中处理Web请求的管道.所有ASP.NET Core应用程序至少需要一个中间件来响应请求,并且您的应用程序实际上只是中间件的集合.当然MVC管道本身就是中间件,早在WebForm时代就出现过HttpModules.HttpHandler.那个时候悠然记得我通过它们来组织我的广告系统,不闲扯我们继续. 每个中间件组件都有一个带有HttpContext参数的Inv

  • ASP.NET Core应用错误处理之DeveloperExceptionPageMiddleware中间件呈现“开发者异常页面”

    前言 在<ASP.NET Core应用的错误处理[1]:三种呈现错误页面的方式>中,我们通过几个简单的实例演示了如何呈现一个错误页面,这些错误页面的呈现分别由三个对应的中间件来完成,接下来我们将对这三个中间件进行详细介绍.在开发环境呈现的异常页面是通过一个类型为DeveloperExceptionPageMiddleware中间件实现的. public class DeveloperExceptionPageMiddleware { public DeveloperExceptionPageM

  • ASP.NET Core应用错误处理之StatusCodePagesMiddleware中间件针对响应码呈现错误页面

    前言 StatusCodePagesMiddleware中间件与ExceptionHandlerMiddleware中间件比较类似,它们都是在后续请求处理过程中"出错"的情况下利用一个错误处理器来完成最终的请求处理与响应的任务.它们之间的差异在于对"错误"的界定上,对于ExceptionHandlerMiddleware中间件来说,它所谓的错误就是抛出异常,但是对于StatusCodePagesMiddleware中间件来说,则将介于400~599之间的响应状态码视

  • ASP.NET Core应用错误处理之ExceptionHandlerMiddleware中间件呈现“定制化错误页面”

    前言 DeveloperExceptionPageMiddleware中间件利用呈现出来的错误页面实现抛出异常和当前请求的详细信息以辅助开发人员更好地进行纠错诊断工作,而ExceptionHandlerMiddleware中间件则是面向最终用户的,我们可以利用它来显示一个友好的定制化的错误页面.按照惯例,我们还是先来看看ExceptionHandlerMiddleware的类型定义. public class ExceptionHandlerMiddleware { public Excepti

  • ASP.NET Core基础之中间件

    什么是ASP.NET Core Middleware? ASP.NET Core中间件组件是被组装到应用程序管道中以处理HTTP请求和响应的软件组件(从技术上来说,组件只是C#类). ASP.NET Core应用程序中的每个中间件组件都执行以下任务. 选择是否将 HTTP 请求传递给管道中的下一个组件.这可以通过在中间件中调用下一个 next() 方法实现. 可以在管道中的下一个组件之前和之后执行工作. 在ASP.NET Core中,已经有很多内置的中间件组件可供使用,您可以直接使用它们. 如果

  • 如何给asp.net core写个中间件记录接口耗时

    Intro 写接口的难免会遇到别人说接口比较慢,到底慢多少,一个接口服务器处理究竟花了多长时间,如果能有具体的数字来记录每个接口耗时多少,别人再说接口慢的时候看一下接口耗时统计,如果几毫秒就处理完了,对不起这锅我不背. 中间件实现 asp.net core 的运行是一个又一个的中间件来完成的,因此我们只需要定义自己的中间件,记录请求开始处理前的时间和处理结束后的时间,这里的中间件把请求的耗时输出到日志里了,你也可以根据需要输出到响应头或其他地方. public static class Perf

  • ASP.NET Core中预压缩静态文件的方法步骤

    前言 Web应用程序的优化是非常重要,因为使用更少的CPU,占用更少的带宽可以减少项目的费用. 在ASP.NET Core中我们可以很容易的启用响应压缩,但是针对预压缩文件,就需要做一些额外的功能了. 这篇博客文章展示了如何在ASP.NET Core中预压缩静态文件. 下面话不多说了,来一起看看详细的介绍吧 为什么需要预压缩文件? 虽然在从服务器请求文件时, 我们可以动态压缩文件,但这意味这Web服务器需要做更多的额外工作. 其实只有在新的应用程序部署时才会更改要压缩的文件. 越好的压缩效果需要

  • 如何在ASP.NET Core中使用Session的示例代码

    ASP.NET Core 是一个跨平台,开源的,轻量级,高性能 并且 高度模块化的web框架,Session 可以实现用户信息存储从而可以在同一个客户端的多次请求之间实现用户追踪,在 ASP.Net Core 中可以使用 Microsoft.AspNetCore.Session 中间件来启用 Session 机制. 中间件的价值在于可以在 request -> response 的过程中做一些定制化的操作,比如说:监视数据,切换路由,修改流转过程中的消息体,通常来说:中间件是以链式的方式灌入到

随机推荐