DEV Community: John Brooks

Making LangChain Apps More Reliable with Bit Components

John Brooks — Wed, 26 Feb 2025 12:57:25 +0000

LangChain applications, which rely on data flowing in and out of LLMs and other AI models, can be unpredictable and difficult to control. Ensuring the reliability of these systems requires careful orchestration of various components and rigorous validation of model outputs.

A proven approach to improving predictability and trustworthiness is by treating key elements—such as agents, templates, output schemas, and more—as standalone Bit components. Each of these components can be individually tracked, versioned, and managed to create a more structured and maintainable AI system.

Example: AI-Powered Technical Blog Writer

The following example demonstrates an AI Technical Writer. This application is composed of two Bit components and a third component that integrates them into a fully functional workflow.

➡️ Explore the ‘Technical Blog Writer’ components on Bit Platform

/**
 * @ComponentId: learnbit.langchain/technical-blog-writer
 * @filename: technical-blog-writer.ts
 */ 

// ...

/* use this component to define the output schema for the model */
import { blogContentSchema } from '@learnbit/langchain.structured-outputs.blog-content';

/* use this component to define the template for the model */
import {
  contentWriterPrompt,
  type ContentWriterPromptInput,
} from '@learnbit/langchain.templates.content-writer-prompt';

// ...

export default async function runTechnicalBlogWriter() {

  const llm = new ChatOpenAI();

  const structuredLLM = llm.withStructuredOutput(blogContentSchema);

  try {
    const topic = await getUserInput(
      'What topic would you like to create content about? '
    );
    const experienceLevel = await getUserInput(
      'What is the audience level of the content? (beginner, intermediate, advanced): '
    );

    const chain = contentWriterPrompt.pipe(structuredLLM);

    /* the template provides a type for its inputs */ 
    const result = await chain.invoke({
      topic,
      experienceLevel,
    } as ContentWriterPromptInput);

  // ...
}

This setup enables a CLI-based AI-powered writing assistant that acts as follows:

AI Bot: What topic would you like to create content about?

User: Individually versioning components in LangChain applications

AI Bot: What is the audience level of the content? (beginner, intermediate, advanced):

User: Advanced

The generated output follows the schema provided by the structured-outputs/blog-content Bit (schema) component:

{
  "seoDescription": "Learn to version components in LangChain for A/B testing and code reuse.",
  "seoTitle": "Individually Versioning Components in LangChain Applications",
  "keywords": ["LangChain", "A/B testing", "component versioning", "code reuse", "system insight"],
  "content": "# Individually Versioning Components in LangChain ..."
}

In this demo, the LLM’s schema is defined using Zod, making it valuable beyond just a reusable building block for other LangChain systems. It also serves as a runtime schema validator and provides a TypeScript type (z.infer) for clients. For example, a UI could use it to display the returned object’s properties in specific fields.

/**
 * @ComponentId: learnbit.langchain/sructured-outputs/blog-content
 * @filename: blog-content.ts
 */

import { z } from 'zod';

export const blogContentSchema = z.object({
  seoDescription: z
    .string()
    .describe(
      'The SEO-optimized description of the blog post (150-160 characters).'
    ),
  seoTitle: z.string().describe('The SEO-optimized title of the blog post.'),
  keywords: z
    .array(z.string().describe('A keyword or category for the blog.'))
    .describe('An array of keywords or categories for the blog.'),
  content: z
    .string()
    .describe('The main content of the blog in markdown format.'),
});

To learn more, visit the project’s scope on Bit Platform:

Why Define AI System Components as Bit Components?

1. A/B Testing and Multi-Variant Testing

Using Bit to version components allows for easy A/B and multi-variant testing:

Compare different agent strategies by switching between versions.
Experiment with various prompt templates to determine the most effective one.
Test multiple output schemas to optimize user experience and content quality.

Bit enables isolated component testing, ensuring precise measurement of their impact on system performance and output accuracy.

2. Code Reusability Across AI Applications

Reusable components significantly streamline development and ensure consistency across projects, this includes schemas and templates that ensure uniformity across AI-powered tools and services.

By leveraging Bit, teams can build once and reuse multiple times, accelerating development and reducing redundancy.

3. Visualizing Dependencies with Bit’s Dependency Graphs

Bit offers powerful dependency graph visualization, which helps developers:

Understand how different components (agents, templates, schemas) interconnect.
Track how changes in one component affect dependent systems.
Identify bottlenecks and optimize AI workflows more effectively.

Since components are versioned following semantic versioning (MAJOR.MINOR.PATCH), developers can clearly assess update impacts and maintain stability across projects.

Final Thoughts

Defining AI system components as Bit components introduces clarity, maintainability, and scalability into AI development workflows.

As AI systems grow more complex, composable architectures will be crucial in maintaining flexibility and ensuring continuous innovation. Explore Bit’s platform to start building modular and reusable AI-powered applications today.

➡️ Visit Bit Platform to learn more

Dependency Injection in Frontend Development: Enhancing UI Components and Micro Frontends

John Brooks — Wed, 29 Jan 2025 22:11:47 +0000

Dependency Injection (DI) is a powerful design pattern that enables flexibility, reusability, and maintainability in frontend development. It allows developers to inject dependencies (such as UI elements, services, or entire micro frontends) rather than hardcoding them within a component or application. This post explores two key use cases where DI significantly improves frontend development:

Making UI components extensible and more reusable
Integrating micro frontends into a platform or app shell using the Inversion of Control (IoC) pattern for build-time integration.

Both use cases have become increasingly relevant as Bit components are more frequently used to compose frontends.

1. Dependency Injection for Extensible UI Components

Reusable UI components are foundational in modern frontend development. However, when these components lack extensibility, developers often find themselves rebuilding them from scratch just to accommodate small modifications. Dependency injection solves this problem by allowing sub-elements of a component to be replaced or extended without altering the component itself.

For example:

const LoadingButton = ({ isLoading, Loader = Spinner, children }) => (
  <button disabled={isLoading}>
    {isLoading ? <Loader /> : children}
  </button>
);

Bit components are not only a way to share code. When used as the building blocks of your application, they transform your codebase from a big pile of files into an elegant graph, where each node is a component with a meaningful name and a purpose.

Since every “building block” in your application is a component, not all components are generic and reusable. However, consumers of a component can suggest changes to make some elements of the component replaceable by other (injectable) elements. This makes the components more generic while keeping them backward compatible.

2. Dependency Injection in Build-Time Micro Frontends

Micro frontends (MFEs) help scale frontend development by allowing teams to work independently while maintaining a cohesive user experience. While runtime composition with Module Federation is common, build-time integration simplifies dependency management and improves performance.

A fundamental goal of micro frontends is independent deployment and development. However, when tightly coupled to the host app, they become harder to scale and modify. Inversion of Control (IoC) through the use of dependency-injection ensures that the host app dictates how MFEs integrate rather than the other way around.

For example, a “Blog” team might need to integrate a blog feature into an existing app maintained by another team. By following a standardized Platform API, the blog MFE can integrate seamlessly without requiring changes in the host app’s codebase.

In this case, the injected dependency is the instance of the app.

/**
 * @filename: blog.tsx 
 */
import type { Frontend, App } from '@learnbit/build-time-mf.platform';

export const blog: Frontend = (app: App) => {
  app.registerRoutes([{ path: '/blog', element: <BlogLandingPage /> }]);
  app.registerHeaderLinks([{ label: 'Blog', path: '/blog' }]);
  return app;
};

The host app only needs a simple import to integrate the blog MFE:

import { App, type Frontend } from '@learnbit.build-time-mf.platform';
import { blog } from '@learnbit.build-time-mf.frontends.blog';

const app = new App();
[blog, ...otherMFEs].forEach((frontend) => frontend(app));
root.render({ app.renderApp() });

Conclusion

Dependency Injection is a powerful pattern that enhances both UI component reusability and micro frontend integration. By allowing components and applications to remain flexible, dependency injection reduces the need for redundant implementations, enables extensibility, and fosters modularity. Whether used in customizable UI components or scalable micro frontend architectures, dependency injection is an essential tool for modern frontend development.

From Specific to Reusable: Transforming UI Components with Bit

John Brooks — Wed, 08 Jan 2025 20:13:18 +0000

Before Bit became part of our workflow, sharing and collaborating on individual components felt like climbing a steep mountain. Managing dependencies, packaging, documentation, and setting up elaborate build tools wasn’t just time-consuming — it was frustrating. These setups often relied on third-party tools that were prone to issues, introducing bugs and bottlenecks along the way.

Because of these hurdles, sharing components was typically limited to the most generic and reusable ones, like UI elements or utility functions. Everything else—components tailored to specific use cases—was left isolated within teams, making collaboration a challenge.

But with Bit, things have changed. Today, developers embrace component-driven development, where every part of an application is built as loosely coupled, self-contained components. Bit doesn’t just help you share code — it transforms your codebase into a well-structured graph, where every node (a component) has a clear purpose and name.

An example of a composable project: readable, comprehensible and easy to maintain

A Tale of Two Teams: Turning Specific Components Into Reusable Gems

This blog explores how Bit helps teams refine specific components into reusable ones, as demonstrated by the collaborative journey of two teams: HR and CRM.

Chapter 1: The HR Team Builds the "Employee Card"

The HR team was tasked with creating an Employee Card to display employee details for their HR platform. They used foundational UI elements shared by the Design Team—buttons, typography, and other reusable building blocks.

The result? A highly effective, well-tested, specific component designed for a single purpose: displaying employee information.

Chapter 2: The CRM Team Discovers an Opportunity

Meanwhile, the CRM team needed a Customer Card for their CRM platform. While exploring the organization's components on *Bit Platform, they stumbled upon the Employee Card. It wasn’t a perfect match — some fields and functionality didn’t align with customer needs—but it came close enough to spark an idea.

Instead of starting from scratch, the CRM team saw potential in refining the specific Employee Card into something more reusable.

The employee card before being modified by the CRM team:

// imports...

export interface EmployeeCardProps {
  contractType: 'full-time' | 'part-time' | 'intern';
 // ...

}

const contractTypeColors = {
      'full-time': 'success',
      'part-time':'warning',
      intern: 'info'
  };

export const EmployeeCard = ({
  avatarUrl,
  // ...
}: EmployeeCardProps) => {
// ...

  return (
    <Card>
      // ...
      <CardContent>
        // ...
          <Chip
            label={`${contractType.toUpperCase()}`}
            color={contractTypeColors[contractType]}
          />
      // ...
    </Card>
  );
};

Chapter 3: Generalizing the Employee Card

The CRM team proposed changes to generalize the Employee Card while keeping it backward compatible. The modifications included:

Customizable Sections: Allowing developers to replace default fields with custom ones, such as replacing the 'contract type' with online/offline status.
Backward Compatibility: Ensuring existing functionality for the HR platform remained intact.

By introducing a flexible API, the Employee Card became more than a specific component—it was now reusable across multiple contexts.

Here’s an example of the transformation:

// imports ...

const contractTypeColors = {
  'full-time': 'success',
  'part-time': 'warning',
  intern: 'info',
} as const;

type ContractType = typeof contractTypeColors;
/**
 * the custom color-map lables can be any string, 
 * but the color values can only be those supported by this component
 */ 
type ChipColorMap = Record<string, ContractType[keyof ContractType]>;

/**
 * Extend the prop type to allow for custom color maps and values
 * instead of the default `contractTypeColors`
 */
export interface EmployeeCardProps<T extends ChipColorMap = ContractType> {
  contractType: T extends ContractType ? keyof ContractType : keyof T;
 /**
  * Nest the props for cutomization under `options` as these are
  * expected to only be used by developers extending this component
  * (rather than using it directly)
  */ 
  options?: {
    chipColorMap: T;
  };
 // ...
}

export const EmployeeCard = <T extends ChipColorMap>({
  contractType,
  options,
 // ...
}: EmployeeCardProps<T>) => {
  /**
   * Use the custom color maps and values, if available
   */
  const chipColorMap = options?.chipColorMap ?? contractTypeColors;

  return (
    <Card>
      <CardContent>
          <Chip
            label={`${contractType.toUpperCase()}`}
            color={(chipColorMap as T)[contractType]}
          />
      // ...
      </CardContent>
    </Card>
  );
};

Chapter 4: Building the Customer Card

The CRM team submits a Change Request (similar to a “Pull Request”) to the HR team via Bit Platform. This request includes detailed documentation of the changes and previews showcasing the card’s extended functionality.

# create a new 'lane' (analogous to git branches)
bit lane create enable-custom-chip-values

# create a 'snap' (analogous to git commit)
bit snap --message "enable the display of custom values instead of contract types" 

# push the 'snap' to Bit Platform and build a pre-release package version of it
bit export

While waiting for the HR team to review their changes, the CRM team began building the Customer Card using the modified Employee Card as a base. Here’s what that looked like:

import {
  EmployeeCard,
  type EmployeeCardProps,
} from '@learnbit-react/generalization.employee-card';

const statusColors = {
  online: 'success',
  offline: 'warning',
} as const;

type Status = typeof statusColors;

export interface CustomerCardProps
  extends Omit<EmployeeCardProps<Status>, 'contractType'> {
  status: keyof Status;
}

export function CustomerCard({
  status,
 // ...
}: CustomerCardProps) {
  return (
    <EmployeeCard<Status>
      contractType={status}
      fullName={fullName}
      startDate={startDate}
      avatarUrl={avatarUrl}
      options={{
        chipColorMap: statusColors,
      }}
    />
  );
}

The “Customer Card” dependencies page (shown in Bit’s Workspace UI) reveals the new dependency:

This approach allowed the CRM team to work in parallel without disrupting the HR team’s workflow. Once the changes to the Employee Card were approved, the CRM team simply updated their dependency to the latest version, saving time and avoiding duplication.

For example:

# install using bit
bit install @acme/hr.employee-card@1.1.0

# install using npm
npm i @acme/hr.employee-card@1.1.0

Benefits of Turning Specific into Reusable

The HR and CRM teams’ collaboration showcases the power of Bit to transform specific components into reusable assets. Here are the key benefits:

Faster Development: Teams can build new components by extending existing ones.
Consistency: Reusing components ensures a unified design language across the organization.
Easier Maintenance: Updates to shared components propagate automatically to all their dependents.

When to Generalize (and When Not To)

Not every component needs to be generalized. If the differences between use cases are too significant, overgeneralizing can lead to:

Complexity: Components become harder to maintain and understand.
Bug Risks: Extending functionality increases the chance of introducing errors.

In these cases, it might be better to create a new component by forking an existing one or starting fresh.

For example:

# Use an existing shared component as the template for a new component
bit fork COMPONENT_ID

Conclusion

The process of turning specific components into reusable ones with Bit is more than just a workflow—it’s a mindset. It empowers teams to collaborate seamlessly, build more efficiently, and maintain high-quality software.

By striking the right balance between specificity and reusability, you can transform your codebase into a flexible, maintainable system. Try Bit today and experience the difference in component-driven development firsthand!

Using Multiple Versions of a Package in a Single Project: Why and How

John Brooks — Wed, 01 Jan 2025 16:15:01 +0000

Modern software development often calls for innovative approaches to managing dependencies, especially in large-scale JavaScript projects. One such approach is using multiple versions of the same package in a single project. This method, while seemingly unconventional, addresses various needs such as ensuring legacy system support, conducting feature toggling, or facilitating A/B testing.

In this blog post, we’ll delve into the reasons behind using multiple versions of a package, with a focus on feature toggling and A/B testing, and explore how Bit can simplify this complex process.

Why Use Multiple Versions of the Same Package?

Legacy Code and Gradual Updates

Legacy systems often rely on older versions of dependencies. Introducing a new version may cause incompatibilities. Using multiple versions ensures new features can leverage updated libraries while older systems remain stable.

Feature Toggling

Feature toggling enables developers to control the availability of specific features without modifying the codebase. This approach is especially useful when releasing features incrementally or testing their impact.

Release Toggles: Delay the public release of a feature while ensuring its code is merged and tested within the main branch.
Experiment Toggles:(A/B Testing): Allow testing features with different user segments to determine the optimal implementation.
Ops Toggles: Provide operational teams with the ability to enable or disable features without deploying new code.

Feature toggling may require multiple versions of a package or component when toggling involves significant changes, such as upgrading a library or altering a core component.

Tagging Bit components with Pre-Release Versions

Bit offers the bit snap command to version your component with a hash instead of a Semantic Version, to indicate the version is no ready for release (the command also executes a slightly different build pipeline, accordingly).

For example:

'bit snap' => package-name@5475049d02fafa0eaf6885a06d36e42e0ffdc4a3
'bit tag' => package-name@1.2.3

However, having a hash as the component's version does not give any information about its purpose, its parent release version, or whether this "branch" of the component's history has additional iterations.

A bit snap is useful as a Bit analogy for git commit but not for experimental release versions that should be integrated into production.

To provide more information, it's recommended to use the prerelease option. For example:

bit tag forms/sign-in -m "add SSO option" --increment prerelease --prerelease-id beta

Managing Multiple Versions of a Package

When using multiple versions of a package/Bit component, dependency aliasing is key. This approach allows teams to maintain multiple package versions within the same project.

{
 "dependencies": {
  "@my-org/my-scope.forms.sign-in": "0.0.1",
  "@my-org/my-scope.forms.sign-in-sso": "npm:@my-org/my-scope.forms/sign-in@0.0.2-beta.0",
}

Alias names make it easy to differentiate between versions:

import { SignInForm } from "@my-org/my-scope.forms.sign-in";
import { SignInForm as SignInFormWithSso } from "@my-org/my-scope.forms.sign-in-sso"

export function SignInPage() {
 if (features.flags.sso.enabled) return <SignInFormWithSso />;
 return <SignInForm />
  );
}

Learn more

The Case for Build-Time Micro Frontends

John Brooks — Wed, 01 Jan 2025 12:00:53 +0000

Micro frontends have reshaped how we build and manage modern web applications. By breaking down monolithic frontends into smaller, independently developed and delivered units, teams can collaborate more effectively, adopt diverse technologies, and scale development processes.

While runtime micro frontends often steal the spotlight with their promise of dynamic loading and independence, build-time micro frontends deserve a closer look. They offer significant advantages in performance, consistency, and modularity—qualities that can make or break complex applications.

Two trending tools, Bit and Ripple CI encourage us to rethink build-time micro frontend integration. These tools challenge traditional assumptions about monorepos and polyrepos by showcasing how build-time integration can achieve significant performance, consistency, and modularity improvements.

By enabling component-driven development using independent Bit components, with advanced dependency management, Bit and Ripple CI offer fresh perspectives on how teams can collaborate and maintain distributed frontend systems effectively.

What Are Build-Time Micro Frontends?

Build-time micro frontends involve assembling different parts of the application during the build process, rather than dynamically at runtime. Components are developed independently, versioned, and combined into a unified application during deployment. Tools like Bit facilitate this approach by enabling teams to create modular, reusable components that can be easily integrated.

The Difference Between Node Packages and Micro Frontends

A common question arises: Could every JavaScript project be considered a build-time micro frontend, given the widespread use of packages?

This question has become even more nuanced with the advent of Bit components, which blur the lines further. While Bit components can be installed as standard Node packages, they offer much more. Each Bit component can be versioned, maintained, and delivered as an independent project, eliminating the need for a dedicated repository. Versioning is handled independently, and development doesn’t require a unique environment or build pipeline—Bit provides a reusable, pre-configured setup that works seamlessly wherever the component is edited.

The simple answer is no—JavaScript packages (including Bit components) and micro frontends serve distinct purposes despite their shared foundation in modularity. Here’s how they differ:

Node Packages: These are libraries or modules designed to provide reusable functionality at build-time. They add features or dependencies to an application but are not standalone entities with their own lifecycle or ownership. Packages exist to enhance or complement an application rather than to function as autonomous components.
Micro Frontends (MFEs): These are self-contained pieces of an application’s user interface. They are designed to operate independently and often include their own lifecycle, ownership, and deployment pipelines. Whether integrated at build-time or runtime, a micro frontend should be deployable as an independent application with minimal modifications, making it a distinct architectural choice.

In essence, while both Node packages and micro frontends emphasize modularity, their scope and goals are fundamentally different. Node packages focus on reusability within the development process, whereas micro frontends prioritize autonomy and scalability in the application’s user interface.

Build-time MFEs: An Example

The "Forever Mars" app invites users to register to a one-way trip to Mars.

The "Forever Mars" app composed of build-time MFEs

The app is composed of Bit components, from the most elementary UI components and utility functions, to full MFEs, ready to be integrated into a single application. The components are shared in access-controlled collections on Bit Platform, called "scopes". Some of these scopes, like the booking scope, contain an MFE (the booking app) while others, such as the design scope, contain only shared dependencies (the design system for this app).

Elementary components and MFEs shared in access-controlled scopes on Bit Platform: https://bit.cloud/cosmo-cruises

While Bit components don't require a repository to be edited and published, developers often prefer to maintain them using git repositories and the collaboration tools they're used to.

Bit Platform allows modules to be shared and used across repositories while Ripple CI enables changes to propagate from one component, maintained in one repo, to other dependent components maintained in other repositories (or, even no repository at all).

Why Choose Build-Time Integration?

1. Optimized Performance

Performance is a cornerstone of any successful web application. Build-time micro frontends excel in this area by eliminating the runtime overhead associated with loading multiple modules dynamically. Since all integration happens during the build process, users experience faster load times and smoother interactions.

For instance, instead of relying on runtime dependencies that can slow down initial rendering, build-time integration ensures that shared dependencies are pre-bundled and optimized. This results in smaller payloads and reduced latency, especially for applications with high traffic or strict performance requirements.

This does not mean that the entire app should always be bundled as a single chunk. Dynamic loading of dependencies can be the more performant options when used in the right places. Code-splitting is often a smart strategy, however, it's worth noting that even then the result would be more optimized chunks, with less chance for runtime errors.

2. Enhanced Consistency

One of the biggest challenges in micro frontend architectures is maintaining consistency across different parts of the application. Runtime micro frontends often lead to version mismatches or styling inconsistencies because teams work independently and deploy updates at different times.

Build-time micro frontends address this by enforcing consistent dependencies and styles during the build phase. Tools like Bit enable centralized management of shared components, ensuring that all parts of the application adhere to the same design system and functionality standards. The result? A cohesive user experience that feels seamless, even if different teams own various parts of the app.

3. Simplified Debugging and Maintenance

Debugging a runtime-integrated application can feel like searching for a needle in a haystack. With multiple micro frontends interacting dynamically, tracing issues back to their source becomes a complex task.

Build-time micro frontends simplify this process. Since components are assembled and tested during the build, issues can be identified and resolved early. Tools like Ripple CI further streamline this workflow by targeting affected components for faster builds and catching dependency conflicts before they reach production.

4. Scalability Through Modularity

As applications grow, so does the complexity of managing them. Build-time micro frontends thrive in large-scale projects by promoting modularity. Each component can be versioned and updated independently, reducing the risk of breaking changes.

Moreover, with platforms like Bit, teams can develop components in a polyrepo setup or even without a traditional repository. This flexibility allows for efficient scaling without being tied to rigid development structures.

5. Centralized State and Communication

Managing global state, routing, and shared services is more straightforward with build-time micro frontends. By centralizing these concerns during the build phase, developers can ensure that all parts of the application use the same state management and communication patterns.

For example, shared contexts for authentication or theming can be wrapped around individual components during the build process. This ensures that every part of the application operates consistently, avoiding runtime discrepancies.

Misconceptions About Build-Time Micro Frontends

There’s a common misconception that build-time micro frontends require a monorepo setup. While monorepos are an option, they’re not mandatory. Tools like Bit make it possible to maintain build-time micro frontends in a polyrepo setup or even independently of a repository. This flexibility allows teams to choose the structure that best fits their workflow.

Another myth is that build-time micro frontends are less dynamic than their runtime counterparts. While runtime solutions excel in dynamic updates, build-time approaches can achieve similar agility with tools like Ripple CI, which automates dependency updates and ensures seamless integration across components.

Conclusion

While runtime micro frontends often garner more attention, build-time micro frontends present a compelling case for scalable, high-performance applications. Their ability to optimize performance, ensure consistency, and simplify maintenance makes them an excellent choice for many teams.

By leveraging tools like Bit and [Ripple CI], developers can unlock the full potential of build-time micro frontends, creating applications that are not only modular and maintainable but also efficient and cohesive. It’s time to give build-time integration the spotlight it deserves and embrace a future where distributed frontends are both powerful and user-friendly.

Building Composable Platforms with Harmony

John Brooks — Wed, 18 Dec 2024 17:49:35 +0000

In today’s fast-paced digital landscape, the need for adaptive, scalable, and maintainable software systems is greater than ever.

Traditional monolithic architectures often fall short in meeting these demands due to their rigidity and complexity. Enter Harmony, a framework designed to enable composable platforms with high efficiency and flexibility.

In this article, we'll explore how Harmony, powered by Bit, transforms the way we build and maintain modern applications.

What is Harmony?

Harmony is a minimalistic yet powerful dependency-injection framework tailored for creating composable architectures. By enabling developers to stitch together independently developed Bit components, Harmony allows teams to build applications that are not only modular but also adaptable to evolving business needs. Harmony supports full-stack composability, making it ideal for integrating frontend and backend functionalities into cohesive platforms.

Key Features of Harmony

Pluggable Aspects: Modular business features, called aspects, can be easily integrated into platforms.
Runtime Flexibility: Official support for Node.js and browser environments ensures compatibility across diverse use cases.

Why Composability Matters

Composability empowers organizations to:

Adapt Quickly: New features can be added or updated independently without disrupting the existing system.
Promote Reusability: Shared components can be leveraged across multiple projects, reducing duplication and increasing consistency.
Foster Collaboration: Teams can work on isolated aspects or components without stepping on each other’s toes.

Building a Composable System with Harmony

As mentioned, the building blocks of a Harmony system are Bit components. However, since Bit components are containers for any unit of software, not every Bit component will do.

Harmony uses components with a specific design to allow them to consume and provide "services" to and from other aspects. These can be frontend-only, backend-only, or full-stack features.

An aspect represents a single business capability 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 or business capabilities 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 surfer clothing.

The team responsible for that online store decided to add a blog to their site. After searching for a suitable Aspects on the Bit platform, they came across this Blog aspect. Deciding they wanted to use it, they added it to their Hamrony application:

/**
 * @coponentId: learnbit.apparel-waves/apparel-waves
 * @filename: apparel-waves.bit-app.ts
 */ 

// imports...
import { SymphonyPlatformAspect } from '@bitdev/symphony.symphony-platform';
import { ApparelWavesPlatformAspect } from '@learnbit/apparel-waves.apparel-waves-platform';
import { BlogAspect } from '@learnbit/blog-pbc.blog';

export const ApparelWaves = HarmonyPlatform.from({
  name: 'apparel-waves',
  platform: [
   /**
    * ascpects register themsevles to the 'platform' aspect which
    * is the entry point for this application
    */
    SymphonyPlatformAspect,
    {
      name: 'Apparel Waves',
      slogan: 'Making waves in fashion',
      domain: 'apparel-waves.com',
    },
  ],
  /**
    * aspects can run in multiple runtime environments. here, aspects 
    * provide functionalitis to the NodeJS services and to the web frontend apps
   */
  runtimes: [new BrowserRuntime(), new NodeJSRuntime()],

  aspects: [
    /* 'apperal waves' aspect extends the system with its 
     * own unique functionalities. this aspect is maintained by 
     * a team that composes the apsects for their own solution.
     */
    ApparelWavesPlatformAspect,
    /**
     * the blog aspect extends the system with content 
     * management capabilities. it is maintained by the blog PBC team.
     */
    [
      BlogAspect,
      {
       /**
         * the blog aspect also provide a config api for this app to use
         * in this case, since the the blog uses the Contenful platform,
         * the fusion team need to provide it with their own Contentful space ID
         */        
        spaceId: 'contentful-spaceId',
      },
    ],
  ],
});

export default ApparelWaves;

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.

NodeJS Runtime

/**
 * @coponentId: learnbit.blog-pbc/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 = [SymphonyPlatformAspect];

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

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

    return blog;
  }
}

export default BlogNode;

Browser Runtime

**
 * @coponentId: learnbit.blog-pbc/blog
 * @filename: blog.browser.runtime.ts
 */


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

  static dependencies = [SymphonyPlatformAspect, HeaderAspect];

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

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

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

    return blog;
  }
}

export default BlogBrowser;

The blog aspect in this example uses the Contentful content management system. It offers a coherent “language” for bought services within the company’s aspect ecosystem, ensuring they can communicate effectively and function seamlessly together.

/**
 * @coponentId: learnbit.blog-pbc/blog
 * @filename: blog-data.ts
 */

import { ApolloClient, InMemoryCache, HttpLink, gql } from '@apollo/client';
import type { BlogConfig } from './blog-config.js';

export class BlogData {
  constructor(private readonly config: BlogConfig) {}

  private contentfulClient = new ApolloClient({
    link: new HttpLink({
      uri: `https://graphql.contentful.com/content/v1/spaces/${this.config.spaceId}`,
      headers: {
        Authorization: `Bearer ${process.env.CONTENTFUL_ACCESS_TOKEN}`,
      },
      fetch,
    }),
    cache: new InMemoryCache(),
  });

  getBlogPosts = async () => {
    const { data } = await this.contentfulClient.query({
      query: gql`
        query GetBlogs {
          pageBlogPostCollection {
            items {
              title
              slug
              author {
                name
              }
            }
          }
        }
      `,
    });
    return data.pageBlogPostCollection.items.map((item) => ({
      title: item.title,
      slug: item.slug,
      author: {
        name: item.author ? item.author.name : null,
      },
    }));
  };
}

Next steps

Explore the "Blog" scope (with the blog aspect)

Visit these Bit scopes to explore demo aspects and fork (copy) them to your Bit workspace to get started quickly.

Visit the Blog scope

Explore the "Apparel Waves" scope (with a Harmony platform)

Visit the Apparel Waves scope

Visit Bit's official documentation

Bit. Composable software.

Bit is build system for development of composable software.

bit.dev

Why Code Reuse is Important in the Age of AI

John Brooks — Mon, 09 Dec 2024 21:09:20 +0000

As AI and AI coding assistants transform software development, questions arise about traditional practices like code reuse. With AI generating code in seconds, some developers wonder if it's still worth investing in sharing and maintaining reusable modules. However, code reuse remains a cornerstone of efficient, maintainable software development—and in this AI-driven age, it’s more vital than ever.

The Evolution of Code Reuse

Before AI coding assistants, the primary way to accelerate development and ensure consistency was by reusing code. Developers shared modules in a monorepo setup or published reusable packages for separate repositories in a polyrepo setup. These practices enabled faster development cycles, reduced errors, and improved maintainability.

Now, with AI assistants capable of generating context-aware code, some question whether this approach is still necessary. But code reuse offers advantages that even advanced AI cannot fully replicate.

Why Code Reuse is Irreplaceable

1. Reliability Through Proven Components

AI-generated code may be innovative, but it’s not always reliable. Reusing curated, tested, and reviewed components ensures stability and reduces the risk of introducing bugs. Components with a track record of success bring a level of confidence that generated code cannot match.

Components shared on the "show off" Bit organization

2. Improved Readability and Maintainability

Despite AI’s advancements, human developers still need to read, review, and edit code. Reused components are typically better documented and more readable than freshly generated code. Moreover, AI assistants thrive in well-structured environments, where they can better analyze and provide relevant suggestions when reusable components are present.

Component-based projects produce a highly readable graph of dependencies where each node in that graph is a component with a clear purpose and function

3. Enhanced Performance

Reused components often come with optimizations, such as reduced load times or streamlined interactions. This kind of performance tuning is hard to achieve with ad hoc code generation.

Combining AI with Reusable Components

The most effective development practices today combine the strengths of AI with the efficiency of code reuse. AI coding assistants, when integrated with systems like Bit, can enhance reusability while minimizing overhead. Here’s how this synergy works.

1. Integrated Build Systems

AI assistants should integrate with the build system, enabling seamless generation, testing, and publishing of reusable components. This eliminates manual steps and accelerates the workflow.

Hope AI integrates into Bit Platform's CI and code review functionality

2. Dependency Awareness

AI assistants that understand the relationships between components can suggest appropriate reuse opportunities. For example, Hope AI, Bit’s native coding assistant, leverages a clear dependency graph to understand each component’s API and required context.

3. Prioritizing Reuse

A well-trained AI assistant prioritizes reusing existing components over generating entirely new code. This reduces duplication, maintains consistency, and minimizes the risk of errors.

Conclusion

In the age of AI, code reuse is not only relevant but essential. It complements AI’s capabilities by ensuring reliability, readability, and performance. By combining reusable components with smart tools like Hope AI, developers can achieve a balance between innovation and maintainability.

Ready to modernize your development process? Explore how Bit and Hope AI can transform your workflow, combining the power of AI with the proven efficiency of code reuse.