5 ms·
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
by 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 agoNote 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.
- richardwhiuk 5y agoJust because they are on different tech stacks doesn't mean you can't do this.
- mixedCase 5y agoI'm having trouble thinking of a web stack where you can't set up a reverse proxy either via Nginx colocated with the frontend web server, through any of the usual suspects for termination (e.g. CDNs or load balancers), or worst case scenario, through the frontend web server itself. Can you share any examples?
- jakub_g 5y agoI'm not an expert because I only work on front-end but scale ops folks in my prev job had their reasons. We had legacy www http/1 monolith and api http/2 geodistributed in the cloud. Making the two go through the common proxy wouldn't probably make sense and/or would be quite expensive.