WaveMaker Docs

WaveMaker Docs

  • Get started
  • Widgets
  • How-to
  • Enterprise
  • Releases
  • Blog
  • Sign-in

›All Blog Posts

All Blog Posts

  • Mitigating Spring Zero-day Vulnerability CVE-2022-22965
  • Archiving WaveMaker 9 Projects
  • URL Change in WaveMaker Android WebView
  • Announcement about Angular 11 Update
  • Mitigating Log4J 2 Vulnerability CVE 2021 44228
  • Ending Support of WaveMaker 9 Projects
  • Git Branching Strategy
  • Important Announcement about Angular 10 Update
  • Accessibility Support in WaveMaker
  • Generating .aab files using wm-cordova-cli or AppChef
  • WaveMaker Studio enables faster database imports
  • Integrate SAP HANA Database with WaveMaker
  • Redshift Database Integration
  • Important Announcement about Changes to Documentation Domain
  • WaveMaker Releases 10.7 Version
  • Theme Builder with some coding (Build + Edit)
  • Understanding Scaling of WaveMaker Applications
  • Automatically Import your Website Branding Styles into a Theme
  • Certificate Pinning Case Study
  • Cordova 10.0.0 Upgrade
  • WaveMaker Releases 10.6 Version
  • Retain UI State in WaveMaker Apps
  • Theme builder is ready with a new update
  • PostgREST OpenAPI support in WaveMaker
  • Fully automated and scalable test execution using k8s
  • New file picker for mobile apps - Improvements in UI to select files in mobile
  • WaveMaker releases 10.5 version
  • Deliver faster applications with WaveMaker!
  • GraphQL in a Micro Services Architecture
  • Build Themes for WaveMaker Apps Without Any Coding
  • COVID-19 Visualization using WaveMaker - Part 2
  • COVID-19 Visualization using WaveMaker - Part 1
  • WaveMaker Integrates with DigitalOcean Kubernetes for App Deployments
  • Deployment Experience made better!
  • OpenAPI support in WaveMaker
  • WaveMaker platform is updated to use WKWebView.
  • Deliver WaveMaker Apps as Micro Frontend Modules
  • All-new WaveMaker docs with a powerful Search
  • Welcome to the WaveMaker Developers Blog

Deliver WaveMaker Apps as Micro Frontend Modules

February 25, 2020

Subodh Kumar

A real-world application is composed of multiple modules. Changes or upgrades to a given module can impact other modules and add more testing effort to the development timeline. Including a new technology into the existing app might be challenging as the existing app might not include all support, such as the build process.

note

For more information about developing Micro Frontend modules, see Developing Micro Frontend Modules in WaveMaker.

What are Micro Frontends

One of the practices which simplify the development and maintenance of such apps is to decompose the application into modules that can be independently developed, tested, and deployed. This is known as the MicroServices pattern.

Adapting these practices to frontend systems enables us to generate independent, composable application modules. Such modules are called Micro Frontends.

This practice helps teams develop modules in parallel, deliver customer-facing solutions quickly, learn directly from customer feedback and improve the module for better adoption. Organizing teams this way to have a direct customer visible deliverable is a key ingredient in setting smaller teams for success by letting their customers connect with the teacher. Adopting or validating new technology for a new feature or replacing an existing feature can be progressively achieved without affecting other app entities.

For enterprises that want to modernize their applications by adopting micro frontend, the architecture gives them a delivery model where they can start deploying modernized modules into their existing application.

As the modules are independent of each other, below are the key gains.

  • Reduced development time and testing effort
  • Parallel and Incremental addition of features
  • Enables using different technology, frameworks for development and delivery
  • Ease of integration of new modules into existing systems

Implementation approaches

There are many approaches to implementing the Micro Frontend pattern to an existing or new application. Let's take an example of an 'e-cart' app to explain the approaches to implementing Micro Frontends to an existing monolith app.

A typical 'e-cart' app can be grouped into below listed main modules.

Catalogue: The available items are managed. User Profile: The user-related operations are handled, such as his info Orders: The order related info such as history, status are managed Payments: The payment-related info such as mode, status is managed

Each of the above can be built into a deployable module bundle. Below are some of the approaches that can be adopted to compose them and serve as an application using the Micro Frontends pattern.

Container Application

With this model, there can be one container module that can

  • House common UI elements such as Headers, Footers, etc.
  • Handles common operations such as authentication and navigation.
  • Loads and unloads each 'Micro Frontend' module based on the user action.

Server Side Composition

With this model,

  • The app is served through an HTML page rendered on the server-side.
  • The page is composed of common elements and placeholders.
  • The page uses server-specific plugins to render MicroFront modules in the placeholders of the HTML as per the need.

Build Time Composition

With this model,

  • Each Micro Frontend module is published as an independent package.
  • The container app will include the packages as library dependency and produce a single deployable Bundle on building
  • However, a change in any module will require rebuilding the container bundle (in turn, rebuilds all the dependent modules) to be served, making it not a good approach to adopt.

Run Time Composition

With this model,

  • Each Micro Frontend module is built as an independent script and exposes a global function as its entry point.
  • Each Module can also be built as Web Components.
  • The container application will have the logic to load required modules on demand and render them into the required DOM node.

With all the approaches and advantages described above, this pattern does come with some costs listed below,

  • The approach might cause an increase in Payload size if the modules share dependencies as the modules are built separately with dependencies.
  • Increase operational cost as each module might involve a different build and delivery approach.

Single-spa framework in WaveMaker

note

For more information about developing Micro Frontend modules, see Delivering WaveMaker Apps as Micro Frontend modules.

Single-spa framework allows you to compose and serve multi-framework modules into an app by including a compatible JavaScript bundle. When built, a real-world web application will not just generate JS bundles but also produce CSS and other metadata artifacts. Currently, the Single-spa framework does not have any specific way of loading non-code, non-JS artifacts. For this reason, the users are requested to add the additional scripts in the steps mentioned above.

WaveMaker is planning to work on a loader script that will load all the artifacts required for a WaveMaker app to work with Single-spa without the need for any additional loading scripts and provide seamless integration support in the coming releases.

Screenshots of Sample S-spa

Home

screenshot

Angular App

screenshot

WaveMaker App

screenshot

Tweet
Recent Posts
  • What are Micro Frontends
  • Implementation approaches
    • Container Application
    • Server Side Composition
    • Build Time Composition
    • Run Time Composition
  • Single-spa framework in WaveMaker
    • Screenshots of Sample S-spa
WaveMaker
  • PRICING
  • PARTNERS
  • CUSTOMERS
  • ABOUT US
  • CONTACT US
Terms of Use | Copyright © 2013-2022 WaveMaker, Inc. All rights reserved.