Micro-Frontends and Shared Component Architecture Quiz Quiz

Explore the key concepts and practices behind micro-frontends and shared component architecture, including integration strategies, communication patterns, and design considerations. This quiz helps developers and architects assess their understanding of building scalable, maintainable front-end systems using modular approaches.

  1. Concept Understanding

    Which statement best explains the main advantage of using micro-frontends in a large web application?

    1. They merge all code into a single, large repository to simplify management.
    2. They allow independent development and deployment of different sections of the UI.
    3. They focus solely on improving server-side performance.
    4. They require all teams to use the same programming language for consistency.

    Explanation: The core benefit of micro-frontends is enabling different teams to develop, test, and deploy separate UI features independently, enhancing agility and scalability. Combining all code in a single repository can lead to complex dependencies and coordination challenges. Micro-frontends do not primarily target server-side performance, nor do they mandate the use of the same programming language for all teams, allowing more flexibility.

  2. Component Sharing Practices

    In a shared component architecture, what is a key challenge when multiple teams use a common component library across different micro-frontends?

    1. Ensuring all teams use completely unrelated styling conventions.
    2. Keeping shared components backward compatible as they evolve.
    3. Forcing every team to redevelop their own version of each component.
    4. Making components accessible only to a single micro-frontend.

    Explanation: Maintaining backward compatibility is essential so updates to shared components do not break existing micro-frontends using previous versions. Unrelated styling conventions can lead to inconsistency, but the main architectural challenge is versioning and compatibility. Making components exclusive to one area goes against the idea of sharing, and redeveloping components reduces efficiency and code reuse.

  3. Isolation Strategies

    What technique helps maintain CSS style isolation between two micro-frontends rendered on the same page?

    1. Relying solely on browser default styles without customization.
    2. Using unique, prefixed CSS class names for each micro-frontend.
    3. Applying global inline styles to every component.
    4. Merging all micro-frontend stylesheets into one large file.

    Explanation: Prefixed or scoped class names help prevent unintended style overrides between micro-frontends. Global inline styles increase the risk of style leakage, and merging stylesheets can introduce conflicts. Solely depending on browser default styles limits customization and does not address isolation concerns.

  4. Communication Patterns

    Which approach provides a decoupled way for two micro-frontends to communicate user actions without creating direct dependencies?

    1. Hard-coding function calls between modules.
    2. Storing shared state only in global variables.
    3. Embedding one micro-frontend entirely within another's codebase.
    4. Publishing and subscribing to custom events on a central event bus.

    Explanation: A central event bus allows micro-frontends to exchange information using events without direct dependencies, supporting loose coupling. Hard-coded function calls and embedding micro-frontends increase interdependence, while global variables risk naming collisions and unpredictable updates.

  5. Deployment u0026 Versioning

    When using a shared component library across various micro-frontends, what is a recommended practice for managing updates and releases?

    1. Always release major and minor updates simultaneously to all micro-frontends.
    2. Never update the shared library to avoid introducing changes.
    3. Use semantic versioning to indicate breaking changes and compatibility.
    4. Only document changes in team meetings rather than version control.

    Explanation: Semantic versioning enables clear communication about which updates are compatible and which could introduce breakages, helping teams manage dependencies safely. Simultaneous releases reduce agility and are not always feasible. Freezing updates prevents improvements and bug fixes, while informal documentation cannot replace versioning best practices.