Which Category is your question related to?
Hosting / API
Amplify CLI Version
3.17
What AWS Services are you utilizing?
AppSync, S3, Cognito, Lambda
Provide additional details e.g. code snippets
For every GraphQL request my Angular app makes, an OPTIONS request is first made then the actual request. This adds a 200ms latency to every single request.
I read up on this (https://medium.com/@praveen.beatle/avoiding-pre-flight-options-calls-on-cors-requests-baba9692c21a) and it appears the way the headers and content type of each graphql request is structured forces the browser to issue an options request every time.
It appears the solution discussed in https://hackernoon.com/speedup-serverless-web-apps-in-aws-12fa25b94600, "Avoid CORS By Accessing Your API and Frontend Using the Same Origin", might resolve these requests and improve overall latency of the app.
But it does not seem Amplify CLI can set this type of setup out of the box. Will have to do these changes outside of Amplify CLI.
My questions:
1) Since Amplify CLI has a hosting category for the frontend, should it be smart enough to create the same cloudfront end point for the frontend, appsync, and s3 to avoid CORS preflight requests
1) Is it normal for OPTION requests with AppSync to take 200ms end to end in a reasonably high speed connection? (I realize this may be outside of the scope of the Amplify CLI service).
Specifically, my question is, Is there a way for Amplify CLI to make aws_content_delivery_bucket have the same value as aws_appsync_graphqlEndpoint in a SPA app through cloudfront. This way preflight requests and the latency involved with them are eliminated.
Here's an example app written by @dabit3 that has this issue btw: https://www.writewithme.dev/#/post/42299768-7ad3-456e-a676-e25011b81a25/some%20testing
For every graphql request, there's actually two http requests, with one being the OPTIONS request and that takes 200ms in my high speed wifi connection, with most of the time spent waiting on the server:

In a world where pagespeed scores on mobile are really important this is not ideal and is very avoidable.
+1 - Any updates on this?
@amcdnl is this still happening for you? It seems this got resolved somehow on my side, I'm no longer seeing multiple OPTIONS requests.
Yup - do you know when it started working by chance? cc @dabit3

Most helpful comment
Here's an example app written by @dabit3 that has this issue btw: https://www.writewithme.dev/#/post/42299768-7ad3-456e-a676-e25011b81a25/some%20testing
For every graphql request, there's actually two http requests, with one being the OPTIONS request and that takes 200ms in my high speed wifi connection, with most of the time spent waiting on the server:
In a world where pagespeed scores on mobile are really important this is not ideal and is very avoidable.