Micro Applications#

Micro applications are a solution for breaking down large projects into multiple independent smaller applications. Each application can be independently deployed, debugged, and quickly integrated into a large user-facing application. It also supports resource sharing between micro applications, making it suitable for multi-team collaborative development. The micro application capability is enabled by default in wis without requiring additional configuration.

Principle#

The micro application technology is currently built upon the mature community solution Module Federation. Based on this, we've made some simplifications and encapsulations, enhanced the convenience of resource sharing and micro application integration, while extending core capabilities such as cross-platform and resource sets to better align with wis's design philosophy.

Registering Applications#

For micro applications to share resources with each other, including page resources, script resources, component resources, and cross-platform resources, they need to be registered first. Each application can be either a producer or a consumer, or simultaneously play both roles.

For example, if we want to use wis's component library in our application, we just need to add the following configuration to the wis.config.ts configuration file:

import type { WisConfig } from "@wisdesign/wis-plugin"
 
export default const config: WisConfig = {
  name: "example",
 
  remotes: {
    wis: "https://static.wis.design",
  },
}

Application Types#

Micro applications themselves don't have type distinctions; each micro application has complete capabilities and can be used for library development (such as component libraries, utility libraries), container application development (like shell applications), and specific vertical business applications. In actual business scenarios, we often define and categorize applications for better understanding.

Shell Applications#

Shell applications typically handle the basic framework parts of a project, such as the overall website layout, navigation menus, breadcrumbs, and user information, serving as an integrated application provided to users.

Business Applications#

Business applications are typically developed for specific business domains, such as order management, product management, user management, etc. Each business application can be developed, deployed, and debugged independently before being integrated into the shell application.

Library Applications#

There are often many commonalities between micro applications, such as shared component libraries and utility libraries. Library applications are specifically designed for sharing resources in such scenarios.

Cross-platform Applications#

Cross-platform applications are a core feature of wis. They allow you to write different implementations for different platforms (PC, Pad, Mobile) using unified definition specifications. When using them, we only need to write one set of unified code without worrying about platforms - the system will automatically direct resources to the corresponding implementation based on the current platform type. This chapter won't discuss cross-platform applications in detail; those interested can refer to Cross-platform Applications.

Application Integration#

Each micro application automatically exports its page resources by default for other micro applications to consume. Usually, we only need to modify the route access address to switch between different applications and pages.

When you want to switch from the current application to another application, such as the wis application, and access wis's Button demo page (/button), we just need to visit the route /wis/button.

For example, if we're accessing the current application through https://localhost:3000#/, we just need to visit https://localhost:3000#/wis/button to complete the application switch. The application switch won't affect the layout part of the current application. For more detailed information, check out Pages and Layouts.

Application Routes#

Applications are represented as part of the route, achieving application switching by changing route addresses. They are positioned between the layout route segment and the page route segment. For detailed information, please refer to Route Composition.

Application Resources#

Besides micro application pages being automatically shared, almost all micro application resources can be shared with other micro applications, including scripts, styles, components, images, etc. We categorize application resources into the following types:

• Resources
• Resource Sets
• Cross-platform Sets
• Cross-platform Resource Sets

Among these, Cross-platform Sets and Cross-platform Resource Sets are core features of wis cross-platform applications, which we'll introduce separately. Those interested can check out Cross-platform Applications.

Resources#

Allows exporting application resources to be shared with other applications while also supporting import within the application itself.

import type { WisConfig } from "@wisdesign/wis-plugin";
 
export default const config: WisConfig = {
  name: "wis",
 
  exposes: {
    // Export a button component
    "./button": "./src/components/button/index",
  },
}

Resource Sets#

The difference between resource sets and regular resources is that resource sets define multiple different types of resources for the same resource. At runtime, only one resource is loaded based on specific matching conditions.

For example, with internationalization resources in a project, language resources typically include language packs for multiple languages, but users only need one resource when actually using it. If internationalization resources are exported as regular resources, all language packs must be exported together. As the number of languages increases, the exported resource package gradually grows larger, creating unnecessary resource waste.

import type { WisConfig } from "@wisdesign/wis-plugin";
 
export default const config: WisConfig = {
  name: "wis",
 
  exposes: {
    "./locales": {
      // Must include at least one default resource
      "default": "./src/locales/en/index",
      "zh": "./src/locales/zh/index",
    }
  },
}

How does the runtime match and identify resources when we import a resource set in our application?

At runtime, the system reads the data-kind attribute of the html tag, whose value format is [pattern]:[value]. When multiple resource sets need to be supported, they are separated by ,.

Taking the above internationalization resource as an example, when we want to switch the system to Chinese, we can set the data-kind attribute of the html tag to ^\.\/locales(?:\/.*)?$:zh. This way, when the system runs, it will load the zh resource from the resource set when loading internationalization resources.

Usage#

When an application needs to use resources or resource sets from other applications, it first needs to register the application containing the needed resources. For specific details, refer to Registering Applications. The usage is simple - just import directly.

import { Button } from "wis/button";
 
export default function () {
  return <Button text="Wis Button" />;
}