DEV Community: Bit

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

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.

Composable Software Architectures are Trending: Here’s Why

Ashan Fernando — Tue, 19 Mar 2024 11:11:18 +0000

The progression from monolithic applications to composable architecture marks a significant leap in building highly scalable and maintainable software applications. This evolution crossed different milestones in its path.

The Era of Monolithic Applications

Historically, software systems were predominantly monolithic. In these systems, various components, including the user interface, business logic, and data access layers, are tightly integrated within a single codebase. While this approach was straightforward and productive initially, it inevitably led to challenges as applications grew in complexity.

Even a minor modification to the application could necessitate rebuilding, testing, and redeploying the entire application, introducing inefficiency. Additionally, developer efficiency decreases as many developers have to collaborate and handle a broader cognitive load to identify the areas of change and their impact.

The Modular Monolith

Before the widespread adoption of microservices and micro frontends, the modular monolith architectural style emerged as a middle ground between the traditional monolith and the fully distributed microservices.

This approach aims to retain the operational simplicity of the monolith while introducing a level of modularity and separation of concerns typically associated with Microservices. It draws clear boundaries around modules, making development and testing more granular, reducing the cognitive load for development, and thus improving overall productivity.

Yet, the fundamental challenges of a large code base still exist, impacting developer collaboration and efficient use of resources to run the application.

Shift Toward Microservices and Micro Frontends

The advent of Microservices marked a paradigm shift to address many challenges of monolithic architectures at scale. Microservices architecture enabled independent development, testing, and deployment by breaking down applications into smaller, loosely coupled services, each responsible for a specific function and communicating through well-defined interfaces.

Building on the principles of Microservices, the concept of Micro frontends emerged to address similar challenges in the frontend landscape. Microfrontends extend the Microservices paradigm to the frontend, breaking down monolithic frontend codebases into smaller, more manageable pieces.

However, there is a fundamental difference between Microservices and Microfrontends. Microservices are distributed systems where each service has an end-to-end lifecycle and complete autonomy in development and operations. Therefore, it is recommended that each Microservice run on its own process (runtime isolation) and databases (data isolation) and has its own codebase (code isolation), minimizing dependencies across development teams, resulting in less reuse and collaboration.

On the other hand, Micro frontends need a significant level of component reuse to keep UI consistent. It requires either run-time or build-time (preferred) integration before running in the browser.

Microservices and Micro frontends are not suitable for everyone. A startup or a small development team may find it difficult and counter-productive to adapt these architectural styles as they come with overheads in setting up projects and managing operations. Therefore, the cost of adapting these architectures makes sense beyond a certain scale.

Introducing Purely Composable Architecture

Composability involves creating software applications from independent, reusable components, each encapsulating its dependencies and distinct functionality. Then, these components (building blocks) can be combined to build complex applications. It’s a fundamental difference to the way we used to develop software applications.

Since components are smaller, reusable building blocks, the context of change becomes the scope of the components that can be modified and tested independently. The main gap in implementing composable architecture in the past is not having robust tooling to support it. And since some changes may cut across multiple components, robust tooling that aids in modifying components in bulk and testing the dependency chain is required.

The following diagram showcases how bit shows the dependency graph of modified components and their dependents.

And the beauty of this approach is that since it’s so fundamental, you can use it with other architectural styles to address some of their weaknesses. Following are some examples.

You can use components to build your Microservices so that you can start collaborating between teams and share components.
Use app as the shell component to build your Micro frontends, using a remote scope for each team.
Create an Env for each Microservice so that the technology used in each Microservice is independent of one another.

And, since each component has its documentation, clear interfaces, tests, and previews and share these in bit.cloud, collaboration increases at scale across codebases and teams.

And there are many other benefits of implementing a composable architecture;

Enhanced Flexibility: Architecture becomes flexible when adopting different styles and patterns.
Scalability of the development team: Individual components can be scaled as needed, allowing for more efficient resource utilization.
Maintainability: The modular nature of composable architectures simplifies maintenance and updates, as changes are localized to specific components.
Innovation and Speed: Reusable components accelerate development cycles and foster innovation by enabling teams to leverage existing functionalities for new applications and collaborate better.
Better dependency management: Consider a scenario where a UI component library is used across multiple projects within an organization. Bit can manage these components’ dependencies, ensuring that updates do not break functionality in any projects relying on the library.

Summary

The evolution from monolithic applications to composable architectures is redefining the standards for software development. With the support of advanced tools like Bit, the future of software development is set to be more flexible, efficient, and aligned with the dynamic needs of businesses.

As we move forward, composable architectures will undoubtedly continue to shape the future of software development, marking a significant shift towards more adaptable and resilient software systems.

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.

3 Principles for Component-Driven Development

Eden Ella — Tue, 23 Jan 2024 11:40:02 +0000

Bit drives a paradigm shift in the way we structure our software and collaborate on code. Its component-based approach produces more maintainable projects and more effective collaboration. However, the power of Bit is best harnessed when you adopt a certain mindset. This blog aims to guide you through the core principles and methodologies of building software with independent Bit components.

An image of a demo Bit organization working on a developer portfolio site, composed entirely of autonomous components

Principle 1: Build for the present, not for vague future needs

Bit components are easy-to-understand, reusable units of code with transparent dependency graphs. When you build software as a composition of Bit components, you inherently future-proof your codebase without any extra effort.

Interestingly, the most effective way to leverage Bit’s future-proofing capabilities is to focus solely on present needs. This approach not only prevents the wasteful allocation of resources on speculative future requirements but also enforces “dogfooding” or “eating your own dog food”.

By using the components you create, you validate the component’s functionality and reliability, thereby increasing overall confidence in the component’s utility for future projects.

The “building for the present” principle extends beyond just the number of components you build. It also entails limiting your components’ API and functionality to the current needs. Over-engineering a component’s API with features that are not currently needed can lead to a bloated, less maintainable component and, as mentioned above, even less reliable (since it's not fully tested by its maintainer).

Principle 2: Start from the most concrete component

The order of component creation/composition corresponds to the feature’s dependency graph

When rolling out a new feature or app, it’s best to start your development with the most concrete component and then work your way to more generic components.

For instance, if you’re constructing a new form, start by creating the ‘form’ component itself. From there, identify the components it requires. Search for existing ones on bit.cloud and use them in your form. If you can’t find what you need, extend existing components or create new ones.

This process continues recursively until you have all the components you need to compose your feature. For instance, if you can’t find the date picker you need for that form, create it, identify the components it requires, search for existing components, and repeat the process. The “base case” for this recursive process is when you reach the most concrete component that answers your current needs. This approach ensures a focused and efficient development process and promotes the reuse of existing components.

It’s worth noting that components are valuable even when they are not reusable. Concrete, specific components that serve a particular function within a feature or application are equally important. They contribute to the modularity and maintainability of your project, even when they are not reused in other places.

Furthermore, component development is an iterative process. A component that starts as a concrete, specific solution can evolve into a more reusable asset as needs change and grow. Over time, you may find that what began as a highly specialized component has gained features or attributes that make it applicable in a broader context, thereby naturally transitioning from a concrete to a reusable component.

Principle 3: Align component names with business objectives

An image of a demo Bit organization working on a developer portfolio site, composed entirely of autonomous components

Adopting a business-centric mindset is crucial when constructing, naming, and organizing Bit components. Component names should be descriptive and closely aligned with the specific business needs they address. Similarly, components should be organized into scopes in a manner that reflects their business structure and functionality.

This business-oriented naming convention serves multiple purposes. First, it makes the codebase more accessible to all stakeholders, including non-developers such as designers and product managers. This fosters a more inclusive and efficient collaboration, with an increased feedback loop among all team members.

Second, properly-named, business-centric components make component dependency graphs easier to understand, which, in turn, makes it easier to refactor code, identify, and resolve bugs.

Lastly, a business-oriented naming convention makes it easier to find and discover components, which, in turn, promotes component reuse and saves time and resources.

Monorepo, Poly-repo, or No Repo at all?

Eden Ella — Fri, 01 Dec 2023 17:57:05 +0000

Should you go for a monorepo or a poly-repo? Should you use a monorepo solution better suited for managing integrated applications or one better suited for managing libraries and publishing packages?

This blog will explain how Bit can be used to implement any architecture and transform “fatal” decisions that seem too hard to change into decisions that are easy to make and change.

We’ll use the "Bits and Pieces" article submission form as an example project to demonstrate the different approaches.

The article submission form app for guest writers

The project is a simple React app that allows users to submit articles for publication.
The app is composed of components from a curated design system. The form data is sent to a serverless Lambda function that saves the article to a database.
In a poly-repo approach, we might have a repository for each application, the client and the API, and a repository for the design system. In a monorepo, a single repository will maintain all our libs and apps.

In this article, we’ll go from a monorepo handled by Bit:

To a fully distributed codebase that consists of independent Bit components:

Bit in repositories

When using Bit in a repository, we decide to treat the repository as the source of truth for all our Bit components.

In this case, we enjoy many of the benefits Bit offers while minimizing the effect Bit has on our development workflow and existing tools.

We can collaborate using our existing Git workflow and tools to build, test, and deploy our applications and services.

When used as a monorepo solution, Bit provides intelligent and efficient dependency management, insight into our codebase, efficient incremental builds, and an easy way to publish packages.

For instance, see this repository that contains the components used in the article submission form. For simplicity's sake, this example uses only Bit, but remember that Bit can be integrated into any existing repository and used alongside any other monorepo tool.

Try out this monorepo example by cloning the repository:



git clone https://github.com/bitdev-community/bnp-article-submission
cd bnp-article-submission
bit install

Run Bit’s workspace UI to get a visual overview of the components in the project:



bit start

Browse around the components and see how they are connected:

Going from monorepo to multi-repo

As you can see, unlike many traditional monorepo solutions, there is no distinction between “apps” and “libs” in this repository. All the components are managed by Bit and are treated as “packages” with the potential to run independently and be deployed as apps.

The project is composed of components of all levels of complexity. Some components are used in multiple places, and others are only used in one place. All of them are published as packages.

One of the things that enables this is that all components are consumed via an absolute package name rather than a relative path.

For example, the article-submission-form component consumes this schema validator using its package name and not using its relative path in the repo:



/**
* @filename: article-submission-form.tsx
**/

import {
  ArticleSubmission,
  articleSubmissionScheme,
} from '@bits-and-pieces/article-submission.entities.article-submission-scheme';

This allows you to move components around the repository without breaking the code that consumes them. More importantly, it allows you to move components between repositories without breaking the code that consumes them.

For example, say that at a certain point, the publication decides to refactor the project and move some parts of it to separate repositories:

The design team will handle the 'design system’ components in a separate repository.
The frontend dev team will handle the ‘article submission’ client side in a separate repository.
The backend dev team will handle the API for the ‘article submission’ in a separate repository.

The process of moving components between repositories is very simple. All you need to do is export the components you want to move and then import them into the new repository.

For example, the following commands create a new version of the article-submission-scheme component, export it to a remote hosting (“remote scope”), and stops maintaining it in the current repository (i.e., install it as a regular package instead of symlinking to its source files in the project):



bit tag article-submission-scheme
bit export article-submission-scheme --eject

From the new repository, you can import the component using the following command (here, we assume the component was exported to the ‘article-submission’ scope maintained by the ‘bits-and-pieces’ organization):



cd article-submission-client 
bit import bits-and-pieces.article-submission/entities/article-submission-scheme

The component can now be developed and updated in its new repository.

What about the code that consumes the component in the previous repository?
It will continue to work as before because it still consumes the component via its absolute package name.

What about the component’s development environment? build setup? tests?
They are all part of a reusable development environment configured on the component itself (the env will also be exported to a remote hosting or “scope” if it’s not available there already).

Bit with no repository: entirely distributed

Exporting components to a remote hosting (“scope”) and importing them into a new repository is not limited to just a number of permanent repositories.

It can be used to collaborate on components without having to maintain a repository at all. In this case, the source of truth for the components is the remote hosting (the “scope”).

Permissions to modify or use components are managed only in the remote hosting, the ‘remote scopes’.

Importing only the components you need into “disposable” Bit workspaces, modifying them, and exporting them back keeps your workspace simple, clean, and understandable.

This distributed form of collaboration significantly improves your dev experience and makes onboarding new teammates and scaling up, in any sense of the word, smoother and more manageable.

What about the CI?

Bit uses Ripple CI as the default CI. Ripple CI is a CI system designed for Bit components.

Ripple with Bit enables efficient builds that run only on modified components and their dependencies (the affected components). Ripple also builds sibling components in parallel for faster builds.

Most importantly, since every Bit component is independent and autonomous, its build steps are determined by it (the component) rather than one central (external) place.

As mentioned at the beginning of this article, “apps” are not much different than “libs.” Both are Bit components hosted on remote scopes and published as packages.

That said, “apps” or app components will have additional build tasks responsible for generating deployable assets and then deploying them to the relevant platform.

One such ‘app component’ is the article-submission-app. It is a Bit component, much like other components. It can even be installed as a package (build-time micro frontends, anyone?).

DEV Community: Bit

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

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

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

Bit. Composable software platform.

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

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

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.

Composable Software Architectures are Trending: Here’s Why

The Era of Monolithic Applications

The Modular Monolith

Shift Toward Microservices and Micro Frontends

Introducing Purely Composable Architecture

Summary

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

3 Principles for Component-Driven Development

Principle 1: Build for the present, not for vague future needs

Principle 2: Start from the most concrete component

Principle 3: Align component names with business objectives

Monorepo, Poly-repo, or No Repo at all?

Bit in repositories

Going from monorepo to multi-repo

Bit with no repository: entirely distributed

What about the CI?