Support Next.js 12

[quinnturner]

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 with swc)
• [ ] 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:

• /api routes can result in Module not found errors, likely related to Webpack 5 (see #1872), thanks @brainer1

[andrewgadziksonos]

For React18, does AWS Lambda support NodeJS streams? Searching around the internet seems to suggest they dont.

For reference, https://github.com/reactwg/react-18/discussions/22

[brainer1]

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?

[quinnturner]

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 😄

[brainer1]

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)"
    ]
}

[brainer1]

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

[brainer1]

tried to upgrade to next-transpile-modules-v9 but still the same result

probably related to this: https://github.com/aws-amplify/amplify-console/issues/1872

perhaps it's time to fully support webpack 5?

[hughesjj]

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"}]',

[madeupname]

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.

[Danetag]

Hi team! Is there a roadmap/release date regarding the support of Next 12? Thanks!

[michaelangeloio]

@Danetag Second this question. Any update?

[MichalBunkowski]

Any updates?

[calexandru]

Any updates on this?

[drmzio]

Updates on this? @swaminator

[Ahmad-Jamal]

kindly update on this ? @swaminator

[hughesjj]

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

• https://github.com/vercel/next.js/discussions/32236#discussioncomment-1955080
• https://github.com/vercel/next.js/discussions/33275

[carlosriveroib]

Well, redirects and image plugin is from NextJS 11 and it's not working on Amplify

[hughesjj]

@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.

[dottodot]

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

[413n]

+1

[hughesjj]

@dottodot

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.

[wottpal]

@brainer1 have the same issue you described. did you find any workaround in the meantime?

[Alek-S]

+1

[DavideCarvalho]

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)"
    ]
}

[quinnturner]

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.

[b-bot]

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: https://github.com/vercel/next.js/discussions/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.

[hughesjj]

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.

[lefnire]

@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.

[hughesjj]

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.

[hughesjj]

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

1. NextJS likes to move fast and break things, which independently of AWS makes it difficult to trust in using them as a vendor
2. 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.

[michaelscheung]

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

[ShanonJackson]

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.

[Fedeorlandau]

Hello there, how are you?

Is there any updates or plan to support Next.js 12 on Amplify?

Thank you :)

[ronyfhebrian]

I need update for Next.JS 12 on Amplify, especially working on webpack 5. I'm having trouble installing sentry. Thank you

[Rafcin]

@ronyfhebrian So fun fact. Sentry will not work (deploying with Next 12 on Amplify), I've tried ten thousand times.

[ronyfhebrian]

@Rafcin Have you solved sentry nextJS problem? What did you do to make it work?

[itseasy21]

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

[calderwoodra]

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

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

[tarunama]

+1

[valentim-guilherme]

Hello there, how are you?

Is there any updates or plan to support Next.js 12 on Amplify?

Thank you :)

[Rafcin]

@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.

[ronyfhebrian]

“People are supposed to fear the unknown, but ignorance is bliss when knowledge is so damn frightening.” - Laurell K. Hamilton

[AbeEstrada]

I gave up and started using AWS App Runner.

[roeean]

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: https://github.com/aws-amplify/amplify-hosting/issues/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.

[colmobildev]

+1

[Rafcin]

@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.

[Nithur-M]

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.

[stevenluongo]

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.

[michrome]

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

[Rafcin]

[maximgeerinck]

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???)