DEV Community: Paul-Sebastian Manole

I Built a Better MFE Template (Because The Old One Sucked)

Paul-Sebastian Manole — Sun, 07 Sep 2025 09:56:07 +0000

So, I've been stuck in MFE hell...

Lately, I've been wrestling with a relic of an MFE architecture at work. We're talking Webpack—yes, Webpack—for a brand new project. I mean, who does that anymore when you've got Webpack-compatible tools like Rsbuild and Rspack that don't make you want to rip your hair out?

The developer experience was an absolute joke. I'm talking minutes just to see a tiny change, and HMR was so broken you couldn't even call it that. It felt like I was back in the Stone Age of .NET Framework 4.0.

To save my sanity—and maybe change the whole team's setup—I started building a demo. And from the ashes of that frustration, this clean, simple, and actually modern MFE template with Rsbuild was born.

It's all on my GitHub here: https://github.com/brokenthorn/module-federation-template-rsbuild-rspack

The README should tell you everything you need to know, so I'm not going to bore you with the details here.

Go have some fun with it. You're welcome. 😉

Consumer-Driven Contract Testing with Pact - Code Example

Paul-Sebastian Manole — Mon, 05 Aug 2024 01:52:24 +0000

NOTE: This is a very short and super high-level example of how one might implement consumer-driven contract testing with Pact. It's meant to convey the principles and make it seem less daunting to start implementing. This continues from where I left off in my first article.

Consumer-Driven Contract Testing with Pact: A Recap

Consumer-Driven Contract Testing (CDCT) is a testing approach that ensures compatibility between services by having the consumer define the expectations for how it interacts with the provider. Pact is a popular tool for implementing CDCT, allowing you to verify that both consumer and provider are aligned in their interactions.

In CDCT, the consumer application defines contracts that specify the requests it expects the provider to fulfill. These contracts are then shared with the provider, which runs verification tests to confirm it can meet the consumer's expectations. This process fosters clear and efficient communication between teams, ensuring that changes in one service don’t break another.

Why Pact?

See the first article in the series.

Key Concepts in Pact

Consumer: The application that sends requests and expects responses.
Provider: The service that fulfills requests made by the consumer.
Pact Contract: The agreement, defined by the consumer, specifying expected request-response pairs.
Verification: The provider validates the contract, ensuring it meets consumer expectations.
Pact Broker: An optional service that stores and shares contracts, making collaboration easier.

Getting Started: Code Example

Let's implement CDCT with a simple Node.js example using Pact. First, set up your project and install Pact dependencies:

npm init -y
npm install @pact-foundation/pact @pact-foundation/pact-node jest

Step 1: Define the Contract in the Consumer

Create a test file, consumer.test.js, where the consumer’s expectations are specified.

const { Pact } = require('@pact-foundation/pact');
const provider = new Pact({
  consumer: 'ConsumerApp',
  provider: 'ProviderService',
  port: 1234
});

describe('Pact with ProviderService', () => {
  beforeAll(() => provider.setup());
  afterAll(() => provider.finalize());

  test('should receive a valid response for a specific request', async () => {
    // Define consumer expectations here
    await provider.addInteraction({
      state: 'provider has valid data',
      uponReceiving: 'a request for information',
      withRequest: { method: 'GET', path: '/data' },
      willRespondWith: { status: 200, body: { id: 1, name: 'Test Data' } }
    });

    // Trigger the request and assert results
    const response = await fetch('http://localhost:1234/data');
    const data = await response.json();
    expect(data).toEqual({ id: 1, name: 'Test Data' });

    await provider.verify();
  });
});

In this test, the consumer defines an expectation: when it sends a GET request to /data, it expects a 200 response with specific data.

Step 2: Publish the Contract

If you’re using a Pact Broker, you can publish the generated contract to share it with the provider.

npx pact publish ./pacts --consumer-app-version 1.0.0

Step 3: Provider Verification

On the provider side, create tests that use the contract to verify compatibility. Here’s a simplified provider verification setup:

const { Verifier } = require('@pact-foundation/pact');

describe('Provider Verification', () => {
  test('validates contract with ConsumerApp', async () => {
    const opts = {
      providerBaseUrl: 'http://localhost:8080',
      // ...
    };
    await new Verifier(opts).verifyProvider();
  });
});

This test verifies the provider against the consumer’s expectations, ensuring compatibility.

Conclusion

By using Pact, you can implement Consumer-Driven Contract Testing effectively, ensuring your services evolve in harmony. CDCT enables quick feedback on contract compliance, reduces integration errors, and fosters collaborative development between service teams.

Consumer-Driven Contract Testing with Pact - The basics

Paul-Sebastian Manole — Mon, 05 Aug 2024 01:52:05 +0000

Consumer-Driven Contract Testing with Pact: The Basics

What is Contract Testing?

Contract testing ensures the interactions between services adhere to shared expectations, or "contracts." Unlike traditional end-to-end tests that check complete workflows, contract testing focuses specifically on the data exchanged between a consumer and provider, reducing complexity and making it easier to identify integration issues in microservices.

Why Consumer-Driven Contracts?

In a Consumer-Driven Contract Testing (CDCT) approach, the consumer (like a frontend or another microservice) defines the interactions it expects from the provider (the API it calls). This consumer-first approach ensures the provider maintains backward compatibility for critical consumer requirements, supporting independent development.

What is Pact?

Pact is a widely used open-source tool for CDCT that facilitates defining, sharing, and verifying contracts between consumers and providers. With Pact, consumers define expected provider interactions, which are then verified by the provider.

How Pact Works

Consumer Pact Tests:
- Consumers write unit tests to specify interactions expected from the provider. Pact creates a "mock provider" that behaves according to these expectations during testing.
- Once the test suite passes, Pact generates .pact files capturing each interaction, which act as contracts and can be uploaded to a Pact Broker or PactFlow for sharing.
Provider Pact Verification:
- Providers use the Pact Verifier to validate these contracts by replaying consumer requests against the actual provider API.
- The provider's responses are compared to the consumer's expectations in the contract. Successful validation confirms compatibility, while failures indicate mismatches to be addressed.
Publishing Contracts with PactFlow:
- PactFlow, a hosted Pact Broker, enables teams to store and share contracts between consumers and providers, automating the process of matching current consumer requirements with provider capabilities.
Can-I-Deploy Checks:
- In CI/CD, PactFlow offers the "can-i-deploy" check to ensure compatibility between services before deploying updates, preventing integration issues from reaching production.

Best Practices for Pact and PactFlow

Isolate Pact Tests: Run Pact tests independently of end-to-end tests, focusing specifically on validating API interactions.
Version Contracts Carefully: Use versioning practices for contracts to maintain compatibility as services evolve.
Automate in CI/CD: Integrate Pact testing into CI/CD pipelines, triggering contract verification on each commit or build. PactFlow simplifies this with automation for contract versioning, compatibility checks, and deployment gating.

Benefits of Pact and CDCT

Reduced End-to-End Dependency: CDCT reduces the need for exhaustive end-to-end testing by isolating and validating individual service interactions.
Enhanced Service Autonomy: Pact testing allows consumers and providers to evolve independently while ensuring compatibility.
Rapid Feedback: Detect integration issues early with clear and fast feedback loops, ideal for microservices and agile environments.

In the next article, I will try to show you how CDCT might look like in practice.