Utility to mock REST endpoints in real-time

Failure is success in progress - Albert Einstein

Prelude

The path to success is never meant to be easy and the destination is never meant to be the success itself. It's always about the journey.

In this article, I would like to introduce everyone to one of the peculiar open source projects that we have been working on for the past few months. We are a team of 2 young engineers [Neel and Aravind], who were keen to learn right from the start of our career. The passion for learning and building projects for the community is one of the burning desires we both have in common.

Mimock - Mock REST endpoints in real-time

This is a great utility tool that helps us to set up mocks for REST API endpoints to test UI applications locally or in CI/CD pipelines. Mimock is an interceptor-based mocking solution that enables the developer to create or update mocks without having to restart the application.

Story of why we built mimock

In the current technological world, the way in which an application is conceptualized, developed, deployed, and brought forward to market is a mind-blowing process. These different applications, projects, and tools built by startups, MSMEs, or even big enterprise companies are hugely reliant on the open source community.

The current trend towards open source contributions is heavily growing. Awesome engineers around the world have started contributing more and more to multiple different projects and even big tech companies now are playing a greater role for the good of the open source community. We were also planning to develop one such open source tool which should be useful as well as something that is easier to use. We tried to identify some of the problems which the developers were facing and tried to figure out solutions for the same.

Problem Statement:

What if the developer or QA can mock a REST API endpoint to mimic its response, without writing any implementation code for the mock itself?

This was the initial step toward conceptualizing our peculiar utility tool.

Mimock is developed for the purpose of setting up mocks for REST endpoints without the hassle of maintaining any code for the mocks. The application exposes a React-based UI which can be used by anyone with no prior coding experience to create and maintain mocks.

If a UI application is built with a configurable origin for the backend it is consuming, then mimock can be wired up in its place to serve the required response. This is applicable for backend services as well which rely on other APIs or services to process a request.

Some examples use cases are as follows,

• If your UI (Web or Mobile) relies on an external metered API that incurs cost based on the total hits, then mimock can be used in its place to mimic that API and serve the response on lower environments or CI/CD pipelines that runs UI automation tests
• If a backend API relies on another endpoint to download a PDF document and if that PDF server's latency is high which is not bearable for just testing the service locally or while running integration tests on pipelines, then mimock will come in handy for serving the required PDF document

Features

Unique features offered by the Mimock utility tool are as follows,

• Intuitive UI: Provides an intuitive UI that lets anyone manage mocks without any coding experience
• No Re-Deployment: Mocks can be added in real-time and no application restart is required. Mocks are created/updated on the go which ensures faster development and turn-around time
• Access Management: The platform follows a role-based user model and the admin can assign roles to the users to set up and restrict the access
• Text and Binary Response: With the support for both text and binary response types, setup your mock to serve a normal JSON response or a JPEG image file or even your desired PDF document

How we achieved to setup mock

We created a spring boot web application that hosts the logic to manage and store the mock REST API endpoints. This web application also performs the pattern matching for the stored mocks whenever they are hit by the respective client/UI application which is accessing the targeted REST API endpoint.

The below section explains one good use case of our platform,

Let us consider an application that has a separate backend and frontend hosted internally. The backend service exposes the APIs and the frontend application provides the user control.

The flow of the request and response diagrams before and after mimock are shown and explained as follows,

Actual interaction without mimock:

The UI application usually sends out the request to the REST API endpoint exposed by the backend service. Based on the API request sent out by the client the backend service performs the business logic and sends out the relevant response back to the UI.

In this case, the request-response flow depends upon the request headers, request body, query parameters, and so on and behaves differently for each and every API. This is the traditional setup we have seen so far in most of the projects.

The cost involved for the UI team to wait out the implementation of the API by the backend team is highly time-consuming. Let alone the cost involved when the API has to be re-deployed whenever there is a new change or feature enhancement for the API. If let’s say the API belongs to some external team the requested feature may or may not be provided in the stipulated timeline and the rate-limiting will be one major factor if it is a paid API.

The UI team also has the testing phase which involves hitting endpoints and analyzing the behavior of the UI using automated tests such as selenium or puppeteer. These tests run mostly in the CI/CD pipeline and the reliance on the backend service is very heavy.

Mimock as a platform acts as a replacement for these backend services deployed along with the UI application dev or testing environments. However the deployment behavior for integration environments, where both the real frontend and backend services, still stay the same.

In the project ideation phase, the best practice is to actually plan out the behavior of the API way ahead of its implementation. Most of the teams decide upon the API contract which will include the request and response details. This is a great advantage to us and why not use it in an automated smart way via a tool.

After introducing mimock:

Mimock platform acts as a replacement for the whole backend service. Here the respective client/UI application sends out the request and the mimock platform intercepts the request and responds based on the dynamic parameters such as query params, request body, and request headers.

Step by Step explanation:

1. The team uses the mimock platform to store the mocked REST API endpoints. (either via REST APIs exposed by us or the UI)
2. They are allowed to store multiple mock behaviors which they might expect and the relevant request and response details associated with them.
3. Now whenever the UI application sends out a request, the mimock platform intercepts the request and matches the route based upon the mocked API stored in its database and responds with the relevant response.

In this way, the mimock platform totally eliminates the reliance on the backend service for the REST API endpoints.

There is also an added bonus here as there is no re-deployment required since the mocks can be changed in real-time and the platform responds to the updated mocks with a faster turnaround time.

Automated UI journey tests can be run in CI/CD pipelines with the help of mimock by either running an ephemeral instance within the pipeline or by hosting mimock as an external service and accessing the mocked endpoints

Tech Stack

Our tech stack involves,

• Spring Boot - For the core backend
• React - For the intuitive UI
• Postgres - For storing the mocks and user information
• Docker - For distribution

Items we have in our roadmap

Some of the items we have in our roadmap includes as follows,

• Import Mocks in Bulk
• Regex matching for dynamic fields in query params, request body, and request headers
• Dynamic text response generation using the fields from the request (query param, request body, or request headers)
• Cloning mocks
• Grouping mocks to folders/categories
• File Preview for binary response mocks in the mimock platform

and much more on the way!!!

Reach out to us

You can reach out to us via the below channels,

• Github
• Website
• Docs
• Slack

Comments

[Justin Collum]

Looked promising but I had enough problems running it from the Docker image that I just gave up. I'd REALLY rather not have to install postgres to get a tool like this up and running.

Looks like I can probably run it with docker compose. In that case I'd make a separate repo that is standalone (no code) for just running the tool via docker. Give me instructions for how to get it up and running and (IMPORTANT) have the app tell me what address it is running on locally. If I have to dig into your source code to find out what port the app is listening on that's a user experience failure.

[Neel]

Hi Justin,

Thanks for your feedback. We are in the process of publishing platform specific bundles with startup scripts that will handle the DB and app config setup, and this is targeted for the next release.

The point about the docker-compose setup makes sense. We will update the docs with clear instructions and will publish the required files for starting the docker-compose service as release artifacts

[JoelBonetR 🥇]

Mock servers are useful tools but if it's a tool I need to run in my local machine I'm wondering Why do I need a DB to mock anything? Isn't it breaking some purposes of the mocks themselves?

I expect to mock certain requests to increase test suite speed in low-level (read unit) tests while having enough flexibility to import API contracts to speed up developments when parallelizing front and back feature developments.
Maybe using the filesystem instead with an import/export feature (so QA can use them for E2E test as well) will be easier 😅

If I'm wrong please explain so I can understand the reasons behind, thank you!