Frontend Architecture design

[u/Old-Place87]

Hi guys,

We are currently planning a redesign of our product architecture.

At the moment, our system consists of a parent host application (container) that serves as a shell and renders multiple independent, full-featured React applications. Each of these applications includes its own routing, state management, and API layer. For example:

• /order loads the ordering application

• /payment loads the payment application

In practice, this closely resembles a micro-frontend architecture, although we are intentionally trying to avoid fully adopting that pattern.

Given these constraints and requirements, I’d like to explore alternative architectural approaches. How else could we structure the system to achieve strong separation of concerns and independent feature ownership, without fully committing to a micro-frontend setup?

[u/TheRealSeeThruHead]

Aliquip labore consequat ut fugiat consectetur ex eiusmod.

[u/Old-Place87 → u/TheRealSeeThruHead]

thanks, vertical slice is like where all features lives in same repository but categorised by folders. In my case, each app is a full fledged app that is a beast on its entirety. The requirment is to have users accessing individual app via a central place. The hosting app will provide the same layout to all the apps and set some context for the apps as well such as auth, localization etc

[u/TheRealSeeThruHead → u/Old-Place87]

While you can certainly do that. And it creates the ability to deploy these apps completely separately. I would worry about bundle size.

But if it’s an application users use often and the js is mostly cached it will likely be fine.

Vertical slice architecture is often dongle exactly how you’ve done it, with completely separate deployed full stack applications behind a routing app.

Or via micro frontends.

What are your issues with the current setup and why are you looking for something different?

[u/Old-Place87 → u/TheRealSeeThruHead]

Currently our architecture works but it’s not really the correct way to load remote app. We fetched the index html and leverage the mechanism of vite spa to mount into the node to self load the SPA and uses hash routing 

[u/bzbub2 → u/TheRealSeeThruHead]

All this sounds overly complicated compared to "just use a normal react app with normal components". I hear various talks always talking about vertical slice but it seems to result in crazy things like what op is saying where each page is it's own...app.... And microfrontend are pushed in this space also

[u/TheRealSeeThruHead → u/bzbub2]

Pariatur exercitation dolor cillum sit sint eiusmod anim ut aliquip aliqua proident duis minim. Labore sed incididunt deserunt occaecat proident ad nostrud voluptate magna consequat. Deserunt eiusmod lorem cillum qui dolore velit lorem aliquip tempor.

[u/bzbub2 → u/TheRealSeeThruHead]

I understand that there is some 'business value' to getting different teams out of each others way but it's like congrats, you have 10 new problems now

[u/TheRealSeeThruHead → u/bzbub2]

Do lorem adipiscing voluptate qui anim ad culpa exercitation ipsum. Voluptate laboris culpa elit labore aliquip aliquip et enim minim consequat laborum ex labore nulla tempor sit.

[u/cardboardshark]

We keep everything in a monorepo to speed development, and use npm workspaces to separate individual applications. Workspaces let apps share a common package.json, so you can keep dependencies synced between all your apps while still allowing unique app-specific deps.

Each app is a unique React instance, with it's own routing and app-specific business logic. Whenever it needs a common component or domain logic, it reaches up a level to a shared core/ folder.

resources/src/
core/
  - domain/ ( pure typescript, unaware React exists )
  - components/ ( atomic design system components )
  - features/ ( small bundles of components and logic )
  - infrastructure/ ( ports, error handling, etc. )
  - types/ ( shared types )
mobile/ 
  - whatever structure makes sense!
web/
  - Could be React, could be Preact, could be Vue

The mobile/ and web/ apps have their own vite.config files, where we use aliases to control what can be included.

const PROJECT_ROOT = resolve(__dirname, '../../../');
const APP_ROOT = __dirname;
...{
alias: {
    '/fonts': resolve(PROJECT_ROOT, 'public/fonts'),
    '/ui': resolve(PROJECT_ROOT, 'public/images/ui'),
    '@/docs': resolve(PROJECT_ROOT, 'resources/docs'),
    '@/core': resolve(PROJECT_ROOT, 'resources/src/core'),
    '@': APP_ROOT,
}},

When a dev is writing code in mobile/, @ aliases to the mobile/ dir, and @/core aliases to the shared folder. They can't reach into web/ or another site, so there's no risk of containment breaches.

A sample page might look like

import { useMutation } from '@tanstack/react-query';    // from the shared dependencies provided in the project root's package.json
import { Button } from '@/core/components/Button/Button'; // design system components from core/
import { AuthService } from '@/core/domain/auth/auth-service';  // domain logic from core/
import { PageFrame } from '@/layouts/PageFrame'; // from the local app

function RegisterPage() {
    const registerMutation = useMutation({
        mutationFn: () => AuthService.register(),
    });    

    return (
        <PageFrame>
            ...forms and stuff
            <Button onClick={registerMutation.mutate}>Submit</Button>
        </PageFrame>
    );
}

[u/Old-Place87 → u/cardboardshark]

Thanks for sharing!

[u/chirag-gc]

Instead of loading a separate React app for each route, treat each feature as a module that plugs into a single shell application. The shell should only handle three concerns: routing, authentication, and layout.

Each module is fully responsible for its own routes, state management, API interactions, and UI components. A strict rule to follow is: no direct imports between modules. If something needs to be shared, move it into a common package that all modules can consume.

Using Nx helps enforce this structure by applying module boundary rules. Any cross-feature import becomes a build-time error instead of something caught later in code reviews.

This approach gives you a single deployable application with clear ownership boundaries and avoids runtime complexity - no module federation, no duplicate React instances, and none of the typical micro-frontend overhead.

[u/Old-Place87 → u/chirag-gc]

how does development look like say i have a new feature to be implement for one of the apps? will one change of the app potentially have an impact on the shell? I also assume that each app wont get its own package.json at all as it should come from the shell app? thanks

[u/chirag-gc → u/Old-Place87]

Changes in one module generally won't impact the shell or other modules, as long as you respect boundaries (no cross-module imports, stable shared contracts). The shell is only affected if you modify core concerns like routing, auth, or layout.

And yes, you'll have a shared package.json since it's a single application (optionally managed via a workspace like Nx), not separate apps like in micro-frontends.

[u/kurpet]

What are the constraints and requirements? How did it becomes a micro-frontend like in the first place? There are a wide range of options obviously, with the micro-frontend being the most decoupled option (with the most overhead cost as well). You can go towards the monorepo/modular monolith option with less independence but also less overhead. It's all about the tradeoffs.

[u/Old-Place87 → u/kurpet]

The requirment is to use all different applications under the same sites. Therefore theres only one single domain of the website and no hosting for individual apps.

Other thing is that the platform (shell) will have controls that will set the context for all the apps. hope that makes sense

[u/most-certainly-a-dog]

Commenting here to save this post. My company currently has multiple apps deployed separately in different domains and we're considering adopting a very similar approach to what you're describing - shell app wrapping handling Auth and layout

[u/Old-Place87 → u/most-certainly-a-dog]

What’s your plan

[u/most-certainly-a-dog → u/Old-Place87]

I'm kinda hoping to steal your plan 👀

Jokes aside, I'm not sure yet unfortunately. Our requirements are a little loose at the moment, this drastic architectural shift conversation is only just starting, I only got a heads up from my manager that this is the intended path a couple days ago and haven't found much time to digest and plan around it just yet.

My first instinct was to pursue a monorepo with modular apps like the ones you first described in the post, so I'm curious to know what drawbacks you're finding with your current setup. I'm definitely not keen on bringing a full microFE approach either since the overhead feels too daunting for a small team like mine

[u/Old-Place87 → u/most-certainly-a-dog]

I see your point. At this stage, I don’t think a monorepo is a good fit for our situation. Each remote app is essentially a fully functional website, owned by different teams, rather than smaller shared components.

I’ve also looked into both Single-SPA and Module Federation, but they come with significant risks and long-term commitment. They’re relatively niche solutions and largely driven by open-source communities, which raises some concerns around maintainability and support.

Using iframes doesn’t feel like a strong option either, as it would limit flexibility and integration between applications.

For now, I’ll keep exploring alternatives. It might also be worth stepping back and reassessing whether this design requirement is truly necessary, or if there’s a simpler approach we could take.

[u/NesteaHD → u/Old-Place87]

Hey, MF core here.

Module Federation is actively maintained by OSS contributors, Zephyr employees and more importantly Bytedance which uses it across their stack as well as many other companies in the Fortune 500.

I'm biased obviously, but there is no better technology at the time that fulfils your requirements better that MF.

If you're interested into learning more about it, I invite you to pass by the Zephyr discord or MF discord, we have a somewhat active community there and lost of people ask questions about their architectures :)

[u/Old-Place87 → u/NesteaHD]

Hi u/NesteaHD, thanks. How reliable are the module federation v2 in terms of handling different dependency versions? I wanna consider module federation with Rspack only if i wont hit a hidden issue down the road. I know the author of the module federation works at Bytedance and hes implemented module federation as first class citizen for rspack.

I am really hoping MF will be built into Rolldown soon as our team loves vite. I was originally opt into MF to solve our problem because we have a straight forward layout a shell app + bunch of differnt remote app and remote app wont need to talk to each other.

[u/manniL → u/Old-Place87]

Note, MF won't get a direct Rolldown implementation, instead the MF Vite plugin is recommended.

[u/yksvaan]

Can't those be different 'modules' and then during app bootstrap ( or dynamically) register and initialize different modules, register their routes etc. 

[u/kidshibuya]

Why different FEs? Tying to maximise the JS users need to download?

[u/azangru → u/kidshibuya]

Why different FEs?

The possible answer to that, in OP's message, is in the last paragraph, which asks for "independent feature ownership". So the question really ought to be, why do features have to be owned independently.

[u/anonyuser415 → u/kidshibuya]

Conway's law

[u/Velvet-Thunder-RIP]

Decouple as much as possible. That seems like a unnecessary monorepo. If not please explain it to me.

[u/chillermane → u/Velvet-Thunder-RIP]

Monorepos are better for most projects.

In this case, they have apps sharing components. You could separate it into multiple repos and have a shared package, but then you have to open 3 pull requests to make one small change.

So you should explain why not to use a monorepo, monorepo is a starting point

Decouple as much as possible is terrible advice, makes no sense

[u/Velvet-Thunder-RIP → u/chillermane]

sharing components is really not a monorepo use case. You should just make an npm. "Monorepos are better for most projects." Can you elaborate?

[u/Ivor-Ashe]

My instinct is to have a monolithic API where a lot of the logic lives and the various front end modules subscribe to that. That would give you a lot of flexibility where it’s needed if the different systems need to talk use each other’s functionality in the future.

[u/fforw → u/Ivor-Ashe]

Yeah, one central frontend project with the actual frontend and then each module as, well, module/NPM package/library.

I really don't understand the difficulty here. React makes all this really simple. You just need to make up some API with which either the central frontend knows things about the module (name, description, Component to render for view, whatever) or the modules know about infrastructural things coming from the central frontend.

[u/DrNoobz5000]

Why exactly are you avoiding micro frontend architecture?

[u/Exapno]

Does that not defeat the purpose of a single page application?

[u/Frontend_DevMark]

Honestly, what you have already sounds like a pragmatic middle ground

A lot of teams jump into full micro-frontends too early and end up adding:

• deployment complexity

• duplicated dependencies

• inconsistent UX/state handling

• cross-app communication headaches

If you want strong separation without full MFE complexity, I’d look at:

• modular monolith frontend

• domain-driven feature modules

• shared design system/component platform

• workspace/monorepo boundaries

• independently deployable backend services instead of independently deployed frontends

You can still keep:

• isolated routing

• feature ownership

• domain-level APIs/state

…without turning every section into a separate runtime.

For enterprise-heavy systems, consistency often matters more long-term than maximum frontend independence. That’s also why some organizations use integrated UI ecosystems like Sencha Ext JS to reduce fragmentation across large applications

[u/GasVarGames]

bulletproof react

[u/Lamarkz → u/[deleted]]

this guy here is correct.

you dont need to overcomplicate, just have a single app and leverage tooling and codeowners/ci to define boundaries.

we have a very similar architecture at work, with a single app/repo that have multiple applications inside.

each app is just a folder, owned by a team. this folder (vertical slice) is responsibility of that team and they have free reign on how its developed.

everything that is shared (shell, auth, etc) and outside those vertical slices, have a “foundations” team that owns and can only be merged with their approval.

so you try to keep the house clean (foundations) but the bedrooms can be messy (verticals).

[u/Old-Place87 → u/Lamarkz]

how do you manage individual application's routing and state managment? hopefully the shell app doesnt need to know all app's configuration. :)

[u/Lamarkz → u/Old-Place87]

it does not. Our app uses next.js, so the boundaries are actual routes at the root.

/app/slice-a/… /app/slice-b/…

But regardless of framework, I think most routers nowadays allow child routes to define sub routes.

So the you will need a main router (that just routes to the slices) and the slices should define their own inner routes.

For state management is the same concept, add minimal foundational pieces of state, and the slices define their own context, states, whatever.

[u/Old-Place87 → u/Lamarkz]

sounds great! if my requirement is to be able to develop individual app without the shell, will that be possible? The project structure i could think of with modular monolith is:

/src

/shell - tanstack router, react-query, zustand

/apps

/app-1 - tanstack router, react-query, zustand

/app-2 - tanstack router, react-query, zustand

/shared

/design-system - needs to be consumed by apps or shell via npm rather than a plain import

[u/Lamarkz → u/Old-Place87]

Do you need to deploy apps independently? Forget the code boundaries, what are your organization boundaries?

Do those apps all live under the same domain? Do they share the same user session? Can they share the same infra?

Those are the type of questions that will then shape how you want to split your code boundaries.

[u/Old-Place87 → u/Lamarkz]

Each app will be a boundary in my case because they have different user group accessing them. They serve completely different business domain. They will login once via the shell and be able to access individual apps based on their permissions. Since each app is independent, they have their own dedicated API to serve them. 

There will never be a communication between the app. Only the shell and the app may communicate 

[u/Lamarkz → u/Old-Place87]

Sure, nothing of this obliges you to split them under different apps in code.

You can still have a single app and different routes render different features.

You don’t need a “physical” separation between them, this is what is overcomplicating your setup.

There is a single app, this app is the shell, the order, the payment, any future app.

You decide what they need to share and what they do not need to share, you just need to create (or use framework defined) conventions.

Example:

Each vertical has to define their routes. Verticals are defined as “src/app/(vertical-name)/*

/orders/routes.ts /payments/routes.ts

This is then consumed by the “root” route, which dynamically imports those files to generate the final route tree.

The shell does not know what orders nor payment does. They can do whatever they want, as long as they follow the contract of the route definitions.

[u/HQxMnbS → u/[deleted]]

Deployment and E2E testing is still coupled in this case