Support Next.js 12
quinnturner opened this issue · comments
Next.js v12 was just announced by Vercel. This issue is requesting for Next.js v12 support on Amplify Hosting.
Here's a checklist for general support. Some of these may Just Work ™️ out of the box; I haven't tested much.
- Basic v12 support (my non-
/api-using app seems to work out of the box. It still uses Babel, would be good to confirm with an app building withswc) - React 18 support: native Next.js APIs &
Suspense - Native ES Modules support
- Middleware support (beta) (with Lambda@Edge)
-
<Image />AVIF Support: Opt-in for 20% smaller images - Bot-aware ISR Fallback: Optimized SEO for web crawlers
- URL imports (alpha)
- React Server Components (alpha) with Next.js at the Edge
Known issues at this time:
For React18, does AWS Lambda support NodeJS streams? Searching around the internet seems to suggest they dont.
For reference, reactwg/react-18#22
we get a 503 error while attempting to access our /apis after upgrading to next12. we didn't change anything besides the upgrade. does anyone have a clue to why this might be happening?
we get a 503 error while attempting to access our /apis after upgrading to next12. we didn't change anything besides the upgrade. does anyone have a clue to why this might be happening?
Post CloudWatch logs if you can 😄
2021-10-27T19:13:15.108Z 7b7ebdab-3a1d-4e16-9435-ab5ffe689052 ERROR Invoke Error {
"errorType": "Error",
"errorMessage": "Cannot find module '../../webpack-api-runtime.js'\nRequire stack:\n- /var/task/pages/api/use-number.js\n- /var/task/index.js\n- /var/runtime/UserFunction.js\n- /var/runtime/index.js",
"code": "MODULE_NOT_FOUND",
"requireStack": [
"/var/task/pages/api/use-number.js",
"/var/task/index.js",
"/var/runtime/UserFunction.js",
"/var/runtime/index.js"
],
"stack": [
"Error: Cannot find module '../../webpack-api-runtime.js'",
"Require stack:",
"- /var/task/pages/api/use-number.js",
"- /var/task/index.js",
"- /var/runtime/UserFunction.js",
"- /var/runtime/index.js",
" at Function.Module._resolveFilename (internal/modules/cjs/loader.js:889:15)",
" at Function.Module._load (internal/modules/cjs/loader.js:745:27)",
" at Module.require (internal/modules/cjs/loader.js:961:19)",
" at require (internal/modules/cjs/helpers.js:92:18)",
" at /var/task/pages/api/use-number.js:198:27",
" at Object.<anonymous> (/var/task/pages/api/use-number.js:204:3)",
" at Module._compile (internal/modules/cjs/loader.js:1072:14)",
" at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)",
" at Module.load (internal/modules/cjs/loader.js:937:32)",
" at Function.Module._load (internal/modules/cjs/loader.js:778:12)"
]
}
i'm suspecting that it has to do with next-transpile-modules but i'm not sure. i'm going to remove an import that i think depends on it from that file and see what happens
tried to upgrade to next-transpile-modules-v9 but still the same result
probably related to this: #1872
perhaps it's time to fully support webpack 5?
If we're using latest in our nextjs amplify app build settings, is there any way to peg it to 11 instead of falling back to ex 10, or having it pick up 12 whenever you release it?
I currently have the following environment variable set in my amplify application. When trying to set the version to "11" earlier this year, it would give me an error/unexpected behavior.
_LIVE_UPDATES: '[{"pkg":"next-version","type":"internal","version":"latest"}]',
It seems to me that at a minimum, the docs should be updated to state v11 is the highest you can use. I had posted a problem to StackOverflow and it seems the solution is roll back to 11:
https://stackoverflow.com/questions/70219534/next-js-run-dev-fails-with-error-object-object
Or possibly, from the previous comment here, roll back to Webpack 4.
But as a new user, it sounds like if I want to use Amplify it'll be easier for me to stick with basic React and ditch Next.js.
Hi team! Is there a roadmap/release date regarding the support of Next 12? Thanks!
@Danetag Second this question. Any update?
Any updates?
Any updates on this?
Updates on this? @swaminator
kindly update on this ? @swaminator
I don't think we're getting this functionality until Next.js (Vercel) themselves get their own house in order. There's a bunch of unstable functionality in their spec, and there doesn't exist a replacement tool for their export serverless target.
See: https://nextjs.org/docs/advanced-features/output-file-tracing
This is not unique to amplify, as nextjs-serverless is having similar issues
See also
Well, redirects and image plugin is from NextJS 11 and it's not working on Amplify
@carlosriveroib I'm not sure what NextJS 11 has to do with this issue, but since we've broached the subject of whinging..
After bashing my head against nextjs since 2019, my current take is that it's actually hot garbage. They keep cramming new features into every release but rarely fix long standing, wide impact bugs from several versions ago, and often introduce new ones upon new release. There's a lot of cool ideas and fun tech in Vercel's product, but for something on version 12 it still feels like more of a beta product than any framework I've worked with in recent memory (that's above a 1.0 release).
I don't plan to write any "production" code on nextjs for any new products going forwards, and it's given me enough of a headache that I'm not enjoying it for personal projects either. This is without using amplify btw, I went to trying raw lambda and docker at different points.
I'm not saying I haven't had my own struggles with amplify, but I am saying many of the things I was "mad" at amplify for ended up being nextjs issues when I dug deeper or tried to do it myself.
At this point, I'm deciding what to switch to for my personal projects, not whether to switch.
@ your problem:
I would sincerely look to vercel first if you're having an issue. In my experience, it's more likely than not the problem is on Vercel's end. I would love for amplify to give us better insight into what nextjs is doing, especially during the build process. Being able to see a snapshot of the file system during build failure would be awesome. I understand it's serverless and thus there is no "one" filesystem, but still.
Netlify supports nextjs 12 https://github.com/netlify/netlify-plugin-nextjs/blob/main/docs/release-notes/v4.md so I would have thought it is possible
+1
Netlify supports nextjs 12 https://github.com/netlify/netlify-plugin-nextjs/blob/main/docs/release-notes/v4.md so I would have thought it is possible
It's possible (since Vercel themselves support it), but it's DIY and unstable. Per their contract, they could totally break/change their nft.json logic in a minor version update. They used to have a "serverless" target spec Amplify/Serverless/Netlify could work against, but they deleted it without providing equivalent supported functionality in nextjs 12.
So, Amplify could try to roll their own interpretation of the logic, but then any minor update may break every user of nextjs ISR on amplify. Amplify could peg to a "Compatible" version, but that would make applying security patches (something not uncommon for nextjs) arduous, could be "wasted work" if Vercel changes the spec again (which, imho is likely), and could cause further work for Amplify customers if they need to expose an amplify-specific contract for interoperability.
If they do end up supporting it natively, I'd really prefer they mark it "BETA" of some sort so that it's obvious to end customers like me that we shouldn't rely on it as a stable, production system. Once again I really love the ideas that Vercel is putting out with NextJS and where they're taking the front-end community as a whole, but as-is I wouldn't bet my career or company on NextJS for any core functionality given how immature their software lifecycle is.
If I were the VP/SVP of AWS mobile, I'd be looking to setup a paid support contract with Vercel for NextJS. It'd be cheaper than trying to constantly work around Vercel, give me as a customer of Amplify more confidence in using NextJS on their platform, would differentiate AWS Amplify from other providers and frameworks by virtue of having contractual support, and introduce some goodwill to offset AWS' past shady business with e.g. elasticsearch
I will note that next export for static sites should still work a-okay for nextjs 12, it's just the ISR and "serverless" targets which are problematic.
@brainer1 have the same issue you described. did you find any workaround in the meantime?
+1
Just leaving our experience about NextJS 12 on Amplify.
On my team we have a NextJS app with a custom .babelrc. Since we have a custom .babelrc, we don't use swc.
We figured it out that Amplify can handle NextJS until version 12.0.7 without using swc
Upgrading to 12.0.8, we started having @brainer1 error. We activated "AMPLIFY_NEXTJS_EXPERIMENTAL_TRACE", and the error stopped, everything was working as it should.
Trying to upgrade to 12.0.9, 12.0.10 and 12.1.0, we started having this strange error (see below)
{
"errorType": "Runtime.UnhandledPromiseRejection",
"errorMessage": "TypeError: Cannot read property 'headers' of undefined",
"reason": {
"errorType": "TypeError",
"errorMessage": "Cannot read property 'headers' of undefined",
"stack": [
"TypeError: Cannot read property 'headers' of undefined",
" at Object.apiResolver (/var/task/node_modules/next/dist/server/api-utils.js:46:43)",
" at Module.<anonymous> (/var/task/chunks/884.js:42:34)"
]
},
"promise": {},
"stack": [
"Runtime.UnhandledPromiseRejection: TypeError: Cannot read property 'headers' of undefined",
" at process.<anonymous> (/var/runtime/index.js:35:15)",
" at process.emit (events.js:400:28)",
" at processPromiseRejections (internal/process/promises.js:245:33)",
" at processTicksAndRejections (internal/process/task_queues.js:96:32)"
]
}
If I've learned one thing about Next.js throughout my time deploying with Amplify, it's that Next.js has no qualms with breaking deployment behaviour that external services depend on between patches all the time. It's so frequent that it almost looks deliberate. With that in mind, I sympathize with the Amplify team delivering this functionality.
If I've learned one thing about Next.js throughout my time deploying with Amplify, it's that Next.js has no qualms with breaking deployment behaviour that external services depend on between patches all the time. It's so frequent that it almost looks deliberate. With that in mind, I sympathize with the Amplify team delivering this functionality.
I have reason to believe that target:serverless was in fact intentionally deprecated to hinder alternative methods of deploying so as to not enjoy a first-class experience. For example any questions related to Amplify are ignored by the core team, see mine: vercel/next.js#22556
I appreciate the work the team is doing and understand this is purely a business decision since being acquired by Accel.
Let's face it, Amplify is almost identical to Vercel with higher configurability. The infrastructure behind it in fact runs on a mixture of AWS and Azure.
I concur with your point. That is the sense I have gotten from the situation by enumeration of the facts.
I think AWS (as a company) needs to pay Vercel if they want to continue using NextJS. It's dumb that people's lives on both sides of the fence are being wasted to intentionally make things harder, resulting in a significantly degraded customer experience and breach of trust for end users.
I believe this was karmatically bound to happen after what ElasticSearch (and various other loved open source products) had to endure when AWS started offering hosting for it without any compensation to the original developers. The Jig is up, the word is out, and I'd imagine every open source company is planning similar to avoid getting rug-pulled by AWS again.
My fear is that AWS leadership is going to be frupid and attempt to do what they did with elastic search, forking or otherwise trying to cut out the inventors of the tech in a strong-armed attempt to keep high profit margins and total control. A big difference here is that, while NextJS is widely used, it has no where near the install base Elastic Search did, and I can't imagine it would ever be profitable to do so.
I also believe AWS leadership won't care, and will grind as many talented engineers they can hire into the stone in a stubborn attempt to avoid actually paying people for their work, no matter how much it costs AWS. I'd further imagine these talented engineers would (rightfully) start diving from the sinking ship, incentivizing mangers to start putting any key "flight risks" on Focus (or even Pivot) plans so they can't transfer teams.
If that happens (preferably, well before such happens), I would sincerely hope the AWS Amplify engineering team takes a look at what new hires to AWS are getting via levels.fyi or the grapevine, realize that 360k base raise is only going to apply for the to 20% that are TT or promoted this year, won't actually cap out the 360k, and will be significantly backloaded, and that their life and soul aren't worth wasting away in an unwinnable situation.
All that can be avoided if AWS simply negotiates a support contract with the inventors of NextJS and pays them for such an innovative product. I'm sure AWS leadership has an endless well of excuses for why they don't want to pay people for their labor. I'm also sure whoever pays the NextJS team at the moment would like to get money for their effort.
If I'm correct and AWS leadership fails to negotiate a contract, I'd be worried about the service being abandoned. Leetcode premium is pretty cheap, all things considered. So is educative.io and their grokking the systems design + advanced systems design + coding interview courses, if you get the yearly subscription. The expected value of a pay raise makes these resources objectively one of the best possible returns on investment you could ever do -- forget the stock market and crypto. It would be dumb for an engineer in a burnout situation not to explore those options, or even just take their vests and make an extended non-company paid sabbatical out of it. Considering WA state (where Amazon is headquartered) offers public healthcare, and the summer is coming up as I can tell from the sun I write this in, that would be a very tempting option for any burnout engineers.
I'm also worried that an exodus due to this NextJS situation could negatively affect other amplify products. I'd be surprised if there was a dedicated oncall rotation for NextJS-only amplify engineers. I'd imagine that cohort would be shared amongst a much larger pool, meaning NextJS issues would affect the entire L8/L10 or whomever they report to.
Much more likely, imho, would be for AWS Amplify to simply drop support for NextJS instead of dealing with them. That would be shocking to me, considering how even SimpleDB is still supported last I heard. Part of the value of AWS is that they don't drop features once supported, at least not without some long term burndown plan. I'm sure there are some examples I'm unaware of, and there's stuff like not supporting old versions of nodejs/python with AWS Lambda , but that's fundamentally different from dropping support for an entire product line which exists and receives frequent releases.
So yeah, as a customer this situation gives me significant pause for either using or recommending Amplify as a product to my peer network. While I'm sure the "small" issue of NextJS support is known by someone up the leadership chain, I'm worried the "larger" issue of not paying for open source software and the potential catastrophic issues resultant from such is either not fully, truly considered or realized by leadership.
It would be nice if AWS leadership could Think Big and show good Customer Obsession by Insisting on the Highest Standards and Delivering Results via paying people for their labor, even if it's a third party whose work they're using. If not, I'm concerned Amazon might not be Earth’s Best Employer. After all, Success and Scale Bring Broad Responsibility.
I'm glad Amazon has integrity and allows customers of AWS like me to voice my valid concerns without hiding or otherwise removing my admittedly critical commentary. Thank you for being a good person and having moral integrity, and not pressuring an H1B to censor critical commentary to save face. That's nice of you to not exploit people in a tender situation for your benefit, AWS.
@hughesjj very thought-provoking post. I didn't realize what I was remembering (ElasticSearch) till you mentioned it. Will be interesting how this pans out.
Elastic Search is the most prominent, but there are definitely more, and it also extends to retail. I'd imagine discussion of any "hypothetical" lawsuits in specific would be quickly scrubbed from this discussion, as is legally prudent, so I'll refrain from doing so here.
Still, I mean, google exists.
If you're on that google site, I might also google the genius that is Tim Bray. Strong leader IMHO, really wish his influence was still felt at AWS.
On an unrelated note, I love how firefox allows you to take full page screenshots with ctrl+shift+s these days. So useful for web development, among other reasons.
Summary of thoughts on my above long post:
I agree with @quinnturner and @b-bot that some compatibility issues might be deliberate. From my third party perspective influenced solely by github issue commentary and historical releases after being in this Amplify+NextJS space to a small degree for the past few years, I get the sense that both
- NextJS likes to move fast and break things, which independently of AWS makes it difficult to trust in using them as a vendor
- I get the sense the compatibility issues are exacerbated, even if at an unspoken level, by fear AWS (or some other cloud company) will eat NextJS' lunch if they can't manage to be financially self-sufficient.
From the perspective of someone in a start up industry, I could imagine making something open source to drive adoption of your product, because who the heck wants to use a brand new product that's completely opaque with zero adoption? It just seems natural to release high level concept for free. Managed hosting is a great way to monetize novel efforts. An issue occurs when the inventors of a novel effort go unpaid because a vulture steals their lunch instead of sharing it.
I love the UX of leetcode. They had a free product that I used, it worked well for me, I decided to pay for it. It was worth every cent given how their explore plans etc were for learning interview patterns. A totally mutually beneficial, positive sum relationship.
It's just a bit insane to me that an entire effort in AWS can occur where leadership finds a product they believe worthy of dedicating effort to supporting as a publicly accessible hosted solution, yet said leadership presumably decides they don't want to support the inventors and maintainers of said underlying product financially. Now that I say that out loud, it's kind of insane. Like even if they don't want to pay to make the underlying product better (which, I totally would if I held the purse strings) in that context... not even paying to support your own adoption is just ... an immoral anti-consumer experience at best.
I might be completely wrong and I totally understand if there's backdoor conversations I'm not privy to, but as a customer, it gives me pause in trusting any non-AWS in-house product to be "delightful" to use.
I concur with your point. That is the sense I have gotten from the situation by enumeration of the facts.
I think AWS (as a company) needs to pay Vercel if they want to continue using NextJS. It's dumb that people's lives on both sides of the fence are being wasted to intentionally make things harder, resulting in a significantly degregaded customer experience and breach of trust for end users.
I believe this was karmatically bound to happen after what happened with ElasticSearch (and various other loved open source products) had to endure when AWS started offering hosting for it without any compensation to the original developers. The Jig is up, the word is out, and I'd imagine every open source company is planning similar to avoid getting rug-pulled by AWS again.
My fear is that AWS leadership is going to be frupid and attempt to do what they did with elastic search, forking or otherwise trying to cut out the inventors of the tech in a strong-armed attempt to keep high profit margins and total control. A big difference here is that, while NextJS is widely used, it has no where near the install base Elastic Search did, and I can't imagine it would ever be profitable to do so.
I also believe AWS leadership won't care, and will grind as many talented engineers they can hire into the stone in a stubborn attempt to avoid actually paying people for their work, no matter how much it costs AWS. I'd further imagine these talented engineers would (rightfully) start diving from the sinking ship, incentivizing mangers to start putting any key "flight risks" on Focus (or even Pivot) plans so they can't transfer teams.
If that happens (preferably, well before such happens), I would sincerely hope the AWS Amplify engineering team takes a look at what new hires to AWS are getting via levels.fyi or the grapevine, realize that 360k base raise is only going to apply for the to 20% that are TT or promoted this year, won't actually cap out the 360k, and will be significantly backloaded, and that their life and soul aren't worth wasting away in an unwinnable situation.
All that can be avoided if AWS simply negotiates a support contract with the inventors of NextJS and pays them for such an innovative product. I'm sure AWS leadership has an endless well of excuses for why they don't want to pay people for their labor. I'm also sure whoever pays the NextJS team at the moment would like to get money for their effort.
If I'm correct and AWS leadership fails to negotiate a contract, I'd be worried about the service being abandoned. Leetcode premium is pretty cheap, all things considered. So is educative.io and their grokking the systems design + advanced systems design + coding interview courses, if you get the yearly subscription. The expected value of a pay raise makes these resources objectively one of the best possible returns on investment you could ever do -- forget the stock market and crypto. It would be dumb for an engineer in a burnout situation not to explore those options, or even just take their vests and make an extended non-company paid sabbatical out of it. Considering WA state (where Amazon is headquartered) offers public healthcare, and the summer is coming up as I can tell from the sun I write this in, that would be a very tempting option for any burnout engineers.
I'm also worried that an exodus due to this NextJS situation could negatively affect other amplify products. I'd be surprised if there was a dedicated oncall rotation for NextJS-only amplify engineers. I'd imagine that cohort would be shared amongst a much larger pool, meaning NextJS issues would affect the entire L8/L10 or whomever they report to.
Much more likely, imho, would be for AWS Amplify to simply drop support for NextJS instead of dealing with them. That would be shocking to me, considering how even SimpleDB is still supported last I heard. Part of the value of AWS is that they don't drop features once supported, at least not without some long term burndown plan. I'm sure there are some examples I'm unaware of, and there's stuff like not supporting old versions of nodejs/python with AWS Lambda , but that's fundamentally different from dropping support for an entire product line which exists and receives frequent releases.
So yeah, as a customer this situation gives me significant pause for either using or recommending Amplify as a product to my peer network. While I'm sure the "small" issue of NextJS support is known by someone up the leadership chain, I'm worried the "larger" issue of not paying for open source software and the potential catastrophic issues resultant from such is either not fully, truly considered or realized by leadership.
It would be nice if AWS leadership could Think Big and show good Customer Obsession by Insisting on the Highest Standards and Delivering Results via paying people for their labor, even if it's a third party whose work they're using. If not, I'm concerned Amazon might not be Earth’s Best Employer. After all, Success and Scale Bring Broad Responsibility.
I'm glad Amazon has integrity and allows customers of AWS like me to voice my valid concerns without hiding or otherwise removing my admittedly critical commentary. Thank you for being a good person and having moral integrity, and not pressuring an H1B to censor critical commentary to save face. That's nice of you to not exploit people in a tender situation for your benefit, AWS.
Based and laborpilled
https://nextjs.org/docs/advanced-features/output-file-tracing
NextJS is adding a few things to make it easier for people to host outside Vercel this new feature makes it significantly easier to do a lot of things that these community based libraries have had a hard time with.
Hello there, how are you?
Is there any updates or plan to support Next.js 12 on Amplify?
Thank you :)
I need update for Next.JS 12 on Amplify, especially working on webpack 5. I'm having trouble installing sentry.
Thank you
@ronyfhebrian So fun fact. Sentry will not work (deploying with Next 12 on Amplify), I've tried ten thousand times.
@Rafcin Have you solved sentry nextJS problem? What did you do to make it work?
I need update for Next.JS 12 on Amplify, especially working on webpack 5. I'm having trouble installing sentry. Thank you
just set AMPLIFY_NEXTJS_EXPERIMENTAL_TRACE=true in the environment variables in amplify and it should work
I need update for Next.JS 12 on Amplify, especially working on webpack 5. I'm having trouble installing sentry. Thank you
just set
AMPLIFY_NEXTJS_EXPERIMENTAL_TRACE=truein the environment variables in amplify and it should work
To add more color to this, I got the following combo of dependencies to work on Amplify:
AMPLIFY_NEXTJS_EXPERIMENTAL_TRACE=true- Next 12.2.0 (set in package.json + amplify build settings)
- Webpack 5 (default enabled in Next 12)
- @sentry/nextjs 7.3.1
+1
Hello there, how are you?
Is there any updates or plan to support Next.js 12 on Amplify?
Thank you :)
@valentim-guilherme although it's not written anywhere the Amplify team are working on a new build system that will be much better and should have support for Next 12 and up. It's just unknown when it will be released.
“People are supposed to fear the unknown, but ignorance is bliss when knowledge is so damn frightening.” - Laurell K. Hamilton
I gave up and started using AWS App Runner.
Hi,
It's been almost a year since Next released version 12. Why is it still not supported?
It's pretty disappointing, considering that even with version 11, there are still problems on Amplify (see example: #2593).
All of your competitors, big and small, already support version 12 of Next, and Amplify hasn't even made any statement about a planned date for it.
I want to continue using your services, but I'm starting to worry if every version; I have to wait over a year for your support.
+1
@roeean The Amplify team hasn't communicated this much, and things may have changed who knows, but if I'm not mistaken, at the end of Q3, we should see a new build system with more flexibility and support not only for newer versions of Next but other frameworks as well. Devs have run into many issues deploying, and it's rough. However, changes are coming, and we can expect fixes!
The major problem, at least with Next, has been the SLS package used for deployment. The author created a post, and due to time issues, he might not be able to support the project, so this new build system, I believe, is all done in-house. Another thing I heard mentioned before was the system will be flexible; with the updates, Next is making for deployments, we can expect Amplify to be able to deploy new versions of Next as well as other frameworks. I'm not 100% sure about the other frameworks part, but at least from what I got during a call, we shouldn't have to see this year's wait time when an update comes out. I'm pretty sure we should expect changes for accessibility to the distributions as well. I've talked to the Amplify team about adding and removing cf headers and stuff, and a lot of those changes have to be done by a service member, and it's not a scalable solution. So I believe we should expect more flexibility; my recent request to add headers to a project was denied, and they are planning a better solution, so I'm confident we can look forward to those types of changes.
From what I've gotten in conversation, they care about all the issues deeply, and they know these are major pain points, but I'm certain they'll pull through, and the coming fixes will be awesome! Also, this is AWS we're talking about, so we'll definitely get a solid build system. In addition to the build system, they're working on many other features and fixes around the backend services and the frontend UI aspects.
You gotta believe, the Amplify team will pull through!
Side Note
Also, I believe, and this is just my opinion, we should have a public road map for current and work-in-progress things. I think features like the UI builder and stuff are nice surprises, but if devs were to know about build changes, planned features, and all these things ahead of time, I think it would stress everyone out less, and people that depend on these services can have an idea of what to do ahead of time for their projects and know if they need to pivot for any reason. We currently have the public roadmap and then the secret internal roadmap. I think excluding security changes or thing's well out of the scope of the public, we should have all these things on some sort of map.
Are there any updates on this one? I am facing a 503 error when I am fetching the Nextjs internal API from the client side.
No updates at the moment, solution is to downgrade your next.js version to 11.1.4. One of these days Amplify will support Next.js 12, but for now we have to suffer T_T. Happy coding.
Thank you all for your patience and enthusiasm on this. We are improving Amplify Hosting's support for Next.js 12, including many items discussed in this thread.
I'm looking for volunteers to test and give feedback on the improvements as part of a gated beta in the coming weeks.
If you're interested in taking part, email me at jrm@amazon.com. In the email, let me know:
- Your AWS Account ID;
- The email associated with the account; and
- Your preferred region to test in e.g.
ca-central-1.
Looking forward to hearing from you,
Mike
@quinnturner @andrewgadziksonos @brainer1 @hughesjj @madeupname @Danetag @michaelangrivera @MichalBunkowski @calexandru @drmzio @Ahmad-Jamal @carlosriveroib @dottodot @413n @wottpal @Alek-S @DavideCarvalho @b-bot @lefnire @michaelscheung @ShanonJackson @Fedeorlandau @ronyfhebrian @Rafcin @itseasy21 @calderwoodra @tarunama @valentim-guilherme @AbeEstrada @roeean @colmobildev @Nithur-M @binolt
Thank you all for your patience and enthusiasm on this. We are improving Amplify Hosting's support for Next.js 12, including many items discussed in this thread.
I'm looking for volunteers to test and give feedback on the improvements as part of a gated beta in the coming weeks.
If you're interested in taking part, email me at jrm@amazon.com. In the email, let me know:
- Your AWS Account ID;
- The email associated with the account; and
- Your preferred region to test in e.g.
ca-central-1.Looking forward to hearing from you, Mike
@quinnturner @andrewgadziksonos @brainer1 @hughesjj @madeupname @Danetag @michaelangrivera @MichalBunkowski @calexandru @drmzio @Ahmad-Jamal @carlosriveroib @dottodot @413n @wottpal @Alek-S @DavideCarvalho @b-bot @lefnire @michaelscheung @ShanonJackson @Fedeorlandau @ronyfhebrian @Rafcin @itseasy21 @calderwoodra @tarunama @valentim-guilherme @AbeEstrada @roeean @colmobildev @Nithur-M @binolt
Great to hear, more than happy to partake. World is really in need of some good vercel competitor for hosting NextJS 12 (and soon 13???)
I'm looking for volunteers to test and give feedback on the improvements as part of a gated beta in the coming weeks.
@michrome Thank you for your great support to be able to use Next.js v12 on Amplify.
Regarding Next.js v12 support, I have a quick question.
Could you share the timeline for supporting Next.js v12 on Amplify ?
We are considering to switch our infrastructure for our Next.js v12 application from Vercel to Amplify but we have no idea that ...
- Move to Amplify now with downgrading Next.js v11 to work on Amplify
or - Wait Next.js v12 official support on Amplify then move
More concrete information about schedule of Next.js v12 support on Amplify, it might be helpful for us to decide it.
@tomoyukikashiro It might be this week, it might be next week it's a bit up in the air, the Amplify team are probably working on some final changes.
You can use Next 12 right now no problem, you just won't be able to utilize middleware or any of the other new features until the beta.
Hey @tomoyukikashiro thanks for reaching out and for your interest. Without knowing the specifics of your app and its infrastructure (you're most welcome to share that with me jrm@amazon.com) my instinct would be to wait, not downgrade.
Hey @tomoyukikashiro thanks for reaching out and for your interest. Without knowing the specifics of your app and its infrastructure (you're most welcome to share that with me
jrm@amazon.com) my instinct would be to wait, not downgrade.
@michrome Thank you for your replaying.
Joining into your a gated beta program would be good but we do not have enough time to move our platform. ( kind of rush )
Let me check our timeline and keep watching amplify team's updates on this issue.
Thank you for your kind support!
I'm looking for volunteers to test and give feedback on the improvements as part of a gated beta in the coming weeks.
@michrome Thank you for your great support to be able to use Next.js v12 on Amplify.
Regarding Next.js v12 support, I have a quick question. Could you share the timeline for supporting Next.js v12 on Amplify ?
We are considering to switch our infrastructure for our Next.js v12 application from Vercel to Amplify but we have no idea that ...
* Move to Amplify now with downgrading Next.js v11 to work on Amplify or * Wait Next.js v12 official support on Amplify then moveMore concrete information about schedule of Next.js v12 support on Amplify, it might be helpful for us to decide it.
Just stay on Vercel. It has much faster build & deploy times. And it seems like it will take them a year to support Next.js 12. Our company chose for Amplify because they are all in on AWS, but we have regret our choice. Sure I hope Amplify will get better with Next.js 12 support, but let them first prove it.
I'm looking for volunteers to test and give feedback on the improvements as part of a gated beta in the coming weeks.
@michrome Thank you for your great support to be able to use Next.js v12 on Amplify.
Regarding Next.js v12 support, I have a quick question. Could you share the timeline for supporting Next.js v12 on Amplify ?
We are considering to switch our infrastructure for our Next.js v12 application from Vercel to Amplify but we have no idea that ...* Move to Amplify now with downgrading Next.js v11 to work on Amplify or * Wait Next.js v12 official support on Amplify then moveMore concrete information about schedule of Next.js v12 support on Amplify, it might be helpful for us to decide it.
Just stay on Vercel. It has much faster build & deploy times. And it seems like it will take them a year to support Next.js 12. Our company chose for Amplify because they are all in on AWS, but we have regret our choice. Sure I hope Amplify will get better with Next.js 12 support, but let them first prove it.
There are actually also drawbacks on vercel, in terms of DNS it's not always flexible enough, which can be resolved by using AWS.
We currently use serverless-nextjs (https://github.com/serverless-nextjs/serverless-next.js) which manages everything rather well, except for .... middleware and other route rewrite features.
Hoping to have this on amplify or on serverless-nextjs soon.
Also heard that Amplify is more expensive than hosting it using serverless-nextjs (saw some benchmarks stating double?) not sure if true as i haven't tested it myself. Either way, cheaper than vercel for big bandwiths
Any updates on this... can't believe v12 isn't supported yet
Looking for an update too
Any updates on this?
Thank you all for your continued patience and for volunteering to try the beta. Work's still underway: will let you know as soon as it's ready.
It's also worth mentioning that as of what I tested, on-demand revalidation is not working as well.
Thank you all for your continued patience and for volunteering to try the beta. Work's still underway: will let you know as soon as it's ready.
Can I be part of the test team? :D
Of course @HectorMu . If you're interested in taking part, email me at jrm@amazon.com. In the email, let me know your AWS Account ID and I will flag you in when the beta is available.
Congratulations to Vercel on releasing Next.js 13. Now amplify is two versions behind.
At this point I don't see any reason to use amplify with Next.js application. I will just switch to Vercel platform and thats it.
@Leejjon I'm sure once the new Amplify Next build system is out of beta you'll be pleased with the results. Next 13 doesn't introduce any breaking deployment changes, since Next 12, Vercel has been working on making deployment easier so when the Amplify beta moves into production you will be able to use 12 and 13 just fine.
@MichalBunkowski, I get you; I, too, thought about switching to Vercel many times. I want to say if you can hang on a bit longer, please do. I genuinely think you'll be happy with the new system!!!
As far as I understand, the vision for the new build system has been to make it work with existing frameworks and future frameworks and avoid using dependencies such as serverless-next, which has been the most significant issue when it comes to deploying Next apps. Vercel exists in a bubble, it's Next, and only Next they focus on, and given they are starting to make most of the valuable tools people use, they have an advantage in regards to hosting features and using all the latest bells and whistles. Amplify is looking to make it easy for any framework to get up and running efficiently, and quickly and have the same bells and whistles, and I think soon AWS will start catching up with Vercel, and then it'll be an even playing field.
Also sorry for the long post, I didn't mean to write such a long post, but I feel bad for the shit the Amplify team gets. It's tough, man; AWS focuses on making the features customers want, and to fulfill all those requests take some time and a lot of work so I get why it's taken a while.
Any ballpark estimation for when this will be out of beta and ready for production? I really, really don't want to move away from Amplify but we have features that we can't deploy because of this and our limit is mid-November before either moving to Vercel or another platform or taking out all of the features that are not supported and deploying the new version (most of which are our money-makers). I just wanna know if we can expect this to be ready in the next 2-3 weeks or if that will be almost impossible before end of year.
I know that this is not an easy task and that the Amplify team is hard at work and I thank you for this, but having a public roadmap or estimation of some sort would be extremely helpful to your customers.
Taking the beta for a spin now, will report back.
Taking the beta for a spin now, will report back.
The beta isn't there yet. Or at least I didn't got notified.
We are in the experimental phase of a new website that uses features from Next 12. When we discovered the problems with Amplify and version 12 of Next, we opted for a palliative: what we are doing is using a hobby account at Vercel for this step with hope for Amplify to update by the end of the year, when we will need to launch the product and opt for one or another service, if Amplify still doesn't support it, we'll have to subscribe to Vercel.
But I have a question about the differences between one and the other, about lambda functions: from what I understand Vercel uses AWS lambdas and its own CDN network called “Vercel Edge Network”. After deploying Vercel allows you to select the function region. In my case I can select the same region where our DynamoDB table and other AWS Lambdas are, for lower latency. However, in deployments with Next on Amplify, 3 or 4 Lambda Edge functions are created in the US region, with no option to change, and AWS uses its CDN network. For the pages that are not static but SSR, isn't it an advantage to be able to choose the region of the function as with Vercel?
Will this behavior remain the same in the changes being tested in Beta?
By the way, I created a basic sample SSG page and another SSR with Next and deployed them to Amplify and to Vercel, then tested with PageSpeed. Amplify was faster in every run, and I really don't know why. Funcion region differences maybe? Influence from Google testing region? don't know...
But it would be nice to see Amplify update and better Next support to be as easy as with Vercel, since for all other services we're already using Amazon.
We are in the experimental phase of a new website that uses features from Next 12. When we discovered the problems with Amplify and version 12 of Next, we opted for a palliative: what we are doing is using a hobby account at Vercel for this step with hope for Amplify to update by the end of the year, when we will need to launch the product and opt for one or another service, if Amplify still doesn't support it, we'll have to subscribe to Vercel.
But I have a question about the differences between one and the other, about lambda functions: from what I understand Vercel uses AWS lambdas and its own CDN network called “Vercel Edge Network”. After deploying Vercel allows you to select the function region. In my case I can select the same region where our DynamoDB table and other AWS Lambdas are, for lower latency. However, in deployments with Next on Amplify, 3 or 4 Lambda Edge functions are created in the US region, with no option to change, and AWS uses its CDN network. For the pages that are not static but SSR, isn't it an advantage to be able to choose the region of the function as with Vercel?
Will this behavior remain the same in the changes being tested in Beta?
By the way, I created a basic sample SSG page and another SSR with Next and deployed them to Amplify and to Vercel, then tested with PageSpeed. Amplify was faster in every run, and I really don't know why. Funcion region differences maybe? Influence from Google testing region? don't know...
But it would be nice to see Amplify update and better Next support to be as easy as with Vercel, since for all other services we're already using Amazon.
When you deployed serverless through Amplify normally I think it deploys lambdas in us-east-1 although I believe that doesn't matter for behind the scenes you'll still get the same performance everywhere. Someone correct me if I'm wrong please. Because as far as I understand if you deployed serverless in us-west-2 it worked for any region.
I guess it doesn't hurt to say it here. New builds such as the graphql-api example from the Next repo builds in 2m22s as opposed to 15-20min. It's pretty damn fast.
Taking the beta for a spin now, will report back.
The beta isn't there yet. Or at least I didn't got notified.
I would contact Mike then. His email is listed above.
Any way to get the beta access?
Taking the beta for a spin now, will report back.
The beta isn't there yet. Or at least I didn't got notified.
I would contact Mike then. His email is listed above.
Any chance to get the beta access? A lot of big companies are moving on next, and it's a shame this old support. Also, if you use something like NX, good luck on enabling next..
I got an email from Mike today, so it seems like the beta is out. As Rafcin said, I'd contact him...
Next 13 is out and we're still unable to use Next 12
I don't think I can recommend using amplify with Next if the new version support is this slow
@Sodj please get on the beta. We have been testing the Next.js 13 features on our service and so far all the GA features (i.e. features not in alpha or beta) work. We will be making this feature available to all customers soon. Thank you for your patience.
considering Next13 has just been released - should we target this issue for Next14 Amplify cooperation? i mean let's keep targets realistic when it comes to timing...
Next 13 is out and we're still unable to use Next 12
@Sodj What am I missing here? I have multiple projects running in Amplify that use Next.js 12.
Are you referring to a specific feature or set of features?
@Huetarded Mainly the middleware feature
@Sodj - Ah, gotcha
Next 13 is out and we're still unable to use Next 12 I don't think I can recommend using amplify with Next if the new version support is this slow
Middleware in my case. Static ones are perfectly fine with 12. Any chance you found a workaround?
So there's a new migrate to Next.js 12/13 feature in the Amplify web console. I'm unsure if I should try this on something that's production... (I'm still running a Next.js 11 application)
@neoplastic we're starting to enable the program that @michrome mentioned a few weeks ago to more accounts, congratulations! We recommend to test with apps that people don't have in production yet, even deploying that same code in a new app, and updating to Next.js 12 or 13 before. If you're on Next.js 11, the migration won't help you.
Edit: Btw, the banner should say Next.js 12 and 13, both versions work (updated message coming soon) 😅
Yeah, I'm going to be super careful about this and try it out in a new app. Thanks @calavera and @michrome!
For anyone who's interested. I've done a relatively quick upgrade of Next.js (11 -> 13 latest stable) and fixed up a bunch of errors and the build result times are:
Next.js 11 - 22m43s
Next.js 13 - 5m31s
That's a build time reduction of about 75%
nice! thanks for the quick turnaround @neoplastic !
facing error from Terraform. Error: expected platform to be one of [WEB WEB_DYNAMIC], got WEB_COMPUTE. I guess I should wait for the AWS underlying API update?
@MejanH yes, sorry for the trouble. The API will be released soon, it takes a little longer because we need to coordinate with other teams to update SDKs.
I have a newly hosted nextjs12 app. However, it builds but does not deploy.
It looks like the cloudfront distribution that is supposed to be created by amplify is not increasing either.
Any troubleshooting on this?
@sync2920 can I have your appId please?
@ferdingler
Thank you for your reply.
The appId is "d3mzsawj4eee6l".
Best regards.
@sync2920 You might have reached the url too early. When I load your app now, it shows a 500 error coming from Next.js. You should be able to see the application logs if you go your application page, then click in "Monitoring", then "Amplify Hosting compute logs", then click the link that will take you to CloudWatch logs.
@calavera @ferdingler
Oh...
When I upgraded my existing app to the new build system, no matter how many changes I made, the content in the page did not change, so I created a new app, but I guess I forgot to bring environment variables and other settings...
Thank you!
Could it be that the distributions created by amplify are no longer visible from the cloudfront page?
Could it be that the distributions created by amplify are no longer visible from the cloudfront page?
we don't create distributions in your account anymore.
Thank you very much, I apologize for the inconvenience.
I updated with the migrate to web compute button, however, now, the web application through my customs domains don't work
mydomain.com goes to the secondary early-stage branch of my project
https://mydomain.com goes to an error page of
This site can’t be reached mydomain.com took too long to respond.
Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_TIMED_OUT
Tested this morning with a Next.js app using v13 that was previously unable to deploy and everything worked perfectly! Great job everyone who made this happen! 🥳
Our Next.js v12 app build time (~4 mins) is a third of what it is on the current Amplify hosting (~12 mins), which is great to see!
Did a quick Lighthouse test and the perf scores (TTI, FCP, LCP) are all the same as our current production non-beta app.
Struggling to find any decent guides about setting up ISR though, can anyone help there?