Co-founder of Microcks | Director of Engineering at Postman Open Technologies
Microcks 1.10.0 release 🚀
We are excited to announce today the 1.10.0
release of Microcks, the CNCF
’s open-source cloud-native tool for API Mocking and Testing, ready for summer ☀️ vacations! 🚀
For this release, we received help from 4 new code committers and dozens of others who opened, contributed, and reviewed 46 issues. Most of them are adopters! Kudos to all of them 👏 and see greetings along 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.
![microcks-feature](/images/blog/microcks-1.10.0-feature_hud4a3f9c5a6ef723d67bffcaf2f3fced7_609799_1251x828_resize_q90_h2_lanczos_3.webp)
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 will take you through a real use-case of managing a realistic 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, which will be 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 with development teams but also for 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 to be used as a secondary artifact format. 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 will never be 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 plan your update carefully depending on your setup. We’ve made significant updates on external container dependencies like MongoDB, Keycloak, and theirits associated Postgres database.
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 thelibrary/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 fresherquay.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 fresherlibrary/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 again in 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 that the dependencies Microcks proposes during installation are provided for commodity purposes only. Our take is that you shouldn’t rely on them for crucial “production” workloads but rather 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 the way you can customize the images and external dependencies 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
like 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 ! 🎉
🚀 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 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 discussion about significant additions regarding 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 Twitter , Mastodon , LinkedIn , and our YouTube channel !
Thanks for reading and supporting us! ❤️