If you want to freshen up on what modern application architectures have brought to the table, what that entails for frontend development and testing and why we propose mocking as a viable solution, you can go ahead and check out the prelude to this article:
The goal π
Our target is to develop, test and validate our assumptions faster and with more confidence using API mocking for frontend environments. Regardless if you require simply a "quick" way to mock an environment, or a more sophisticated approach to adopt inside your team independent of size and complexity. Hope I can spark some thoughts for experimenting with a new mindset.
The problem and one common misconception π
One common misconception when engineers hear API mocking is that they explicitly wait for specifications, contracts and detailed documentation to be able to have something to work with.
This de-facto expectation is a conceptual blocker to reaping the serious benefits that API mocking can bring you.
Depending on the size of your team and the maturity of the application you are working on, some quick questions dumpen the mood even further around our efforts:
- Do we have a proper API documentation ?
- Is the documentation up-to-date and why not ?
- Do we have the time/resources to create and maintain API documentation ?
Taking into account the fact that modern frontend applications can depend on multiple APIs handled by different teams or even domains, we can consider the best case scenario:
With solid team responsibilities, diligence and effort, in medium and large teams you will probably find the assets in some form of Swagger definitions or Postman collections that you can read and even mock with some tooling!
If you are already there, that is a great start but in the case you are working on larger scale projects, more questions start creeping up from the back of your head π
- Does every team document their API in the same tool/repository ?
- How many third-party APIs our application is pulling data from and do they have a proper documentation ?
Before this sounds too depressing...
For a large span of use cases, you do not require all of these criteria to mock your API environment π ββοΈ
The issue and the 1-minute solution
So imagine the only thing that you have access to is a page or a set of pages, you have to work on in your own development environment. The API interactions that you aim to mock are there, happening in production, staging, test or any environment that you want to mock them from.
What you want is to be able to record and replay responses independently of the presence of the actual system. To add into it, you don't want only a specific endpoint, but all the endpoints from not one but more than one hosts.
Here comes
All the code that you need for this technique can be found in this sandbox with brief instructions.
What if there was a way to just specify some URL criteria for the endpoints you would like to mock, navigate to the set of pages that have these interactions and store them automatically so that you can use it later with a mock server ?
Seems there is a way you can do it; independent of backend/frontend implementation and without complex logic or many dependencies.
The technique involves the snapstub CLI tool and the Puppeteer library.
It does not have a name yet but we can call it puppeteer-snapstub.
The features that we are interested in from Puppeteer involve the capability to open a browser and intercept network requests with certain filter criteria.
patterns: [
{
urlPattern: "*host-you-want-to-intercept.com*",
resourceType: "XHR",
interceptionStage: "HeadersReceived"
}
/*
Add as many patterns as you like
*/
]
From snapstub we are intereted in its exposed programmatic API that allows us to add new mock entries and certainly the server that can then replay them.
snapstub.save({ url, stdin, saveOptions: { ... });
The process goes just like:
- You open up a page with Puppeteer.
- You do the interactions that will trigger the requests you expect.
- Close down puppeteer and start the snapstub server.
- Mocks are ready and waiting.
This is it, you now have mock responses for any network request that satisfied the criteria that were specified. When you want to use these endpoints during development just change the hosts to request those APIs from to use localhost:8059 and you are good to go.
In less than a minute, the time that it will take you to navigate between the pages, you have a folder with all the mock requests recorded and ready to be automatically replayed.
It is now portable, ready to be shared with the team or even stored in the frontend repository and most of all 100% available.
Special thanks
This article and methodology would not be without stumbling upon a presentation by Ruy Adorno with the topic of Mocking APIs for fun & profit in an npm newsletter some time ago.
Drawings made in the amazing excalidraw
Image by F. Muhammad from Pixabay
Top comments (1)
Very cool! Thanks for sharing π