We have all been there when the backend isn't ready with APIs so the frontend developers manually hardcode the response.

It's time consuming and comes with a lot of indirect problems.

Today, we will explore how Requestly can help you build frontend applications at least 10x faster by reducing dependency on backend developers.

Let's jump in.

In a nutshell, we are covering these topics in detail.

1. What is the usual workflow when APIs aren't available?
2. How Requestly solve that problem with use cases.
3. More things that Requestly can help you achieve.

Star Requestly ⭐

1. What is the usual workflow when APIs aren't available?

In most cases, there isn't an efficient way to implement a proper frontend without API logic.

We can mock an API using Mirage JS but it still won't solve the issue completely.

Let's see what is the usual dev workflow for any frontend developer when there are no APIs ready yet.

⚡ Backend developers create API contracts, which define how the frontend can interact with the backend services. These contracts are shared in JSON format, detailing the expected request and response structures.

⚡ Frontend developers take these API contracts and hardcode the expected responses directly into their code (workaround). This is often done to allow for immediate development and testing of the UI without waiting for the backend to be fully implemented.

⚡ When frontend developers need to integrate the actual API or submit a pull request (a request to merge their code changes into the codebase), they have to remove the hardcoded responses. This is necessary to ensure that the code interacts with the live API rather than the static data.

⚡ If reviewers leave comments on the pull request, frontend developers may need to revert to the hardcoded responses to continue refining the UI based on the feedback, since the actual API might not be available or stable at that moment. It's a huge hassle for simple stuff.

⚡ Similarly, during API integration, if issues arise (for instance the API is not returning the expected data), developers may need to bring back the hardcoded responses to continue working on the UI without being blocked by backend issues.

⚡ This back-and-forth of removing and reintegrating hardcoded responses can lead to a disorganized codebase and is very time-consuming. Developers may spend a lot of time managing these changes rather than focusing on building features.

⚡ The reliance on hardcoded responses makes it very tough to test various edge cases. Developers have to repeatedly modify the hardcoded data to test different situations, which may lead to errors and inconsistencies.

✅ Instead of hardcoding responses, a simple solution for developers can be to use mock servers that simulate API responses. This allows for more dynamic testing and reduces the need to modify code repeatedly.

Let's see how we can solve this problem in the next section!

2. How Requestly solves that problem including use cases.

If you've ever developed a website, you know that every app needs to make a call to the server to fetch its resources.

It can be API requests, scripts or anything else to render it on the webpage.

Requestly is an open source frontend development platform that helps developers test and debug their apps faster without needing multiple deployment cycles. It helps you to:

✅ Build features when backend API is not ready.

✅ Testing code changes in production without deployment cycles.

✅ Testing, Validating, Mocking API responses and many more.

🎯 How to install Requestly?

You can download the desktop app or find it on your preferred browser including Chrome, Safari and Brave.

As I discussed the hardcoding responses in the codebase, you no longer need to do it after setting up Requestly. With a mutual understanding of the backend and frontend, an API contract is decided and then defined on the Requestly dashboard for the desired API endpoint.

It serves the response in such a way that it's coming from the server to avoid making any changes in the codebase or any other complex configuration.

The teams can agree on the responses. It can be added to the Requestly dashboard which leads to proper progress on the same feature by both teams without any big problems!

There are many other use cases like Requestly can help avoid the risk of accidentally committing mock code. However, I will explore a single use case on how we can use it to update the response with production APIs.

Let's see how to change the response body of HTTP requests without making actual changes in the server content using the Requestly Response Rule.

First, let's create a new Rule to modify the response body of an HTTP request.

We will only look at modify response rule with different examples and cases.

You get various template options as well if you quickly want to get started.

🎯 Wikipedia quick peek update - Static Override.

We will explore how we can update the quick peek data with fixed data so that after hovering any word on Wikipedia will show the same response.

As usual, we are going with the REST API.

✅ Explanation.

-→ Request: this will contain the main API endpoint URL that will be used along with options like contains and equal.

-→ Response status: This will be the status code sent with the response that will help you identify the log easily. You can select the status codes like 3xx, 4xx, 5xx and many more depending on your case.

-→ Response: We can use static response data or a dynamic request to add custom logic using code. In case of lengthy API calls or the need to manage multiple requests simultaneously, using Async/Await can be efficient. It's damn useful :)

We will use Static Response in this example, which is another way of saying static override.

If you're not aware of what a quick peek is, it is shown whenever anyone hovers over a text to understand more. You would have noticed it on Wikipedia.

To get the API endpoint, just start searching on Wikipedia and filter the network requests to get the one responsible for a quick peek.

The API endpoint responsible is: en.wikipedia.org/api/rest_v1.

Set up the rule with an example response, I've just used a quick peek JSON response of Amazon grabbed from the network log. You can copy this response from this gist on GitHub.

This should update the quick peek of any hovered word.

As you can see, the rule is applied properly.

Output.

The best part is that Requestly provides its own network log where you can catch the requests and analyze so many other stuff.

🎯 Amazon Search Suggestion - Dynamic Override.

Let's understand how we can update the response on the Amazon search suggestions by using Dynamic JavaScript in this example, which is another way of saying dynamic override.

To get the API endpoint, just start searching on Amazon and filter the network requests to get the one responsible for search suggestions.

The API endpoint we get is: https://completion.amazon.in/api/2017/suggestions.

-→ 🎯 Logic 1.

We are using a rule to append a number of suggestions with the URL of the API in the first suggestion of the Amazon query. The query is defined below!

function modifyResponse(args) {
  const {method, url, response, responseType, requestHeaders, requestData, responseJSON} = args;
  // Change response below depending upon request attributes received in args
  res= responseJSON
  res.suggestions[0].value= res.suggestions[0].value + " - " + res.suggestions.length + " - " + url
  return response;
}

Once the rule is implemented, a message will be clearly shown on the page that the rule has been applied. I did it with multiple rules and it clearly showed that those specific rules were being applied.

Output.

-→ 🎯 Logic 2.

Change the above rule to just show the response including the length of suggestions in the 2nd suggestion without appending the URL.

res.suggestions[1].value= res.suggestions[1].value+" - "+responseJSON.suggestions.length;

Output.

-→ 🎯 Logic 3.

Let's change the first suggestion entirely to requestly in the rule by using:

res.suggestions[0].value='requestly';

Output.

-→ 🎯 Simulating Error.

During testing, you often face a situation where you want to test your feature in case of an API Error because simulating some errors can be tricky on backends. Let's put the response code as 400.

Due to the error, there are no search suggestions visible!

You can read more on the official blog on how to use Modify API Response Rule.

Or watch this video!

3. More brief on what Requestly can help you achieve.

You can lots of other stuff like:

-→ Testing scripts or APIs directly on staging/production sites by redirecting HTTP requests(API Calls/Files) from one environment to another.

-→ Modify headers or Inject custom scripts/styles on external web pages.

-→ Intercept, Modify, and Mock GraphQL Query by applying extra targeting on operation name and query data.

It's extremely useful for QA Software engineers or frontend teams. Let's see some of the exciting features:

✅ You can create a workspace to share rules, mocks, and sessions. Faster collaboration leads to solving problems quickly!

✅ You can record sessions and it's automatically done whenever you test a rule from the dashboard.

✅ You can enable/disable rules from the dashboard.

✅ You can get free credits and buy a premium plan after doing some basic things like creating a rule.

✅ You can read the documentation on how they perform in comparison with competitive tools like Charles Proxy, Fiddler, Resource Override, ModHeader, HTTP Toolkit, Proxyman, Wireshark, Mockoon, BirdEatsBug and Jam.

You can follow the quickstart guide and read how to guides which would answer most of your questions.

I also recommend watching this quick demo to get started with Requestly!

I think it's safe to say Requestly can help you build your frontend apps at least 10x faster. It's easy and efficient.

It's worth it and a lot of international teams already use it in their workflow.

Let me know if you've any questions or feedback.

Have a great day. Till next time!

If you like this kind of stuff, please follow me for more :)

"Write more, inspire more!"