画aws图
Software engineers must pick the right API technology. GraphQL can be the best choice when it comes to rich data-intensive applications. Pair it with AWS AppSync, so you waste no time setting up your infrastructure and you can focus on creating valuable functionalities.
软件工程师必须选择正确的API技术。 当涉及丰富的数据密集型应用程序时，GraphQL可能是最佳选择。 将其与AWS AppSync配对，因此您不会浪费时间设置基础架构，并且可以专注于创建有价值的功能。
In a data-driven world, one of the most important needs is data exchanging between multiple systems and applications.
在数据驱动的世界中，最重要的需求之一就是在多个系统和应用程序之间进行数据交换。
For this, as we all think about choosing the proper storage and computing system, we also need to pick the right API technology.
为此，当我们所有人都在考虑选择适当的存储和计算系统时，我们还需要选择正确的API技术。
At Quantyca one of our design principles is to be open to polyglotism, even when it comes to APIs. For this reason, we studied GraphQL and when and how to go for it in our projects.
在Quantyca ，我们的设计原则之一是对多语言开放，即使涉及API。 因此，我们研究了GraphQL以及在项目中何时以及如何使用它。
In this blog post, I will present you with a summary of our learnings. We will take a look at the following topics:
在此博客文章中，我将向您介绍我们的学习摘要。 我们将研究以下主题：
🎯 What is GraphQL and when and why (not) use it
🎯什么是GraphQL，何时以及为什么(不)使用它
🎯 GraphQL architecture — the big picture
🎯GraphQL体系结构—全局
🎯 AWS AppSync — a cloud-based fully managed GraphQL service
App AWS AppSync-基于云的完全托管的GraphQL服务
什么是GraphQL以及何时以及为什么(不)使用它 (What is GraphQL and when and why (not) use it)
According to GraphQL Foundation website:
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.
GraphQL是API的查询语言，是用于使用现有数据来完成这些查询的运行时。
It was developed by Facebook in 2012 and now open-sourced as a specification.
它是由Facebook在2012年开发的，现在已作为规范开源。
By being a query language, the main feature of GraphQL is that it gives clients the power to ask for exactly what data they need. Nothing more and nothing less. This characteristic prevents both over fetching and under fetching. The former implies retrieving data that is actually not needed while the latter means retrieving not enough information to meet data requirements.
作为一种查询语言，GraphQL的主要功能是它使客户可以准确地询问他们需要什么数据。 一无所有。 此特性可防止过度获取和不足获取。 前者意味着检索实际上不需要的数据，而后者意味着检索的信息不足以满足数据需求。
Also, GraphQL queries allow to access not just the properties of one resource but also smoothly follow reference between them. That ability can be leveraged especially in domains where there are a lot of resources extremely interconnected.
此外， GraphQL查询不仅允许访问一种资源的属性，而且还可以平滑地遵循它们之间的引用 。 尤其是在存在大量相互连接的资源的域中，可以利用该功能。
Besides this, GraphQL provides a complete description of the capabilities of the APIs. It lays out a type system to describe data in your APIs and to clearly define supported operations. Thanks to the GraphQL introspection system, you will no longer worry about lacking proper ways of knowing what operations are supported by an API, how to use them, and what are input arguments and possible responses.
除此之外， GraphQL还提供了有关API功能的完整描述 。 它列出了一个类型系统，用于描述API中的数据并明确定义支持的操作。 借助GraphQL自省系统，您将不再担心缺少了解API支持哪些操作，如何使用它们以及输入参数和可能的响应是什么的正确方法。
I just let you taste the potential of GraphQL, but it is important to understand the tradeoffs of this technology to choose the right tool for the right job.
我只是让您品尝GraphQL的潜力，但是了解此技术的权衡因素以选择合适的工具来完成正确的工作非常重要。
The biggest issue is that letting clients run any query they want can be a double-edged sword. Let’s list some pros and cons of this powerful feature:
最大的问题是让客户运行他们想要的任何查询可能是一把双刃剑 。 让我们列出此强大功能的一些优缺点：
👍 Clients can minimize the amount of data that needs to be transferred over the network and thus improve application performance even on slow network connections.
👍客户端可以最大程度地减少需要通过网络传输的数据量，从而即使在网络连接速度较慢的情况下也可以提高应用程序性能。
👍 There is no need to build and maintain specific APIs to fulfill each possible client application requirement.
👍无需构建和维护特定的API即可满足每种可能的客户端应用程序需求。
👎 Clients can ask for as much data as they want. So, if you are not careful, a few big queries can bring your server down to its knees.
👎客户可以根据需要索取尽可能多的数据。 因此，如果您不小心，一些大的查询可能会使您的服务器瘫痪。
👎 Complex queries are hard to design and develop because such complexity cannot be split over several endpoints.
👎复杂的查询很难设计和开发，因为这样的复杂性无法分散在多个端点上。
Therefore, when do we say yea or nay to GraphQL?
因此，我们什么时候对GraphQL说是或否？
Definitely, the flexibility and richness of GraphQL are game-changers for rich mobile and web applications but add complexity that may not be worthwhile for simple APIs.
毫无疑问， GraphQL的灵活性和丰富性改变了丰富的移动和Web应用程序的游戏规则，但增加了复杂性，对于简单的API可能不值得 。
GraphQL体系结构—大图 (GraphQL architecture — the big picture)
As mentioned earlier, GraphQL is a specification. It defines both the rules for the query language and the execution engine. These rules include: how to draft queries, how the type system works, how to perform schema introspection and validation, and how a well-formed response must be.
如前所述，GraphQL是一个规范 。 它定义了查询语言和执行引擎的规则。 这些规则包括：如何起草查询，类型系统如何工作，如何进行模式自省和验证以及必须如何形成正确的响应。
Therefore, the first thing you need to get started with GraphQL is an implementation of the execution engine. Out there is a heterogeneous landscape of GraphQL servers. Each implementation decides upon which software language to use and it can add its own features (such as caching and monitoring).
因此，开始使用GraphQL的第一件事是执行引擎的实现。 那里是GraphQL服务器的异构环境。 每个实现都决定使用哪种软件语言，并且可以添加自己的功能(例如缓存和监视)。
But every GraphQL server needs to fill in data for every field in the schema. Through resolvers, servers can populate data in any way you define, for example by fetching data from a database or a third-party API.
但是每个GraphQL服务器都需要为模式中的每个字段填写数据。 通过解析器，服务器可以用您定义的任何方式填充数据，例如，通过从数据库或第三方API获取数据。
Then GraphQL clients come into play. You can query a GraphQL server directly with an HTTP request but you can simplify your life by using a dedicated client library. GraphQL clients will seamlessly take care of constructing and sending queries, parsing the responses, and updating your UI.
然后GraphQL客户端开始起作用。 您可以直接通过HTTP请求查询GraphQL服务器，但可以使用专用的客户端库来简化您的工作。 GraphQL客户端将无缝处理构造和发送查询，解析响应以及更新UI的工作。
Over the years a lot of projects have sprung up. You can find a list of server libraries here and a list of clients here.
多年来，许多项目如雨后春笋般涌现。 你可以找到服务器库的列表， 在这里和客户名单这里 。
I will quote here the ones that I consider the most interesting:
我在这里引用我认为最有趣的内容：
AWS AppSync —基于云的完全托管的GraphQL服务 (AWS AppSync — a cloud-based fully managed GraphQL service)
As stated above, using GraphQL require manual installation and maintenance of software infrastructure components. Plus, nowadays mobile and web application users demand quick access to information at scale so at least we need to worry about high availability, reliability, and fan-out capabilities.
如上所述，使用GraphQL需要手动安装和维护软件基础结构组件。 另外，当今的移动和Web应用程序用户要求快速大规模访问信息，因此至少我们需要担心高可用性，可靠性和扇出功能。
This is where AWS AppSync comes to rescue.
这是AWS AppSync抢救的地方。
AWS AppSync is a
AWS AppSync是一个
🔥 cloud-based 🔥 fully managed 🔥 serverless
基于云的完全托管的无服务器
GraphQL implementation.
GraphQL实现。
As follows, AWS AppSync does not require any manual installation nor any maintenance and it scales up and down dynamically depending on the load. So you waste no time setting up your infrastructure and you can immediately focus on creating valuable functionalities.
如下所示，AWS AppSync不需要任何手动安装也不需要任何维护，它会根据负载动态伸缩。 因此，您无需浪费时间设置基础结构，就可以立即集中精力创建有价值的功能。
Additionally, AWS AppSync has its own way of spicing up GraphQL.
此外， AWS AppSync具有自己的加码GraphQL的方式。
First of all, the most advantageous feature is that AWS AppSync has built-in resolvers that automatically translate GraphQL requests and fetch information from a range of pre-configured data sources. Indeed, AWS AppSync can streamline the connections to services like AWS DynamoDB, AWS Aurora, AWS Elasticsearch, and AWS Lambda functions in addition to any arbitrary HTTP endpoint. By leveraging built-in resolvers, developers can simplify the retrieval and manipulation of data and consequently cuts down implementation effort and time.
首先，最有利的功能是AWS AppSync具有内置的解析器，该解析器可以自动转换GraphQL请求并从一系列预配置的数据源中获取信息。 实际上，除了任何任意的HTTP端点之外，AWS AppSync还可简化与服务的连接，例如AWS DynamoDB，AWS Aurora，AWS Elasticsearch和AWS Lambda函数。 通过利用内置的解析器，开发人员可以简化数据的检索和处理，从而减少实现工作量和时间。
Moreover, AWS AppSync implements server-side data caching. Developers can selectively cache data fields and operations defined in the GraphQL schema with customizable expiration. This way, there is a reduced need to directly access data sources and performance can be improved.
此外，AWS AppSync实施服务器端数据缓存。 开发人员可以有选择地缓存GraphQL架构中定义的数据字段和操作以及可自定义的到期时间。 这样，减少了直接访问数据源的需求，并且可以提高性能。
Last but not least, AWS AppSync grants enterprise-level security and fine-grained access control. It integrates flawlessly with AWS IAM and AWS Cognito for email and password functionality, social providers, OAuth features, as well as enterprise federation with SAML.
最后但并非最不重要的一点是，AWS AppSync授予企业级安全性和细粒度的访问控制。 它与AWS IAM和AWS Cognito完美集成，以提供电子邮件和密码功能，社交提供程序，OAuth功能以及具有SAML的企业联盟。
Here you find a recap of AWS AppSync key features and advantages.
在这里，您可以找到AWS AppSync关键功能和优势的概述。
✨ It is a cloud-based, fully managed, serverless implementation of GraphQL spec.
✨这是GraphQL规范的基于云的，完全托管的，无服务器的实现 。
✨ Thanks to built-in resolvers, AWS AppSync simplifies the retrieval and manipulation of data across certain AWS data services.
✨借助内置的解析器 ，AWS AppSync简化了跨某些AWS数据服务的数据检索和操作。
✨ It implements server-side data caching for delivering data that doesn’t change frequently at low latency.
✨它实现了服务器端数据缓存，以传递在低延迟下不经常更改的数据。
✨ It grants enterprise-level security and fine-grained access control by joining forces with AWS IAM and AWS Cognito.
✨通过与AWS IAM和AWS Cognito联手，授予企业级安全性和细粒度的访问控制 。
结论 (Conclusions)
GraphQL is a brand new paradigm for implementing API that is especially powerful for data-intensive mobile and web applications. The cloud-based and serverless implementation provided by AWS AppSync represents the cherry on top thanks to its incredible advantages.
GraphQL是用于实现API的全新范例，该API对于数据密集型移动和Web应用程序特别强大。 AWS AppSync提供的基于云和无服务器的实施得益于其无与伦比的优势，代表了最高的樱桃。
Have you ever used GraphQL and AWS AppSync and for which use cases? Do you think that they are valuable tools that have more pros than cons or vice-versa? Let me know in the comments section below.
您是否曾经使用过GraphQL和AWS AppSync，以及哪些用例？ 您是否认为它们是有价值的工具，具有比利弊更多的利弊，反之亦然？ 在下面的评论部分中告诉我。
翻译自: https://medium.com/quantyca/a-birds-eye-view-on-graphql-and-aws-appsync-e220da5345b4
画aws图
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
