DEV Community: Eden Ella

Micro Frontends: Enabling Scalable and Autonomous Development with Build-Time Integration

Eden Ella — Tue, 18 Feb 2025 15:57:53 +0000

Micro frontends (MFEs) are often integrated at runtime rather than build time. This choice isn’t necessarily because runtime integration offers a better user experience—it’s because it enables faster builds and smoother collaboration between teams. With runtime integration, teams can work autonomously, developing, building, and deploying their MFEs independently, often in separate repositories.

However, runtime integration comes with trade-offs. It can lead to inconsistencies in UX, integration challenges, and suboptimal performance. In contrast, build-time integration allows for thorough end-to-end testing, reducing the likelihood of bugs in production. It simplifies dependency management, ensures a consistent UX across the application, and reduces overall bundle(s) size.

The solution presented in this blog implements build-time integration for micro frontends (MFEs) while maintaining team autonomy and ensuring consistency. The key elements of this approach include:

Inversion of Control: MFEs integrate into the app shell based on their own implementation rather than being dictated by the app shell team. MFEs implement an interface that "expects" to be injected with an app instance. The app, injected by the application shell, exposes integration slots, global states, and shared functions.
Shared Interfaces: The TypeScript interfaces that MFEs need to implement are shared as Bit components, ensuring compatibility and seamless integration.
Shared UI Components: The design system, the elementary UI components for the app, are shared as Bit components to maintain a consistent user experience across all MFEs.
MFEs as Bit Components: Each MFE is released and shared as a Bit component. MFEs are consumed by the app shell as external dependencies (i.e., as packages).
Bit Platform Webhooks: Automatic dependency updates to the application shell when a new MFE is released

Implementing Build-Time MFE Integration with Bit

Bit can be adopted in different ways. Some teams use Bit as a complete development solution, maintaining their applications as deployable Bit components without traditional Git repositories. However, most Bit users integrate it into existing workflows and tools, and that’s the approach we’ll follow in this example.

Our demo solution is a single-page space travel application built with Vite and React, managed in a Git repository. It integrates two Micro Frontends:

Marketing
Booking

Each MFE is managed in its own Git repository and Bit scope.

1. Setting Up Bit Scopes and Git Repositories

The first step is to create Bit scopes and set up Git repositories for the MFEs, their shared UI library, and the orchestration components.

Repository Structure:

Foundation: Components responsible for orchestrating and integrating MFEs
Design: Shared UI components ensuring a consistent UX
Booking: Components for the booking MFE
Marketing: Components for the marketing MFE

Note: The app shell in this demo is not a Bit component but a standalone application.

Each Bit scope is hosted on Bit Platform, which provides access control features. In this setup, each scope corresponds to a single repository, but a single repository can also contain multiple Bit scopes if needed.

2. Creating the App Shell and Integration Components

The app shell orchestrates MFEs and provides shared dependencies. It consists of two main parts:

1. A Subscriber Component (Bit)

The subscriber defines how MFEs integrate into the system. It provides an API for MFEs to register routes, header links, and shared states.

export class App {
  private routes: RouteType[] = [];
  private headerLinks: HeaderLink[] = [];

  registerRoutes(routes: RouteType[]) {
    this.routes.push(...routes);
  }

  registerHeaderLinks(headerLinks: HeaderLink[]) {
    this.headerLinks.push(...headerLinks);
  }

  renderApp() {
    return (
      <Theme>
        <Header links={this.headerLinks} />
        <Routes>
          {this.routes.map((route) => (
            <Route key={route.path} path={route.path} element={route.element} />
          ))}
        </Routes>
      </Theme>
    );
  }
}

2. The Application (Non-Bit Component)

The application defines which MFEs should be included and handles the build and deployment process.

import { createRoot } from 'react-dom/client';
import { App, Frontend } from '@cosmo-flux/foundation.subscriber';
import { marketingMfe } from '@cosmo-flux/marketing.marketing-mfe';
import { bookingMfe } from '@cosmo-flux/booking.booking-mfe';

const app = new App();
const frontends: Frontend[] = [marketingMfe, bookingMfe];
frontends.forEach((frontend) => frontend(app));

createRoot(document.getElementById('root')!).render(<>{app.renderApp()}</>);

3. Implementing the MFEs

Each MFE follows the Frontend type defined by the subscriber component. This ensures the MFE teams maintain autonomy while integrating seamlessly.

For example, the Booking MFE registers the Red Planet Reservations page:

import type { Frontend } from '@cosmo-flux/foundation.subscriber';
import { RedPlanetReservations } from '@cosmo-flux/booking.pages.red-planet-reservations';

export const bookingMfe: Frontend = (app) => {
  app.registerRoutes([
    { path: '/reservations', element: <RedPlanetReservations /> },
  ]);
  app.registerHeaderLinks([
    { label: 'Reservations', path: '/reservations' },
  ]);
  return app;
};

Because both the MFE and its components are Bit components, they can be imported directly into the app shell project as regular dependencies.

4. Automating Deployment with Webhooks

To replicate the developer experience of runtime MFEs while leveraging build-time integration, we use Bit Webhooks to automatically trigger the app shell’s CI/CD pipeline when a new stable version of an MFE is released.

Using Bit Webhooks in Composable Software: 5 Use Cases | by Mike Chen | Feb, 2025 | Bits and Pieces

Automate Updates, Streamline Development, and Improve Collaboration with Bit Webhooks

blog.bitsrc.io

Automating the build and deployment process might seem risky at first, but in practice, it enhances stability compared to traditional runtime integrations.

Build-time integration enables comprehensive end-to-end testing and automated verifications, ensuring failures occur during the build process rather than at runtime.

Conclusion

By leveraging Bit for build-time integration, teams can enjoy the best of both worlds—independent development with runtime-like autonomy while maintaining stability, performance, and consistency across the entire application.

Using Bit and Bit Platform, components are shared and synced across separate repositories, allowing you to treat your poly-repo setup as one single virtual monorepo.

AI Coding Assistants, Starter Templates, and More: A Guide to Working Less

Eden Ella — Tue, 19 Nov 2024 14:13:11 +0000

You’re a JavaScript developer with big dreams to build amazing things. But before you can even start on that next incredible app idea, you’re stuck spending hours setting up boilerplate code and infrastructure. There’s the dev environment to configure, CI pipelines to set up, and plenty of generic features to build, like user profiles and auth flows.

You feel like that’s not exactly the best use of your time or talent. That’s when you start hunting for shortcuts. Tools and resources that can handle the mundane parts of your app so you can focus on that special feature you’re trying to build.

You probably already rely on AI coding assistants to some extent, but the real magic happens when they’re paired with other development tools and resources designed to jumpstart our projects.

While AI can streamline many tasks, understanding how to use tried-and-true tools and resources effectively is critical. These can guide your AI assistant to generate cleaner, better-tested, and more efficient code.

Project Templates and AI Coding Assistants

Project templates provide pre-configured setups for various tech stacks. They’ve been around for a long time but, perhaps counterintuitively, have become even more important with the rise of AI coding assistants.

Example: starter templates on Vercel.com and Remix.run

A template provides the best context for your AI assistant, saving hours of meticulous prompt-engineering and lengthy conversations with your AI comrade. A template is detailed. It defines the development environment, dependencies to use, data transfer methodology, frameworks, state management, styling solutions, and so on.

A template also has coding conventions and development standards embedded in it. With a solid, tested, and verified base, you’re spared from piecing together the entire thing prompt-by-prompt.

Customizing a pre-made project (template) using Cursor AI and the @Codebase mention

In addition to the template itself, some AI assistants (like Cursor AI) also support a general instruction file to guide the AI in every suggestion it makes. For example, see this collection of Cusror AI instructions, written by senior developers, to use inside the .cursorrules file:

https://cursor.directory/

Infrastructure-as-Code and AI Coding Assistants

Coding isn’t just about writing frontend or backend logic — it’s about setting up the entire ecosystem for your app to thrive. Tools like AWS CDK, Pulumi, or Terraform let you define your cloud infrastructure as code.

Modern IoC tools like SST are highly “aware” of the functional side of your codebase. They embed into your app’s logic to make for a streamlined and more failproof development. Modren IoC tools often provide incredibly abstract APIs, which makes it simpler for you and your AI companion to comprehend.

Using IoC allows your AI coding assistant to assist you more. It can manipulate and extend your infrastructure, just like it does with your logic and UI. Your codebase is all your AI needs to service you well. Nothing is hidden away, including the resources that power your app.

/**  
* SST Example; the code for nextjs deployment   
* along with the creation of an S3 bucket (which is accessible to it)  
**/  

const bucket = new sst.aws.Bucket("MyBucket", {  
  access: "public"  
});  

new sst.aws.Nextjs("MyWeb", {  
  link: [bucket]  
});

Self-hosted UI libraries and AI Coding Assistants

There’s been a noticeable shift towards embedding UI components directly into projects instead of installing them as (immutable) npm packages, giving you more flexibility to tweak and extend them.

One major advantage of having your own instance of UI componetns as part of your codebase is that it makes it easier for your AI coding assistant to compose new UIs on demand while referring to your customized collection of components and their (potentially) modified behavior and APIs.

Some component collections like shadcn/ui offer a CLI tool to help you with the “copy-paste” process. Other tools like Bit can help you do the same with any UI library hosted on the Bit Platform. Any component can either be installed or copied into your project.

A custom collection of Radix components hosted on Bit Platform

In the case of Bit Platform, a dedicated AI assistant can also generate a custom collection of shared components based on your favorite component libraries.

Generating a shared collection of custom Material UI components on Bit Platform

Composable Codebase and AI Coding Assistant

Composable software or composable codebases are two closely related concepts that have also been around in software development for some time now.

In essence, a composable codebase is designed with modular, reusable, and independently manageable components or modules. These modules can be assembled in different ways to produce new systems or modify existing ones. A system can be composed during build-time, runtime, or a hybrid, forming the frontend, backend, and even its infrastructure.

Example: A composable React + Apollo server application compsosed of reusbale components

The ‘composable’ approach is loved and adopted by many for the standardized, maintainable, and highly adaptable code it produces.

‘Standardized’ because the same components are reused across the system. ‘Maintainable’ because components in the system form a clear dependency graph that describes how they relate to each other, but also because the total lines of code (LOC) are drastically reduced. Lastly, it is ‘adaptable’ because components can be used in different constellations to address new needs as they come.

AI coding assistants are giving composability a whole new spin.

Platforms like Bit have embraced this approach, offering a home for independent components, along with an AI-powered coding assistant. This assistant goes beyond simple code generation; it understands the system’s dependency graph and prioritizes reusing existing components over creating new code from scratch.

This strategic reuse ensures the codebase remains efficient and maintainable, avoiding unnecessary bloat. Moreover, since the reused components have already been tested and validated, you‘re guaranteed a better night's sleep.

For example, see the following prompt given to Bit’s AI assistant:

Generating a new feature using Bit’s AI coding assistant

The generated component would be a composition of existing independent componetns from your codebase:

The AI generated component ‘contact-us-form’ is composed of existing components from the codebase

The component is then built and tested before it joins your codebase, which is, in a way, a curated collection of reusable components:

An AI generated component is built and tested before it joins your codebase on Bit Platform

Conclusion

Nobody got into coding because they were psyched about setting up boilerplate or wrestling with pipelines. The real magic happens when you get to focus on the creative, game-changing stuff that actually matters. AI coding assistants are here to help however, using them without a plan or methodology in mind, can often result in lengthy and tedious conversations with your AI partner.

Sharing UI Components: Copy VS Install

Eden Ella — Tue, 29 Oct 2024 19:27:28 +0000

In recent years, there's been a noticeable shift in how developers approach UI libraries, moving away from installing entire component libraries via npm packages and toward directly copy-pasting the code into their codebase.

This trend has been largely popularized by Shadcn/UI, a library that provides developers with ready-made, customizable components that can be copied directly into a project for maximum flexibility.

shadcn/ui voted as the most popular design system accroding to The Software House

Why Copying Wins for Complex Components

The copy-paste approach shines, particularly for complex UI elements such as authentication pages, detailed dashboards, or intricate data visualizations. These components require fine-tuned customization that’s difficult to achieve through immutable npm packages.

Instead of overwhelming the library’s API with endless configuration options, this approach allows developers to leverage the composable and declarative nature of modern frontend frameworks, enabling greater control over every part of the component.

Instead of long and complex CSS selectors, you can directly apply styles to elements in a component. Instead of injecting components using a complex dependency injection logic, you simply place or rearrange components however you choose.

An interactive shadcnui chart on Bit Platform

This approach has gained even greater significance with the introduction of AI coding assistants. Instead of generating components from scratch through AI with long, complex prompts — or engaging in a lengthy conversation with the assistant — you can begin with a pre-built composition close to what you need.

By embedding the code into your project, you give the AI assistant a specific, tangible context. From there, you can ask it to make incremental adjustments, such as tweaking styles, adding accessibility features, or changing the layout.

Bit Components: Packages that you can directly edit

Bit has introduced a new entity to the world of web development: The Bit Component. In short, a Bit component can be thought of as a super-package. You can share it, install it, copy it, and even collaborate on it independently of any particular project setup.

For simplicity, we can divide UI components into two groups: design system components and block components. In the design system, basic components like Card are fundamental building blocks. Meanwhile, block components, such as a MediaCard, are composed of design system elements but offer more advanced functionality.

Choice 1: Composing with Design System Components

When creating a new component, the first option is to compose from your design system. For instance, to build a custom card, you may need to combine components like Card, Button, and Typography.

MUI-based components shared on the Bit Platform

These components can be installed in your project through npm, pnpm, yarn, or Bit’s installation:

npm i @bitdesign/material-ui.surfaces.card bitdesign.material-ui/inputs/button @bitdesign/material-ui.data-display.typography

Choice 2: Utilizing Block Components

When opting for a pre-built block component, you have several flexible choices beyond simple installation.

The easiest route is to install the component package directly and use its API. This approach works well if the component fits your needs out of the box or requires only minor tweaks.

For scenarios where you need to make extensive changes, Bit’s fork command allows you to copy the component’s full code into your project. This includes source files, dependencies, and configurations (including the component’s dev tools).

https://bit.cloud/learnbit-react/material-ui-blocks/content/media-card

For example, to copy the MediaCard component and its configuration, we’ll run bit fork and pass its component ID (not package name) as an argument:

bit fork learnbit-react.material-ui-blocks/content/media-card

It’s worth noting that Bit also provides the bit import command, which allows you to create changes to the component and release a new version. This option requires that you have the proper permissions to modify the component (unlike the bit fork command, which does not affect the original component).

Ejecting dependencies’ source files

When forking components with dependencies, Bit auto-installs them for convenience. However, if you need direct access to the source code of a dependency, you can also fork those dependencies.

For instance, if you want to copy the Button component, you can fork it as well from your team’s collection on Bit Platform:

bit fork bitdesign.material-ui/inputs/button

Top 9 React Component Libraries for 2025 | by Eden Ella | Nov, 2024 | Bits and Pieces

Jumpstart your next React project with developer-friendly and user-friendly UI libraries: aesthetic, performance-optimized, and…

blog.bitsrc.io

Manage Your Shared Components and Modules in The Cloud

Eden Ella — Wed, 11 Sep 2024 17:01:06 +0000

You have several modules you'd like to share across different projects. These could be UI components, micro-frontends, utility functions, services, or even shared configuration files. However, you soon realize that sharing them is more challenging than you initially expected.

Your shared modules require a proper setup to be developed, tested, packaged, and versioned independently from the projects that consume them. They should also be well-documented and easily accessible, allowing you and other developers to quickly find and use them.

Bit platform simplifies the process of creating, sharing, and managing shared modules by providing a cloud-based solution that allows you to discover, edit, review, test and build a shared module using nothing more than a web browser.

It does that so you don't have to set up a complex monorepo with multiple build pipelines and development environments or maintain separate repositories for each shared module or group of modules.

1. Set up a Bit Platform account

Head to bit.cloud and sign up for a free account.

2. Create an access-controlled scope to store your shared components

Bit components are modules that can be maintained, shared and versioned independently. They are stored in access-controlled scopes on the Bit Platform. Head over to bit.cloud/create-scope to create a new scope.

Note that this workflow frees you from any repository setup or maintenance.

For example, I'll create a scope called cloud-demo.

3. Start a new Bit Cloud Workspace

Once created, you'll be presented with the following options:

Start locally: To install Bit on your local machine and initialize a new Bit workspace.
Create a workspace: To create a new Bit Cloud Workspace instance that will be maintainable using a web browser.

I'll choose to create a new Bit Cloud Workspace. My workspace is already configured to use the cloud-demo scope I created earlier as the default scope for my components.

4. Create a new component

Using the standard cmd + shift + p shortcut, open the VSCode command palette and select Bit: Create new component.
This will provide a list to choose the type of component you want to create. I'll choose React option and name my component button.

Nested under my cloud-demo directory, I now have a new component called button that I can start working on.
The component files are already scaffolded for me, These include a generic implementation file, a test file, and a documentation file, and a "composition" file that allows me to create examples of how the component can be used.

The component is already set up with a Bit Reusable Development Environment that defines the development environment and build pipeline for it (you can create your own envs as well).

I've updated my button component and added a few component examples to the composition file:

To see how the component looks and behaves, I can run the bit: start command in the VSCode command panel, or run bit start in my terminal.
This will start a local development server that will allow me to see the component in action. The terminal will output a clickable link that will open the Workspace UI in a new tab in the browser.

The component page which includes the component examples, documentation with live playgrounds, the API reference, and additional details about the component such as dependencies and dependents will also be available for others to view once the component is versioned and stored in the scope.

5. Tag the component with a new release version and store it in the scope

Using the VSCode command palette, I can run the Bit: Snap/tag local changes and export them command to tag the component with a new release version and export it to the scope.

The 'Tag and Export' command run the component's build pipeline in Bit Platform's CI service, Ripple CI, to ensure the component is built and tested correctly before it is stored in the scope.

The component's build also include a 'Package and Publish' step to make it consumable as a standard Node package.

6. Install the component in a project

One the build is done and the component is stored in the scope, it can be installed in a project as a standard Node package using bit/npm/yarn/pnpm.

In addition to that, at any point in time, I can go back to the component in the Bit Cloud Workspace and make changes, test them, and tag new versions of the component using the 'Edit component' button in the component page.

This workflow does not include a review process for the changes made to the component. However, Bit Platform does provide a collaborative environment where you can review and discuss changes to shared modules with your team.

Learn More

Create and Edit Shared Modules in The Cloud | by Eden Ella | Sep, 2024 | Bits and Pieces

Effortless cloud-based component management and Collaboration

blog.bitsrc.io

Hope AI: A Code Assistant for Composable Software | by Eden Ella | Jul, 2024 | Bits and Pieces

An AI assistant that understands your codebase, generates, builds, tests, and releases reusable components with previews and documentation.

blog.bitsrc.io

A Modern Approach to React Development | Eden Ella | Bits and Pieces

Build composable and modernized React apps with Bit!

blog.bitsrc.io

Monorepo VS Polyrepo

Eden Ella — Wed, 31 Jul 2024 10:25:48 +0000

The question of whether to maintain your codebase as monorepo or polyrepo has become even more puzzling with the rise in popularity of micro-architecture patterns like microservices, micro frontends, and micro apps.

On the one hand, monorepos are great for cross-project code sharing, dependency management, and consistency across the codebase. On the other hand, polyrepos offer more flexibility in managing projects, dependencies, and releases, and give teams the autonomy they need to work independently.

In a way, polyrepos are the more "natural" approach for micro-architecture designs as they allow us to enjoy the benefits of small, simple and autonomous projects without the complexity of a monorepo. Unfortunately, polyrepos come with their own set of challenges, especially when it comes to managing dependencies and ensuring consistency across the codebase.

A solution that combines the best of both worlds

There's a clear need for a solution that combines the best of both worlds: the simplicity and autonomy of polyrepos with the code sharing and consistency of monorepos. This is where Bit comes in. Bit allows you to manage each component of your codebase as a standalone entity, called a "Bit component."

Bit can be integrated into existing monorepos or polyrepos, or it can be used to manage your codebase in a completely decentralized way, without the need for a repository.

The first approach transforms your repository into a fine-grained monorepo, or a composable repository/codebase. The second approach no longer requires a repository at all, as Bit components can be modified, built, versioned, and shared, independently, not coupled to any repository.

Click here for a high-resolution diagram

Composable codebase: maximizing code reuse and simplifying project maintenance

To understand how a composable codebase works, let's first look at how projects are structured in a monorepo. Monorepos typically host two types of projects: libraries and apps (with 'services' included). Libraries are reusable pieces of code that are shared across multiple apps, while apps are standalone projects that use these libraries (and other dependencies).

A composable codebase, on the other hand, consists only of Bit components. A Bit component is both a library and, possibly, an app (i.e, a deployable component). Unlike the common structure of a monorepo, a repository consisting of Bit components will have a simple, "flat" structure that is similar to any other composable design.

	Standard Applications/Services	NodeJS Libraries	Bit Components
Published to NodeJS Registries	No.	Yes.	Yes. Bit components are published to Bit Platform and possibly other registries like the NPM registry. This includes deployable components or “app components”. Bit components can be installed as standard NodeJS packages.
Deployable	Yes.	No.	Yes. While all Bit components are published to NodeJS registries, some can also be configured to be deployed.
Source-of-Truth	Project-level VCS and VCS platforms like Git and Github.	Project-level VCS and VCS platforms.	Either “Bit scopes” and platforms like Bit Platform or project-level VCS and VCS platforms.
Component-Specific Development Setup and Dependencies	No. Development tools and config, as well as dependencies, are configured on the entire repository or a sub-directory of it.	No. Development tools and config, as well as dependencies, are configured on the entire repository or a sub-directory of it.	Yes. Each Bit component can have its own development setup and dependencies, completely independent of its current repository or its location inside the repository. Development environments/setups are maintained as Bit components and reused by other Bit components, across projects.

Each Bit component has its source files in its own directory and a single file to serve as its entry point or "main" file. Each Bit component consumes other Bit components via their symlink/installed instance in the node_modules directory. For example:



# An example of a composable repo

button/
    index.ts
    button.ts
my-app/
    my-app.ts
    my-app.bit-app.ts (defines 'my-app' as a deployable app component)
    index.ts
node_modules/
    @my-scope/button/
      index.js -> (symlink for type support and IntelliSense)
      button.js -> (symlink) ../../button/button.ts
      dist/
        index.js (compiled)
        button.js (compiled)
    @my-scope/my-app/
      index.js -> (symlink) ../../my-app/dist/index.ts
      my-app.js -> (symlink) ../../my-app/my-app.ts
      dist/
        index.js (compiled)
        my-app.js (compiled)

There is no structural distinction between libraries and apps in a composable codebase. Each Bit component can be consumed by other Bit components and can consume other Bit components, regardless of their type.

This greatly simplifies your project maintenance and management. You can easily understand the relationship between components, manage dependencies, and ensure consistency across the codebase.

Furthermore, every piece of functionality in your codebase (not just utility functions and basic UI elements) is a standalone entity that can be shared, versioned, and updated independently. And the best thing is that it doesn't require additional overhead or complexity. Your code is just "naturally" shareable, reusable, and even portable.

Common issues and challenges for code sharing and reusing are no longer a concern, as Bit takes care of it all, including: dependencies, documentation, build, test, versioning, and even CI/CD.

Decentralized codebase: improving team autonomy and codebase flexibility

A decentralized codebase is one that is not managed in a single repository but is distributed across multiple repositories or even none at all. As mentioned in the table above, when working with Bit components, you decide their source of truth. It can be a project-level repository hosted on a platform like GitHub, GitLab, or Bitbucket, or individual components hosted on the Bit platform.

Depending on your team’s workflow structure, you can choose the source of truth: either the Bit scopes where components are hosted or the project repositories where they are maintained. Choosing the Bit scopes as the source of truth allows you to manage your codebase with fine-grained access-control and build setup, over each component and unparalleled flexibility in managing your codebase.

Repositories can be created and destroyed, components can be moved around, and you can decide where they should be maintained based on your team's or ogranization's workflow and the project's requirements.

Designing Your Codebase for Optimized AI-Driven Development

Eden Ella — Tue, 23 Jul 2024 12:46:17 +0000

AI-driven software development leverages artificial intelligence to automate various stages of the software development lifecycle, such as automating code reviews and generating code. This enables developers to deliver software more quickly and efficiently.

While AI-driven software development offers many benefits, including faster code writing and improved code quality, it also has its drawbacks. It can introduce inconsistencies in development standards and practices, leading to code that is difficult to read, maintain, and debug.

If left unchecked, these inconsistencies can degrade software quality and negatively impact the user experience. To address these risks, developers limit the use of AI and ensure it operates under human supervision.

To further ensure quality, developers use additional tools and practices like fine-tuning large language models (LLMs) to a specific codebase and employing utility-based AI agents. These measures help ensure that AI-generated code aligns with the existing codebase and meets quality standards.

Recently, Bit Platform launched an AI assistant named “Hope AI.” This assistant helps developers generate new Bit components, edit existing ones, test and document components, and create change requests (similar to pull requests in Bit). This facilitates more effective collaboration among developers and helps them understand the impacts of their changes on the overall codebase.

Hope AI enhances your codebase's organization, efficiency, and consistency by reusing existing components. This reduces the risk of inconsistencies and prevents the code from becoming bloated and difficult to manage.

A decentralized codebase consisting of small, reusable components with clear interfaces, dependencies, and responsibilities provides an ideal platform for effective collaboration among humans and between humans and AI.

Like human developers, AI agents perform better when working with smaller, more focused components. Breaking tasks into smaller, manageable parts makes them easier to formulate and understand. The results are more accurate and reliable when tasks are executed modularly and incrementally, using existing components as building blocks whenever possible.

Learn More

Bit. Composable software platform.

A complete development platform for innovative teams, building composable software products.

bit.cloud

Building Composable JavaScript Software: Tips and Tricks | by Eden Ella | Bits and Pieces

How to create composable systems using standardized, independent, and well-documented components of different granularity levels

blog.bitsrc.io

3 Principles for Component-Driven Development, Modular Design and Modular Architecture | by Eden Ella | Medium | Bits and Pieces

Principles and methodologies of software composition using independent Bit components.

blog.bitsrc.io

Module Federation: Building a Micro Frontends Solution in 2024

Eden Ella — Wed, 03 Jul 2024 19:01:10 +0000

In this blog, we’ll use Module Federation and Bit to implement a runtime integration of Micro Frontends.

We'll cover the following topics:

Using Bit’s templates to generate host applications and remote modules
Managing ModFed shared dependencies as a Bit component
Creating a “plugin system” via shared types that allows remote modules to integrate into the host application in various ways
Running remote modules in development within the context of their host application

The deployed solution

The Bit org that maintains the MFEs solution

The repos maintaining the Bit workspaces for the shared components, host app, and remote modules

Host Apps and Remote Modules

The host app and remote modules were generated using pre-configured templates (made available by Bit):

npx @teambit/bvm install # install Bit
bit init my-modfed-solution # create a new Bit workspace
cd my-modfed-solution

Add the following to your workspace.jsonc to make the ModFed templates available in your workspace:

"teambit.generator/generator": {
    "envs": [
      "frontend.module-federation/envs/mf-react-env"
    ]
  }

Run the following commands:

bit install # install the workspace dependnecies
bit create modfed-remote-mfe storefront # generate a remote module
bit create modfded-remote-mfe blog
bit create modfed-host-app shell-app # generate a host app

Run bit templates to list the available ModFed templates

To list the available apps (and remote modules), run:

bit app list

The output lists the component IDs and their corresponding app names:

┌─────────────────────────────────────────────────┬─────────────────────┐
│ id                                              │ name                │
├─────────────────────────────────────────────────┼─────────────────────┤
│ bit-bazaar.storefront/storefront                │ storefront          │
├─────────────────────────────────────────────────┼─────────────────────┤
│ bit-bazaar.blog/blog                            │ blog                │
├─────────────────────────────────────────────────┼─────────────────────┤
│ bit-bazaar.shell-app/shell-app                  │ shell-app           │
└─────────────────────────────────────────────────┴─────────────────────┘

You can run the apps locally by using their app name:

bit run storefront

Shared Dependencies

Our solution consists of many shared dependencies configured to be excluded from the app bundles and loaded as separate chunks. This is one of ModFed’s strengths. It allows us to optimize our bundle size, maintain consistency, and avoid conflicts between versions of the same module.

Our shared dependencies are maintained as a Bit component shared across projects (the host app and the remote modules). This allows teams to maintain consistency while working independently.

The list of shared dependencies consists primarily of runtime libs and a design system:

The ‘shared dependencies’ component (which lists the shred deps) is used by the host app config and remote modules config

https://bit.cloud/bit-bazaar/shell-app/shared-dependencies/~code/shared-dependencies.ts

For example:

/**
 * @filename: storefront.bit-app.ts
 * @component-id: bit-bazaar.storefront/storefront
*/

import { MfReact } from '@frontend/module-federation.react.apps-types.mf-rspack';
/* import the 'shared dependnecies' components */
import { shellAppSharedDependencies } from '@bit-bazaar/shell-app.shared-dependencies';


export default MfReact.from({
  name: 'storefront',
  clientRoot: './storefront.app-root.js',
  moduleFederation: {
    exposes: {
      // ...
    },
    shared: shellAppSharedDependencies,
  }
});

A Shared Design System

Our component library and theme are based on Material UI. They are maintained in the “design” scope and shared across Micro Frontends.

The “design” scope which contains the shared UI components and themes

Shared Context

The ‘Theme Provider,’ ‘Auth Provider,’ and other context components are part of the “host app” or “shell app.” As such, they are maintained by the “shell app” team.

The context for all MFEs (provided by the shell app)

Teams working on MFEs do not need to bother with authentication, authorization, or any other shared functionality. The “host” or “shell” team provides it all to them.

For example, if team Storefront needs to implement functionality based on the user auth, they would explore the ‘shell app’ scope and look for the proper “SDK”.

The “auth” context and hook

Routing and Navigation

The shell app provides a sort of “plugin system” where Micro Frontends (remote modules) can integrate into it in ways that go beyond a simple link. It does so by providing the types for each “plugin”.

The shared “navigation item” type

For example, a remote module can implement a “navigation item” interface that includes its navigation options.

This can then be exposed for the shell app (which will load it at runtime):

/**
 * @filename: blog.bit-app.ts
 * @component-id: bit-bazaar.blog/blog
*/

export default MfReact.from({
  name: 'blog',
  clientRoot: './blog.app-root.js',
  moduleFederation: {
    exposes: {
      /** 
       * the MFE navigation exposed to be loaded 
       * by the shell app at runtime
       **/
      './blognav': './navitem.js',
       /**
        * the main chunk of the 'blog' MFE
        **/
      './blog': './blog.js',
    },
    shared: shellAppSharedDependencies,
  },
  deploy: Netlify.deploy(netlifyConfig),
});

The routing is handled at the level that suits the module. For example, the shell app only handles routing to /blog/* and /storefront/*. It does not determine the routing “inside” each MFE (such as storefront/products).

/**
 * @filename: shell-app.tsx
 * @component-id: bit-bazaar.shell-app/shell-app
*/

export function ShellApp() {
  return (
    <BrowserRouter>
          <Routes>
            <Route path="/" element={<Layout />}>
              <Route index element={<Homepage />} />
              <Route path="store/*" element={<Store />} />
              <Route path="blog/*" element={<Blog />} />
              <Route path="*" element={<div>Not Found</div>} />
            </Route>
          </Routes>
    </BrowserRouter>
  );

Accordingly, remote modules, such as the blog, are not responsible for the /blog/* routing (the routing to the blog MFE)—only for nested routes.

/**
 * @filename: blog.tsx
 * @component-id: bit-bazaar.blog/blog
*/

export function Blog() {
  return (
      <Routes>
        <Route path="articles" element={<ArticlesPage />} />
        <Route path="categories" element={<CategoriesPage />} />
      </Routes>
  );
}

DevX

For the ultimate dev experience, each team uses a “Platform” component to consume an immutable version of the shell app and possibly other remote modules.

This provides the MFEs with the proper context to run in development. It ensures a consistent and seamless dev experience while properly enforcing permissions and access control (e.g., the 'blog' team cannot modify the 'storefront' MFE or the shell app).

https://bit.cloud/bit-bazaar/storefront/storefront-platform/~code/shell-platform.bit-app.ts

The 'shell-app' as an immutable dependency of the ‘storefront-platform’ used by the ‘storefront’ team for ‘storefront’ development in full context

For example, the ‘storefront’ team are able to run the ‘storefront’ MFE in its full context (shell app and even other MFEs) by running the 'platform' app maintained by them (for development only):

bit run storefront-platform

You can generate a 'Platform' component using the template provided by the ModFed env (the one configured as a generator at the beginning of this blog):

bit create modfed-platform my-platform

Composable Backend-for-Frontend

Eden Ella — Wed, 15 May 2024 18:12:14 +0000

The Backend-for-Frontend (BFF) pattern is an architectural approach where a dedicated backend service is created for each frontend application or client type.

Utilizing the BFF pattern allows developers to tailor the APIs and backend services to the specific requirements of each client. This can result in improved performance, better security controls, and a more cohesive user experience.

For the BFF architecture to be effective and sustainable, it has to be composable. BFFs should be assembled using loosely coupled, interoperable components that can be easily combined, reused, or replaced.

A "BFF component" in a composable system is a standardized abstract layer for specific technical tasks or services built in-house or bought from different vendors.

Components in this system should adhere to "rules of communication" agreed upon across teams to make them easily pluggable into the wider system architecture.

A well-designed system of "BFF components" facilitates innovation and allows businesses to quickly respond to new opportunities or threats.

In this article, we’ll explore Bit Harmony, an innovative framework for the composition of full-stack components using smart dependency injection. The platform uses Bit components as its building blocks.

Visit the "LazyWorks Inc." Bit organization to see a demo of this approach.

Aspects

An aspect is the building block of a Harmony solution. It is a full-stack Bit component that provides UI and backend “services” for other aspects.

An aspect represents a single feature that can be plugged into a larger system to form a full solution, a new application.

Aspects extend other aspects by registering to their ‘slot’ API. This inversion of control allows teams to compose features with minimal overhead since the aspect is responsible for the integration, not the system that composes it.

For example, the following Harmony app is an online shop for lazy living. The team responsible for that online store decided to add a blog to their site. After searching for a suitable aspect on the Bit platform, they came across this Contentful-based Blog aspect. Deciding they wanted to use it, they added it to their Hamrony application:



/**
 * @coponentId: lazyworks.no-sweat-shop/no-sweat-shop
 * @filename: no-sweat-shop.bit-app.ts
 */ 

// imports...

/**
 * The "LazyWorks Platform" defines how an 
 * aspect can integrate into the system 
 * (i,e, register new routes, 
 * extend the GraphQL schema, etc) 
 */
import { LazyworksPlatformAspect } from '@lazyworks/platform.lazyworks-platform';
import { NoSweatShopPlatformAspect } from '@lazyworks/no-sweat-shop.no-sweat-shop-platform';
import { BlogAspect } from '@lazyworks/blog.blog';

export const NoSweatShop = HarmonyPlatform.from({
  name: 'no-sweat-shop',
  platform: [
   /**
    * aspects register themselves to the 'platform' aspect which
    * is the entry point for this application
    */
    LazyworksPlatformAspect,
    {
      name: "No Sweat Shop",
      slogan: "Effortless Living, Delivered.",
      domain: "no-sweat-shop.com",
      logo: "https://static.bit.dev/extensions-icons/my-project.svg",
    },
  ],
  /**
    * aspects can run in multiple runtime environments. here, aspects 
    * provide functionalities to the NodeJS services and the web frontend apps
   */
  runtimes: [new BrowserRuntime(), new NodeJSRuntime()],

  aspects: [
    /* 'no sweat shop' aspect extends the system with its 
     * own unique functionalities. this aspect is maintained by 
     * a team that composes the aspects for their own solution.
     */
    NoSweatShopPlatformAspect,
    /**
     * the blog aspect extends the system with content 
     * management capabilities.
     */
    [
      BlogAspect,
      {
       /**
         * the blog aspect also provides a config API for this app to use
         * in this case, since the blog uses the Contentful platform,
         * the team needs to provide it with their own Contentful space ID
         */        
        spaceId: 'contentful-spaceId',
      },
    ],
  ],
});

export default NoSweatShop;

The Blog aspect registers itself to the platform in several ways:

It extends the system’s GraphQL schema with a node for content retrieval. This is done in the NodeJS Runtime.
It extends the system’s routing with the /blog route. This is done in the Browser Runtime.
It extends the header with an additional item a ‘Blog’ link to /blog . This is done in the Browser Runtime.

Note that the UI provided by the aspects is optional. In some cases, depending on the type of application the BFF is serving, the browser-runtime features might not be used

NodeJS Runtime



/**
 * @coponentId: lazyworks.blog/blog
 * @filename: blog.node.runtime.ts
 */

export class BlogNode {
  constructor(private config: BlogConfig) {}

  async getBlogPosts() {
    const blogData = new BlogData(this.config);
    return blogData.getBlogPosts();
  }

  static dependencies = [LazyworksPlatformAspect];

  static async provider(
    [lazyworksPlatform]: [LazyworksPlatformAspect],
    config: BlogConfig
  ) {
    const blog = new BlogNode(config);
    const gqlSchema = blogGqlSchema(blog);

    lazyworksPlatform.registerBackendServer([
      {
        gql: gqlSchema,
      },
    ]);

    return blog;
  }
}

export default BlogNode

Browser Runtime



/**
 * @coponentId: lazyworks.blog/blog
 * @filename: blog.browser.runtime.ts
 */


export class BlogBrowser {
  constructor(private config: BlogConfig) {}

  static dependencies = [LazyworksPlatformAspect, HeaderAspect];

  static async provider(
    [lazyworksPlatform, header]: [LazyworksPlatformBrowser, HeaderBrowser],
    config: BlogConfig
  ) {
    const blog = new BlogBrowser(config);

    lazyworksPlatform.registerRoute([
      {
        path: '/blog',
        component: () => {
          return (
            <ApolloBlogProvider spaceId={config.spaceId}>
              <BlogLobby />
            </ApolloBlogProvider>
          );
        },
      },
    ]);

    header.registerLink([{ label: 'Blog', href: '/blog' }]);

    return blog;
  }
}

export default BlogBrowser;

To learn more, visit Bit's documentation site or the Bit Platform.

Theming using CSS Variables? Turn Them into VS Code Snippets for Faster, Error-Free Coding

Eden Ella — Sun, 14 Apr 2024 13:34:12 +0000

Styling using native CSS (or pre-processor languages compiled to CSS) can be great as it offers better performance than JavaScript-based solutions.

In addition, CSS is as “universal” as it gets. You won’t waste your time learning framework-specific styling solutions that might become obsolete or fall out of favor, leading to costly refactoring later on.

Having said that, some aspects of the dev experience are vastly improved when using CSS-in-JS libraries or frameworks, mainly type support and IntelliSense.

One place where CSS is lacking the most is when using CSS vars (or custom props) to theme your UI components. In this scenario, the CSS props are often not included in the CSS file used to style the components but are instead defined elsewhere. This can become problematic when working with teams or large codebases, as the lack of direct visibility of variable definitions can lead to confusion and inconsistency.

To help solve this issue, we can use various tools such as VSCode extensions, ESLint plugins, and a number of other solutions. However, I’d like to offer another tool to the mix: generating VS Code Snippets based on the design tokens or theme specifications your team uses.

These code snippets are a great way to improve our dev experience. They can list the available CSS variables and even provide instructions on how and when to use them.

Our demo solution was built using Bit, which allows us to create shareable components, render component “previews,” generate component docs, and so on.

Our solution consists of four Bit components:

Design tokens: This component holds the list of tokens for our design system
My Theme: The theme component "feeds" this theme generator with the design tokens and their default values
My React Env: A reusable React development environment that will auto-generate the snippet file when a themed Bit component is created or imported into the workspace. Reusable dev environments provide the tooling for Bit components (build pipeline, compilers, test runners, linters, etc). To complement this with proper IDE support, these dev environments also auto-generate the relevant config files for the IDE to read. I've used this feature to auto-generate the code snippets file.
My Button: The themeable UI component we'll build in this blog to test our entire setup.

Theming a component with the entire solution in place

To create new Bit components using the reusable development environment from before, we’ll add it to the workspace.json:

/** @filename: workspace.jsonc */

{
 "teambit.generator/generator": {
    "envs": [
       "learnbit.style-snippets/dev/my-react-env",
    ]
  },
}

Now we can use the component templates offered by that env:

bit create react my-button

A new component directory with the pre-configured files was created.

└── my-button
    ├── index.ts <-- component main file
    ├── my-button.composition.tsx <-- component "previews" (isolated renders)
    ├── my-button.docs.mdx <-- component documentation
    ├── my-button.module.scss <-- component styles
    ├── my-button.spec.tsx <-- component tests
    └── my-button.tsx

In addition to that, since our component uses the reusable dev environment, a code snippet file was auto-generated for it at the root of the workspace:

/** @filename: .vscode/scss.code-snippets */

{
  "--primary-color-background": {
    "prefix": "--primary-color-background",
    "body": [
      "var(--primary-color-background, #568cb0)"
    ],
    "description": "Use this color as the background for key UI elements that need to stand out. It should be used to promote actions or areas of importance."
  },
  "--primary-color-text": {
    "prefix": "--primary-color-text",
    "body": [
      "var(--primary-color-text, #ebebeb)"
    ],
    "description": "Use this color as the text color for key UI elements that need to stand out."
  }
}

Now, when we create styles for our components, we’ll be able to search for the custom CSS props that we need:

To complete our UI component, we’ll create a preview for it using our theme:

/** @filename: my-button/my-button.composition.tsx */

import { MyTheme } from '@learnbit/style-snippets.my-theme';
import { MyButton } from './my-button.js';

export const BasicMyButton = () => {
  return (
    <MyTheme.ThemeProvider>
      <MyButton>hello world!</MyButton>
    </MyTheme.ThemeProvider>
  );
};

If we head over to Bit UI, we can see the button’s preview:

Sharing components

To share our components, we’ll create a new version of them and export them to Bit Platorm:

bit tag -m "new version"
bit export

The components are built on Ripple CI, the CI system for components, offered by the Bit Platform:

As you can see, Ripple CI builds each component indepndently. Once a Bit component is built, the CI propagates to its dependents. When Bit components are siblings (one is not dependent on the other) Ripple builds them in parallel, to optimize the build’s performance.

Once the build is over, the Bit components are available on Bit Cloud.

UI Libraries are Dying: What’s Next?

Eden Ella — Wed, 03 Apr 2024 16:49:42 +0000

UI libraries are a collection of UI components, styles, and utilities packaged and published to be reused in applications. They help maintain consistency in and across apps, speed up development and make code more maintainable.

UI libraries come with their own set of challenges, which greatly limit their effectiveness. These challenges stem from more fundamental problems related to code sharing and reuse. Let’s explore some of these challenges and examine how a new entity, the Bit component, addresses them.

What Is a Bit Component?

A Bit component can be thought of as a next-generation package. Its build setup, tooling and even version control are all encapsulated within the component itself. Bit components are hosted on bit.cloud, grouped by scopes with different access controls. That means a Bit component is not tied to any git repository. You can import (clone) it into your development environment, modify it and push it back to bit.cloud.

When components are released they go through a build process that generates artifacts. One important artifact is the component’s package. A component can be installed as a regular Node package or, as mentioned earlier, imported (cloned) into your project where it can be updated.

For example, to modify a component, we’ll first search for it on bit.cloud:

We’ll run the following to import it into our project:



bit import bitdesign.sparks/actions/button

The imported component is now available as source files to modify and a package to consume. Bit automatically updates the package on every change.



.
└── my-project
   └── sparks
    └── button
        ├── button.tsx
                └── index.ts
└── node_modules
    └── @bitdesign/sparks.actions.button

Once our changes are made, we can create a new version of the component and push it back to bit.cloud:



bit tag --message "use lighter color tokens"
bit export

Our button component is now available with a new version on bit.cloud. We can keep maintaining it, or we can remove it from our project while keeping only the package for consumption.

Making Your UI Components Reusable and Portable Is Hard

Sharing individual UI components as packages takes too much effort. Decoupling the component from the project, making sure it is generic or “reusable enough,” configuring its package.json, documenting, versioning and publishing can be a hassle.

This is more evident when it comes to complex components like forms and full-page layouts. These components often remain “hidden” in repositories and unshared, forcing others to build them from scratch, which is time-consuming, leaves room for errors and makes the code base more difficult to maintain.

As you’ll see in the next section, limited collaboration is also a factor in this problem. Package consumers are not able to modify and extend components to address new needs as they arise. By following this iterative process, concrete components are made more generic and reusable.

Closely related to this issue is the common practice of creating “mega-libraries” that contain a large number of components. This is another symptom of the same problem: Sharing individual components as packages is not easy.

Bit Makes Sharing Individual Components Simple and Easy

Teams are more inclined to share components when the process is easy, and equally, they are more prone to reuse components when they are easy to find. Bit makes sharing components easy. Bit components require no configuration. Their dependencies are automatically detected and intelligently resolved to the proper versions and types.

Bit also auto-generates the component documentation and makes it simple to render component previews.

As mentioned earlier, package publishing is an integral part of a component’s build pipeline. When a component is versioned and released, its package gets automatically published to bit.cloud’s registry (and possibly to a registry of your choice), where it can be discovered and installed by others.

Individually packaged components allow the consumers to pick and choose the components they need and avoid meaningless updates to their project’s dependencies.

UI Libraries Limit Collaboration

Component libraries are built to enforce consistency in UI/UX and development standards. This is a good thing; however, it can also become a challenge if the library is not flexible enough to address the project’s needs. When that happens, the team is forced to work around the library, fork it and maintain their own version, or suggest a pull request (PR) to the library maintainers and wait for it to be merged and released.

This can often lead to poor library adoption, which beats the purpose of having a library in the first place.

Bit Components Promote Cross-Team Collaboration

Since Bit components are autonomous, they canbe developed and maintained anywhere. That means that teams consuming a component can also contribute to it without having to come up with various workarounds or switching from one repository to another.

Components can be modified and improved instantly from any consuming project, while the maintainers can review and merge the changes at their own pace.

Changes are immediately available in that project, and they can be reviewed, tested and merged at the maintainers’ own pace.

A Future Beyond Libraries: Fully Component-Based Projects

With Bit, the traditional concept of separate UI libraries, or libraries in general, may soon become obsolete. The natural composition from “library” to more complex components can be achieved using the same structure and tooling without the need to distinguish between “library code” and “application code.”

This shift toward a more integrated and flexible approach to code reuse and package management heralds a new era in software development. The boundaries between libraries and applications blur, leading to more efficient, maintainable and collaborative development practices.

As we move forward, the focus will likely shift from using and contributing to standalone UI libraries to creating and sharing Bit components in a more dynamic, interconnected ecosystem.

This evolution promises to make software development more modular, scalable and inclusive, paving the way for a future where developers can easily build upon each other’s work, leading to faster innovation and more robust applications.

Micro Frontends with Vite and Bit

Eden Ella — Wed, 13 Mar 2024 11:35:17 +0000

In this tutorial, you'll learn the steps to create a micro frontend application leveraging the capabilities of Vite, Bit, and the modern browser.

Our Micro Frontend applications (MFEs) and their shared dependencies will be bundled into ES Modules.

In development, our MFEs and shared dependencies will be loaded from our local workspace. This allows us to develop and test the MFEs locally without having to deploy them.

In production, our MFEs will be loaded (in runtime) from their remote entry point according to the import map in the host app's index.html. For example:



<script type="importmap">
{
  "imports": {
    "react": "https://esm.sh/react@18.2.0",
    "@learnbit/react-es-mfe.my-mfe": "https://bit-react-esm-mfe.netlify.app/v0.0.1.js"
  }
}
</script>

Our micro frontend solution will consist of three Bit components:

A micro frontend: An app bundled as an ESM library that can be imported and rendered by the host app (at runtime).
A remote module list: A list of shared modules and micro frontends consumed at runtime by our host app and micro frontend.
A host app: A container application that imports and renders the micro frontends.

The dependency graph of our solution. The host application and the micro frontend both share the list of remote modules (to be excluded from their bundles and imported dynamically).

In this project, we'll use Bit to manage different parts of our solution as Bit components. We'll share the components on bit.cloud and deploy the apps (also Bit components) to their respective hosting services.

Explore this project by:

Reviewing the Bit components in their remote scope on bit.cloud
Forking (copying) the entire solution to your Bit workspace by running bit scope fork learnbit.react-es-mfe YOUR_ACCOUNT_AND_SCOPE_NAME (use your bit.cloud account and scope name)
Visiting the deployed application

Creating the micro frontend

To get started with our project, we'll create a new Bit workspace (replace my-account.my-scope with your own bit.cloud account and scope name):



bit new basic my-workspace --default-scope my-account.my-scope
cd my-workspace

Since our solution is entirely component-based, our host app and micro frontend will also be maintained as independent Bit components.

To create a new React Vite app, we'll use Bit's out-of-the-box component template for React Vite apps:



bit create react-app my-mfe

See the micro frontend component in its scope

To make our MFE dynamically loadable as an ES Module, we'll configure Vite to build it as a library with the 'es' format.

We'll do this by adding the necessary configuration to the vite.config.js file at the root of our component's directory:



import { defineConfig } from 'vite';
import reactPlugin from '@vitejs/plugin-react';
import cssInjectedByJsPlugin from 'vite-plugin-css-injected-by-js';
import { myRemoteModules } from '@learnbit/react-es-mfe.remote-modules';

export default defineConfig({
  plugins: [
    reactPlugin({
      jsxRuntime: 'classic', // it's easier to exclude react from the bundle when not using the new jsx runtime
    }),
    cssInjectedByJsPlugin(), // this is to inject this MFE's CSS, when it is loaded
  ],
  define: {
    'process.env': '{}', // this is to avoid 'process is undefined' error in the browser
  },
  build: {
    lib: {
      formats: ['es'],
      entry: './my-mfe.tsx',
      fileName: 'v0.0.1', // it's recommended to use a version for each MFE deployment
    },
    rollupOptions: {
      external: myRemoteModules.listModules(), // the remote modules to exclude from the bundle
    },
  },
});

The remote modules component, used by this config, contains a list of modules to be loaded dynamically at runtime, and to be excluded from the MFE and host app bundles. This list contains shared dependencies like react, as well as micro frontends.

We'll also exclude shared dependencies from our MFE's bundle to keep our bundles small and avoid duplications.

Bit components are configured as "app components" when they include a *.bit-app.ts file in their component directory. This file configures the app's build and deployment. In this example, we'll deploy our app components (the MFE and host app) to Netlify.

Since this is an app, we can run it locally using the bit run command:



bit run my-mfe

Run bit app list to list the apps available in your workspace

Creating the remote modules mapping

As mentioned earlier, our MFEs and host app will use a (shared) Bit component to manage the list of modules to be loaded dynamically at runtime.

We'll create a new Bit component to manage this list. This time, we'll use Bit's out-of-the-box component template for a simple Node.js module:



bit create node my-remote-modules

See the remote module component in its scope

Our list of modules will include the shared dependencies and the MFEs. In this example, we'll include react and the previously created MFE.



import { RemoteModules } from './remote-modules.js';

export const myRemoteModules = new RemoteModules([
  {
    name: 'react',
    path: 'https://esm.sh/react@18.2.0',
  },
  {
    name: '@learnbit/react-es-mfe.my-mfe',
    path: 'https://bit-react-esm-mfe.netlify.app/v0.0.1.js', // the MFE's URL as defined by its bit-app.ts file.
  },
]);

Creating the host app

To create our host application, we'll, again, use Bit's out-of-the-box component template for a React Vite app:



bit create react-app my-host-app

See the host application component in its remote scope

Our host app will be built as a regular Vite app. However, since it should dynamically load the MFEs, we'll need to configure it to exclude shared dependencies and MFEs from its bundle.
We'll, also inject an import map to the HTML file, to instruct the browser on how to resolve imports at runtime.



import { defineConfig } from 'vite';
import reactPlugin from '@vitejs/plugin-react';
import { myRemoteModules } from '@learnbit/react-es-mfe.remote-modules'; // the remote modules list
import importMapPlugin from '@learnbit/react-es-mfe.vite-import-map-plugin'; // a custom Vite plugin to inject the import map

export default defineConfig({
  plugins: [reactPlugin(), 
// inject the import map (from the remote-modules component)
importMapPlugin(myRemoteModules.createImportMap())], 
  build: {
    rollupOptions: {
      // exclude remote modules from the app's bundle
      external: myRemoteModules.listModules(),
    },
  },
});

The custom plugin used by the host app replaces the <--importmaps--> placeholder in the HTML file with the import map generated by the remote modules list.

To run the host app locally, we can use the bit run command:



bit run my-host-app

In development, our host app will consume the MFEs from the local node_modules directory in the workspace, and will not load them from their deployed URLs (as it would in production).

This allows us to develop and test the MFEs locally, without having to deploy them (when Bit components are maintained locally, they are symlinked from their source directory to the node_modules directory. Otherwise, they are installed from the registry).

Sharing the components and deploying the apps

Run the following to build your components, export (push) them to their remote scope on bit.cloud, and deploy the app components to their hosting (as configured in the .bit-app.ts file of each app component):



bit tag -m "first version"
bit export

The components will be built on bit.cloud. Once the build is over, the components will be available in their remote scope (the remote scope was configured at the beginning of this tutorial when we initialized a new Bit workspace with the --default-scope property).

Explore the components in their scope on bit.cloud

Implementing a Service Oriented Architecture in 2024

Eden Ella — Mon, 12 Feb 2024 10:36:58 +0000

The advantages of microservices can generally be categorized into two groups: technological and human-centric. Within the human-centric category, the benefits relate to how we work and collaborate.

Teams working on microservices have full ownership over parts of the system. They can work independently, choose their own stack, and deploy their services independently and in parallel to other teams.

In addition to that, although microservices as a system can become more complex, individual services are simpler and easier to understand and maintain.

This sort of “reverse Conway’s Law,” where the system’s architecture influences the organizational structure, is a key benefit of microservices that can also be found in other types of distributed systems.

How can we make our system more distributed and composable to get more of the same benefits?

In this article, we’ll look at Bit as a tool that allows us to compose systems from independent components of all levels of granularity, from simple utility functions to microservices and, ultimately, to entire systems.

Bit: A next-generation build system for composable software.

We’ll see how Bit components can be shared and reused across microservices, how microservices can be maintained as Bit components, and how they can be composed in runtime using an API gateway component.

Building a composable system

To better understand how Bit can be used to compose microservices, let’s start by creating a new workspace with a few Bit components:



bit new react my-project --env bitdev.react/react-env --default-scope my-org.my-project



cd my-project

Your new workspace has seven components. Run bit start to explore your components using Bit’s UI:

To run the system, run:



bit run my-project

The output should list several different processes listening on different ports. Two microservices, discussion-server and user-server, an API gateway, and a frontend application:



[discussions-server]: running on port 5003
[user-server]: running on port 5002
[HPM] Proxy created: /  -> http://localhost:5002/graphql
[HPM] Proxy rewrite rule created: "/user-server/" ~> "/"
[HPM] Proxy created: /  -> http://localhost:5003/graphql
[HPM] Proxy rewrite rule created: "/discussions-server/" ~> "/"
backend server running on 5001
frontend server running on 3001

This runtime composition of different services, both locally and remotely, is done using the platform component. It is another Bit component whose role is to serve as the entry point for this system:



import { Platform } from '@bitdev/platforms.platform';

const UserServer = import.meta.resolve('@bitdev/node.examples.user-server');
const DiscussionServer = import.meta.resolve('@my-org/discussions.discussions-server');
const AcmeWeb = import.meta.resolve('@my-org/my-project.my-platform-project-web');
const PlatformGateway = import.meta.resolve('@bitdev/symphony.backends.gateway-server');

export const MyPlatformProjectPlatform = Platform.from({
  name: 'my-platform-project-platform',

  frontends: {
    /** main frontend application for the platform */
    main: AcmeWeb,
  },

  backends: {
    /**
     * use an api gateway component.
     * supports proxy of graphql and restful requests.
     */
    main: PlatformGateway,
    services: [
      /** compose micro-service components. */
      UserServer,
      DiscussionServer
    ]
  },
});

Note that not all Bit components need to be maintained locally. A composition of services can include remote services that are not available locally. This is tremendously helpful for local and remote testing of services in the context of the entire system.

To learn more, see the Platforms documentation.

Also, note that the API Gateway can be implemented in whatever way suits your needs. To explore the one used by this example, see:

Build-time or runtime integration? The choice is yours!

One thing that is immediately apparent when reviewing the Bit components in your workspace is just how different they can be. UI and non-UI, Node and React, small and large.

However, in the context of this article, the most important distinction is whether they are “app components” or not. App components are components that are available for consumption as Node packages, just like “regular” Bit components, but are also deployable and available for runtime compositions.

For example, our discussion-server Bit component runs as a separate process. Looking at its implementation, we can find one file that sets it apart from other components: the .bit-app.ts file.



/** @filename: discussion-server.bit-app.ts */

import { NodeApp } from '@bitdev/node.node-app';

export default NodeApp.from({
  name: 'discussions-server',
  artifactName: 'discussion-service',
  mainPath: import.meta.resolve('./discussions-server.app-root.js'),
  /** 
   * an optional deploy function for this app component -
   * to be executed when a new version of this compoennt is released
   */
  // deploy: () => {}
});

With Bit components, you’re always building and delivering independently.

You can enjoy the benefits of a composable and distributable system, regardless of how (and when) components are being integrated. This gives you the freedom to construct a system that perfectly balances your human or organizational needs with technological requirements.

For example, you might want more than one team to maintain different aspects of a microservice. You can split the microservice into several microservices, but that’s not always the best solution when taking into consideration your system’s performance. It might be that build-time integration of independently delivered Bit componetns is a better choice.

A symmetry between dependencies in dev and prod

One benefit of this style of composition of Bit components is that it provides you with a clear dependency graph that includes components composed in runtime. This can be tremendously helpful in understanding complex systems and in maintaining them.

As mentioned earlier, with Bit your system’s composition is a hybrid of services integrated in runtime and packages integrated in build time. Zooming out a bit further will reveal some of the Bit components used to compose this services:

Reusing Bit components: faster development and better standardization

Bit components can be maintained, released, and installed from any project. That makes them an excellent tool for reusing code and standardizing the development process across separate projects.

The ‘discussion’ entity component as an example

For example, your workspace has an entity component called discussion. The discussion component provides the data modeling and a set of operations that can be utilized by any microservice or frontend application that handles discussion data within your system.

It is a contract between services that outlines the structure and rules of engagement for discussions, ensuring consistency and reducing the duplication of effort when developing new features that interact with discussions.

Furthermore, by using Bit’s versioning system, developers can easily upgrade to new versions of the discussion component as it evolves while maintaining compatibility across the services that depend on it.

DEV Community: Eden Ella

Micro Frontends: Enabling Scalable and Autonomous Development with Build-Time Integration

Implementing Build-Time MFE Integration with Bit

1. Setting Up Bit Scopes and Git Repositories

Repository Structure:

2. Creating the App Shell and Integration Components

1. A Subscriber Component (Bit)

2. The Application (Non-Bit Component)

3. Implementing the MFEs

4. Automating Deployment with Webhooks

Conclusion

AI Coding Assistants, Starter Templates, and More: A Guide to Working Less

Project Templates and AI Coding Assistants

Infrastructure-as-Code and AI Coding Assistants

Self-hosted UI libraries and AI Coding Assistants

Composable Codebase and AI Coding Assistant

Conclusion

Sharing UI Components: Copy VS Install

Why Copying Wins for Complex Components

Bit Components: Packages that you can directly edit

Choice 1: Composing with Design System Components

Choice 2: Utilizing Block Components

Ejecting dependencies’ source files

Related Articles

Manage Your Shared Components and Modules in The Cloud

1. Set up a Bit Platform account

2. Create an access-controlled scope to store your shared components

3. Start a new Bit Cloud Workspace

4. Create a new component

5. Tag the component with a new release version and store it in the scope

6. Install the component in a project

Learn More

Monorepo VS Polyrepo

A solution that combines the best of both worlds

Composable codebase: maximizing code reuse and simplifying project maintenance

Decentralized codebase: improving team autonomy and codebase flexibility

Designing Your Codebase for Optimized AI-Driven Development

Learn More

Module Federation: Building a Micro Frontends Solution in 2024

Host Apps and Remote Modules

Shared Dependencies

A Shared Design System

Shared Context

Routing and Navigation

DevX

Composable Backend-for-Frontend

Aspects

NodeJS Runtime

Browser Runtime

To learn more, visit Bit's documentation site or the Bit Platform.

Theming using CSS Variables? Turn Them into VS Code Snippets for Faster, Error-Free Coding

Theming a component with the entire solution in place

Sharing components

UI Libraries are Dying: What’s Next?

What Is a Bit Component?

Making Your UI Components Reusable and Portable Is Hard

Bit Makes Sharing Individual Components Simple and Easy

UI Libraries Limit Collaboration

Bit Components Promote Cross-Team Collaboration

A Future Beyond Libraries: Fully Component-Based Projects

Micro Frontends with Vite and Bit

Creating the micro frontend

Creating the remote modules mapping

Creating the host app

Sharing the components and deploying the apps

Implementing a Service Oriented Architecture in 2024

How can we make our system more distributed and composable to get more of the same benefits?

Building a composable system

Build-time or runtime integration? The choice is yours!

A symmetry between dependencies in dev and prod

Reusing Bit components: faster development and better standardization

The ‘discussion’ entity component as an example