A reusable CI/CD components is now available in the GitLab CI/CD Catalog. These components make it incredibly easy to import API artifacts and run contract conformance tests directly from your pipeline—with just a few lines of YAML!

By leveraging GitLab Components, we've made Microcks integration as simple as including a component reference in your pipeline configuration. Let's see how!

What You Can Do with Microcks GitLab Components​

The Microcks GitLab Components provide two main capabilities:

1. Import API Artifacts - Push your OpenAPI, AsyncAPI, Postman collections, and other specifications into your Microcks instance
2. Run Contract Tests - Validate that your deployed API endpoints conform to their specifications

Getting Started​

Prerequisites​

Before you begin, make sure you have:

• A running Microcks instance with its API URL (e.g., https://microcks.apps.acme.com/api/)
• A Service Account configured in your Microcks Keycloak realm
• The Service Account's client_id and client_secret

Pro tip: Store your credentials as masked GitLab CI variables for security! Navigate to Settings → CI/CD → Variables in your GitLab project and add:

• MICROCKS_URL → Your Microcks API endpoint
• KEYCLOAK_CLIENT_ID → Service Account client ID
• KEYCLOAK_CLIENT_SECRET → Service Account client secret

Finding the Components in the Catalog​

The Microcks GitLab Components are published in the GitLab CI/CD Catalog

From there, you can browse documentation, view available versions, and see usage examples. Let's explore how to use each component!

Importing API Artifacts into Microcks​

The first component, microcks-import, allows you to push your API specifications into Microcks. This is perfect for keeping your mocks in sync with your latest API definitions.

Here's a simple example:

# .gitlab-ci.yml
include:
  - component: gitlab.com/microcks-cncf/microcks-community/microcks-gitlab-components/microcks-import@~latest
    inputs:
      specs: "specs/weather-forecast-openapi.yml:true,specs/weather-forecast-postman.json:false"
      microcks_url: "https://microcks.apps.acme.com/api/"
      keycloak_client_id: $KEYCLOAK_CLIENT_ID
      keycloak_client_secret: $KEYCLOAK_CLIENT_SECRET
      stage: import

stages:
  - import

Some important things to notice here:

• You can customize the stage name to fit your pipeline structure
• Using @~latest ensures you always get the most recent component version

Once this runs, your API specifications will be imported into Microcks, and your development team can immediately start consuming mock endpoints!

Running Contract Conformance Tests​

The second component, microcks-test, runs contract tests against your deployed API endpoints. This ensures your implementation matches your specification—automatically catching breaking changes before they reach production!

Here's how to use it:

# .gitlab-ci.yml
include:
  - component: gitlab.com/microcks-cncf/microcks-community/microcks-gitlab-components/microcks-test@~latest
    inputs:
      api_name_version: "Weather Forecast API:1.0.0"
      test_endpoint: "https://my-weather-api.example.com"
      test_runner: "OPEN_API_SCHEMA"
      microcks_url: "https://microcks.apps.acme.com/api/"
      keycloak_client_id: $KEYCLOAK_CLIENT_ID
      keycloak_client_secret: $KEYCLOAK_CLIENT_SECRET
      stage: test
      wait_for: "15sec"

stages:
  - test

Putting It All Together: A Pipeline sample​

Let's see how both components work together in a real-world pipeline. The following example demonstrates how to import a local spec file, and how to run the test against a running API.

To run this example, you will need to:

• Configure $MICROCKS_DN and $PASTRY_API_DN as GitLab CI variable.
• Run the Pastry API
• Configure a running Microcks instance in Dev mode
• Load the Pastry sample

# .gitlab-ci.yml
include:
  - component: $CI_SERVER_FQDN/microcks-cncf/microcks-community/microcks-gitlab-components/microcks-import@~latest
    inputs:
      specs: "samples/HelloService.postman.json:true"
      microcks_url: "http://$MICROCKS_DN:8080/api/"
      stage: import
  - component: $CI_SERVER_FQDN/microcks-cncf/microcks-community/microcks-gitlab-components/microcks-test@~latest 
    inputs:
      api_name_version: "API Pastry - 2.0:2.0.0"
      test_endpoint: "http://$PASTRY_API_DN/"
      test_runner: "OPEN_API_SCHEMA"
      microcks_url: "http://$MICROCKS_DN:8080/api/"
      stage: test

stages:
  - import
  - test

Here's the resulting pipeline in GitLab, with the import stage followed by the test stage:

If the contract test fails, the pipeline stops, preventing broken APIs from reaching production. It's continuous verification in action!

Version Pinning for Stability​

While @~latest is great for always getting improvements, you might want stability in production pipelines. Simply specify a version:

include:
  - component: gitlab.com/microcks-cncf/microcks-community/microcks-gitlab-components/microcks-import@0.0.2

This ensures your pipeline behavior remains consistent even as new component versions are released.

Under the Hood​

Behind the scenes, these components leverage the Microcks CLI.

The beauty of GitLab Components is that all this complexity is abstracted away—you just declare what you want, and the component handles the rest!

Wrap-Up​

With the Microcks GitLab Components, integrating API mocking and contract testing into your CI/CD pipelines has never been easier. You get:

• Simple integration - Just include the component, no complex scripts
• Reusable configuration - Use across all your projects
• Version control - Pin versions or stay on latest

Ready to give it a try? Check out the components in the GitLab CI/CD Catalog and start mocking!

Improve the GitLab Components​

The Microcks GitLab Components are designed to cover the most common use cases, but we know there's always room for improvement! The underlying Microcks CLI supports many advanced options and flags that aren't yet exposed as component inputs. Feel free to contribute!

Moving from the Sandbox to the Incubating stage is a massive achievement. For the Microcks community, this isn't just a new label; it is a formal validation of our project's maturity. Reaching this level means the CNCF Technical Oversight Committee (TOC) has thoroughly reviewed and confirmed our real-world adoption, solid governance models, and rigorous security posture.

For platform teams and enterprises evaluating tools for production-grade API mocking and testing, Incubating status represents the credibility threshold required to rely on a tool at scale.

A Year of Explosive Growth​

Our momentum leading up to this announcement has been record-breaking. In the latest CNCF Projects Velocity report (1/1/2025 - 1/1/2026), Microcks ranked within the top 65 of over 236 projects, a testament to the sheer energy of our ecosystem.

This velocity is reflected in our 2025 metrics:

• Global Adoption: We saw a massive surge in usage, with annual container image downloads jumping from 850k in 2024 to 2.5+ million in 2025: more than 3x growth year-over-year.
• 2026 Headstart: The momentum isn't slowing down; we have already reached over 1.3 million downloads since January 2026 alone.
• Community Depth: Our contributor base grew to 167 active individuals representing 35 different organizations, ensuring diverse perspectives drive our roadmap.
• Trusted by Industry: We now have 34 public adopters, with 13 new organizations joining the list in 2025 to help demonstrate Microcks' sustainability in real-world business contexts.

A Heartfelt Thank You to Our Community​

This milestone belongs to all of you. We are extremely proud and happy about this move, which is the direct result of years of community effort.

• Our Contributors: Your energy, code, and documentation are the heartbeat of this project.
• Our Adopters: A special thank you to our public adopters who rely on Microcks in real-world, business-critical contexts.
• Our Sponsor: We owe a debt of gratitude to Postman, our sponsor for the past three years. Their graceful support and belief in open source collaboration have been instrumental in our growth.

Gratitude to the CNCF​

We want to thank the CNCF TOC, TAG App Delivery, and the broader CNCF team for their invaluable support and guidance throughout this process. We are staunch promoters of the "Better Together" approach, and this collaboration reinforces how complementary cloud native projects can deliver greater value to end users.

A special kudos to Katie Gamanji, who served as the Microcks sponsor over the past several months. We deeply appreciated her feedback and help in refining key aspects of our incubating application; her collaboration was essential to making this happen.

Understanding the Journey​

For those interested in the rigorous process and "due diligence" behind this promotion, we invite you to explore the full details here:

• Microcks Incubation Application: GitHub Issue #1552
• Microcks Due Diligence: GitHub Pull Request #2038

Looking Ahead: The Future of API Mocking​

As we enter this new chapter in 2026, our mission remains unchanged, but our resolve is stronger. We are ready to keep growing and become the de facto standard for open source API mocking and testing.

We empower cloud native developers to level up their API execution. By leveraging our mocking and sandboxing capabilities, organizations can accelerate the adoption of microservices while ensuring conformance testing never bottlenecks innovation.

Let’s keep building the future of API testing together !

This release marks a significant milestone in our journey to provide the most comprehensive simulation environment for modern architectures. As distributed systems become more complex, the lines between synchronous and asynchronous interactions blur. Microcks 1.14.0 bridges these worlds with powerful new features for OpenAPI and AsyncAPI, allowing you to simulate sophisticated business flows with ease.

Below are the highlights of this major release.

Simulating OpenAPI Callbacks 🛎️​

In the OpenAPI v3 specification, Callbacks are used to describe asynchronous, out-of-band requests that your service sends back in response to a specific event (like a payment confirmation or a long-running registration process).

Microcks 1.14.0 now fully supports the simulation of these callbacks. You can now define ordered, contextual, and asynchronous callback sequences. By using the x-microcks-callback.order extension, you can ensure that notifications are sent in the exact order your business logic requires, using data captured from the initial request to make the simulation realistic.

Check out the OpenAPI Callbacks guide to see how to implement this in your mocks.

Support for OpenAPI Webhooks 🎣​

While callbacks are tied to a specific request, Webhooks represent a stream of events that consumers can subscribe to independently. They are essential for modeling event-driven behaviors within a RESTful ecosystem.

With this release, Microcks introduces a dedicated Manage Webhooks UI and API. This allows you to register subscribers, configure the frequency of events, set expiration delays, and even monitor delivery errors. It’s never been easier to simulate a live stream of "New Pet" or "Order Updated" events for your consumers!

Dive into our OpenAPI Webhooks documentation for a full walkthrough.

Sync-to-Async Triggers ⚡️​

In modern cloud-native apps, a common pattern is a "Sync-to-Async" flow: a user hits a REST endpoint (Sync), which then triggers an event on a message broker like Kafka or RabbitMQ (Async).

Microcks 1.14.0 introduces Sync-to-Async triggers**, allowing you to describe these cross-protocol scenarios. By adding a simple trigger to your OpenAPI or gRPC operation, Microcks will automatically publish a contextualized message to your AsyncAPI channels whenever the mock is invoked. This ensures that your entire event-driven choreography can be tested end-to-end without a single line of code.

Read more about Async API event triggers to master these complex scenarios.

Request-Reply for AsyncAPI 🤝​

Microcks is a community-driven project, and this release features a fantastic contribution from Adam Hicks 🙏, who implemented support for the Request-Reply pattern in AsyncAPI.

This enhancement is a game-changer for simulating asynchronous interactions that require a correlation between a request message and a response message.

A huge thank you to Adam for his hard work and for helping Microcks support even more real-world messaging patterns! 👏

Other Improvements​

This release is one of our largest yet, with nearly 70 issues resolved! Beyond the major features, we’ve included:

• UI Enhancements: Updates to Angular 19.2.18 for a smoother experience.

• Better Debugging: Homogenized "Live Traces" between Groovy and JS engines.

• Quality & Stability: Numerous bug fixes in gRPC error handling and test controllers.

For the full list of changes, please check the milestone details on GitHub.

What’s Next?​

As we continue to push the boundaries of API mocking and testing, your feedback is our North Star. Join our community, share your ideas, and let's build the future of API tooling together! You can either help us define the scope of the next 1.15 release in this discussion.

Come say hi on our Discord chat, give us a star on GitHub ⭐️, or follow us on our social channels!

Thanks for your continued support! ❤️

This is a powerful step forward: instead of static mocks, you can now create dynamic, context-aware simulations that behave much closer to real services.

ℹ️ Note: Microcks already supported Groovy-based dispatchers in earlier releases. JavaScript is now offered as an alternative, making it easier for teams who prefer JS or want to align dispatcher logic with front-end or Node.js skills.

Setting up Microcks locally​

To get started quickly, you’ll need Docker Compose. This sample command will give you a demo working environment in a one-liner:

echo 'services:
  mongo:
    image: mongo:4.4.29
  app:
    depends_on:
      - mongo
    image: microcks/microcks
    ports:
      - "8080:8080"
    environment:
      - SPRING_DATA_MONGODB_URI=mongodb://mongo:27017
      - SPRING_DATA_MONGODB_DATABASE=microcks
      - KEYCLOAK_ENABLED=false' | docker compose -f - up

Once Microcks is up, try this quick path:

1. Open http://localhost:8080 in your browser
2. Go to Microcks Hub -> MicrocksIO Samples APIs -> Pastry API - 2.0
3. Hit Install -> + Direct Import
4. In the left panel, open APIs | Services
5. Pick API Pastry - 2.0 -> select the second endpoint ⋮ (three dots) -> Edit Properties
6. Scroll down and set Dispatcher to JS ✅

Introducing JavaScript dispatchers​

Now comes the fun part. In your API definition, you can attach a JavaScript dispatcher script. This script inspects incoming requests and decides which example response to serve.

Example: dispatch by path parameter and Accept header​

We’ll attach a script that looks at the name path parameter and the Accept header to choose the appropriate example. For Eclair Cafe, we’ll return a JSON or XML variant depending on the requested content type; for anything else, we’ll default to Millefeuille.

const contentType = mockRequest.getRequestHeader("Accept").toString();
const nameParam = mockRequest.getURIParameter("name");

if (nameParam === "Eclair Cafe") {
  if (contentType === "text/xml") {
    return "Eclair Cafe Xml";
  } else {
    return "Eclair Cafe";
  }
}

return "Millefeuille";

Try the following requests against API Pastry - 2.0:

curl -X GET 'http://localhost:8080/rest/API+Pastry+-+2.0/2.0.0/pastry/Eclair+Cafe' -H 'Accept: application/json'

Returns:

{
  "name": "Eclair Cafe",
  "description": "Delicieux Eclair au Cafe pas calorique du tout",
  "size": "M",
  "price": 2.5,
  "status": "available"
}

Requesting XML:

curl -X GET 'http://localhost:8080/rest/API+Pastry+-+2.0/2.0.0/pastry/Eclair+Cafe' -H 'Accept: text/xml'

Returns:

<pastry>
    <name>Eclair Cafe</name>
    <description>Delicieux Eclair au Cafe pas calorique du tout</description>
    <size>M</size>
    <price>2.5</price>
    <status>available</status>
</pastry>

And the default variant when requesting another pastry name:

curl -X GET 'http://localhost:8080/rest/API+Pastry+-+2.0/2.0.0/pastry/Millefeuille' -H 'Accept: application/json'

Returns:

{
  "name": "Millefeuille",
  "description": "Delicieux Millefeuille pas calorique du tout",
  "size": "L",
  "price": 4.4,
  "status": "available"
}

Tweaking the script is easy (with server-side logging)​

One of the benefits of JavaScript dispatchers is how quickly you can iterate: update the snippet, save, and re-run the same requests. You can also add server-side logs with the built-in log.info to trace what’s happening:

const accept = mockRequest.getRequestHeader("Accept").toString();
const name = mockRequest.getURIParameter("name");
log.info(`Dispatching for name=${name}, accept=${accept}`);

if (name === "Eclair Cafe" && accept === "text/xml") {
  log.info("Returning XML example for Eclair Cafe");
  return "Eclair Cafe Xml";
}

return "Millefeuille";

Check your Microcks container/server logs to see these messages and understand which path the script took.

Why it matters​

With JavaScript dispatchers, Microcks becomes much more flexible:

• Dynamic behavior – responses vary depending on request context
• Richer test scenarios – simulate more realistic API flows
• Fewer examples needed – reuse existing payloads with smart logic
• Maximum availability - works in standard, uber, and native-compiled distributions of Microcks

This makes it easier to mock APIs for contract testing, early integration, or even demos where you want your mock to “feel alive”.

Next steps​

We’ve only scratched the surface here. In the full documentation, you’ll find:

• How to write and attach dispatcher scripts
• The full request/response object model is available in scripts
• Examples covering REST, gRPC, and event-based APIs

👉 Check the official documentation for more details and start experimenting with your own mocks.

Our platform relies heavily on an event-driven architecture running on Google Cloud. While this is powerful in production, it creates friction for our "inner loop" development. Developers often have to connect to real cloud resources just to test a single microservice, which means managing complex credentials, spending time waiting for cloud resources to deploy, and incurring cloud costs for every test run.

We want to shift our testing left, enabling our engineers to spin up a transaction flow simulation on their laptop, completely offline. We want to publish mock payment events, verify how services consume them, and iterate instantly without waiting for a cloud deployment.

However, Microcks couldn't be used with the Google Pub/Sub emulator, so I've recently contributed a new feature to Microcks to bridge this gap.

What is the use case?​

The use case is simple: Local Development without the Cloud.

Developers often use tools like LocalStack to mock AWS services (like SQS or SNS) locally. We wanted the same seamless experience for Google Pub/Sub.

Previously, Microcks' Google Pub/Sub implementation assumed it was always talking to the real GCP service. It required a Service Account key file and valid authentication to a real Google Cloud project. This is great for integration testing in a staging environment, but for a developer working offline or trying to keep their setup lightweight, it was a blocker.

With this change (introduced in PR #1851, available from v1.13.1), Microcks can now detect and connect to a local Google Pub/Sub emulator. This allows you to publish mock messages from Microcks directly to the emulator.

Example Use Case​

Let's look at how to set this up. The magic happens by configuring the Microcks Async Minion to recognise the standard PUBSUB_EMULATOR_HOST environment variable.

1. The Setup​

First, you need a docker-compose.yml that spins up Microcks (and its Async Minion) alongside the Google Pub/Sub emulator.

Here is the Docker Compose configuration you can use to get started:

services:
  microcks:
    image: quay.io/microcks/microcks-uber:1.13.1
    ports:
      - "8080:8080"
    environment:
      - ASYNC_MINION_URL=http://microcks-async-minion:8081 # Link to Async Minion
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/api/health"]
      interval: 10s
      timeout: 3s

  microcks-async-minion:
    image: quay.io/microcks/microcks-uber-async-minion:1.13.1
    ports:
      - "8081:8081"
    environment:
      - ASYNC_PROTOCOLS=,GOOGLEPUBSUB # Enable Google Pub/Sub support
      - MICROCKS_HOST_PORT=microcks:8080 # Link to Microcks
      - PUBSUB_EMULATOR_HOST=pubsub-emulator:8681 # Link to Pub/Sub Emulator
    depends_on:
      microcks:
        condition: service_healthy
      pubsub-emulator:
        condition: service_started
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8081/q/health/ready"]
      interval: 10s
      timeout: 3s

  pubsub-emulator:
    image: gcr.io/google.com/cloudsdktool/cloud-sdk:441.0.0-emulators
    command: gcloud beta emulators pubsub start --host-port=0.0.0.0:8681 --project=my-project
    ports:
      - "8681:8681"

Running this with docker compose up should result in a local Microcks environment that you can access the Web UI at http://localhost:8080

2. The AsyncAPI Specification​

You don't need to change your AsyncAPI specification to support this! That’s the beauty of it. Microcks uses the same contract definition whether you are targeting production GCP or your local emulator.

Here is the AsyncAPI file we are using for this example:

asyncapi: 3.0.0
id: 'urn:io.microcks.example.hello-microcks'
info:
  title: Hello Microcks API
  version: 1.0.0
  description: Example showing a simple pub/sub message
defaultContentType: application/json
channels:
  helloEvents:
    address: microcks/hello
    description: Topic with Hello events
    bindings:
      googlepubsub:
        schemaSettings:
          encoding: json
          name: projects/my-project/topics/my-topic
    messages:
      hello.message:
        description: A simple Hello event message
        traits:
          - $ref: '#/components/messageTraits/commonHeaders'
        payload:
          type: object
          properties:
            greeting:
              type: string
              const: hello
            fullName:
              type: string
            sentAt:
              type: string
        examples:
          - name: microcks-example
            summary: Hello to Microcks example message
            payload:
              greeting: hello
              fullName: Microcks
              sentAt: '{{now()}}'
            headers:
              version: 1
          - name: random-example
            summary: Example message with random name
            payload:
              greeting: hello
              fullName: '{{randomFirstName()}}'
              sentAt: '{{now()}}'
            headers:
              version: 2

operations:
  receivedHellos:
    action: receive
    channel:
      $ref: '#/channels/helloEvents'
    summary: Receive hellos
    messages:
      - $ref: '#/channels/helloEvents/messages/hello.message'
components:
  messageTraits:
    commonHeaders:
      headers:
        type: object
        properties:
          version:
            type: integer
            minimum: 0
            maximum: 10

This spec has two example messages, one with the fullName field set to “Microcks” and another with a random name for each message.

How you can verify it's working​

Once you have your stack running, verification is straightforward.

Import your API​

Import the AsyncAPI definition above into Microcks using the Web UI uploader at http://localhost:8080/#/importers

Check the logs​

If you look at the logs for the microcks-async-minion container, you should see that it has detected the emulator configuration and is outputting mock message.

...snip...
[io.git.mic.min.asy.pro.GooglePubSubProducerManager] (QuarkusQuartzScheduler_Worker-9) Using Google PubSub emulator at pubsub-emulator:8681
[io.git.mic.min.asy.pro.GooglePubSubProducerManager] (QuarkusQuartzScheduler_Worker-9) Publishing on topic {HelloMicrocksAPI-1.0.0-receivedHellos}, message: {"greeting":"hello","fullName":"Microcks","sentAt":"1767870113823"}
...snip...

Receiving Messages​

You can use a local subscriber script to confirm that messages are arriving.

Here is a simple python script that streams messages from the topic

from google.cloud import pubsub_v1
from google.api_core.exceptions import AlreadyExists, NotFound

PROJECT_ID = "my-project"
TOPIC_ID = "HelloMicrocksAPI-1.0.0-receivedHellos"
SUBSCRIPTION_ID = "stream-out-py"

def get_or_create_subscription(project_id, topic_id, subscription_id):
    """
    Creates a subscription if it doesn't exist, then returns the path.
    """

    subscriber = pubsub_v1.SubscriberClient()
    publisher = pubsub_v1.PublisherClient()

    topic_path = publisher.topic_path(project_id, topic_id)
    subscription_path = subscriber.subscription_path(project_id, subscription_id)

    with subscriber:
        try:
            subscriber.create_subscription(
                request={"name": subscription_path, "topic": topic_path},
            )
            print(f"Created new subscription: {subscription_path}")
        except AlreadyExists:
            print(f"Subscription already exists: {subscription_path}")
        except NotFound:
            print(f"Error: The Topic '{topic_id}' does not exist. Please create the topic first.")
            raise

    return subscription_path

def receive_messages(sub_path):
    """Receives messages from the subscription."""

    def callback(message):
        print(f"Received: {message.data.decode('utf-8')}")
        message.ack()

    subscriber = pubsub_v1.SubscriberClient()
    stream = subscriber.subscribe(sub_path, callback=callback)
    print(f"Listening for messages...\n")

    with subscriber:
        stream.result()

if __name__ == "__main__":
    sub_path = get_or_create_subscription(PROJECT_ID, TOPIC_ID, SUBSCRIPTION_ID)
    receive_messages(sub_path)

Running this with the environment variable PUBSUB_EMULATOR_HOST pointing at our emulator

PUBSUB_EMULATOR_HOST=localhost:8681 python stream.py

Will output live message events

Created new subscription: projects/my-project/subscriptions/stream-out-py
Listening for messages...

Received: {"greeting":"hello","fullName":"Microcks","sentAt":"1767870122753"}
Received: {"greeting":"hello","fullName":"Josie","sentAt":"1767870122759"}
Received: {"greeting":"hello","fullName":"Microcks","sentAt":"1767870125757"}
Received: {"greeting":"hello","fullName":"Merlin","sentAt":"1767870125762"}

🥳

Summary​

This small but mighty change opens up a smoother local development workflow for anyone building event-driven systems with Google Cloud. For us at Dojo, it means faster iterations and happier developers. By supporting the native Pub/Sub emulator, Microcks continues to be the most versatile tool for mocking and testing, no matter where your infrastructure lives, in the cloud or on your machine.

I hope this helps you streamline your testing loops! If you have any questions or feedback, feel free to reach out on GitHub.

Happy Mocking! 🚀

2025 has been a transformational year for Microcks. It drove massive adoption growth, fostered deeper ecosystem collaborations, strengthened community ownership, and facilitated global expansion. It also reinforced our belief in open source, better-together principles and cloud native collaboration.

Let’s look back at some of the highlights before we step confidently into 2026.

🚀 Microcks in Numbers​

2025 clearly exceeded our expectations and our KPIs across almost every dimension:

Microcks is no longer just growing; it’s scaling globally.

• 📦 2.5+ million container image downloads in 2025, compared to 850k total downloads in 2024. That’s more than 3× growth year over year.
• 🔗 3,300+ LinkedIn followers, with +700 new followers in 2025, showing steady and organic growth.
• ⭐ 1,800 GitHub stars on the main repository (+300 in 2025). While this is solid progress, we believe there’s much more potential here, and we welcome ideas from the community to help amplify this metric.
• 🏢 34 public adopters in total. We’re especially grateful to the 13 organizations that joined the public adopters list in 2025. Public references are critical for open source sustainability, and we warmly invite private adopters to help the project and the community by adding themselves 🙏 here.
• 🌍 Global expansion continues, with new users across all regions. Microcks documentation traffic insights from Scarf.sh and Google Analytics confirm strong worldwide adoption growth throughout the year.

🙌 Community Contributions​

Open source lives and thrives through its people, and 2025 proved once again how strong the Microcks community is!

❤️ The Heart of Microcks​

A huge thank you to Harshvardhan Parmar from the Yosemite Crew, who became a Code Owner (Domain Maintainer) for the Microcks CLI.

This recognition highlights his outstanding contributions, technical leadership, and ongoing impact on the project 👏

Harshvardhan joins Sébastien Degodez (AXA France), Code Owner of the Testcontainers .NET library since 2024, and leads the Microsoft Aspire integrations.

This growing maintainer base, backed by dedicated individuals and organizations, is a cornerstone of the project’s long-term sustainability.

📊 Contributor Growth in 2025​

Behind the numbers lies what matters most to us: a strong, collaborative, and invested community. Microcks continues to grow thanks to a diverse group of contributors who not only use the project but also actively help shape it.

What we are particularly grateful for is that many of our contributors are also adopters of Microcks. These individuals and organizations rely on Microcks in real-world, business contexts, and they clearly understand a fundamental open source principle:

If you like and depend on a project, you should invest in it.

This mindset is incredibly powerful. It means improvements are driven by real needs, feedback is grounded in practice, and the project evolves in ways that directly benefit the broader community. As maintainers, we couldn’t agree more with this approach, and we deeply appreciate and support the organizations that choose to contribute back.

In 2025, this collaboration translated into:

• 167 active contributors
  What it represents: unique individuals contributing code, reviews, issues, documentation, and ideas throughout the year.
  Why it matters: this reflects a vibrant, healthy, and engaged community where innovation is shared and collective.

• 35 active organizations
  What it represents: contributors affiliated with a wide range of companies and institutions.
  Why it matters: this diversity strengthens the project’s resilience, reduces dependency on any single entity, and ensures long-term sustainability.

👉 For more informations and metrics: Microcks, a CNCF project, LFX Insights and CLOMonitor.

These numbers are more than metrics; they are proof of shared ownership, mutual trust, and a community that believes in building Microcks together. We are deeply grateful to every contributor and organization for their ongoing commitment and collaboration.

🌟 Ecosystem Collaborations​

2025 was a year of deep and meaningful ecosystem collaborations, reinforcing our belief that integration beats isolation 👍 Better Together 🤝

Dapr​

A fantastic collaboration with the Dapr community, including:

• CNCF blog post: "Cloud Native App Local Development Made Easy with Microcks and Dapr" and Live demo and discussion during a Dapr Community Call.

Score​

Great collaboration with Mathieu Benoit, maintainer of the Score project, exploring how our projects are better together with more planned for 2026 (talk at KubeCon EU 2026).

AsyncAPI Generator​

Microcks now provides acceptance testing infrastructure for the AsyncAPI Generator:

• Generated clients are tested against Microcks mocks at PR level
• Initially, for WebSockets, with Kafka support coming next

This is a powerful example of Microcks enabling confidence in API tooling ecosystems.

Observability & OpenTelemetry 🔭​

In 2025, we integrated OpenTelemetry directly into the Microcks engine, enabling:

• Live Traces and Improved observability for API testing workflows 👉 https://microcks.io/blog/microcks-1.13.0-release/

These partnerships demonstrate how Microcks enhances local development and testing experiences in cloud-native architectures, and how CNCF projects can join forces to deliver greater value to end users.

Traefik Labs​

Traefik Labs introduced a Sandbox-as-a-Service offer, powered by Microcks and our new Kubernetes Operator. What a great demonstration of a fully GitOps-driven workflow.

APIquality​

APIquality now uses Microcks as a backend service in their offering, along with professional training: https://apiquality.io/apimocking-microcks/

These provide strong validation of Microcks’ role in production-grade cloud native environments.

🎤 Communication & Knowledge Sharing​

Microcks continued to gain visibility through talks, meetups, conferences, and community events, thanks to our amazing contributors and advocates.

Highlights include:

• Spring I/O: “Simplifying cloud-native app testing across environments” by Mauricio Salatino from Diagrid & Laurent Broudoux.
• KubeCon NA Atlanta: "Simplifying Cloud Native App Testing Across Environments" presenting how Dapr ✚ Microcks enhance developer experience by Laurent Broudoux & Artur Ciocanu) from Adobe.
• Devoxx Belgium: two talks, see the recording of the session “Smart API sandboxes: why? what? how?”.
• Cloud Native Pune Meetup: Thanks to Pratik Mahalle for his talk “From Chaos to Confidence: How Microcks Brings Order to Modern API Testing”.

And many more talks at: Cloud Nord 🇫🇷, Amadeus Engineering Days, AXA 🇫🇷 meetups… and more!

👉 Follow us on LinkedIn to catch recordings and announcements.

💡 Looking Ahead: 2026​

Open source is not the easiest path, but it is the one we deeply believe in, and as we enter 2026, our goals are clear:

• Continue growing the contributor and adopter base
• Strengthen ecosystem integrations
• Improve observability, scalability, and developer experience
• Continuing discussions started at KubeCon NA 2025 Maintainer Summit
• And, give back to the cloud native community

🌱 A Major Milestone Ahead​

One of the important objectives for 2026 is our application to move Microcks from CNCF Sandbox to Incubation. We started this work more than a year ago, and we’re looking forward to reviews and collaboration with the CNCF TOC.

This step would be a huge milestone for the project, and we’ll keep you posted every step of the way. See all details on this GitHub issue: https://github.com/cncf/toc/issues/1552 👀

👥 Join Our Community Meetings​

Don’t forget to join our two monthly community meetings, designed to accommodate multiple time zones and open to everyone.

Thank you for being part of this journey. Here’s to a healthy, innovative, and impactful 2026 🥂

Let’s keep building the future of API mocking and testing together.

This release brings exciting new features and enhancements that focus on improving the developer experience, debugging, and overall usability. We've listened to your feedback and are proud to deliver a version that makes working with Microcks even more intuitive and powerful.

As we recently celebrated 10 years of Microcks and the ascent achieved, and as usability is the main theme, we found it natural to illustrate this release with a summit and a quiet, dark yet highly visible night. Here are the related highlights:

• A new Dark UI theme, Drag & Drop zones, and Quick imports let you bend Microcks to your own preferences, style, and workflow!
• Observability everywhere with the addition of Live Traces in the mocking engine - makes the tuning and debugging experience a breeze!
• The integration of a JavaScript engine that lets you implement your own mock matching logic in a super user-friendly way - for both standard, uber, and native-compiled distributions of Microcks!

This new release is also the largest so far, with over 80 resolved issues and 12 contributors! Kudos to all of them 👏 and see the greetings in the notes below.

Let’s start with the most noticeable enhancements from a user perspective!

Dark theme and UI enhancements​

For those who prefer a more subdued interface, we're excited to introduce a brand-new dark theme! This highly requested feature offers a comfortable viewing experience, particularly during extended coding sessions, and aligns with the aesthetics of modern development environments. Hit the top-right corner moon or sun icon, and you’ll switch the UI from light to dark theme:

Thanks a lot to Apoorva64 🙏 for refactoring our stylesheets and introducing CSS variables that ease building this theme. By the way, we’re still looking for seasoned UI artist suggestions and help to polish it! 🎨

To streamline the workflow of importing local files to Microcks, we have also updated the entire application to enable drag-and-drop functionality. Just drag files from your desktop or file explorer on the UI, and you’ll see it change like below:

Releasing your drag now directly opens up a Quick Import dialog prefilled with file information:

This Quick Import is also directly available from the top-right corner of the menu bar and also allows you to tell Microcks to directly download remote artifacts:

Importing your API definitions and mock data is now faster and more intuitive, reducing the setup time and letting you get to testing quicker!

Thanks again to Apoorva64 🙏 for bringing these nice ideas and contributing it!

Observability with Live Traces​

When working with Microcks, users often faced the challenge of understanding why a request was matched (or not matched) and of debugging issues during dispatching. It can be sometimes difficult to understand the reasoning behind request/response matching or simply get access to the logs and identify the relevant parts.

Debugging and tuning your API mocks and tests just got a whole lot easier with the introduction of Live Traces. This powerful new feature provides real-time insights into how your mocks are being processed, allowing you to identify and resolve issues quickly. You can now see the exact flow of requests and responses, understand dispatcher decisions, and pinpoint any discrepancy in the logic.

A new Live Traces foldable panel is now available within each operation's details. You need to Connect first, and as soon as the mock endpoint is hit, you’ll receive new Trace details as illustrated below:

A Trace can be expanded to review the full details of the request matching decision process:

Ever wondered which user or application was calling which mock endpoints within a specific orchestration? We got you covered as well! As the mocking engine is now instrumented, whatever the mock protocol, you can now visualize and collect the traces from a user perspective using the new Live Traces page from the left menu bar:

The Live Traces feature is implemented by leveraging the OpenTelemetry model of distributed traces and spans. Actually, the entire Microcks engine has been reconfigured to contribute additional spans and events to provide all the details needed to follow and track the requests. As a consequence, this also means that these extra details are exported and made visible in your favorite OpenTelemetry stack and dashboards!

Thanks again to Apoorva64 🙏 for designing and implementing this! Your support for debugging and making it work with an external OTEL collector in the days before the release was much appreciated!

New JavaScript engine integration​

The existing SCRIPT dispatcher is a super flexible way of adding smartness to your dispatching logic and simulating complex business behavior. Over the years, we heard about people extending scripting with libs, performing complex computations for more dynamic responses. We also implemented the stateful mocks features on top of it and made recent huge performance improvements. However, we had an issue. The SCRIPT dispatcher is not working on our new native-compiled container images we provided since Microcks 1.9. What at first seems anecdotic, now becomes "a problem" because of the success of these images 😉 and more globally of the *uber *distribution (more than 60k fresh downloads just on October 2025 🚀 )

We started explorations on this topic during the Spring, investigating what can be done to solve this issue, and it appears that Groovy would never be able to play well in native mode…

Thanks to Andrea Peruffo 🙏, we discovered QuickJs4J that brings the lightweight QuickJS JavaScript engine to both the JVM and the native-compiled worlds. By running code in a sandbox, QuickJs4J ensures memory safety, prevents system access, and offers portability and native-image friendliness. We decided to give it a try, and Andrea successfully implemented a solid integration!

You can now use our new JavaScript JS engine in all Microcks distributions! From the standard, full-featured one running on a JVM to the lightweight, uber distribution running as a native-compiled binary and starting in 200ms! Moreover, with the addition of JavaScript, Microcks now supports a truly mainstream scripting language.

See how expressive a JS dispatching script can be:

const testCase = mockRequest.getRequestHeader("testcase")[0];
log.info("testCase: " + testCase);
if (testCase !== undefined) {
  switch (testCase) {
     case "1":
        return "negative amount";
     case "2":
        return "null amount";
     case "3":
        return "positive amount";
     case "4":
        return "standard amount";
  }
}
return "standard amount";

And how easy it can be to manipulate persistent information to implement stateful mocks on Microcks:

const foo = store.get("foo");
const bar = store.put("bar", "barValue");
store.delete("baz");

Check out our updated documentation on JavaScript scripting in Microcks to get you started! There’s no plan to discontinue the existing SCRIPT dispatcher, but we encourage you to rename your dispatcher to the new GROOVY for better clarity. Thanks again to andreaTP 🙏 for this great contribution!

However, we know that integrating yet another engine would not solve all the usability issues we had with scripting. We heard how painful it could be to tune and troubleshoot this script. And then, we decided to combine our new Live Traces feature with the script editing experience!

When editing a JS (or a GROOVY) script from the Microcks UI, you can now rely on embedded Live Traces to give you immediate feedback on whether your script is working correctly or not! Just save your script and hit the Try it now! play-style button you’ll find on available responses. The Microcks UI then immediately acts as a mock consumer, and you should see a new Trace appear below!

And the nice thing is that all the log.info() statements from the script are directly embedded into the Trace details! What if your script doesn’t compile or misbehaves? We got you covered here, displaying the corresponding Trace in red with failure details and complete stacktrace:

Tuning and troubleshooting custom scripts in Microcks has never been so easy! 🔥

Other improvements​

As mentioned in the introduction, this release is the largest in Microcks' history in terms of features and contributions. There are many improvements worth noting as well! Here’s a non-exhaustive list:

• Support of complex dependency resolution on Protobuf imports - see #449,
• Support of mongodb+srv:// protocol for connecting to MongoDB Atlas - see #1791,
• Support of AWS IRSA and pod identity for connecting to SQS and SNS - see #1789 and #1790,
• Support of 2025-06-18 protocol for MCP endpoints - see #1724,
• New delay strategies to allow random latency simulation - see #1591 and thanks to SebastienDegodez 🙏 for the contribution,
• Add formData definition support in OpenAPI - see #1688 and thanks to varkart 🙏 for the contribution,
• Add export of samples in APIExamples format - see #1639,
• Support of defaults when evaluating null or blank values in templates - see #1667,
• Add cookie definition support in OpenAPI - see #1626

For the comprehensive list of changes and enhancements, please be sure to check the milestone details on GitHub.

What’s coming next?​

As we conclude this huge release, we extend our heartfelt thanks to all the contributors and adopters. Your dedication, enthusiasm, and valuable contributions have significantly enriched the Microcks project.

Let’s continue moving forward with joy and fun, pushing Microcks to new summits! You can check and collaborate on our GitHub issues list and the project roadmap. Please join us to shape the future!

Remember that we are an open community, which means you, too, can jump on board to make Microcks even greater! Come and say hi! on our GitHub discussion or Discord chat 👻, send some love through GitHub stars ⭐️ or follow us on BlueSky, X, Mastodon, LinkedIn, and our YouTube channel!

Thanks for reading and supporting us! ❤️

Photo by Diva Plavalaguna from Pexels

The Reality Behind the Code​

For years, the Microcks team of contributors and maintainers has dedicated countless hours to creating, enhancing, and maintaining Microcks. They have handled complex bugs, responded to support requests, and continuously improved the platform to satisfy the expanding demands of API mocking and testing.

This work has been done without financial compensation, driven purely by passion for creating valuable tools for the developer community.

The numbers tell a story:

• Thousands of downloads
• Hundreds of GitHub stars
• A growing user base that spans startups to enterprise organizations

Microcks has become integral to many development workflows, saving teams countless hours and enabling better API development practices.

The Silent Users​

Yet, despite this adoption, we've noticed something troubling: many users remain silent beneficiaries.

They download, deploy, and benefit from Microcks, but the response is often silent when we reach out for feedback, feature requests, or documentation help.

This creates a paradox: while usage metrics climb, lack of engagement makes it difficult to prioritize development, understand real-world pain points, or build the collaborative ecosystem that makes open source sustainable.

We find ourselves making decisions in a vacuum, unsure if we’re solving the right problems.

This isn't about demanding gratitude. We know not everyone can contribute code, but there’s a vast middle ground between passive consumption and active development.

The Cost of Silence​

This one-sided relationship creates challenges:

• Sustainability concerns – When maintainers burn out or move on to other projects, there's often no one ready to step up. The knowledge and passion that built the project can disappear overnight.
• Innovation stagnation – Without diverse input from real users, we're essentially developing in an echo chamber. We miss crucial use cases, overlook pain points, and may focus on features that sound good in theory but don't address real-world needs.
• Community fragmentation – A healthy open source project builds a community, not just a user base. Without engaged users, we risk losing the collaborative spirit that makes open source powerful.
• Recognition deficit – While we don't seek fame, visibility helps attract new contributors, secures funding opportunities, and validates the time we invest in the project.

Simple Ways to Give Back​

Contributing to Microcks (and any open source project) doesn’t require being a coding wizard. Here are meaningful ways to support the community:

• Spread the word: Share your success stories, write blog posts about how Microcks solved your problems, or mention it in relevant discussions. Word-of-mouth is incredibly powerful.

• Engage authentically: Star the repository, participate in discussions, attend community calls, or join our Slack/Discord. Your presence and voice matter.

• Documentation contributions: Did you find something confusing? Noticed a gap in our docs? Even minor improvements to documentation help countless future users.

• Report issues thoughtfully: When you encounter bugs, report them with details. Good bug reports are contributions that help everyone.

• Answer questions: Share your knowledge if you see someone struggling with something you’ve figured out. Peer support strengthens the entire community.

• Join the adopter community: If Microcks helps your organization, join the public adopter list: https://github.com/microcks/.github/blob/main/ADOPTERS.md.

A Sustainable Future​

We’re not asking for charity,we’re asking for partnership.

Open source works best when it’s truly collaborative, when users become stakeholders in the project’s success. The most successful open source projects aren’t just tools; they’re communities of people who care about solving problems together.

Microcks has reached a critical juncture. We can continue growing as a community-driven project or remain a tool maintained by a few for the benefit of many. The choice isn’t ours alone, it belongs to everyone who has ever benefited from our work.

Your Turn – Join Me in Building These Resources​

If Microcks has helped you ship better software, meet deadlines, or solve API testing challenges, I have specific ways you can help make it even better for everyone. As part of my LFX mentorship project, I’m working on critical resources our community desperately needs, but I can’t complete them without your real-world insights.

Here’s how you can contribute right now:

• Share Your Deployment Details – Help build the Compatibility Matrix (#85) by sharing which versions of Kubernetes, MongoDB, and Keycloak work with your Microcks setup. Your configuration details help others avoid compatibility headaches.
• Contribute Performance Data – Join our Sizing Guide (#86) by running our k6 benchmarks and sharing your results. Whether you’re running Microcks on a laptop or enterprise Kubernetes, your performance data helps teams right-size their deployments.
• Share Security Solutions – If you’ve figured out how to secure Microcks mock endpoints with API gateways, please contribute to our Security Documentation (#51). Your Kong/ AWS API Gateway/ Traefik or NGINX configurations could save someone days of troubleshooting.

The next time you see these issues or similar calls for help, don’t scroll past. Your experience is precisely what we need to build resources that genuinely serve the community.

These are not just documentation requests, they’re opportunities to save others from repeating solved challenges.

👉 Explore our community repository. The community is waiting for your insights to help ensure these initiatives succeed.

✨ Quote from the Maintainer​

“As a maintainer of the Microcks project and mentor to Krishi during the 3-month LFX mentorship program, I was both glad and impressed to see how clearly she articulated one of the core challenges many open source projects face: the gap between being a good open source citizen and users who remain passive or silent.

The project she worked on was a perfect example of something maintainers often can’t take on themselves, as our focus must remain on the project's core objectives. After all, Microcks is an open source initiative, not a commercial product. This means adopters and the community must take responsibility for their deployment environments and requirements.

The future of Microcks depends not just on code commits, but on community commits.

💡 Are you ready to make yours?

This release received no less than 51 new resolved issues. Kudos to all the people 👏 who helped along the way by writing code, commenting on issues, or writing posts. You’ll see that this release focuses on two big topics:

• The addition of Model Context Protocol (MCP) as a first-class citizen in Microcks. It allows all your existing mocks to be available as MCP-enabled endpoints.
• A huge refresh of the frontend stack we were using - we made a giant leap from Angular 8 to Angular 19.

Let’s do a review of what’s new on each one of our highlights without delay.

MCP-enabled mocks for all your APIs!​

You know that API and AI are closely related and that tomorrow—and even today—LLMs and AI agents will be among the top consumers of your APIs. It becomes crucial to be able to check how AI Agents will reuse your API as tools!

Starting with version 1.12.0, Microcks automatically translates your API mocks into Model Context Protocol (or MCP) aware endpoints! A new MCP Server section in the mock properties gives you access to MCP-compatible endpoints to integrate your mocks with your favorite tool.

As you can see in the capture above, Microcks provides two different kinds of endpoints and transports:

• HTTP SSE Endpoint as defined in the 2024-11-05 version of the protocol,
• HTTP Streamable Endpoint as defined in the 2025-03-26 version of the protocol.

Depending on the tool you’re using—we tested MCP Inspector, Postman, Claude or Cherry Studio—you’ll need one or the other endpoint based on how it supports MCP.

The best thing is that, thanks to Microcks' homogeneous support for all API styles and protocols, this is available for OpenAPI and GraphQL APIs as well as gRPC services!

Check our documentation with links to our video demonstrations and test it while it’s hot! 🔥 We’re looking forward to hearing from you!

Frontend stack refresh​

As introduced in this GitHub Discussion, we have known that Microcks UI was at risk for many years now. We depended on the PatternFly design system's Angular library, which was subsequently discontinued by the community in favor of a React Implementation.

This put us in a bad situation because many of pulled transitive dependencies from those foundations are now outdated with a lot of CVEs, as illustrated by the security vulnerabilities report of the frontend part:

Having open discussions always brings fresh ideas and new perspectives! And as I was much more attracted by a complete rewrite, at first, I found the feedback of the community appealing:

• Angular was not that bad and dead and Angular 19 was a very different beast,
• Existing Patternfly Look and Feel experience was still quite good - the only complaint being it was missing a dark theme 🎨,
• Our 2005 architecture hypothesis (pure SPA architecture, no SSR, no real need for SEO) was confirmed.

As a consequence, we adapted our strategy and decided to stick with Angular - processing to a major upgrade - and to update and vendor the Patternfly library to be able to control our future usage of it!

This leads us to major upgrades and tasks like:

• A Typescript upgrade (from version 3.5 to 5.7),
• An Angular upgrade (from version 8 to 19),
• The adoption of the Vite build tool,
• The vendoring of needed Patternfly NG components,
• Upgrade of very old libraries like d3 or c3,
• The replacement of the wizard component reusing the one from Material Angular Theme (🙏 thanks to @soGit for that),

Most importantly, the number of vulnerabilities has dramatically dropped from 103 to 6, and I'm confident we can even reduce it by vendoring Patternfly CSS (only the NG component has been vendored at the moment). And this was our driver number 1 in engaging this refactoring!

What does that mean to all the re-design opportunities and contribution ease we foresee by opening the debate here in this thread? Does it mean we're closing the topics and waiting until the next big maintenance issue to start everything again? Certainly not.

First, we'd be in a better position to welcome incremental enhancements! I think we have a lot on our plates:

• The current UI is too square. Would you like more rounded buttons?
• Are you allergic to light themes, and would you prefer a dark theme?
• Layout and fonts are too "classical" or too much enterprisey?

With the vendoring process, we would have everything at hand to integrate incremental changes to make it look more modern and sexy to users. Please, use your best designing skills and propose new wireframes or Figma arts so that we can study things and build a look & feel theme that represents and supports the Microcks brand! Consistency is key in this kind of change integration.

Community amplification 📣​

We extend our heartfelt thanks to the community for amplifying Microcks' presence in recent events.

At KubeCon + CloudNativeCon Europe 2025, Microcks was featured in two insightful sessions:

• From 0 to Production-Grade With Kubernetes Native Development 🍿 by Thomas Vitale and Kevin Dubois highlights Microcks' role in enhancing the developer experience with Kubernetes-native Java applications.
• Platform Engineering Loves Security: Shift Down To Your Platform, Not Left To Your Developers! 🍿 by Maxime Coquerel & Mathieu Benoit emphasized the importance of integrating security and quality assurance into the platform layer, a strategy that aligns with Microcks' approach within the API lifecycle.

Additionally, we were honored to present at the Dapr Community Call 🍿 on May 14th, where we provided a teaser of the integration value between Microcks and Dapr.

Our collaboration culminated in a comprehensive session at Spring I/O 2025 🍃 in Barcelona, where we discussed simplifying cloud native app testing across environments using Microcks and Dapr. Stay tuned for the recording.

We are grateful for the community's support and enthusiasm, which continues to drive Microcks' evolution in the cloud native ecosystem.

What’s coming next?​

As we conclude the LFX Mentorship Program Term 1, we extend our heartfelt thanks to all our mentees. Your dedication, enthusiasm, and valuable contributions have significantly enriched the Microcks community. We hope this experience has been as rewarding for you as it has been for us.

We will eagerly prioritize items according to community feedback. You can check and collaborate via our list of issues on GitHub and the project roadmap. Please join us to shape the future!

Remember that we are an open community, which means you, too, can jump on board to make Microcks even greater! Come and say hi! on our GitHub discussion or Discord chat 👻, send some love through GitHub stars ⭐️ or follow us on BlueSky, X, Mastodon, LinkedIn, and our YouTube channel!

Thanks for reading and supporting us! ❤️

Our French Retail Banking entity (BCEF) is driving this change, with Microcks, a Cloud Native Computing Foundation (CNCF) Sandbox project, playing an instrumental role.

In this post, we share our strategic and confident implementation of Microcks to mock internal APIs and offload mainframe core banking services. This approach has accelerated our development and validation processes and led to substantial financial savings and sustainability gains. This post explores how BNP Paribas leads the charge in greening the cloud.

Innovating Within a Legacy System​

Like many large financial institutions, BNP Paribas operates in a complex infrastructure and highly regulated environment, including legacy systems such as mainframes. These mainframes are the backbone of our core banking services, processing millions of daily transactions. While our environment is reliable and secure, it presents challenges regarding agility, scalability, and cost-effectiveness in a cloud-first world.

Nadji Berraf - Head of Software Expertise Center & Cloud Leader at BNPP:

Developing and validating new features or services on these mainframes can be time-consuming and resource-intensive. Each test or development cycle consumes significant computational power and storage, fueling costs, and energy consumption.

To address these challenges, we needed a solution that would enable us to speed up our development processes while reducing the environmental impact and operational costs.

How BNP Paribas Leverages Microcks​

Microcks is an open source project designed to create mock or simulated versions of APIs and microservices. These mocks allow developers to test their code against realistic scenarios without accessing the production backend services.

Patrick Jacob - Chapter Lead Automation Lab (BCEF IT – Center of Excellence for Software & Design Authority):

As a CNCF Sandbox project, Microcks is cloud native, making it ideal for modern IT infrastructures using Kubernetes that prioritize scalability, flexibility, and environmental sustainability.

Microcks deployment architecture at BNP Paribas.

Six units have access to Microcks (operational units of the French IT department):

✅ 32 squads driving innovation

✅ 29 applications seamlessly integrated

✅ 356 mocks & 1628 API operations ensuring reliability

1. Offloading Mainframe Core Banking Services​

We use Microcks to offload traffic from our mainframe by mocking the banking services that are exposed via REST/HTTP APIs.

Previously, our developers and testers had to interact directly with the mainframe to validate API integrations or test new features. This process was slow and placed unnecessary strain on the mainframe.

Core Banking API Mocking with Microcks.

With Microcks, we can create realistic mocks of our core banking services and allow our developers to build and test integrations without accessing the mainframe. This approach speeds up the development process and frees up mainframe resources.

2. Accelerating Development and Validation​

Time-to-market is crucial in the financial industry, where being the first to launch a new feature or service can provide a significant competitive advantage. The traditional development and validation processes, especially those dependent on legacy systems, can be slow.

Microcks enables us to simulate dynamic API endpoints, allowing our developers to test their code against realistic scenarios without waiting for backend services to become available. This parallel development approach reduces bottlenecks, speeds up the release cycle, and thoroughly tests new features before deployment.

3. Performing Heavy Benchmarks with Simulated Latency​

Benchmarking and stress testing are essential to ensure that our systems can handle high loads and unexpected spikes in demand. However, conducting these tests directly on the mainframe can be complex and costly.

Microcks allows us to simulate production-like conditions, including introducing latency in API responses. Replicating mainframe behavior in a controlled environment ensures robust and reliable applications while correctly sizing production infrastructure resources.

4. Driving Sustainability with Reduced Energy Consumption​

Sustainability is at the core of BNP Paribas' IT strategy. By offloading API requests from the mainframe and utilizing mocked services, we have significantly reduced the computational load on our legacy systems.

This reduction in mainframe usage not only cuts operational costs but also significantly decreases energy consumption, contributing to a reduction in carbon footprint and supporting the organization's sustainability and green IT goals.

Overcoming Challenges on the Path to Success​

Implementing new technology within a large, established organization like BNP Paribas is challenging. However, the benefits of adopting Microcks far outweighed any initial hurdles.

How Microcks fits in BNP Paribas CI/CD pipelines.

1. Integrating with Existing Systems​

Although Microcks works seamlessly with modern systems, we needed to carefully plan to ensure compatibility with our highly secure and controlled on-premises private cloud. So, one of our first challenges involved integrating Microcks with our existing infrastructure.

By collaborating closely with the Microcks community and leveraging the project's extensive documentation, we successfully integrated Microcks into our environment.

2. Ensuring Realistic Mocking​

Another challenge was ensuring that the mocked APIs were realistic enough to be helpful. We needed to replicate the behavior of our core banking services accurately, including handling edge cases and unexpected inputs. Microcks' support for dynamic and stateful mocks proved invaluable, allowing us to create highly realistic simulations that meet our exacting standards.

3. Educating the Team​

Adopting a new tool requires buy-in from our development and testing teams. We invested in training and workshops based on Microcks documentation to ensure our teams were comfortable using Microcks and fully understood its benefits. This investment paid off as our teams quickly recognized the advantages of mocked services over dedicated platforms for every test.

Realized Benefits: Financial Savings and Sustainability Gains​

Adopting Microcks has brought several tangible benefits to BNP Paribas.

1. Significant Cost Savings​

We have substantially saved costs by reducing our reliance on mainframe systems for development and testing. Mainframe operations are expensive, and by offloading a significant portion of this workload to Microcks, we have considerably reduced our operational costs.

2. Accelerated Development Cycles​

Microcks has enabled us to accelerate and helped cut our development and testing cycles by two-thirds. This agility and the ability to deploy mock sandboxes everywhere, ready to use, have allowed us to quickly bring new features to market, providing us with a competitive edge in the fast-paced financial industry.

3. Enhanced Sustainability​

One of the most significant benefits of adopting Microcks is reducing energy consumption. By minimizing the use of mainframe resources, we have significantly reduced our carbon footprint, directly contributing to our sustainability goals. This reduction supports our broader corporate environmental responsibility strategy and reinforces BNP Paribas’s position as a leader in sustainable IT practices.

By early 2025, 32 squads had onboarded, with 10 squads relying on Microcks daily. Over 500 developers and testers actively optimized APIs using the platform.

Proven at scale with real-world usage:

✅ Over 2.5 million API calls per week

Conclusion: A Success Story in Sustainable IT​

BNP Paribas' journey with Microcks is a testament to the power of innovative technology in driving business success and sustainability. By leveraging Microcks to mock internal APIs, offload mainframe services, and simulate production-like conditions, we have accelerated our development processes and achieved significant financial savings and sustainability gains.

As a Cloud Native Computing Foundation project, Microcks continues to play a pivotal role in our IT strategy, helping us meet our goals of agility, cost-efficiency, and environmental responsibility. This initiative demonstrates how the financial industry can embrace cloud native technologies to achieve a greener, more sustainable future.

Our experience with Microcks offers valuable insights and inspiration for organizations looking to balance innovation with sustainability. By adopting similar strategies, businesses can reduce their environmental impact while enhancing their competitive edge in the digital age.

Microcks is more than just a tool; it is a key enabler of BNP Paribas' sustainable IT journey, a journey that others in the financial world can learn from and follow!

As we benefit from an upgraded technical stack with the previous release, this 1.11.1 allowed us to focus on usage and performance optimizations. It received no less than 22 new resolved issues that concentrate on three different areas:

• The streamlining of our AI Copilot features to allow using it at Scale,
• The tuning of the Uber distribution container images to achieve un-precedent startup times that will bring developers joy when used with Testcontainers,
• The optimization of our CI/CD pipeline to reduce build time, energy consumption, and feedback loop for contributors.

Kudos to our community 👏, and let’s dive in without further ado.

AI Copilot at Scale!​

AI Copilot is present in Microcks for a few releases but it was more of an an experiment. We’ve worked a lot on making things more robust, enhancing the LLM prompts and response analysis (see issue #1507) and we now streamline its usage.

We focused on the following user story that is now a breeze with Microcks:

• As a user, load a raw spec in Microcks (it could be OpenAPI, AsyncAPI, gRPC, or GraphQL): no mocks are available.
• Hit the AI Copilot button and Microcks will generate realistic samples for all the operations and response codes. This is done asynchronously and enhances your API definition with ready-to-use mocks!
• Filter and export those samples: as an APIExamples artifact or as an OpenAPI Overlay artifact for REST APIs,
• Share this artifact with your teammates, partners, or customers,
• Allow them to build rich sandboxes with Microcks and reuse samples for API-drift testing!

Better than a long speech, we recorded a video to demonstrate this:

This feature will lower the entry bar and bring tremendous acceleration in the adoption of mocking! We’re looking forward to hearing from you on this! BTW, it’s also the first time we recorded such a demonstration, let us know if you like it and want more! 🙏

Faster Uber distribution startup​

The Uber container images received two important optimizations with this 1.11.1 release.

The most significant one is for the Uber Async Minion container image which is in charge of asynchronous features support in Microcks. We now distribute a new flavor of this image which uses GraalVM native compilation. Just append -native to the image name and see the enhancements:

• From 1.4 sec to 140 ms startup time: 10x startup boost!
• From 217 MB to 136 MB: a 35% reduction in image size!

The main Uber container image also improves the startup time by enabling the Ahead Of Time compilation of the underlying Spring Application. While the image size remains the same, we measured a startup time reduction of roughly 10%—from 2.5 sec to 2.1 sec.

These optimizations bring dramatic enhancements to the developer’s experience when using Microcks on your laptop - typically with Testcontainers. Remember that the Uber container image already comes with the -native flavor and very low startup time (~ 300ms), but people who needed Microcks full features will also be covered with this enhancements on JVM-based flavor.

Optimized CI/CD pipeline​

Even if the CI/CD pipeline optimizations are not directly visible from the end-users point of view, this is a crucial topic that ensures that Microcks contributors can deliver new features faster and with better confidence!

Those optimizations were executed in two steps. The first one focused on reducing the global build time by optimizing the GitHub runners used in the workflow. We previously used amd64 only runners and Docker’s QEMU emulation support when building arm64 container images. We had a very long build time and a workflow that was far from optimized on the energy consumption level. 🪫

Thanks to GitHub's new Arm64 runners, we have been able to remove this emulation layer and reduce the build time from 1h15 to less than 27 minutes! 🔋

The second optimization step targeted the contributor’s workflow. We suffered from inappropriate error reports because some steps of the workflow were triggered even if it was not possible or necessary to execute them.

Contributors now have more precise contribution feedback—no more expected errors—and faster—in less than 7 minutes!

This topic was also the opportunity to receive the 1st contribution of Meet Soni 🙏 one of Microcks LFX Mentorship program mentees 😉

What’s coming next?​

As announced a few weeks ago, Microcks is starting an exciting new phase of its growth by welcoming 7 mentees for the next 3 months in the LFX Mentorship program! Expect a boost on topics like the CLI, the testing workflows, the Microcks Hub, or the documentation!

We will eagerly prioritize items according to community feedback. You can check and collaborate via our list of issues on GitHub and the project roadmap. Please join us to shape the future!

Remember that we are an open community, which means you, too, can jump on board to make Microcks even greater! Come and say hi! on our GitHub discussion or Discord chat 👻, send some love through GitHub stars ⭐️ or follow us on BlueSky, Twitter, Mastodon, LinkedIn, and our YouTube channel!

Thanks for reading and supporting us! ❤️

With over 60 resolved issues and 12 contributors, this is one of the biggest releases! Kudos to all the people 👏 who helped along the way by writing code, commenting on issues, or writing posts. Check our greetings and notes below.

This release had no specific theme at the beginning but reviewing the content, we realized it was mainly about validation & traceability:

• Validation on mocks with new controls on input requests and new gRPC error management;
• Validation and Traceability of the way we build Microcks with huge enhancements related to the security of the software supply chain!

Without further ado, let’s review the latest updates for each of our key highlights.

Validation on mocks​

It’s a common concern to lower the entry barrier when providing mocks so that people can easily discover and play around with your API endpoints. For that, Microcks only uses a subset of incoming request elements to try to find a matching mock response. This is great for a quick start but this also means that all the non-matching elements - like query parameters or body information - can be totally false without any raised concern on the consumer side 🤔

The Constraints feature is typically there to avoid this, but until today, it was an opt-in option you had to explicitly set by adding constraints to your mocks via the Web console or the API only.

With this new 1.11.0, we drastically enhanced the way that Constraints can be set and applied to prevent your API consumers from being blind to their own errors.

1️⃣ The Parameters Constraints corresponding to required elements in query or headers are now automatically inferred and applied at runtime. Just try calling a Microcks mock missing a required header and you’ll now receive a 400 response indicating a malformed request,

2️⃣ All the other constraints - type, regular expression, recopy, etc. - can now be specified in your OpenAPI or YAML artifacts using our OpenAPI extension or our own APIMetadata format. You no longer need to issue an API call or connect to the console.

What about body payload? Applying full body payload validation on each incoming request can be impactful on behavior for existing users but also on performance. That’s why we also introduced new validation-enabled mock endpoints with this version!

From the small toggle next to the Mock URL you can now ask for the valid endpoint option:

Just issue an invalid call to this endpoint - changing the price to a string for example - and you’ll see the validation in action:

curl -X PATCH 'http://localhost:8080/rest-valid/API+Pastries/0.0.1/pastries/Eclair+Cafe' \
    -H 'Accept: application/json' -H 'Content-Type: application/json' \
    -d '{ "price": "2.6" }' -v

[...]
< HTTP/1.1 400 
[...]
[instance type (string) does not match any allowed primitive type (allowed: ["integer","number"])]%

This new validation option is available for both REST and SOAP endpoints. The gRPC endpoint already embeds this body payload validation, which is mandatory for Protobuffer serialization.

gRPC enhancements​

gRPC is quickly gaining popularity as it offers an efficient alternative to text message serialization in performance-critical situations. With this 1.11.0, Microcks enhanced its gRPC mocking and testing support thanks to awesome contributions by Anika Apel 🙏 and Caio Amaral 🙏

1️⃣ Microcks now supports using gRPC metadata (or headers) into the SCRIPT dispatcher. This allows you to simply use the mockRequest.getRequestHeaders() function to access gRPC metadata and define smart dispatching rules using them,

2️⃣ It also supports injecting gRPC headers into test requests when contract-testing implementation endpoints. The headers you specify - either through the Web console, the Microcks CLI, an API call, or your favorite Testcontainers module - are passed to the endpoint under test and become dynamic elements of the tests,

3️⃣ And it also relates to validation - you’ll now have the capability to mock gRPC failure responses as well! Oftentimes, one wants to simulate edge cases in order to verify the application behavior and simulating errors can be a handful too! It’s now possible to do so and it’s even easier using our new APIExamples format simply specifying the status of a gRPC response 😉

In addition to those awesome contributions, our friends at Bitso have also crafted a very interesting blog post on how they’re using Microcks to setup isolated local development for their Spring Boot gRPC developers. A must-read! 🤩

Secured Software Supply Chain​

As in most software projects, the way we build Microcks is not the most glamorous part of it! But as an open-source project, part of an exposed foundation like the CNCF, and being used in mission-critical organizations like Banks, Telcos, and Public Governmental organizations, the software supply chain integrity is a major concern 🤔

The 1.11.0 release has been entirely built with this in mind, applying the best practices from the community and especially from the SLSA project (for Supply-chain Levels for Software Artifacts).

What changes have been introduced? What traceability, auditability and integrity guarantees are we providing? Well, that’s a lot! Here’s a non-exhaustive list of new practices and guarantees we introduced:

• We settled the dependencies management policy, dependencies update tools, and security insights,
• We removed dangerous workflows by reviewing CI/CD permissions and dependencies,
• We fully automated the release process so that change can’t appear without a formal review,
• We now generate a Software Bill of Materials (SBOM) for each package we release,
• We are also signing released packages and their checksums so that it’s easy to check their integrity.

The Microcks project also provides a bunch of container images and we’ve done similar things for them:

• The images we provide are now all signed using Sigstore,

• Attached as image layers, we also provide:

  • A SLSA Provenance attestation that can attest that the container comes from our CI/CD process,
  • A SPDX SBOM attestation that tracks all the dependent layers in the image

• We became a Verified and Official publisher on ArtifactHub.io, the CNCF official artifact repository.

Whouah! This was a long-run task that spans the six last months and has been tracked in issue #1201. This has been done not just for the main Microcks packages but for all the packages coming from all the GitHub repositories in the Microcks organization! To help us monitor that daily, we have set the CLO Monitor tooling that you can also use to track our progress 😎

As a Microcks end-user, you would be particularly interested in the process of checking the integrity of downloaded container images. The Software Supply Chain Security documentation details how things are structured and can be easily checked using standard tools like docker, cosign, or oras.

Improvements that are worth noting​

Aside from the major changes listed above, here are some other improvements that are worth being aware of. Without any specific priorities:

• We now support embedded Avro schema and schema registry integration for AsyncAPI - See issue #1422
• We now support multi-templating in AsyncAPI channel names - See issue #1339
• We fixed a permission issue when deploying MongoDB on certain Kubernetes distro - See issue #1420
• We fixed all the documentation links in the Web console - See issue #1350
• We provide a new fallback notation for templating - See issue #1446

And many more… The full release notes with all changes can be found here.

⚠️ Warning

With the release 1.11.0, we decommissioned the Microcks Ansible Operator that will no longer work if you choose Microcks 1.11.0 or latest as your Microcks version. As a consequence, we recommend not to change the Microcks version in your existing MicrocksInstall Custom-Resource and pin it to 1.10.1 if you temporarily want to stick with this operator.

We now provide a new Microcks Operator that is more lightweight, performant with more features in a 100% GitOps oriented way. The new Microcks Operator has been used in production for months by different adopter and we're confident it behaves well.

What’s coming next?​

As usual, we will eagerly prioritize items according to community feedback. You can check and collaborate via our list of issues on GitHub and the project roadmap.

More than ever, we want to involve community members in design discussions and start some discussions about significant changes regarding Microcks UI Future or our Participation to LFX mentorship programs. Please join us to shape the future!

Remember that we are an open community, which means you, too, can jump on board to make Microcks even greater! Come and say hi! on our GitHub discussion or Discord chat 👻, send some love through GitHub stars ⭐️ or follow us on BlueSky, Twitter, Mastodon, LinkedIn, and our YouTube channel!

Thanks for reading and supporting us! ❤️

The 0.3 series is a major step forward that completes the set of features and elevates Microcks as a fully featured mocking library for development purposes. It can be used with different testing styles (classicist, mockist, state-based, and interaction-based) and provides features for all major languages and all kinds of API!

The 0.3 versions are coincident releases made last week on the three main languages we currently support: Java ☕️, NodeJS/Typescript and Golang. With those new releases, we now have complete feature parity among the three different technology stacks! We plan to add the same features to the upcoming .NET module that we added to our portfolio in December 2024.

Let's introduce the new features of those releases that complete the picture!

What's inside?​

1️⃣ Interaction checks​

If you spend some time reading about Test Driven Development, you may know that it exists two main school of thought: the Classicist and the Mockist. (more on this in this excellent article)

Until now, Microcks Testcontainers integration was Classicist in the sense that it was focused on providing canned responses when the mocks endpoints were called. With this 0.3 release, we now also have a Mockist approach in the case you want to check the interactions of your component under test with a dependant API.

You can now call verify() or getServiceInvocationsCount() on a Microcks container to check whether an API dependency has actually been called - or not. This is a super powerful way to ensure that your application logic (when to interact with an API) and access policies (caching, no caching, etc.) are correctly implemented and use the mock endpoints only when required!

A big shout out to pierrechirstinimsa 🙏 who contributed this one for our Java module 🎉

2️⃣ Access to messages in synchronous API contract-testing​

The second thing we added in this release is the ability to retrieve exchanged messages when doing contract-testing. Different contract-testing runners already exists in Microcks but they're mainly focused on syntactical conformance checking. However, we know that there are multiple levels of contract testing.

The new getMessagesForTestCase() function on Microcks container allows you to retrieve the requests and responses that were used during an operation tests case. You can then use them to perform extra checks more related to business conformance; validating, for example, that data retrieval or transformation logic is correctly implemented.

These extra checks can be done manually directly in the programming language of your tests but you can also delegate them to frameworks like Cucumber which are written in plain language by business experts; for running acceptance tests!

3️⃣ Access to events in asynchronous EDA contract-testing​

Finally, we also added a way to do the same thing for asynchronous events received during a contract test on an asynchronous broker.

Until now, Microcks ASYNC_API_SCHEMA tests allowed you to check that events were fired, correctly sent, read back from - let say - an Apache Kafka topic and valid regarding a schema. But what about the content of this event? Was it really related to the business function call that fired it?

The new getEventMessagesForTestCase() function allow you to retrieve those events that were read from the broker topic and - here again - perform extra checks. Typically, you can validate that the data from the event is correctly correlated to the original data that triggered the event emission.

💡 In the the case of EDA, those checks are also tightly related to interaction checks; and this is a situation we faced during the development of the supporting demo application! Once we added them, we realized that our Kafka producer has a flushing issue and that we received more messages than we expected! Due to a too low timeout configuration, events were not sent at the right time, introducing de-synchronization and collisions! 💥

Enthusiastic?​

We hope this walkthrough has made you enthusiastic about this new set of features in Microcks Testcontainers 0.3! The best thing is that you don't have to wait another Microcks release to test them out as they're are leveraging APIs and features that are present for a long time in Microcks core!

If you want to learn them and see them in action, we have completed our demonstration application and tutorials on Testcontainers Modules as well! You just have to check the following links:

• For Java ☕️: How to check the mock endpoints are actually used, How to verify the business conformance of a synchronous API, and How to verify the event content for an asynchronous API

• For NodeJS/TypeScript: How to check the mock endpoints are actually used, How to verify the business conformance of a synchronous API, and How to verify the event content for an asynchronous API

• For Golang: How to check the mock endpoints are actually used, How to verify the business conformance of a synchronous API, and How to verify the event content for an asynchronous API

As usual, we’re eager for community feedback: come and discuss on our Discord chat 👻

Thanks for reading and supporting us!

This year has been transformative, marked by growth, innovation, and a sense of community that fuels our journey. Here's a look at some key highlights as we enter 2025.

🚀 Microcks in Numbers​

2024 has been a year of outstanding achievements:

• Over 140k downloads for December 2024, consistently growing every month and 600k+ downloads in the last year!
• A surge in community engagement with 2600+ LinkedIn followers, gaining over 1100 followers in 2024.
• We have almost 1500 GitHub stars on our main repository, a growth of +500 this year, reflecting the increasing interest in Microcks.
• We welcomed 21 public adopters (+10 this year!) and 28 private adopters we know of. We encourage private adopters to join our public list to showcase their use of Microcks.
• Expanded globally with new users across LATAM and APAC regions, emphasizing our growing international footprint, as highlighted by the Google Analytics data below for the microcks.io website over the past year.

🙌 Community Contributions: The Heart of Microcks​

Our community constantly amazes us with its contributions, driving innovation and expanding Microcks' possibilities. Adopters and users actively contributed ideas and implementations, enabling new capabilities for the Microcks platform.

A special shoutout to AXA France and Sebastien Degodez, who has become the maintainer of the Testcontainers .Net library, expanding our ecosystem to our shift-left approach for Microsoft developers 👉 https://testcontainers.com/modules/microcks/

Contributor Growth: 2024 saw significant contributors' growth, demonstrating our community's enthusiasm and commitment. According to devstats, Microcks had 60 contributors in 2024. These include committers from 25 organizations such as Google, Red Hat, Catena Clearing, Vinted, Adeo, Bancolumbia, OPT New Caledonia and so on.

👉 Explore more stats here.

🌟 Ecosystem Collaborations: Stronger Together​

2024 was a banner year for partnerships and collaborations that pushed the boundaries of what's possible.

KubeCon + CloudNativeCon NA​

At Salt Lake City, we announced an exciting new partnership with Traefik Labs. We deliver Sandbox as a service with a fully GitOps-automated approach to Kubernetes. This collaboration showcases the seamless integration of Traefik's API Gateway with Microcks' API mocking and testing capabilities 👉 Read more here.

AppDeveloperCon synergies with the Quarkus community during day 0 of KubeCon + CloudNativeCon NA. See the recording our the talk done with Daniel Oh (Java Champion, CNCF Ambassador, Developer Advocate at Red Hat) 👉 “Streamlining Cloud-Native Development: Simplifying Dependencies and Testing with Microcks”.

Bump.sh Partnership​

We teamed up with Bump.sh, which revolutionized how developers work with API specifications. Combining Bump's sleek documentation tools with Microcks' robust mocking and testing capabilities offers a well-connected, efficient workflow 👉 Check out the details.

Observability with Grafana Labs​

Working with Alain Pham from Grafana Labs, we introduced observability at scale for Microcks using OpenTelemetry, showcasing how modern monitoring tools can empower API testing workflows 👉Blog post here.

Collaboration with API Evangelist​

Partnering with Kin Lane, the API Evangelist, we explored a new schema for defining API examples. This initiative enhances the specification of reusable examples, fostering interoperability and opening doors for broader collaboration in the open source ecosystem 👉 Learn more about this specification.

🗣️ Communication Contributions​

Adopters and partners have played a crucial role in spreading the word about Microcks through talks, events, and blog posts.

Notable highlights include:

• Ludovic Pourrat from Lombard Odier sharing their journey in "Revolutionizing API Strategy: Lombard Odier's Success Story with Microcks."
• Sebastien Fraigneau from CNAM detailing their collaboration with “Microcks for automated SOAP service mocking”.
• Julien Breux from Google, at Conf42 Tech Conference for a talk on “Testing with Testcontainers in Go!”.
• Leon Nunes from Solo.io, meetup in Bangkok regarding “Mocking GraphQL with Microcks and Gloo Platform”.
• Hugo Guerrero from Red Hat, during KCD Guadalajara on Microcks journey in Spanish “Llevando tu Proyecto de Hobby a la Cloud Native Computing Foundation”.
• ...and many more, apologies to the ones I missed in this brief recap!

These stories inspire us and highlight the various ways Microcks is making a meaningful impact in the real world, while also encouraging community members to contribute to enhancing the project's visibility and promotion.

In 2024, we introduced two monthly community meetings, scheduled to accommodate different time zones. These sessions are open to everyone, so feel free to join us live!

👉 Watch the recording of previous sessions.

💡 Looking Ahead: 2025 and Beyond​

2024 was a year of hard work, camaraderie, and innovation. But we're not stopping here. In 2025, exciting news and activities are lined up to make Microcks the #1 open source solution for API and microservices mocking and testing and level up within the Cloud Native Computing Foundation (CNCF).

Stay tuned for announcements, new features, and opportunities to collaborate and grow.
Thank you for being part of this incredible journey. Here's to a happy, healthy, and prosperous 2025! 🥂

Let's make the cloud native future even brighter together.

Structured as an independent partnership, Lombard Odier is solely owned by its Managing Partners. This governance model allows the Bank to remain completely client-focused and innovative at the highest level in the organisation.

Lombard Odier has quickly recognized APIs' pivotal role in modern IT strategies, to foster agility and innovation, Lombard Odier embarked on a transformative journey, integrating Microcks as a cornerstone in its API lifecycle management.

Adding Mock and Sandbox as a Service Capability​

One of Lombard Odier's IT strategies for accelerating its transformation program is the incorporation of a mock and a sandbox as a service capability within its API strategy. Recognizing the importance of testing and iterating without disrupting their live APIs, they leveraged Microcks to integrate mock services seamlessly. This approach allows developers to experiment, refine, and perfect their APIs in a controlled environment, ensuring a smooth and transparent transition to production.

APIOps Approach: The Driving Force​

Lombard Odier adopts an entire APIOps approach, treating APIs as products and orchestrating their development, deployment, maintenance, and operability. This approach aligns perfectly with Microcks' capabilities, making it the linchpin of their API strategy. Through Microcks, Lombard Odier brings agility and efficiency to their APIOps pipeline, from design to deployment.

Support for Multiple Specifications and Protocols​

Lombard Odier operates in a diverse technology landscape, employing various specifications and protocols to cater to different use cases. Microcks seamlessly integrates with OpenAPI, AsyncAPI, GraphQL, and gRPC, providing a unified platform for managing this diverse set of APIs. This flexibility ensures that Lombard Odier can choose the best tool for the job while maintaining a consistent and efficient API management process.

A Testimonial from Ludovic Pourrat, Head of API Management at Lombard Odier. In the ever-evolving landscape of API management, Lombard Odier stands out as a trailblazer in embracing cutting-edge technologies to drive innovation and growth.

Microcks is a robust open source tool that has become an essential solution for Lombard Odier. It enables us to manage, maintain, and automate the lifecycle of our extensive API ecosystem efficiently. At the heart of our remarkable journey, Microcks has become a key asset that achieves the right balance between innovation and stability, empowering developers with fast iterations of their APIs.

The Numbers Speak: Managing Over 2000 API Endpoints with Less Than 200 Developers. Microcks' scalability and efficiency are evident in Lombard Odier's achievement of managing over 2000 API endpoints with a lean team of fewer than 200 developers.

Microcks' ability to streamline workflows, automate testing in our CI/CD pipelines, and enhance collaboration ultimately allows Lombard Odier to scale its API operations seamlessly.

Conclusion​

Lombard Odier's success story with Microcks exemplifies the transformative power of embracing modern API management practices. By integrating a mock and sandbox as a service capability, adopting a complete APIOps approach, and leveraging Microcks' support for various specifications and protocols, Lombard Odier has not only streamlined its API lifecycle but has also set the stage for continuous innovation and development efficiency.

As organizations worldwide grapple with the complexities of API management, Lombard Odier's journey is an inspiring testament to the impact of adopting the right tools and strategies. Microcks, as a central player in their API ecosystem, has proven its worth in driving efficiency, agility, and sustained success.

For this release, we received help from 4 new code committers and from dozens of others who opened, contributed to, and reviewed 46 issues. Most of them are adopters! Kudos to all of them 👏, and see the greetings in the notes below.

1.10.0 release brings you a wave of new features, including Stateful mocks support, a new lightweight API Examples specification format, tons of enhancements in the Uber and Native distributions, and a big refresh on installation dependencies.

Let's review the latest updates for our key highlights without further ado.

Welcome, stateful mocks!​

Microcks has allowed specifying dynamic mock content using expressions since the early days. Those features help translate an API's dynamic behavior and provide meaningful simulations.

But sometimes, you may need to provide even more realistic behavior, and that’s where stateful mocks may be of interest. Stateful mocks are a game-changer in the pursuit of an even smartest mocking experience. You can now experience enhanced realism in your API simulations and free your creativity!

However, automatically turning mocks into stateful simulations is impossible, as numerous design guidelines need to be considered. At Microcks, we put this power in the user’s hand, providing powerful primitives like scripts, store, requestContext, and template expressions to manage persistence where it makes sense for your simulations. This feature is now available at your convenience via the store service that is directly usable from scripts like this:

store.put("my-key", "Any value represented as a String");
def value = store.get("my-key");
store.delete("my-key");

Check our new Configuring stateful mocks how-to guide, which takes you through a real use case of managing a shopping cart where customers' items are persisted during the process.

A new API Examples specification format​

While Microcks' motto is not to reinvent the wheel and reuse standard artifacts (see artifacts reference), we think 1.10.0 may be the right time to introduce our own specification format, fully driven by the goal of importing mock datasets into Microcks.

APIExamples can be seen as a lightweight, general-purpose specification that solely serves the need to provide mock datasets. The goal of this specification is to keep the Microcks adoption curve very smooth for both development teams and non-developers. The files are simple YAML and aim to be very easy to understand and edit.

Moreover, the description is independent of the API protocol! We’re rather attached to describing examples depending on the API interaction style: Request/Response based or Event-driven/Asynchronous.

As a sample, you’ll see below the APIExamples snippet for our gRPC mock tutorial, but it would be rather the same when dealing with a REST API:

apiVersion: mocks.microcks.io/v1alpha1
kind: APIExamples
metadata:
 name: org.acme.petstore.v1.PetstoreService
 version: v1
operations:
 getPets:
   All Pets:
     request:
       body: ""
     response:
       body:
         pets:
           - id: 1
             name: Zaza
           - id: 2
             name: Tigress
           - id: 3
             name: Maki
           - id: 4
             name: Toufik
 searchPets:
   k pets:
     request:
       body: |-
         { "name": "k" }
     response:
       body: |-
         {
         "pets": [
           {
             "id": 3,
             "name": "Maki"
           },
           {
             "id": 4,
             "name": "Toufik"
           }
         ]
        }

This format is intended for use as a secondary artifact. It would be a companion to our existing APIMetada format but dedicated to API Examples.

Be sure to read our API Examples Format reference documentation that details the different properties available and how to use this format for different types of APIs.

Uber and Native images enhancements​

Introduced in recent Microcks releases, microcks-uber distribution and its GraalVM native variant are perfectly well-adapted for a quick evaluation or for an ephemeral usage via libraries like Testcontainers. However, they were still a bit behind the regular distribution in terms of features covered.

Starting with 1.10.0, we reduced this feature gap a lot by making:

• MQTT and RabbitMQ/AMQP protocols available to the Uber distribution,
• gRPC features and full templating features work into the Native-variant of this Uber distribution.

The long-term goal we’re pursuing and are close to achieving is full feature parity between the regular/uber/uber-native distributions—except for some structural ones that would be impossible to port. Typically, the Groovy SCRIPT feature is not available in native mode, as dynamic evaluation is, by definition, antagonistic to static compilation.

If you want to learn more about feature gap reduction and associated changesets, please refer to #1239 for MQTT support, #1240 for RabbitMQ support, #1227 for gRPC testing features support, and #1226 for templating features support.

Dependencies and installation upgrade​

While considering upgrading to 1.10.0, you should also carefully plan your update based on your setup. We’ve made significant updates to external container dependencies, including MongoDB, Keycloak, and their associated Postgres databases.

These are noticeable changes you should take care of:

• The centos/mongodb-36-centos7 that was no longer maintained for 3 years has been replaced by the library/mongo:4.4.29 that is 3 months old and still updated,
• The quay.io/keycloak/keycloak:22.0.3 has reported CVEs and has been replaced by the fresher quay.io/keycloak/keycloak:24.0.4,
• The centos/postgresql-95-centos7:latest has not been updated in 5 years and has been replaced by a fresher library/postgres:16.3-alpine updated 12 days ago.

Unfortunately, updating MongoDB and Postgres engines cannot be done without breaking things. That’s why we recommend not rolling in-place upgrades of existing installations but rather proceeding with care: exporting and backing up your data from MongoDB and Postgres before importing it into new instances. This can be done with low-level tools (like mongodump and pg_dump) or at an application level (using Microcks snapshots or Keycloak realm exports).

⚠️ Warning

Be cautious: the dependencies Microcks proposes during installation are provided for convenience only. Our take is that you shouldn't rely on them for crucial "production" workloads; instead, use an external component. You can override the default image OR completely disable the installation of external dependencies in our Helm Chart or Operator.

In addition to these upgrades, we also changed how you can customize the images and external dependency artifacts in our Helm Chart. Where we previously had a single image field for each component (the main one, postman, keycloak, mongo, etc), we have split these single fields into multiple properties registry, repository, tag or digest as illustrated below:

image:
  registry: quay.io
  repository: microcks/microcks
  tag: nightly
  digest:

This change brings the benefits of:

• Being aligned with community best practices regarding image customization - other communities like OpenTelemetry, Strimzi or Jaeger are following the same conventions,
• Allowing easier customization for people using a corporate registry as a cache or wanting to pin the artifact coordinates to an immutable digest.

Thanks to Romain Quinio 🙏 from Amadeus IT Group for bringing this enhancement suggestion to the discussion! You can check the original #1211 issue.

Community amplification​

The Microcks community continues to grow and make waves in the tech world! Here are some of our latest highlights:

🎤 Talk from Hugo Guerrero at Riviera DEV 2024​

We are thrilled to share that Hugo (Red Hat) presented an outstanding talk at Riviera DEV 2024! His session featured a great demo showcasing Microcks' shift-left approach using Quarkus and Testcontainers. Check out his LinkedIn post for more details.

📝 Microcks Mentioned as an Alternative to WireMock​

Microcks has been highlighted in Speedscale's blog post as a top alternative to WireMock. We're proud to be recognized among the top 5 WireMock alternatives:

https://speedscale.com/blog/wiremock-alternatives/

🌐 Microcks Joins the CAMARA Project​

Microcks, a Cloud Native Computing Foundation (CNCF) Sandbox project, is now officially listed as a member of the CAMARA Project, an initiative by The Linux Foundation! 🎉

https://camara.landscape2.io/

🚀 Member of CNCF App Development Working Group​

As a CNCF project, Microcks is proud to join the App Development Working Group within the CNCF TAG App Delivery. This initiative aims to bridge the gap between developers and CNCF projects that directly impact daily workflows 🙌

https://www.cncf.io/blog/2024/07/05/a-new-app-development-wg-has-now-been-launched/

📢 Shoutout to Java Dominicano Community​

A massive thank you to the Java Dominicano community and a special shoutout to Eudris Cabrera for his outstanding talk and demo on Microcks! 🌟

🎉 Microcks Hits 2000+ Followers on LinkedIn!​

We are excited to announce that we have reached over 2000 followers on LinkedIn! Join us to stay updated on the latest news and updates about Microcks. Follow Us on LinkedIn.

Stay tuned for more updates, and continue to be a part of our journey as we grow and innovate together!

What’s coming next?​

As usual, we will prioritize items based on community feedback. You can check and collaborate via our list of issues on GitHub and the project roadmap.

More than ever, we want to involve community members in design discussions and start a discussion about significant additions to OpenAPI callbacks, webhooks, and AsyncAPI in Microcks. Please join us to shape the future!

Remember that we are an open community, which means you, too, can jump on board to make Microcks even greater! Come and say hi! on our GitHub discussion or Discord chat 👻, send some love through GitHub stars ⭐️ or follow us on X, Mastodon, LinkedIn, and our YouTube channel!

Thanks for reading and supporting us! ❤️

KubeCon EU 2024 at the Microcks Project Pavilion booth, showcasing core contributors from Red Hat (Hugo Guerrero), Google (Julien Breux) and Microcks core maintainers (Laurent Broudoux & Yacine Kheddache).

Microcks' Integration into the CNCF Sandbox: A Milestone of Success

Microcks took a significant step forward by becoming part of the CNCF Sandbox, a space dedicated to nurturing early-stage cloud-native projects. The CNCF, well-known for supporting and promoting cloud-native technologies, provided Microcks with a platform that validated its potential and exposed it to a vast community of developers, enterprises, and enthusiasts. This integration was marked by Microcks' announcement in the blog post titled "Microcks Joining CNCF Sandbox", a testament to our community dedication and ambition.

The 1-Year Transformation: Positive Impacts on Microcks​

1. Rapid Growth and Adoption

One of the most visible impacts of Microcks' inclusion in the CNCF Sandbox is its exponential growth. This growth is vividly evident in the ADOPTERS.md file on Microcks' GitHub repository. This file is a directory of organizations and projects that have embraced Microcks as part of their development workflow. Over the first year, the list of adopters expanded significantly, reflecting the rising popularity and utility of the Microcks project.

• Public adopters have grown from 1 to 16 in just a year, spanning various verticals and geographies! 🌍🚀😊
• Private adopters (companies who are not yet listed publicly but are in touch with the community) now include more than 20 organizations... 🚀🤝😊

Moving from private to public adopters is a small contribution that makes a big impact. It greatly helps the project gain momentum and credibility. Your support is truly important for our growth! 🌟🙏

As enterprises and developers integrated Microcks into their development lifecycle practices, it became evident that the CNCF affiliation increased the project's visibility and instilled higher trust among our community users. Being part of the CNCF family inherently brings a sense of credibility and reliability, a factor that likely contributed to Microcks' rapid adoption.

Keep discovering by reading adopters' testimonials:

• CNAM Partners with Microcks for Automated SOAP Service Mocking
• Extend Microcks with custom libs and code
• J.B. Hunt: Mock It till You Make It with Microcks

2. Embracing the "Shift Left" Paradigm

Microcks' tenure in the CNCF Sandbox has reinforced the importance of the "shift left" approach to software development. The "shift left" paradigm emphasizes addressing issues as early in the development cycle as possible, reducing the chances of critical problems emerging in later stages. In Microcks’ context, this translates to incorporating API mocking and testing right from the outset of development.

The shift left approach was expertly outlined in the informative article "Mocking and Contract Testing in Your Inner Loop with Microcks". This piece elaborates on how Microcks' inner loop focus empowers developers to mock APIs and run contract tests early in their development cycle. This leads to swifter identification and resolution of issues, allowing developers to iterate more efficiently and ultimately deliver higher-quality software.

Metrics for Testcontainers Microcks’ module downloads and usage are rapidly increasing, demonstrating the need and enthusiasm of developers: 🌟

• From 500 downloads in Q4 2023 🚀
• To over 2K downloads in May 2024 🎉

The same goes for our popular Docker Desktop Extension: listed among the top extensions every developer must try and installed over 6.4K times! 🚀🌟😊

⏩ Very easy and straightforward to start with Microcks in 3 mins, watch:
Getting Started with Microcks Docker Desktop Extension

Since day one, the Microcks project has been robust and efficient in managing all kinds of API use cases for your outer loop. Based on adopters and community feedback, we now have a lighter and faster version of Microcks named microcks-uber. By packaging our Microcks Java application into a platform-native binary using GraalVM native and Spring Boot AOT compilation, we've achieved an incredible startup time of just 300 milliseconds, consuming very few resources!

We are now the ultimate tool to bridge the gap between development on a laptop and centralized, highly scalable operations on Kubernetes. 🚀💻🌐

See our article regarding:
“How Microcks fit and unify Inner and Outer Loops for cloud-native Development” 💡

3. Better Together: Eco-System Orientation

The CNCF Sandbox status brings a sense of camaraderie and the opportunity to be part of a broader ecosystem. This "better together" mindset encourages projects to explore integrations and collaborations that enrich the developer experience.

Microcks' alignment with the CNCF ecosystem is a testament to this ethos. The project isn't just about standalone functionality and fitting into the larger cloud-native landscape. Microcks demonstrates its commitment to creating a seamless developer experience within the CNCF ecosystem by promoting compatibility with other cloud-native technologies.

Explore our ecosystem partnerships by discovering key articles and videos highlighting our collaborations with OpenTelemetry and Grafana Labs, Testcontainers, Docker, Backstage, Canonical, Red Hat, GitLab, Solo.io and more if you follow us ;-)

Microcks, by the numbers and key metrics​

Microcks maintainers, care about metrics and are committed to continuous improvement. We're excited to share how we've leveled up our contributions and community engagement through CNCF metrics. Our diversity of contributors, contributions growth, and GitHub activity have all shown remarkable progress. Dive into the details and explore our journey using the CNCF DevStats, Linux Foundation Insights, and some great help from our friends at Bitergia, where you can double-check the data or dig deeper into our success story. Let's celebrate our growth and the power of open-source collaboration! 🎉

Worldwide diversity of contributors, with notable contributions growth from APAC (mainly China) over the last 12 months: 🌍

More and more contributions are coming from organizations that rely on Microcks and have decided to participate in project maintenance and evolution to secure and invest in their supply chain. 😊

Net Newly Attracted Affiliations: 25 new organizations with developers actively participating in the Community! 🚀

Git Overview 🚀 910 commits this year vs. 486 commits last year 📈

Attracted New Developers Continue to Rise! 🌟 The growth has skyrocketed since we joined the CNCF! 😊

Conclusion​

Microcks' journey within the CNCF Sandbox has been nothing short of transformative. From achieving remarkable growth and adoption to embracing the shift left approach and contributing to a better-together ecosystem, the project's trajectory has been infused with energy, innovation, and a collaborative spirit. This one-year period highlighted the inherent advantages of being part of a foundation that champions cloud-native technologies and encourages projects to reach new heights.

As the open-source community continues to evolve, success stories like Microcks remind us of the immense value that foundation affiliations can bring. By fostering an environment of support, collaboration, and growth, foundations like the CNCF provide projects with the tools they need to make a lasting impact on the world of software development. With its remarkable journey thus far, Microcks is a shining example of how a project's affiliation with the proper foundation can propel it to new heights of success and innovation.

Stay tuned as Microcks gears up to elevate within the CNCF! We're excited to announce our plans to submit and launch the qualification process to become an incubating project in the foundation during our second year! 👀

Additionally, we coordinate with and assist the local organizations within our network, which consists of 164 entities deployed nationally, regionally, and locally throughout France. We rely on SOAP (Simple Object Access Protocol) for our historical and mission-critical legacy systems to facilitate seamless information exchange among these organizations.

Source (🇫🇷): https://www.assurance-maladie.ameli.fr/qui-sommes-nous/organisation/reseau-proximite

At CNAM, we manage hundreds of services that process a significant data flow daily, with each potentially relying on others. In our development and testing phases, we depend on thousands of simulations representing different versions of each service. Throughout all project phases, multiple individuals or groups utilize these simulations, contributing to our extensive use of datasets. This poses challenges in maintaining and accelerating testing, validation, interoperability, and conformance at scale.

APIs and web services at CNAM​

With a diverse ecosystem of healthcare organizations and systems, interoperability is critical to ensuring that data can be exchanged and understood across different platforms. APIs provide standardized interfaces that allow disparate systems to communicate and share data effectively and securely, regardless of the underlying technology stack.

By exposing functionalities through APIs, CNAM can automate various processes and workflows, increasing efficiency and reducing manual effort. This automation streamlines administrative tasks, reduces errors, and frees up resources to focus on more critical aspects of healthcare delivery.

CNAM relies on SOAP for its legacy systems, which are mission-critical for its operations. APIs and web services enable the integration of these legacy systems with modern applications and technologies, ensuring that CNAM can leverage its existing infrastructure while embracing innovation.

As CNAM's network continues to evolve and grow, APIs provide scalability and flexibility to adapt to changing requirements and accommodate new technologies and services. This agility allows CNAM to respond quickly to emerging healthcare challenges and opportunities.

Benefits of the Solution​

CNAM previously used a homemade mocking solution, which was statically built and required consumers to provide business examples and behavior. This approach consumes many infrastructure resources and generates drift, disparities, and non-reusable assets between organizations within the ecosystem.

During our research for an API mocking and testing solution, we discovered Microcks and immediately embraced its open-source, community-driven, and very innovative approach to managing all kinds of APIs using the same facilities, including SOAP, which is mandatory for our systems.

We also realized the power and advantages of moving from a consumer to a provider-driven approach. We recognized many of our pains of being 100% consumer-driven for all our business datasets and examples in the article from Laurent Broudoux. It has completely changed our mindset and the way we are now using mocking and sandboxes in our development lifecycle.

At CNAM, we have chosen Microcks to accelerate and automate the simulation (mocking) of our 450 SOAP services and more than 100 Oracle Tuxedo processing and transaction systems exposed via SOAP. Our usage of Microcks replaces the existing internal solution and offers several benefits tailored to our needs.

1. Accelerated and Automated Simulation: Microcks accelerates and automates the simulation (mocking) of CNAM's extensive suite services and data processing systems. This streamlines our internal processes and reduces manual effort, leading to faster development cycles.

2. Reuse of Existing Datasets: By leveraging Microcks, we can reuse existing datasets, eliminating the need to recreate mocks for each service. This not only saves time but also ensures consistency across different testing scenarios.

3. Fully Automated Sandboxes as a Service: Microcks empowers us to provide fully automated sandboxes to all consumers, accelerating development and testing workflows.

4. Self-Service Mock Generation: With Microcks, we enable self-service mock generation for API consumers, empowering developers to iterate quickly and test their applications effectively.

CNAM Mock admin web application workflow.

Using the Mock Admin application based on Microcks has significantly streamlined our testing processes. Its intuitive interface and flexibility allowed us to create customized mocks to simulate complex and mission-critical scenarios, crucial for our automated tests with the INS and SNGI databases. Microcks has demonstrated exceptional reliability and performance, enhancing the quality of our tests and allowing us to detect anomalies early in our development and validation process.

Laurent Fontaine, Application Owner at CNAM

The datasets imported in Microcks are formatted as CSV files, containing various information such as letters, words, phrases, numbers, tables, or regular expressions (regex).

CSV-formatted CNAM dataset and Microcks dynamic custom dispatch.

This structure demonstrates that the first column acts as a discriminator value, the last column specifies the response name, and the remaining columns inject mock data into the response context.

Overall, Microcks' self-service and on-demand capabilities enable us to speed up complex development and validation processes, ensuring efficient and reliable healthcare services for all stakeholders (including non-technical associates using XLS and CSV files to provide business examples). Additionally, it reduces infrastructure size and consumption, aligning with our sustainability objectives.

Finally, we're extensively leveraging Microcks' extensibility and custom libraries in the API dispatching process. This has been detailed in a technical blog post titled:
"Extend Microcks with custom libs and code".

By leveraging existing datasets and libraries, we seamlessly integrate business and functional behavior validation into Microcks mocks, enabling dynamic generation. This not only enhances efficiency and accuracy but also significantly reduces time to market and improves delivery timelines.

Next objective: test automation​

Initially, we primarily used Microcks for mocking services, but now we are working to expand its usage to include comprehensive testing capabilities. This transition will significantly advance our testing strategy, allowing us to achieve greater efficiency, reliability, and agility in the CNAM software development lifecycle.

With Microcks' support for non-regression tests and validation, we can ensure that any changes or updates to our APIs do not introduce regressions or break existing functionality. By automating these tests within our existing CI/CD pipeline, we will be able to identify and address issues early in the development process, minimizing the risk of introducing bugs or defects into production environments.

Automated testing reduces manual quality assurance effort and enables faster feedback loops, allowing developers to iterate more quickly and confidently to improve overall development velocity.

CNAM Mock admin web application to Microcks’ automation tests pipeline.

This step is essential for our progress, paving the way for additional opportunities to enrich our development lifecycle with Microcks now that the solution is in production.

Contributing to Open-Source​

At CNAM, we are vested in contributing to the open-source Microcks community upstream for several compelling reasons.

Firstly, in alignment with the French and European governments' open-source directive and its emphasis on digital sovereignty, We recognize the strategic importance of investing in and actively participating in open-source projects. By contributing to Microcks, CNAM not only strengthens its own digital sovereignty but also contributes to the broader ecosystem of open-source solutions, which are essential for the success of our mission and objectives.

By actively participating in Microcks' development and enhancement, we can contribute to the project's direction, tailor its features and functionalities to suit CNAM's needs better and guarantee the longevity and sustainability of our supply chain. This ensures that Microcks remains a dependable and effective tool in our software development processes.

Moreover, by participating in an open-source project like Microcks, CNAM employees can enhance their skills, collaborate with a diverse community of developers, and contribute to advancing technology in their field. This can lead to increased job satisfaction, professional growth, and a sense of pride in contributing to a project that positively impacts both CNAM and the broader software development community.

With no less than 30 newly resolved issues, this release is special as it is the first to have so many issues directly contributed by community users! 25 evolutions out of 30 directly come from them! Kudos to our community 👏, and see greetings along the notes below.

New Proxy features​

Aside from the numerous enhancements we'll discuss just after, this release's main new feature is the addition of Proxy behavior, which Nikolay Afanasyev introduced in this blog post.

As stated in this post, 1.9.1 comes with two new dispatchers called PROXY and PROXY_FALLBACK. While PROXY is a simple passthrough to an external backend service, PROXY_FALLBACK handles a bit more logic and allows to call the external backend service only if Microcks doesn’t find a matching mock response at first.

One great thing is that this new proxy logic has been implemented consistently for REST, SOAP and GraphQL APIs in Microcks. Check the full blog post for more details. Thanks again, Nikolay! 🙏

Noticeable enhancements​

Below is a list of noticeable enhancements and shootouts to people who contributed them without order or preference.

Templating of responses’ headers​

This enhancement lets you specify response header values using Microcks specific {{ }} template notation. The {{ }} notation is a placeholder that can be replaced with dynamic values. You can use it to return random values (think of a UUID as a transaction or correlation identifier) or request-based values. It was, for example, used to implement OpenID Connect mocks.

headers:
  'Location':
    schema:
      type: string
   examples:
     generic:
       value: "{{ request.params[redirect_uri] }}?state={{ request.params[state] }}&code={{ uuid() }}"

Check #1097 for more details on this, and thanks again to Nikolay 🙏 for the initial discussion and Pull Request.

JSON pointers extended usage​

This enhancement allows you to reference arrays or array elements in mock responses - still using the {{ }} notation placeholder. Arrays or their elements will be directly serialized as JSON and integrated as such into the response body. For example, you can use this template:

{
  "allBooks": {{ request.body/books }},
  "firstBook": {{ request.body/0 }}
}

to get results like:

{
  "allBooks": [{ "title":"Title 1", "author":"Jane Doe" },{ "title":"Title 2", "author":"John Doe" }],
  "firstBook": { "title":"Title 1", "author":"Jane Doe" }
}

Check #1139 for more details on this, and thank Andreas Zöllner 🙏 for proposing and writing this enhancement.

Object query parameters support​

This enhancement adds support for serializing an object's properties as request parameters. It follows the serialization rules for style: form parameters with explode: true, which translates in OpenAPI by having a query parameter of object type.

So typically, you may define a GET /users?name=Alex&age=44 endpoint where the query parameter is a User object. How cool! 😎

Check #1143 for more details, and thanks to Samuel Antoine 🙏 for proposing and writing this enhancement.

Webapp enhancements and linting​

While functional, the Microcks web app undoubtedly needs more love and enhancements as it is not the expertise field of original maintainers 😉 Thanks to community contribution, we’re now in better shape and have people still seeking improvements.

We have some noticeable improvements here:

• Selecting/deselecting operations when launching a test can now be done with a single checkbox,
• Broken unit tests have been removed from the codebase,
• Broken links to documentation have been fixed,
• Linting of application and refactoring for better standard respect has been applied,
• Analyses on how we could move to fresher dependencies or frameworks are coming.

Check #1153, #1163, #1166 and #1171 contributions by Siarhei Saroka 🙏 for more details.

More Tests​

Contributing to an Open Source project is not only a matter of writing code. Starting with documentation and adding new tests is a great way to get hands-on experience. As Microcks becomes a critical tool for many organizations, increasing the coverage of our test suite is essential.

We moved from 36.8% coverage on January 1st to 48.4% as of today! This is great progress for a code base of nearly 12K lines of code, and we can still get even better!

Check #1128, #1130 and #1150 for awesome contributions on tests by Matheus Cruz 🙏

Documentation refactoring effort​

We also want to take the opportunity of this release notes post to announce a significant refactoring effort on documentation. As stated above, Microcks has become critical and attracts more and more newcomers. The documentation needs to be reorganized to better assist with onboarding and help users find what they’re looking for.

We came up with a new approach to the documentation structure exposed in this GitHub thread. Our main goal is to clarify the categorization of information between Tutorials, Guides, Explanations, and Reference materials. We want to make it easier and faster for newcomers to find valuable information depending on where they are in their learning process. We also want to make it easier for community users to contribute new content easily.

For all of that, we need your help! So, if you are or would love to be a Tech Writer and want to contribute to this cool Open Source project, please join us and share your recipes and experiences to improve our documentation!

What’s coming next?​

As usual, we will eagerly prioritize items according to community feedback. You can check and collaborate via our list of issues on GitHub and the project roadmap.

Remember that we are an open community, which means you, too, can jump on board to make Microcks even greater! Come and say hi! on our GitHub discussion or Discord chat 👻, send some love through GitHub stars ⭐️ or follow us on Twitter, Mastodon, LinkedIn, and our YouTube channel!

Thanks for reading and supporting us! ❤️

Recently, a quality assurance specialist approached me with a request: "The mocks work fine, but we need to implement a new testing scenario. Every third or random response should be a mock-up, while the rest should be from the actual service..."

To achieve this, we could use an external load balancer, for example. Additionally, we would need a new configuration point for the balancer, its behavior, and so on... This is not the Samurai way 😊

Luckily, Microcks is an open-source project with an active community. After discussing the issue with Laurent, we created two dispatchers to provide simple and advanced proxy logic available for REST, SOAP, and GraphQL protocols.

Those two new dispatchers - to be released in the 1.9.1 version of Microcks - are called PROXY and PROXY_FALLBACK. While PROXY acts exactly as its name suggests, you’ll see that PROXY_FALLBACK handles a bit more logic and allows handling advanced use cases. Let’s dive into the explanations!

The new PROXY behaviors​

The simple PROXY dispatcher simply changes the base URL of the Microcks and makes a call to the real backend service.

Enabling the PROXY dispatcher is a per-operation setting. That means that within the same API, you may have some operations that use regular mocks and others that just delegate API calls to a real backend system. Your client still calls the Microcks endpoints though - allowing you a smooth transition from mocked inexistent operation to ready-ones on a real implementation.

The advanced PROXY_FALLBACK dispatcher works similarly to the FALLBACK dispatcher, but with one key difference: when no matching response is found within the Microcks’ dataset, instead of returning a fallback response, it changes the base URL of the request and makes a call to the real service.

Here again, enabling this proxy mechanism is a per-operation setting that allows you to mix different behaviors in the same Microcks API endpoints. Hence, you can use regular mocks, or try to proxy a request when nothing is found on the Microcks’ side or always proxy to the real backend.

How do we enable them?​

Dispatcher configuration in Microcks is a per-operation setting, so enabling PROXY or PROXY_FALLBACK must be done at the operation level. There are many ways to set up this part in Microcks - overriding the inferred default dispatching mechanism, you can: use the UI, use the API, use a Metadata artifact, or use API specification extensions like we did just below.

PROXY​

To enable the PROXY dispatching, we only need to specify PROXY as the dispatcher and the base URL of the actual service as the dispatcherRules:

x-microcks-operation:
  dispatcher: PROXY
  dispatcherRules: http://external.net/myService/v1

PROXY_FALLBACK​

The configuration of the PROXY_FALLBACK dispatcher is similar to that of the FALLBACK dispatcher. However, instead of the fallback key and its value which refers to the response name, we have the proxyUrl key with the base URL of the actual service as its value:

x-microcks-operation:
  dispatcher: PROXY_FALLBACK
  dispatcherRules: |
    {
      "dispatcher": "URI_PARTS",
      "dispatcherRules": "name",
      "proxyUrl": "http://external.net/myService/v1/"
    }

Myriad of opportunities!​

So, now we have two more ways to customize Microcks' behavior. Why would we need this?

We can now set up Microcks' URL for our client application and switch between mocking and calling the actual backend service by turning on/off the proxy dispatcher in the Microcks UI without any changes to the client application configuration.

And if we need some kind of automated, exotic logic, we can use the power of the SCRIPT dispatcher, which the PROXY_FALLBACK dispatcher wraps. This is the approach I took to implement the behavior that the QA engineer requested.

x-microcks-operation:
  dispatcher: PROXY_FALLBACK
  dispatcherRules: |
    {
      "dispatcher": "SCRIPT",
      "dispatcherRules": "if (new Random().nextInt(3) == 0) { return 'mock'; }",
      "proxyUrl": "http://external.net/myService/v1/"
    }

I really hope this new feature will be helpful. Based on my own experience, I would say that the contribution process is easy and comfortable. The journey from an idea to the finished feature has been a pleasant experience for me. So If you have any ideas on making Microcks more powerful, please feel free to share your thoughts with the community!