6 ms·

What is the author trying to say, it is very hard to recognize the answer of the article. Is it to point requests to sub path of the main domain to reduce OPTI

by miyuru 5y ago

What is the author trying to say, it is very hard to recognize the answer of the article. Is it to point requests to sub path of the main domain to reduce OPTIONS requests? eg: api.example.com ---> example.com/api In that case why not use proper "Access-Control-Max-Age" headers? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

wereHamster 5y ago
Chrome imposes a limit of 2h on Access-Control-Max-Age (other browsers may differ). Anyway, today we have the tools to expose different backends through the same domain. Reverse proxies, k8s ingress, … a separate domain may not add much value in most situations.
- berkes 5y ago
  Even then, most often your backend API service runs off one domain, so it needs only one OPTION request ever two hours for the user session. If your users make only one request per two hours, that still doubles the requests, so in that case caching'll hardly help. But in more typical cases, where one session does 20+ requests, it's a meagre 5% of the requests. In which case 'resolving that n+1 request' or 'speeding up that 1200ms response' is far better low hanging fruit than removing the single OPTIONS request. It depends on your case, though.
- franga2000 5y ago
  Subdomains absolutely have value! It doesn't matter that we have those tools "today" (it's not like we didn't have reverse proxies many years ago), different domains are still the only way to truly split up traffic. A reverse proxy by definition doubles your total bandwidth requirement, which is expensive and inefficient if you aren't running everything in one datacenter. You'd need to not only get servers with enough bandwidth to cover their traffic, but another server with the sum of all individual server bandwidths to handle proxying. And if you want to do geographic sharing, you either need to shard all services, or be fine with an increase in latency for non-sharded services.
todd3834 5y ago
Yes I believe the article is suggesting exactly that. Even with that header users will still hit that latency on the first request. If the goal is to lower latency on first page load then that won’t help. Although it should definitely help after that.
- conradfr 5y ago
  Is it still that much important with http2 for most webapps? You can answer the options request at the webserver level or even Varnish which should be quick enough and the http connection reused.
  - masklinn 5y ago
    > Is it still that much important with http2 for most webapps? Yes? The overhead of a full request/response cycle is still overhead, even if it's lowered by not having to duplicate establishing the connection itself.
- jakub_g 5y ago
  Sometimes it's very difficult to use same domain if e.g. API is on different tech stack. IIRC you could then do something like <link rel=preconnect crossorigin=anonymous href="https://api.example.com https://api.example.com"> or <link rel=preload crossorigin=anonymous href="https://api.example.com/emptyendpoint https://api.example.com/emptyendpoint"> just to initiate the connection/CORS dance early one before your JS kicks in. In my prev job we'd do a request to empty endpoint from inlined JS. Poor hack but it worked.
  - jakub_g 5y ago
    Note that if you send any non standard request headers, for the CORS response to be cached and reused, you need to make an initial request with exactly same set of headers, which means it is only possible via JS (preload request can't have extra headers). Hence inlined JS to send the "warmup" request. You can wrap it in a promise which resolves on response, and only then do the actual app request.
  - 5y ago
berkes 5y ago
Caching is one solution and it work fine, not perfect. Another thing to consider is avoid hitting your api application with those requests. You quite probably don't need authorization or any other business logic in that preflight. You can just catch any OPTION or OPTION+preflight headers in your proxy, webserver or balancer and handle it there. You certainly don't want to handle them in Rails/Rack, nodejs, lambda, django, spring or such. This makes them so much faster for users, and so much lighter for servers that the once per 2 hours cached request hardly is measurable, even.
deleted 5y ago
[deleted]

by miyuru 5y ago

wereHamster 5y ago

Chrome imposes a limit of 2h on Access-Control-Max-Age (other browsers may differ). Anyway, today we have the tools to expose different backends through the same domain. Reverse proxies, k8s ingress, … a separate domain may not add much value in most situations.

berkes 5y ago
Even then, most often your backend API service runs off one domain, so it needs only one OPTION request ever two hours for the user session. If your users make only one request per two hours, that still doubles the requests, so in that case caching'll hardly help. But in more typical cases, where one session does 20+ requests, it's a meagre 5% of the requests. In which case 'resolving that n+1 request' or 'speeding up that 1200ms response' is far better low hanging fruit than removing the single OPTIONS request. It depends on your case, though.
franga2000 5y ago
Subdomains absolutely have value! It doesn't matter that we have those tools "today" (it's not like we didn't have reverse proxies many years ago), different domains are still the only way to truly split up traffic. A reverse proxy by definition doubles your total bandwidth requirement, which is expensive and inefficient if you aren't running everything in one datacenter. You'd need to not only get servers with enough bandwidth to cover their traffic, but another server with the sum of all individual server bandwidths to handle proxying. And if you want to do geographic sharing, you either need to shard all services, or be fine with an increase in latency for non-sharded services.

todd3834 5y ago

Yes I believe the article is suggesting exactly that. Even with that header users will still hit that latency on the first request. If the goal is to lower latency on first page load then that won’t help. Although it should definitely help after that.

conradfr 5y ago
Is it still that much important with http2 for most webapps? You can answer the options request at the webserver level or even Varnish which should be quick enough and the http connection reused.
- masklinn 5y ago
  > Is it still that much important with http2 for most webapps? Yes? The overhead of a full request/response cycle is still overhead, even if it's lowered by not having to duplicate establishing the connection itself.
jakub_g 5y ago
Sometimes it's very difficult to use same domain if e.g. API is on different tech stack. IIRC you could then do something like <link rel=preconnect crossorigin=anonymous href="https://api.example.com https://api.example.com"> or <link rel=preload crossorigin=anonymous href="https://api.example.com/emptyendpoint https://api.example.com/emptyendpoint"> just to initiate the connection/CORS dance early one before your JS kicks in. In my prev job we'd do a request to empty endpoint from inlined JS. Poor hack but it worked.
- jakub_g 5y ago
  Note that if you send any non standard request headers, for the CORS response to be cached and reused, you need to make an initial request with exactly same set of headers, which means it is only possible via JS (preload request can't have extra headers). Hence inlined JS to send the "warmup" request. You can wrap it in a promise which resolves on response, and only then do the actual app request.
- 5y ago

berkes 5y ago

Caching is one solution and it work fine, not perfect. Another thing to consider is avoid hitting your api application with those requests. You quite probably don't need authorization or any other business logic in that preflight. You can just catch any OPTION or OPTION+preflight headers in your proxy, webserver or balancer and handle it there. You certainly don't want to handle them in Rails/Rack, nodejs, lambda, django, spring or such. This makes them so much faster for users, and so much lighter for servers that the once per 2 hours cached request hardly is measurable, even.

deleted 5y ago

[deleted]