Closed smakinson closed 4 months ago
We have exactly the same question.
I do have a prerender server up and running. Redirect based on user agent could be a solution?
I have tried the middleware via their prerender-cloudfront.yaml from the middleware and that setup seems to work fine, however it involves a S3 bucket. I'm thinking the rewrite may be the best option here. @swaminator What are your thoughts on this?
Any progress on this? Is AWS Amplify console a valid solution at all if it comes to this?
Thank you for investigating!
@smakinson apologies we didn't get to this sooner. We had a number of other priorities that came above this. At this point, it is close to the top of our list of issues and I'm hoping to have a response here in the next 2-3 weeks.
@swaminator That sounds great! Thank you!
@swaminator Do you have any further updates on this ?
@swaminator Appreciate if you could provide an update on this request, for now, I have moved my site deployment to 'netlify' ( as they have built in pre-rendering service). Hoping that Amplify team implements the pre-rendering service at the earliest.
Any updates?
I'm trying to find out about the recommended practices for SSR with Amplify. Is there anything official on the matter?
I am trying to figure out an answer on this same question. I'd appreciate any help or suggestions!
I eventually solved it with Cloudfront + Lambda (got the link to a repo from the first post in this thread)
https://github.com/jinty/prerender-cloudfront
So far it's been working perfectly for me. If you go for this solution, pay special attention to increase the versions of your lambda whenever you update it.
@arturocanalda Thanks for the suggestion, and that's awesome you got this working!
Did you stand up a new Cloudfront distribution that has those two Lambda@Edge functions to handle the routing? And the origin for that distribution was the Amplify-deployed URL?
If I understand correctly, the example has the direct S3 link to the SPA build that we don't have access to with Amplify. I wasn't sure if standing up a second Cloudfront distribution to deploy the Lambda would (a) not work or (b) incur double Cloudfront/access costs. However, I'd probably still go this path if it ends up working.
I already had a CloudFront distribution.
I don't see any reference to S3 in the template :)
In that example there are 2 Lambda (edge) functions:
/googlebot|adsbot\-google|Feedfetcher\-Google|bingbot|yandex|baiduspider|Facebot|facebookexternalhit|twitterbot|Whatsapp|rogerbot|linkedinbot|embedly|quora link preview|showyoubot|outbrain|pinterest|slackbot|vkShare|W3C_Validator
prerender.io
if the http request header contains some extra/custom headers (added by SetPrerenderHeader
). Otherwise it won't modify the request. Once those functions are created, in you Clooudformation template (amplify/backend/hosting/S3AndCloudfront/template.json
-> Add I added the following to DefaultCacheBehavior
:
"LambdaFunctionAssociations": [
{
"EventType" : "viewer-request",
"LambdaFunctionARN" : {
"Ref": "setPrerenderHeaderArn"
}
},
{
"EventType" : "origin-request",
"LambdaFunctionARN" : {
"Ref": "redirectToPrerenderArn"
}
}
]
Where setPrerenderHeaderArn
and redirectToPrerenderArn
are passed as a template param from amplify/backend/hosting/S3AndCloudfront/parameters.json
(*) Notice I created this functions once and they are used by my 3 environments (dev, stg, prd). Not a best practice, but didn't have more time to invest on it.
@arturocanalda Perfect, thanks so much for your help! The WebBucket
at the start of the YAML threw me off a bit, but your reply helped me realize that you just setup the Cloudfront distribution with the Amplify URL as the origin, setup the two edge lambdas, and everything works out.
I ended up changing the origin-request
lambda to redirect to an S3 bucket with my own pre-rendered pages, so it took me the weekend to get it all working right. I should have just saved my time and used prerender.io... but it was certainly a good learning experience.
I do think Amplify is standing up its own Cloudfront distribution as part of the original deployment. However, it's hidden and can't be modified with edge lambdas, so we need to stand-up our own distribution to make this work. I think this means we're double-paying in some sense (with some CDN cost built into the Amplify pricing), but I'll tackle this problem when it actually becomes a practical versus theoretical issue. Hopefully, the Amplify team will have found a solution before that time.
Thanks again for the help @arturocanalda !
@theforager you're welcome. Somehow we are all in the same boat :)
Hi @arturocanalda and @theforager How did you exactly make it work? I'm using the Amplify console, so I can't access to the S3, Cloudfront and execute LamdaEdge functions. Should I start a new project just using the cli and use the S3Cloudfront hosting? What are the steps to make it work? The documentation is quiet poor. Thanks
Hey @fnavarrodev,
As you noted, you don't have access to any of the "behind the scenes" tools for Amplify (S3, Cloudfront, etc.), so you actually need to stand-up a new Cloudfront distribution that points to the remote origin of your Amplify URL. You can then create the Lambda@Edge functions, attach them to your new Cloudfront distribution, and direct an incoming origin-request to either Prerender.io or your Amplify-hosted origin. I believe this means requests are routed through two Cloudfront distributions (first your newly created one and then a second controlled by Amplify), but it appeared to work fine.
Due to some of these limitations, I ended up moving off Amplify by creating my own CICD pipeline using GitHub Actions to build my SPA, deploy it on S3, and then I changed the Cloudfront origin from the Amplify URL to my newly deployed S3 URL. It took several days basically rebuilding some of the things Amplify handles really nicely out of the box, but it's given me a lot more flexibility in setting things up and a deeper understanding of some of the core tools.
Hope this helps, and let me know if you have other questions.
@theforager Thanks so much for your quick response. Amplify is a great tool/framework but to me still looks very uncompleted and all those "behind the scenes" things happening just make it worst. We are evaluating if we should continue using amplify or, as you did, have more control with a more customized CI/CD pipeline.
First I'll try having 2 cloudfront distributions like you suggested and see how much they charge us ;)
PD: We are all in the same boat.
@fnavarrodev I only have one Cloudfront distribution. It's the one created by Amplify as "Hosting" resource (for production environments - S3AndCloudFront). I didn't have to setup a new one on my own.
What I had to setup on my own is the Lambda function (Lambda@edge when executed/deployed by CloudFront) and modify the CloudFormation template in order to trigger the function as part of the DefaultCacheBehavior
. In my case this template is in amplify/backend/hosting/S3AndCloudfront/template.json
, but that will depend on which name you gave to your hosting resource.
@arturocanalda Were you building your entire app with the Amplify CLI? I was actually searching around, and it appears with the Amplify CLI you can actually make some modifications to the S3 and Cloudfront distributions by setting up a backend deployment. I had connecting my frontend via the Amplify Console only to deploy the SPA, and I was separately managing all the backend pieces.
@theforager yes, I built it entirely through the CLI. Just the Lambda@edge configuration was done manually by modifying the CloudFront CloudFormation template (many clouds... :).
@arturocanalda Yes is true, using the CLI you have more control, but I don't really see how to connect my github repository to that backend hosting(S3AndCloudFront) and get all the magic with new subdomains for branches and so on.
@fnavarrodev I had no issues connecting to my github repository. At the moment I have 3 branches = 3 backend environments (dev-stg-prd). But CI/CD with all the magic happening... that will be another battle (which I try to ignore/postpone so I can still sleep in the night :)
I added the hosting like they explain here https://docs.amplify.aws/cli/hosting so now I have a backend environment(S3AndCloudFront), but still don't see how is connected to my repo. I need to go to the console now? I do commit/push and no magic yet
@fnavarrodev indeed, that part has to be done from the console. App settings -> General
. You should see a button to connect your repository. I don't know the name of the button because my repo is already connected. But I attached the screenshot of how it looks after.
Thanks, I'm just giving up this is what I get:
So after an infinite loading... I tried from frontend environments, and works but now I have 2 hosting. Is it any guide to follow somewhere?
Is there any update on a tool through amplify console to save our SEO?
Also curious about any updates
Any update?
Any updates about this topic? I'm facing the same issue
I'm using nextjs now it's perfect
If anyone is still looking for help, the solution pointed out above in this thread is still working fine. You just have to play around a little bit with the cloudformation template of the repo suggested in the comments. Hope this helps, I was desperate too 🥲
Hey folks -- I think with Next.js SSR this use case should be solved. Going to close this for now!
This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.
This issue has been automatically locked.
Hey everyone,
I'm trying to determine if Amplify can use prerender.io. They provided me a link to Cloudfront middleware: https://github.com/jinty/prerender-cloudfront
Is it possible to use that through Amplify (Console)? If yes, how might I do so?
If not is it possible to get Amplify like features around the various branch urls, etc outside of Amplify?
I also read somewhere that using rewrites to send over to prerender.io is an option. I believe I would need to send Basic Auth info to do this. This is the url I found an example of that from someone using IIS: https://mono.software/2016/02/22/Installing-Prerender-io/ Its down under the "Client Side" heading. If I am unable to use middleware with Amplify, is it possible to provide the Basic Auth info like that via the rewrites? I did not see the docs make any mention of this. Need to be able to check User Agent also.
Thank you for your help!