stax 修改_我们如何为Stax控制台构建无服务器Web应用程序

stax 修改

This post was originally published on the Stax website.

该帖子最初发布在Stax网站上 。

Building a web console for a product as complex as Stax presented a number of challenges. Our API-first, serverless platform offers a diverse range of features for enterprises who want to manage and optimize their AWS ecosystem.

为像Stax这样复杂的产品构建Web控制台带来了许多挑战。 我们的API优先，无服务器平台为想要管理和优化其AWS生态系统的企业提供了多种功能。

With such a developer-focused foundation, we needed to provide customers with a performant, reactive web app, with an intuitive user-experience that didn’t hide the power and functionality of our API. Data access through our console also needed to be built to the same high standard of security and compliance as the rest of our product.

在以开发人员为中心的基础上，我们需要为客户提供高性能，React灵敏的Web应用程序，并且要具有直观的用户体验，而这并没有掩盖我们API的强大功能。 通过我们的控制台进行的数据访问也需要与产品的其余部分建立在相同的高安全性和合规性标准之上。

This post will cover what we set out to achieve when building the Stax Console, our experience building a serverless GraphQL API to power it, and the lessons we learned along the way.

这篇文章将介绍我们在构建Stax Console时要实现的目标，构建无服务器的GraphQL API为其提供动力的经验以及我们在此过程中学到的经验教训。

无服务器设计 (Serverless by Design)

We wanted to produce a solution that was serverless from the start, to match the architecture we use for the rest of the product. One of the biggest benefits we’ve seen from going all in on serverless architectures at Stax is uptime and reliability. Avoiding relying on a server that can become a single point of failure allows us to meet our Service-Level Agreement, and ensure customers can access the platform during peak load times. Using AWS Lambda means queries from our front-end scale out horizontally and there’s always enough compute resources to process requests.

我们希望从一开始就提供一种无服务器的解决方案，以匹配我们在产品其余部分使用的架构。 通过在Stax中全面采用无服务器架构 ，我们看到的最大好处之一就是正常运行时间和可靠性。 避免依赖可能成为单点故障的服务器，这使我们能够满足我们的服务水平协议，并确保客户可以在高峰负载时间内访问平台。 使用AWS Lambda意味着前端的查询可以横向扩展，并且始终有足够的计算资源来处理请求。

Using serverless products also improves security during development, as services like AWS Lambda provide baked-in compliance and service levels out of the box. Allowing Amazon to handle upgrades and patching of the infrastructure that our code runs on allows us to focus on building software instead of managing hardware.

使用无服务器产品还可以提高开发期间的安全性，因为AWS Lambda之类的服务提供了现成的合规性和服务级别。 允许Amazon处理我们的代码所运行的基础架构的升级和修补，使我们能够专注于构建软件而不是管理硬件。

The minimal infrastructure overhead when going serverless has allowed our team to fully own the deployment and monitoring of our GraphQL API. For example, developers can add new Networks functionality using separate Lambda functions to those used to fetch account data, minimizing the blast radius from pushing a new change to production.

转向无服务器时的最小基础架构开销使我们的团队可以完全拥有GraphQL API的部署和监视。 例如，开发人员可以使用单独的Lambda函数向用于提取帐户数据的函数添加新的Networks功能，从而最大程度地减少将新更改推向生产的爆炸半径。

早些年 (Early Days)

The first iteration of our Console had a fairly traditional web architecture. A React single-page application (SPA) called the Stax REST API directly, which is a serverless solution using AWS API Gateway and AWS Lambda in front of a relational database. AWS Cognito handles user authentication and sign-on for both the Console and REST API.

控制台的第一个版本具有相当传统的Web架构。 React单页应用程序(SPA)直接称为Stax REST API，这是在关系数据库之前使用AWS API Gateway和AWS Lambda的无服务器解决方案。 AWS Cognito处理控制台和REST API的用户身份验证和登录。

We ran into a few technical issues with this approach:

这种方法遇到了一些技术问题：

1. Tooling. Modern front-end frameworks evolve quickly. Consuming data from REST APIs with React was complex and it was difficult to manage state.

   工具 。 现代前端框架发展Swift。 通过React使用REST API的数据非常复杂，并且难以管理状态。

2. Stability. The tight coupling of our front-end SPA to back-end REST API was efficient, but the contract between systems was constantly changing as features developed which risked breaking our user interface.

   稳定性 。 我们的前端SPA与后端REST API的紧密耦合是有效的，但是随着功能的发展，系统之间的契约在不断变化，这有可能破坏我们的用户界面。

3. Real-Time Updates. We would need to build our own WebSocket implementation to push data to our front-end SPA to provide real-time updates. This would have been complex to implement in both the front end and back end.

   实时更新 。 我们将需要构建自己的WebSocket实现，以将数据推送到前端SPA，以提供实时更新。 在前端和后端都难以实现。

It also became apparent that as Stax grew as a product, the Console needed to integrate with other back-end services than our REST API, such as Cost and Compliance data for accounts and our Customer Support Case service. Interfacing with multiple APIs and protocols, all with differing authentication mechanisms, led us to consider a Back End for Front End pattern with a single GraphQL API.

还很明显，随着Stax作为产品的增长，控制台需要与REST API之外的其他后端服务集成，例如帐户的成本和合规性数据以及我们的客户支持案例服务。 与多个具有不同认证机制的API和协议的接口，促使我们考虑使用单个GraphQL API的后端为前端模式。

现在我们的控制台架构 (Our Console Architecture Now)

The architecture centers on a GraphQL API layer that acts as a proxy between our front-end and back-end services. GraphQL is a query language for APIs; it allows developers to define the types of data in a system (the schema), and wire up functions to fetch data from different sources (resolvers). Relationships between data can be expanded in a single GraphQL query. For example, a single request can resolve a Stax Workload and the user that deployed it in one go.

该架构以GraphQL API层为中心，该层充当我们的前端和后端服务之间的代理。 GraphQL是API的查询语言； 它允许开发人员定义系统(架构)中的数据类型，并连接功能以从不同来源(解析器)获取数据。 数据之间的关系可以在单个GraphQL查询中扩展。 例如，单个请求可以解析Stax工作负载以及一次性部署它的用户。

A key reason GraphQL suited our needs is that data can be fetched from any source by a resolver and be presented to a front end as a single interface. This means that as Stax grows, we can refactor and optimize back-end services with minimal impact to our front-end developers and customers. Authentication is also massively simplified. The front-end authenticates to our GraphQL API in one place, which handles connections to various REST and GraphQL APIs and event sources behind the scenes.

GraphQL满足我们需求的一个关键原因是解析器可以从任何来源获取数据，并将其作为单个接口呈现给前端。 这意味着随着Stax的增长，我们可以重构和优化后端服务，而对前端开发人员和客户的影响最小。 身份验证也大大简化了。 前端在一个地方对我们的GraphQL API进行身份验证，该身份验证处理与各种REST和GraphQL API以及后台事件源的连接。

At Stax, we’re closely partnered with AWS, and try to use native AWS solutions where possible as part of our development philosophy. We opted to use AWS AppSync, a fully managed serverless GraphQL implementation as the core of our service.

在Stax，我们与AWS紧密合作，并尝试尽可能使用本机AWS解决方案作为我们开发理念的一部分。 我们选择将AWS AppSync (一种完全托管的无服务器GraphQL实现)用作我们服务的核心。

AWS AppSync implements the main GraphQL directives, including GraphQL Subscriptions that manage WebSocket connections between clients and your GraphQL API. AWS Lambda fetches and transforms data in GraphQL resolver functions, AWS DynamoDB is used for serverless data stores, and AWS EventBridge triggers Lambda functions in response to system events.

AWS AppSync实现了主要的GraphQL指令，包括用于管理客户端与GraphQL API之间的WebSocket连接的GraphQL订阅。 AWS Lambda在GraphQL解析器函数中获取和转换数据， AWS DynamoDB用于无服务器数据存储， AWS EventBridge触发Lambda函数以响应系统事件。

内置Stax (Built with Stax)

Stax is an API-first product, so we leveraged the publicly available Stax REST API to build the majority of the customer console. Consuming (dogfooding, really) our own REST API means we can road-test functionality and improve our documentation before the functionality is released to customers, acting as our own quality control. Having a GraphQL API that proxies our back end also lets us introduce new features into the Console before they are made public to customers in the Stax REST API. We can simply connect it to AppSync and add it into the Console as “Beta” functionality.

Stax是API优先产品，因此我们利用可公开获得的Stax REST API来构建大多数客户控制台。 使用我们自己的REST API(实际上是dogfood) ，意味着我们可以在将功能发布给客户之前进行路测功能并改善我们的文档，作为我们自己的质量控制。 拥有可以代理后端的GraphQL API，还可以让我们在Stax REST API中向客户公开新功能之前，将新功能引入控制台。 我们可以简单地将其连接到AppSync，并将其作为“测试版”功能添加到控制台中。

Our GraphQL API communicates with the Stax back end by sharing authentication information from AWS Cognito between services. This ensures user data remains strictly segregated by a customer’s organization at each step of the process, and maintains an audit trail tied to the specific user that initiated an action. Having a single GraphQL API for our front end also lets us enforce role-based access control, which means we can enforce restrictions for user actions based on their role at a query level.

我们的GraphQL API通过在服务之间共享来自AWS Cognito的身份验证信息来与Stax后端进行通信。 这样可以确保在流程的每个步骤中，用户数据始终由客户组织严格隔离，并维护与发起操作的特定用户相关的审核跟踪。 前端只有一个GraphQL API，这使我们能够实施基于角色的访问控制 ，这意味着我们可以根据用户在查询级别的角色来实施对用户操作的限制。

The AppSync API is also connected to the Stax Event Bus to listen to system events generated by back-end services, like the status of individual account setup steps) completing. We use GraphQL Subscriptions to enhance the functionality provided by the Stax Event Bus and push updates to the Console without customers needing to refresh their page.

AppSync API还连接到Stax Event Bus，以侦听后端服务生成的系统事件，例如各个帐户设置步骤的状态。 我们使用GraphQL订阅来增强Stax事件总线提供的功能，并将更新推送到控制台，而无需客户刷新页面。

拥抱局限性 (Embracing the Limitations)

Authentication often poses a challenge with serverless architectures, as user authentication information needs to be shared with each service or API involved in fulfilling a request. A single GraphQL query might result in multiple downstream services being called — for example, to show a Network, the account in which it’s deployed, and the user that created it.

身份验证通常会给无服务器架构带来挑战，因为用户身份验证信息需要与完成请求所涉及的每个服务或API共享。 单个GraphQL查询可能会导致调用多个下游服务，例如，以显示一个网络，该网络的部署帐户以及创建该网络的用户。

AWS AppSync makes it easy to abstract authentication by using AppSync Pipeline Resolvers, but it’s still important to ensure calls to services with strict rate limits like AWS Cognito are minimized. We approached this by abstracting interactions with Cognito into a dedicated service, but there’s room for this to be improved with caching.

AWS AppSync使您可以使用AppSync Pipeline Resolvers轻松抽象身份验证，但是确保对具有严格速率限制的服务(例如AWS Cognito)的调用最小化仍然很重要。 我们通过将与Cognito的交互抽象为专用服务来解决此问题，但是通过缓存可以改善这一点。

As a relatively new product offering, AWS AppSync had a few limitations in its GraphQL implementation that we had to overcome. AppSync imposes a strict, 30-second timeout for all queries, meaning large paginated lists of data with nested relationships need to be handled carefully. AppSync also allows batching Lambda functions when dealing with one-to-many relationships, but currently has a batch limit of 5, which is too low to be useful in practice. Deploying our own GraphQL implementation would have let us avoid these issues, but the benefits of using a fully managed serverless solution outweighed the pain points.

作为一种相对较新的产品，AWS AppSync在其GraphQL实施中存在一些必须克服的限制。 AppSync对所有查询施加30秒的严格超时，这意味着需要仔细处理带有嵌套关系的大型分页数据列表。 AppSync还允许在处理一对多关系时对Lambda函数进行批处理，但当前的批处理限制为5，该限制太低而无法在实践中使用。 部署我们自己的GraphQL实现将使我们避免这些问题，但是使用完全托管的无服务器解决方案的好处超过了痛苦点。

下一步 (Next Steps)

The future of our GraphQL API will focus on performance improvements through data caching, and on extending real-time updates to all Stax components. Caching data will allow customers to manage their Stax environments and view data even when downstream services are unavailable.

GraphQL API的未来将集中于通过数据缓存提高性能，以及将实时更新扩展到所有Stax组件。 缓存数据将使客户能够管理他们的Stax环境并查看数据，即使下游服务不可用也是如此。

As the Stax platform continues to evolve, we’ll continue adding new features to our console, to make it as easy as possible for your organization to manage all aspects of their AWS ecosystem from a single place. But since we’re leveraging a serverless approach, we don’t need to allocate effort to maintaining servers. Instead, we can focus on building out more amazing experiences for our customers while at the same time remaining secure and compliant, even as the platform grows more sophisticated.

随着Stax平台的不断发展，我们将继续向控制台添加新功能，以使您的组织尽可能轻松地从一个地方管理其AWS生态系统的各个方面。 但是，由于我们正在利用无服务器方法，因此无需分配精力来维护服务器。 相反，即使平台变得越来越复杂，我们也可以专注于为我们的客户构建更出色的体验，同时保持安全性和合规性。

If you’re interested in learning more about Stax, and how it might fit into your organization’s AWS ecosystem, get in touch and we’ll arrange a demo.

如果您想了解有关Stax的更多信息，以及它可能如何适合您组织的AWS生态系统，请联系我们，我们将安排一个演示 。

翻译自: https://www.sitepoint.com/how-we-built-a-serverless-web-app-for-the-stax-console/

stax 修改