The flow for developing the Frontend first using API specifications and mock data instead of an unfinished Backend

Generate dummy JSON for API responses

Generate mock data in the browser from JSON samples without confidential information by specifying field rules, count, Seed, and output format.

Open API mock data generation tool Open the JSON formatter and syntax checker Open the JSON Schema Generator Open the JSON Schema Validator

Conclusion: Use the API specification as the source of truth and create a mock response

Rather than defining Path or Status independently, extract Response Body types from the API specification and create normal, empty, and Error Fixtures. The Frontend handles Mocks and the live API through the same Interface, limiting switch points.

If the frontend develops an independent mock, its types, null handling, and pagination format may not match when the backend is complete. Synchronize contract changes with the mock.

Division of work before the backend is complete

Deliverable	Assignee	confirmation
API contract	Frontend/backend collaboration	Type, required, Status
Mock JSON	Use on the frontend	Matches the contract
Request Intercept	MSW, etc.	Path, Method, Status
Production API	Backend	Pass the same Contract Test

Steps for implementing the frontend first

1. Agree on success, empty, and error responses for each endpoint.
2. Create one JSON example that contains no personal information.
3. Generate the required number and save them as fixtures.
4. Replace the data access layer with a mock and implement the UI.
5. After the backend is complete, run contract tests and switch to the real API.

UI states to check first

Account to check	Cases to prepare	Confirmation details
Loading	Configure delays on the MSW side	Skeleton and duplicate submission
Success	Normal response	Basic display
Empty	Empty array / zero items	Empty State
Error	Error body and status	Retry and guidance

DevelopTools does not set delays or HTTP status codes. Manage generated bodies separately from network mock settings such as MSW.

Make it easy to switch to the real API

Do not continue importing Fixtures directly into UI Components; replace Mocks at the Repository or Fetcher boundary. Sharing type definitions, OpenAPI, or JSON Schema as a contract makes differences easier to detect.

What the API mock data generator can and cannot do

Item	Current support	Additional information
Input	Pasted JSON, .json files, and five types of presets	Direct input of OpenAPI / JSON Schema is not supported.
output	Pagination JSON in single-object, array, and fixed formats	Does not start HTTP endpoints or mock servers
Number of	1 to 10,000 items	The number of array elements is 0–100. There is no output byte limit.
Values	Sequential numbers, UUIDs, names, email addresses, URLs, IP addresses, numbers, booleans, dates and times, enums, null, and more	Inference from field names and sample values is heuristic
Reproducibility	Regenerate using the same settings as the string seed.	Changing the generator implementation may change future values
Locale	Japanese and English	Use the built-in dictionary; do not load the Faker Library.
Edge Case	null probability, empty arrays, fixed values, and numeric ranges	Occurrence probabilities for Optional fields and dedicated Boundary Scenarios are not supported.
Save	Copy and UTF-8 JSON download	Do not send input or generated results to the server.

The generated content is JSON data that can be used for API responses. Configure MSW handlers that intercept requests, HTTP status, headers, delays, and endpoints themselves in a separate development environment.

Compare primary sources with the implementation

Specifications for Faker, MSW, Storybook, OpenAPI, and JSON Schema are updated. Do not permanently rely on examples in articles; check the version in use and official documentation. DevelopTools' generator does not embed Faker or MSW; it generates JSON using its own seeded random number generator and built-in dictionaries in the browser.

Example: Create a product list before the backend

Agree on the Product id, name, price, and stock, and prepare 20 normal items and an empty array.

Use a separate fixture for the error body and configure HTTP 500 in the MSW handler.

Agree on the Response type
Generate normal, empty, and Error cases
Integrate into MSW, etc.
Rerun the same UI test against the real API

Before integration, check response differences so the UI does not use properties that exist only in mocks.

Frequently asked questions

Do I also need a Mock Server?: Fixtures are sufficient when only passing Data to a simple Component. Combine them with MSW or similar when also testing actual fetch processing.
Can I leave a Mock in production?: Limit it to development/test use and separate the configuration so it cannot enter production bundles or switching conditions.