Create fake APIs with API stubs

The best way to test your application and ensure that all data bindings work, is using actual data. In a typical modern web application, this data would be fetched from a remote web API. However, this API may still be under construction or not be available at all. Therefore, JitBlox allows you to simulate these using API stubs and Mock data.

For a detailed how-to, we recommend following the tutorial Using mock data sets and API stubs.

Stub operations

API Stubs let you define a set of operations that would otherwise be performed against a real API endpoint. When you create components that need to fetch their data from a backend, you can select any of the API operations that you defined in an API Stub. By doing so, JitBlox will generate all the necessary code to make the actual API call but return a mock data set instead.

Mock data

An API stub also needs to return some data, which is what mock data sets are for: setting up test data. Once you created a mock data set, you can return that data set as the result of an API operation. Multiple operations can return data from the same data set, as long as the type of the data set matches the return type of the operation. API operations can also accept filter parameters that allow you to return a subset of the associated mock data set.

Edit mock data as JSON

If you prefer, you can see and edit the raw JSON structure of your mock data. This can be useful if you want to easily move data between different mock data sets, or between mock data sets and component properties.

1. At any level in the mock data editor, click the edit as JSON icon text_snippet in the bottom right corner.
2. This will bring up a simple text input that allows copy/pasting JSON data. Any malformed JSON won't be imported, and neither will properties that are not part of the current type (these will simply be ignored).

Dealing with mock data in your downloaded app

Apps generated by JitBlox make use of the popular Mock Service Worker (MSW) API mocking library. MSW intercepts API requests at the network level and returns mocked results instead of forwarding the request to the actual API. This keeps your app’s API client code free from mocking code.

For example, consider the following getAllBooks() method in Angular:

import { HttpClient } from '@angular/common/http';
import { inject, Injectable } from '@angular/core';
import { Observable } from 'rxjs';
import { Book } from '../model';

@Injectable({ providedIn: 'root' })
export class BookService {
  private client = inject(HttpClient); 

  /**
  * Returns all books.
  */
  public getAllBooks(): Observable<Book[]> {
    // Replace "/_mock-api/book-service/get-all-books" with a real URL if you wish
    return this.client.get<Book[]>('/_mock-api/book-service/get-all-books');
  }
}

Assuming you have connected this request to return the mock data set named bookMockData, you will find the following handler in the src/app/mocks directory of your app’s source code:

import { http, HttpResponse } from 'msw';
import { Book } from '../model';
import { bookMockData } from './book-service-mock-data';

export const bookServiceHandlers = [
  // Returns all books.
  http.get<{}, {}, Book[]>('/_mock-api/book-service/get-all-books', () => {
    // Return book mock data, sorted by title
    return HttpResponse.json(bookMockData.sort((a, b) => a.title == null ? -1 : b.title == null ? 1 : a.title.localeCompare(b.title)));
  })
];

The advantage of this separation is that your mock data is completely isolates from the rest of the application. With minimal changes, you can gradually replace your mock API URLs with real API endpoints.

Disabling mocking entirely

In addition to adjusting the URL per API call, you can also enable or disable MSW entirely. This can be done by setting the enabled flag to false in src/app/mocks/mock.config.ts:

export const mockConfig = {
  enabled: false,
  basePaths: [
    '/_mock-api/'
  ]
}