跨域资源请求作用和应用场景_跨域资源共享请求如何影响应用程序的性能

跨域资源请求作用和应用场景

The title may lead you to think that this post is another ranting post about the downside of a “Single Page Application”. It is more about shedding some light on the performance perspective to keep in mind while designing the SPA. Especially if your SPA consumes APIs from different domain services.

标题可能使您认为该帖子是关于“单页应用程序”的缺点的另一篇冗长的文章。 在设计SPA时，要更多地考虑性能方面的注意事项。 特别是如果 你的 SPA使用来自不同域服务的API。

If you are designing an SPA which consumes the API from the same domain of the SPA, then great. You should skip this article if your SPA only pulls from the API on the same domain.

如果要设计一个使用SPA相同域中的API的SPA，那就太好了。 如果您的SPA仅从同一域中的API中提取，则应该跳过本文。

Most SPAs involve “microservices.” They consume different endpoints of services serving by different domains within the SPA. This adds resilience, fault tolerance, and an improved user experience of our product. Multiple domain requests become inevitable until and unless we strictly adhere to the same domain app API Gateway — Microservices Pattern for our SPA.

大多数SPA涉及“微服务”。 它们使用SPA中不同域提供的服务的不同端点。 这增加了弹性，容错能力，并改善了我们产品的用户体验。 除非并且除非我们严格遵守SPA的同一个域应用程序API网关-微服务模式 ，否则多个域请求将不可避免。

Let’s Imagine we have a GET API /users/report/:id served from domain api.example.com. Our SPA is served from spa.example.com. The :id means its a value that can change for every request.

想象一下，我们从域api.example.com提供了一个GET API /users/report/:id 。 我们的SPA是从spa.example.com 。 :id表示其值可以针对每个请求进行更改。

Can you guess the issue with the above API design with respect to CORS (Cross-Origin Resource Sharing) and its impact on the performance of our SPA?

您可以针对CORS (跨原始资源共享)猜测上述API设计的问题及其对SPA性能的影响吗？

Here’s a brief Introduction of CORS from MDN:

这是MDN的CORS的简要介绍：

CORS is all good while it’s a simple request that doesn’t trigger a CORS preflight. But most often we make requests that are not a “ simple request.”

CORS很好，虽然它是一个简单的请求 ，但不会触发CORS起飞前检查。 但是大多数情况下，我们发出的请求不是“ 简单的请求” 。

This is due to the fact that we need to send a header that is not CORS-safelisted-request-header. An example header is Authorization, x-corelation-id. Frequently our Content-Type header value is application/json. This is not an allowed value for the Content-Type header for cors-safelisted-request-header.

这是由于我们需要发送的标头不是CORS-safelisted-request-header 。 标头示例为Authorization, x-corelation-id 。 通常，我们的Content-Type标头值为application/json 。 这不是cors-safelisted-request-header的Content-Type标头的允许值。

If our api.example.com server accepts content-type of application/json, our SPA domain spa.example.com will first send an HTTP request by the OPTIONS method. It is sent to the resource /users/report/12345 on the other domain api.example.com. To determine whether the actual request is safe to send, the option is sent preflighted. Cross-site requests are always preflighted like this, since they may have implications for user data.

如果我们的api.example.com服务器接受application/json content-type ，那么我们的SPA域spa.example.com将首先通过OPTIONS方法发送HTTP请求。 它被发送到另一个域api.example.com上的资源/users/report/12345 。 为了确定实际请求是否可以安全发送，该选项已预检发送。 跨站点请求总是这样进行预检，因为它们可能会对用户数据产生影响。

It’s the job of api.example.com server to let the other domain spa.example.com know it’s safe to send the data. You might have done something similar to this for CORS inside your Application.

api.example.com服务器的工作是让另一个域spa.example.com知道发送数据是安全的。 您可能在应用程序内部对CORS执行了类似的操作。

Once the api.example.com server sends the proper response from “OPTIONS” method to other domain spa.example.com then only the actual data with the request you were trying to make is done.

api.example.com服务器将来自“ OPTIONS”方法的正确响应发送到其他域spa.example.com之后，仅完成您尝试发出的带有请求的实际数据。

So to access a resource api.example.com/users/report/12345 two actual requests were performed.

因此，要访问资源api.example.com/users/report/12345 需要执行两个实际请求。

You might say yes. We can use the Access-Control-Max-Age header to cache the results of a preflight request. The next time we access the resource api.example.com/users/report/12345 from spa.example.com there is no preflight request.

您可能会说是。 我们可以使用Access-Control-Max-Age header 缓存预检请求的结果。 下次我们从spa.example.com访问资源api.example.com/users/report/12345 ，没有预检请求。

Yes, that’s true, but then remember the title — The terrible performance cost of CORS requests on the single-page application (SPA). This comes from the API that we’re are consuming and the way it’s been designed. In our example, we designed our API /users/report/:id, where :id means its a value that can change.

是的，的确如此，但是请记住标题-单页应用程序(SPA)上CORS请求的巨大性能成本。 这来自我们正在使用的API及其设计方式。 在我们的示例中，我们设计了API /users/report/:id ，其中:id表示其值可以更改。

The way preflight cache works is per URL, not just the origin. This means that any change in the path (which includes query parameters) warrants another preflight request.

预检缓存的工作方式是每个URL，而不仅仅是源。 这意味着路径中的任何更改(包括查询参数)都将保证另一个预检请求。

So in our case, to access resource api.example.com/users/report/12345 and api.example.com/users/report/123987, it will trigger four requests from our SPA in total.

因此，在本例中，要访问资源api.example.com/users/report/12345和api.example.com/users/report/123987 ，它将总共触发来自SPA的四个请求。

If you have a slow network, this could be a huge setback. Especially when an OPTIONS request takes 2 seconds to respond, and another 2 for the data.

如果您的网络速度较慢，那么这可能是一个巨大的挫折。 尤其是当一个OPTIONS请求需要2秒响应，而另外2个数据响应时。

Now imagine your SPA application making millions of such requests for different domains. It will have a terrible impact on your SPA’s performance. You’re doubling the latency of every request.

现在，假设您的SPA应用程序对不同的域发出了数百万个这样的请求。 这将对您的SPA的性能产生可怕的影响。 您正在将每个请求的延迟加倍。

SPAs are great in their own domain. But for consuming different domains they come with their own cost. If the API is poorly designed, the latency issues of your SPA can hurt more than the benefits they provide.

SPA在自己的领域中很棒。 但是，要使用不同的域，它们需要自己付费。 如果API的设计不当，那么SPA的延迟问题可能会给他们带来的好处更多。

There is no solution or technology that is wholly good or bad. Knowing its shortcoming and what it takes to make it work are what matters. This is what differentiates your Application from the others.

没有解决方案或技术完全是好是坏。 重要的是要知道它的缺点以及使其工作所需的时间。 这就是您的应用程序与其他应用程序不同的地方。

翻译自: https://www.freecodecamp.org/news/the-terrible-performance-cost-of-cors-api-on-the-single-page-application-spa-6fcf71e50147/

跨域资源请求作用和应用场景