pluggable child apps (multiapp)

[pi0]

• POC: [RFC] multi app support nuxt#5818 (closed due to complexity on code-base and limitations)
• Nuxt2 solution for extending: https://github.com/nuxt-community/nuxt-extend

Background

When the project structure grows, sometimes it is not convenient to use a flat directory structure or keep everything in a single repo.

Why?

• A simple way to split big projects into separate parts with separate business logic
• We already have srcDir implemented in Nuxt. This feature needs a small refactor effort and does not makes core complicated.

Proposed Solution

One can structure a project like this:

├── shop
|  ├── components
|  |  └── nav.vue
|  ├── layouts
|  |  └── admin.vue
|  ├── middleware
|  |  └── admin.js
|  ├── pages
|  |  └── shop
|  |     └── index.vue
|  └── store
|     └── admin.js
├── nuxt.config.js
├── package.json
├── pages
|  └── index.vue
└── store
   └── public.js

The shop/ dir should basically follow the same standard nuxt directory structure. Builder module combines all children app to the main one. And also creates aliases so components inside admin can be required using:

import Nav from '~shop/components/nav

For registering admin app, it should be registered inside nuxt.config. (Items can be npm packages or local dirs)

export default {
  apps: [
    '~/shop'
  ]
}

Limitations

These are problems with current POC. We can progressively enhance this functionality and workaround these limitations.

• Currently, store and middleware cannot be supported because srcDir is hardcoded in vue-app templates
• There is no namespace support. (adding admin/ prefix to store modules and pages) -- children will be registered with the same namespace.
• Just like the main project, child app files are not lodash templates. We can add a template flag to support and copy the template child apps to the .nuxt

[Koc]

Do we really need care of this? IMHO it easier create 2 separate apps with different Nuxt config, packages.json and build/deploy them independently. Otherwise we got big monolith which is hard to maintain.

[pi0]

@Koc Exactly that's also my concern/preference to use separate projects. But I know monolith projects that may benefit from this feature to structure their project better. Also, we have the possibility to add parts using an NPM package. (Probably admin was not a good example tough!)

[Koc]

Also, we have the possibility to add parts using an NPM package.

For sharing some code between apps we can use monorepo approach, extract common business logic/api clients/etc into separate package and require it using path package or npm-link or tools like Rush

[clarkdo]

Agree with @Koc concern, we should consider more about this.

• pages/routes priority in different apps because different apps may contain same route
• global/scoped middleware/plugin which in run globally or only in specific app
• complexity for development
• avoid influence on traditional usage (performance and configuration)

In my perspective, I would like leverage yarn workspace for mono repo, like:

├── cms
|  ├── pages
|  └── store
|  ├── nuxt.config.js
|  └── package.json
├── app
|  ├── middleware
|  ├── pages
|  ├── nuxt.config.js
|  └── package.json
└── package.json

For common app, we already provide components as a dir to put reusable stuff in:

├── pages
├── store
├── components
|  ├── cms
|  └── app
├── nuxt.config.js
└── package.json

If necessary, it would be better to use module or sth like extend to import reusable components or pages.

[pi0]

@clarkdo I see your point about route conflicts. that's also mentioned in the notes to be supported

About mono-repo yes that's one solution for separating admin/cms I personally use (and also common/ dir for shared components/base config)

The Purpose of this enhancement is not having different parts (admin/cms/mobile) and not a good practice to use it for that. but splitting the main project into separate and reusable modules. The increasing number of pages for an enterprise project is unavoidable and there is no way to split it into smaller modules.

One other point is that client-side routing works across this sub-apps.

[nicodevs]

Yes, please! It would be great to have this feature.

[bovas85]

I'd prefer this to losing the state on micro Frontends. Maybe pairing it with some best practices guidelines would make this more resilient

[paulmelero]

We've been experimenting this in a PoC at my company. We were able to inject sub-apps routes via Nuxt modules. And were proposing this for one of our products.

I love to see we are aligned, @pi0. Given it's a very specific case that most of Nuxt apps are not going to use, I hope it won't affect the size of their bundles.

@clarkdo is pointing fair concerns.

I think Nuxt core is mature enough to envision this but our current file structure isn't. Therefore a lot of things that come after (in how Nuxt wires up its parts) are coupled with this file structure.

Think about backend architectures. For example, the Hexagonal Architecture. If Nuxt core was really a core, it wouldn't care if there are 1 or 2 apps. Or 1 or 2 UI systems.

Replying to @clarkdo's points:

• The different apps shouldn't share routes, because each one could be enforced to mount in a different basePath (/, /app) or baseURL or subdomain.
• global/socped plugins and midldewares are indeed needed
• development complexity could be improved with a better CLI. Same thing Guillaume Chau is working on for Vue.
• Traditional biases is a good one. I wouldn't like Nuxt to become Angular.

This keeps coming to my head. If there is no consensus, how about creating a module that tries to handle handles this without affecting the rest of the user's performance? cc/ @pi0 (❤️)

[pi0]

@pm-LTK This does not affect the user's performance at all. All sub-apps are finally merged into the same data structure. We just glob multiple directories.

I also thought about the module, but that module should duplicate most of the logic of @nuxt/builder package which introduces inconsistencies. Please refer to related PR to have a better vision of this change.

[HapLifeMan]

It would be a VERY GREAT feature, in my case for multi-domains support 🙂
Especially to have different pages (components, assets and layouts would be shared between domains).

For instance (it is absolutely not for i18n but it's a good understandable example):

├── pages-com         <==== https://mydomain.com
|  ├── index.vue
|  ├── about.vue
|  └── contact.vue
├── pages-fr          <==== https://mydomain.fr
|  ├── index.vue
|  ├── about.vue
|  └── contact.vue
├── components
├── layouts
├── middleware
├── store
└── package.json

It would fit perfectly for:

• an admin interface, docs, blog (with subdomains)
• maintain an app without having multiple repos
• use shared components/layouts/... but different pages per domain
• ...

[blowsie]

I just stumbled across this after making something similar.
I created a themeable nuxt application. By extending the vue router.

https://codesandbox.io/s/my-app-9ythm

You set the theme path in the nuxt.config, which essentially could be an environment varible.
The code then looks into your themes folder for said theme, and if a page is deinfed for it, use that instead.

That enables you to reuse any existing component code via extends.
You can switch out styles/ templates / js as required.

[simllll]

We actually ran into something similar as our project got bigger. But we ended up using a monorepo, with several "seperate" nuxt projects, but all the nuxt projects use a shared component library (see a demo how we did that with nuxt: https://github.com/simllll/nuxt-library-demo) and a "module" library where we abstracted all the shared middleware and plugins. Therefore it's only business logic and pages / custom components that are in the nuxt projects. Furthermore one of the sub packages of our mono rep is a cordova mobile app which is using one of the nuxt projects and builds a SPA app out of it.

I would prefer keeping the code "stuctured" but "seperated". Which I'm unsure if this is the case if nuxt allows sub-apps. It's just one special use case that is covered with it (think about e.g. a storybook for your components, another cordova app, or something else people can come up with.. ;))

So for us, we have all freedom and all advantages combined with a monorep approach (which is also used in different projects and is commonly used everyhwere around ;)) and still have a very strickt seperation of code and logik, therefore I would vote for a better documentaton or CLI for a monorepo setup (with a component library or other templates in it) instead.