[▲ Vercel Community](/) · [Categories](/categories) · [Latest](/latest) · [Top](/top) · [Live](/live) [Feedback](/c/feedback/8) # Microfrontend's documentation is incorrect 119 views · 2 likes · 5 posts Wolf Yuan (@wolfyuan) · 2025-10-18 Hello there! I'm trying to use Vercel's microfrontend thing to split my website and API backend. But I faced some problem with the documentation itself. In https://vercel.com/docs/microfrontends/quickstart, the documentation said: > Application names in `microfrontends.json` should match the Vercel project names. I assumes this is the value inside `applications` property in `microfrontends.json`, but after trying out, the Vercel system seemingly does not actually matches this field to project name. Instead, it matches to `*.vercel.app` domain name. --- Here's a more straightforward explanation: If I currently have a project called `my-awesome-resume`, with another project called `my-awesome-frontend`, which has configured as top level microfrontend project in that group. Now, the `my-awesome-frontend` has this microfrontend configuration: ```json { "$schema": "https://openapi.vercel.sh/microfrontends.json", "applications": { "my-awesome-frontend": { "development": { "fallback": "dead-website.vercel.app" } }, "my-awesome-resume": { "routing": [ { "paths": ["/resume"] } ] } } } ``` This configuration now routes `/resume` to `my-awesome-resume`, thing works. But if I change project `my-awesome-resume` domain to `my-cool-resume.vercel.app`, the routing broke. Navigating to `/resume` now results in this error:  Note that removing existing domain will also break routing. Changing the domain name back to the one that matches project name (`my-awesome-resume`) in this case, microfrontend now able to forward requests to this project. No error given. Kit Foster (@kitfos) · 2025-10-21 · ♥ 1 Hey Wolf! Great that you’re trying out microfrontends, and thanks for writing up the issue you had so well. The reason you saw the https://vercel.com/docs/errors/MICROFRONTENDS_MISSING_FALLBACK_ERROR is because changing the domain in your project removed the fallback domain the microfrontends routing was using. Microfrontends tried to route to the old domain, which didn’t exist. To fix this, you can redeploy the project after changing the domain, and that will then update the fallback to use the new domain. We will work on fixing this flow, so that changing the production domain doesn’t require redeploying. Please reach out if you have any other issues :folded_hands: Wolf Yuan (@wolfyuan) · 2025-10-21 Thanks for your reply! I will try to redeploy the deployment of my microfrontend. According to your reply, I think the microfrontend still requires at least one domain associate with it? Is there a way to use microfrontend without a domain for subprojects? Kit Foster (@kitfos) · 2025-10-21 · ♥ 1 > Is there a way to use microfrontend without a domain for subprojects? Unfortunately that is not possible at the moment, as microfrontends routing works hand in hand with domains. A project’s production domain works as the pointer for “what is the current production deployment”. The production domain is how microfrontends determines which deployment to route to. To expand further, the current production deployment is not always the latest production deployment. There are many considerations including: project pre-promote checks, roll backs, promoting deployments, and rolling releases. Wolf Yuan (@wolfyuan) · 2025-10-23 Ok, thanks for your explanation!
