DEV Community: Nilesh Kumar

How to Test Cursor-Based Pagination & Infinite Scroll in React Without a Backend

Nilesh Kumar — Fri, 23 Oct 2026 03:15:00 +0000

Standard offset-based pagination (?page=2&limit=10) works fine for simple tables, but for modern infinite scroll feeds (Twitter, Instagram, Reddit style), offset pagination fails because:

New items inserted at the top shift the entire list, causing duplicate items or skipped entries when scrolling down.
Database OFFSET queries degrade severely on large datasets.

Modern production APIs use Cursor-Based Pagination (?cursor=<base64>&limit=10), returning a pointer to the last item seen (nextCursor) and a boolean hasMore flag.

Playground API now provides native Cursor-Based Pagination across all endpoints!

1. The Cursor Endpoint Contract

Make a request with cursor and limit:

curl "https://playground.nileslabs.com/posts?cursor=eyJpZCI6MTB9&limit=10"

JSON Response:

{
  "data": [
    { "id": 11, "title": "Next Post Title", "body": "..." },
    { "id": 12, "title": "Another Post", "body": "..." }
  ],
  "pagination": {
    "nextCursor": "eyJpZCI6MjB9",
    "hasMore": true,
    "total": 100
  }
}

When reaching the end of the collection, hasMore returns false and nextCursor returns null.

2. Integrating with TanStack React Query (`useInfiniteQuery`)

import { useInfiniteQuery } from '@tanstack/react-query';

async function fetchPosts({ pageParam = null }: { pageParam?: string | null }) {
  const url = pageParam
    ? `https://playground.nileslabs.com/posts?cursor=${pageParam}&limit=10`
    : 'https://playground.nileslabs.com/posts?limit=10';

  const res = await fetch(url);
  return res.json();
}

export function InfiniteFeed() {
  const {
    data,
    fetchNextPage,
    hasNextPage,
    isFetchingNextPage,
  } = useInfiniteQuery({
    queryKey: ['infinite-posts'],
    queryFn: fetchPosts,
    getNextPageParam: (lastPage) => lastPage.pagination.nextCursor,
    initialPageParam: null,
  });

  return (
    <div>
      {data?.pages.map((page, i) => (
        <div key={i}>
          {page.data.map((post: any) => (
            <div key={post.id} className="post-card">
              <h4>{post.title}</h4>
            </div>
          ))}
        </div>
      ))}

      {hasNextPage && (
        <button onClick={() => fetchNextPage()} disabled={isFetchingNextPage}>
          {isFetchingNextPage ? 'Loading more...' : 'Load More'}
        </button>
      )}
    </div>
  );
}

3. Interactive Pagination Studio

Explore cursor tokens, page parameters, and infinite scrolling in the documentation:
👉 https://playground.nileslabs.com/docs/pagination

Conclusion

Test real infinite scroll feeds and TanStack Query caching seamlessly with Playground API!

How to Test Multipart File Uploads & Cloud Storage CDN in React Without an S3 Bucket

Nilesh Kumar — Thu, 22 Oct 2026 03:15:00 +0000

Building drag-and-drop file upload interfaces in React often hits a major hurdle during development: where do the files actually go?

Setting up AWS S3 pre-signed URLs or Cloudinary credentials just to test if your progress bar animates or if image thumbnails render properly is tedious. Worse, when you need to test edge cases—like uploading a 15MB file over a slow 3G connection, or handling unsupported file types (415 Unsupported Media Type)—mocking FormData requests in client-side code feels impossible.

Playground API provides a dedicated Multipart File Upload & Cloud Storage Sandbox (POST /api/v1/uploads and POST /api/v1/uploads/bulk) with simulated upload latency and CDN media URLs!

1. Uploading a Single File with `FormData`

Send standard multipart/form-data requests:

const formData = new FormData();
formData.append('file', selectedFile);
formData.append('folder', 'avatars');

const res = await fetch('https://playground.nileslabs.com/api/v1/uploads', {
  method: 'POST',
  body: formData,
});

const data = await res.json();
console.log('CDN URL:', data.url);

JSON Response:

{
  "id": "upl_9f8a7b6c5d",
  "filename": "avatar.png",
  "mimetype": "image/png",
  "size": 245912,
  "url": "https://images.unsplash.com/photo-1534528741775-53994a69daeb?w=500&auto=format&fit=crop",
  "thumbnail_url": "https://images.unsplash.com/photo-1534528741775-53994a69daeb?w=150&auto=format&fit=crop",
  "folder": "avatars",
  "created_at": "2026-09-20T00:00:00.000Z"
}

2. Simulating Upload Latency & Progress Bars

To test your UI progress bars and loading spinners under real-world conditions, pass the _delay query parameter or X-Simulate-Delay header:

curl -X POST "https://playground.nileslabs.com/api/v1/uploads?_delay=2000" \
  -F "file=@sample.pdf"

Playground API holds the connection and streams progress events before completing with the CDN asset metadata.

3. Bulk Uploads & Multi-File Validation

Need to test multi-file upload zones? Use POST /api/v1/uploads/bulk:

const formData = new FormData();
files.forEach((file) => formData.append('files', file));

const res = await fetch('https://playground.nileslabs.com/api/v1/uploads/bulk', {
  method: 'POST',
  body: formData,
});
const { items, total_files, total_size } = await res.json();

4. Live Interactive Upload Studio

Test drag-and-drop uploads, inspect CDN response URLs, and preview image thumbnails directly inside the docs:
👉 https://playground.nileslabs.com/docs/uploads

Conclusion

Say goodbye to dummy file upload mocks. Test real FormData requests, simulated bandwidth, and CDN responses with Playground API today!

Learn how to test native WebSockets, Socket.io, room messaging, typing indicators, and SSE streams in frontend apps without running local WS servers.

Nilesh Kumar — Wed, 21 Oct 2026 03:15:00 +0000

Frontend engineers building real-time collaborative interfaces—such as live customer support widgets, multiplayer notification bars, or team chat channels—inevitably run into a painful testing hurdle:

"How do I test bi-directional message dispatching, typing indicators, reconnection loops, and multi-user room broadcasting before the backend WebSocket server is deployed?"

Traditionally, you either have to write a local Node.js ws or socket.io server script, manage local port tunnels with ngrok for mobile testing, or write brittle in-memory mock classes that don't test true RFC 6455 network frames.

In this guide, we explore the mechanics of real-time protocols, compare Native WebSocket vs Socket.io vs Server-Sent Events (SSE), and demonstrate how to build an interactive, multi-room chat client in React tested against Playground API's zero-config real-time gateway.

1. Comparing Real-Time Transport Protocols

Before writing frontend code, let's look at the three primary real-time communication patterns:

Protocol Comparison Matrix

Feature	Native WebSocket (`wss://`)	Socket.io (`/socket.io`)	Server-Sent Events (SSE)
Directionality	Full-Duplex Bi-directional	Full-Duplex Bi-directional	Unidirectional (Server → Client)
Browser Native?	✅ Yes (`new WebSocket()`)	❌ Requires client library	✅ Yes (`new EventSource()`)
Automatic Reconnect	❌ Manual implementation	✅ Built-in	✅ Built-in by browser
Room / Namespace	❌ Manual routing	✅ Built-in	❌ Single stream URL
Best For	Live chat, gaming, standard APIs	Enterprise messaging, auto-fallbacks	Live notifications, telemetry

2. Connecting to the Live Real-Time Gateway

Playground API provides a unified real-time gateway where Native WebSocket clients and Socket.io clients communicate seamlessly in the exact same room:

Native WebSocket: wss://playground.nileslabs.com/ws?room=general&username=Alice
Socket.io 4.x: https://playground.nileslabs.com with path /socket.io
Server-Sent Events (SSE): https://playground.nileslabs.com/api/v1/stream/notifications

The Standard Message Schema

All incoming and outgoing chat payloads follow this standardized format:

{
  "type": "message",
  "id": "msg-local-12345",
  "room": "support",
  "sender_id": 1,
  "sender_name": "Alice Developer",
  "recipient_id": "bot_assistant",
  "text": "Hello, I need help testing real-time events!",
  "created_at": "2026-09-19T10:00:00.000Z"
}

3. Building a Real-Time React Chat Component

Let's build a clean, production-ready React chat component using the native browser WebSocket API with automatic reconnection, typing indicators, and room switching:

// src/components/LiveChatWidget.tsx
import React, { useState, useEffect, useRef } from 'react';

interface ChatMessage {
  id: string;
  room: string;
  sender_name: string;
  text: string;
  created_at: string;
}

export function LiveChatWidget() {
  const [messages, setMessages] = useState<ChatMessage[]>([]);
  const [inputText, setInputText] = useState('');
  const [room, setRoom] = useState('support');
  const [isConnected, setIsConnected] = useState(false);
  const [botTyping, setBotTyping] = useState(false);
  const wsRef = useRef<WebSocket | null>(null);

  useEffect(() => {
    // 1. Establish Native WebSocket connection with query parameters
    const wsUrl = `wss://playground.nileslabs.com/ws?room=${room}&username=FrontendEngineer`;
    const ws = new WebSocket(wsUrl);
    wsRef.current = ws;

    ws.onopen = () => {
      setIsConnected(true);
    };

    ws.onmessage = (event) => {
      try {
        const payload = JSON.parse(event.data);

        if (payload.type === 'message') {
          setMessages((prev) => [...prev, payload]);
        } else if (payload.type === 'typing') {
          setBotTyping(payload.isTyping);
        }
      } catch (err) {
        console.error('Invalid JSON payload:', event.data);
      }
    };

    ws.onclose = () => {
      setIsConnected(false);
    };

    return () => {
      ws.close();
    };
  }, [room]);

  function handleSendMessage(e: React.FormEvent) {
    e.preventDefault();
    if (!inputText.trim() || !wsRef.current || wsRef.current.readyState !== WebSocket.OPEN) return;

    // 2. Dispatch message to the room
    const messagePayload = {
      type: 'message',
      room: room,
      sender_name: 'FrontendEngineer',
      text: inputText,
    };

    wsRef.current.send(JSON.stringify(messagePayload));
    setInputText('');
  }

  return (
    <div className="max-w-lg mx-auto p-4 bg-slate-900 border border-slate-800 rounded-2xl shadow-xl text-slate-100 font-sans">
      {/* Header & Status */}
      <div className="flex items-center justify-between pb-3 border-b border-slate-800">
        <div className="flex items-center gap-2">
          <span className={`w-2.5 h-2.5 rounded-full ${isConnected ? 'bg-emerald-500 animate-pulse' : 'bg-rose-500'}`} />
          <h3 className="font-bold text-sm text-white">Live Chat (#{room})</h3>
        </div>
        <select
          value={room}
          onChange={(e) => { setMessages([]); setRoom(e.target.value); }}
          className="bg-slate-950 text-xs px-2 py-1 rounded border border-slate-700 text-slate-300"
        >
          <option value="support">#support (Echo Bot Enabled)</option>
          <option value="general">#general</option>
          <option value="random">#random</option>
        </select>
      </div>

      {/* Messages Feed */}
      <div className="h-64 overflow-y-auto my-3 space-y-2 p-2 bg-slate-950/60 rounded-xl border border-slate-800/80 text-xs">
        {messages.length === 0 ? (
          <p className="text-slate-500 text-center py-20">No messages yet. Send a message to chat with the Echo Bot!</p>
        ) : (
          messages.map((msg, idx) => (
            <div key={msg.id || idx} className={`p-2 rounded-lg ${msg.sender_name === 'FrontendEngineer' ? 'bg-indigo-600/20 ml-6' : 'bg-slate-800/60 mr-6'}`}>
              <span className="font-bold text-slate-300 block">{msg.sender_name}:</span>
              <p className="text-slate-200 mt-0.5">{msg.text}</p>
            </div>
          ))
        )}
        {botTyping && (
          <div className="text-slate-400 italic text-[11px] animate-pulse">
            Support Bot is typing...
          </div>
        )}
      </div>

      {/* Input Form */}
      <form onSubmit={handleSendMessage} className="flex gap-2">
        <input
          type="text"
          value={inputText}
          onChange={(e) => setInputText(e.target.value)}
          placeholder="Type your message or mention @bot..."
          className="flex-1 bg-slate-950 border border-slate-700 px-3 py-2 rounded-lg text-xs text-white focus:outline-none focus:border-indigo-500"
        />
        <button
          type="submit"
          disabled={!isConnected}
          className="bg-indigo-600 hover:bg-indigo-500 disabled:bg-slate-800 text-white font-bold text-xs px-4 py-2 rounded-lg transition-colors"
        >
          Send
        </button>
      </form>
    </div>
  );
}

4. Testing the Built-in Support Bot Simulator

When testing chat applications locally, it’s frustrating to test alone because you have to open two browser windows to simulate a conversation.

Playground API includes an Automated Echo Support Bot:

When you join the #support room or mention @bot, the gateway automatically fires a { type: "typing", isTyping: true } event.
After 250ms of natural typing delay, the bot replies with an echo acknowledgment.
It automatically turns off the typing indicator event!

5. Summary & Key Takeaways

Native WebSockets and Socket.io can be tested without local servers. By targeting wss://playground.nileslabs.com/ws, frontend developers can verify connection lifecycles, typing indicators, and room routing instantly.
Server-Sent Events (SSE) provide lightweight unidirectional streams. Use GET /api/v1/stream/notifications for testing notification bells and real-time dashboard counters.
Session state is preserved. Chat history created during your session persists across refreshes.

Explore the interactive live Chat Studio and copy starter code at:

👉 https://playground.nileslabs.com/docs/chat

Zero-Config GraphQL Prototyping: Nested Queries, Relations & State Mutations

Nilesh Kumar — Tue, 20 Oct 2026 03:15:00 +0000

I still remember the first time I tried to prototype a React app using GraphQL.

I loved the core promise of GraphQL: no more waterfall REST requests, no over-fetching, and the ability to declare the exact relational data tree my UI needed in a single, clean query.

I sat down over a weekend to build a simple social feed prototype with authors, nested posts, and comments. But within an hour, my excitement turned into pure exhaustion.

Before I could write even a single GraphQL query in my React component, I was completely buried under backend plumbing: writing SDL schema definitions, handcrafting recursive resolvers in Apollo Server, configuring Prisma models, setting up SQLite, and fixing N+1 database queries.

What should have been a 2-hour frontend UI experiment turned into an entire weekend of backend boilerplate.

When I looked around the ecosystem for a hosted GraphQL sandbox to prototype with, every free mock API I found only supported basic REST endpoints. There wasn't a single zero-config GraphQL sandbox that supported real nested relational queries AND stateful mutations for a developer's session.

I got so tired of that barrier to entry that I built a native GraphQL gateway directly into Playground API.

In this guide, I'll show you how to prototype complex React interfaces with nested relational queries, execute stateful mutations, and test schemas in an interactive GraphiQL IDE — with zero backend configuration.

The Power of Nested Relational Resolvers

Consider a common frontend UI: an Author Bio card that displays the author's details, their published posts, and the top comments under each post.

In a traditional REST architecture, fetching this data requires multiple roundtrips:

GET /users/1
GET /users/1/posts
GET /posts/1/comments, GET /posts/2/comments, etc.

In GraphQL, you request this entire hierarchy in a single nested query:

query GetAuthorWithPostsAndComments($authorId: ID!) {
  user(id: $authorId) {
    id
    name
    email
    company {
      name
    }
    posts {
      id
      title
      body
      comments {
        id
        name
        body
      }
    }
  }
}

The server resolves each child node recursively, returning a clean, perfectly structured JSON tree matching your UI layout.

Exploring the Live GraphQL Gateway & GraphiQL IDE

Playground API by Niles Labs includes a full GraphQL Gateway at:

https://playground.nileslabs.com/api/v1/graphql

If you open this URL in your web browser, you are greeted with a full in-browser GraphiQL IDE.

The interactive IDE includes:

Interactive Schema Documentation Explorer: Click through User, Post, Comment, Todo, and Geo types.
Real-Time Autocomplete & Validation: Syntax highlighting and auto-completion as you type.
Variable Support: Test parameterized queries with dynamic JSON variables.

Executing GraphQL Queries in React with Zero Dependencies

You don't need heavyweight client libraries like Apollo Client or Relay to start querying GraphQL. You can execute queries using standard JavaScript fetch:

// src/services/graphqlClient.js
const GRAPHQL_ENDPOINT = 'https://playground.nileslabs.com/api/v1/graphql';

export async function executeGraphQL(query, variables = {}) {
  const response = await fetch(GRAPHQL_ENDPOINT, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      query,
      variables,
    }),
  });

  const result = await response.json();

  if (result.errors && result.errors.length > 0) {
    throw new Error(result.errors[0].message);
  }

  return result.data;
}

Executing Stateful GraphQL Mutations

Most mock GraphQL endpoints only support read-only queries. If you run a mutation, the data is not actually saved.

With Playground API, mutations operate against the virtual session overlay. When you execute a GraphQL mutation, the new record is saved to your session and is immediately accessible in subsequent GraphQL queries and REST calls.

The GraphQL Mutation:

mutation CreateNewPost($title: String!, $body: String!, $user_id: ID!) {
  createPost(title: $title, body: $body, user_id: $user_id) {
    id
    title
    body
    user {
      name
      email
    }
  }
}

Complete React Implementation:

// src/components/GraphQLPostManager.jsx
import React, { useState, useEffect } from 'react';
import { executeGraphQL } from '../services/graphqlClient';

const GET_POSTS_QUERY = `
  query GetRecentPosts {
    posts(limit: 5) {
      id
      title
      body
      user {
        name
      }
    }
  }
`;

const CREATE_POST_MUTATION = `
  mutation AddPost($title: String!, $body: String!, $user_id: ID!) {
    createPost(title: $title, body: $body, user_id: $user_id) {
      id
      title
      body
      user {
        name
      }
    }
  }
`;

export default function GraphQLPostManager() {
  const [posts, setPosts] = useState([]);
  const [title, setTitle] = useState('');
  const [body, setBody] = useState('');
  const [loading, setLoading] = useState(true);

  const loadPosts = async () => {
    try {
      setLoading(true);
      const data = await executeGraphQL(GET_POSTS_QUERY);
      setPosts(data.posts);
    } catch (err) {
      console.error(err);
    } finally {
      setLoading(false);
    }
  };

  useEffect(() => {
    loadPosts();
  }, []);

  const handleCreate = async (e) => {
    e.preventDefault();
    if (!title.trim()) return;

    try {
      const data = await executeGraphQL(CREATE_POST_MUTATION, {
        title,
        body,
        user_id: 1,
      });
      // Prepend the created post: it persisted in the session!
      setPosts(current => [data.createPost, ...current]);
      setTitle('');
      setBody('');
    } catch (err) {
      alert(`Mutation failed: ${err.message}`);
    }
  };

  return (
    <div style={{ maxWidth: '600px', margin: '2rem auto', fontFamily: 'sans-serif' }}>
      <h2>⚡ GraphQL Sandbox Manager</h2>

      {/* Mutation Form */}
      <form onSubmit={handleCreate} style={{ display: 'flex', flexDirection: 'column', gap: '8px', marginBottom: '2rem' }}>
        <input
          type="text"
          placeholder="Post title..."
          value={title}
          onChange={e => setTitle(e.target.value)}
          required
          style={{ padding: '8px', borderRadius: '4px', border: '1px solid #cbd5e1' }}
        />
        <textarea
          placeholder="Post content..."
          value={body}
          onChange={e => setBody(e.target.value)}
          rows={3}
          style={{ padding: '8px', borderRadius: '4px', border: '1px solid #cbd5e1' }}
        />
        <button type="submit" style={{ padding: '8px', background: '#e11d48', color: '#fff', border: 'none', borderRadius: '4px', cursor: 'pointer' }}>
          + Execute Mutation
        </button>
      </form>

      {/* Query Results */}
      {loading ? (
        <p>Fetching GraphQL data graph...</p>
      ) : (
        <div>
          {posts.map(post => (
            <div key={post.id} style={{ border: '1px solid #e2e8f0', borderRadius: '6px', padding: '1rem', marginBottom: '1rem' }}>
              <h4 style={{ margin: '0 0 4px 0' }}>#{post.id} {post.title}</h4>
              <p style={{ margin: '0 0 8px 0', color: '#64748b' }}>{post.body}</p>
              <small style={{ color: '#0284c7' }}>Author: {post.user?.name || 'Anonymous'}</small>
            </div>
          ))}
        </div>
      )}
    </div>
  );
}

3 Core Tips for GraphQL Frontend Prototyping

Leverage the In-Browser GraphiQL Explorer: Before writing frontend queries in JSX, construct and test them inside https://playground.nileslabs.com/api/v1/graphql to verify field names and query execution.
Use Variables for Dynamic Inputs: Never concatenate strings into GraphQL query strings (query { user(id: ${id}) }). Always use GraphQL variables (query ($id: ID!) { user(id: $id) }) to prevent syntax parsing errors and injection vulnerabilities.
Verify Mutation Responses: Always ask for the fields your UI needs immediately after a mutation executes so you can update client caches without needing an extra roundtrip fetch.

Conclusion

GraphQL makes data fetching declarative, type-safe, and elegant. With a zero-configuration GraphQL gateway that supports nested relations and stateful mutations, you can master and prototype GraphQL interfaces without spending hours configuring backend servers.

Test nested queries and mutations today on the Playground API GraphQL Gateway.

How to Test JWT Authentication and Silent Token Refresh in React Without a Backend

Nilesh Kumar — Mon, 19 Oct 2026 03:15:00 +0000

I once lost an entire Saturday afternoon trying to debug a silent JWT token refresh loop in a React app I was building.

The login modal and user dashboard were completely done. But testing the actual security mechanics was driving me up the wall:

How was I supposed to test what happens when an access token expires after 15 minutes?
How could I verify that my Axios interceptor cleanly caught the 401 Unauthorized, paused queued requests, called /auth/refresh, and retried the original request without logging the user out?
How could I test updating authenticated profile data via PATCH /auth/me?

The backend team wasn't ready yet, and none of the public mock APIs in the ecosystem offered realistic JWT authentication. They either didn't support auth at all, or returned static dummy strings that couldn't be decoded or verified.

To test a simple React AuthContext and an Axios interceptor loop, I was suddenly forced to stop frontend work and spend hours building a custom Express auth microservice with bcrypt, jsonwebtoken, database tables, and refresh token rotation logic from scratch.

It was infuriating. Frontend engineers shouldn't have to build an entire custom authentication backend just to test whether their Bearer token interceptor and login redirects work.

I thought: Why can't a mock API offer real, verifiable JWT authentication with /auth/login, /auth/refresh, and /auth/me built directly into the sandbox?

That frustration was the exact reason I built a full JWT Auth Simulation engine into Playground API.

In this guide, I'll walk you through how to implement and test a complete React authentication lifecycle — including login, token storage, silent refresh interceptors, and protected routes — without writing backend code.

The Standard JWT Authentication Architecture

A production frontend authentication flow typically follows this sequence:

sequenceDiagram
    autonumber
    actor User as React Application
    participant Auth as Auth API Sandbox

    User->>Auth: 1. POST /auth/login { username, password }
    Auth-->>User: 200 OK { access_token (15m), refresh_token (7d), user }

    User->>Auth: 2. GET /auth/me (Authorization: Bearer <access_token>)
    Auth-->>User: 200 OK { id: 1, name: "Leanne Graham", ... }

    Note over User,Auth: Time passes... Access token expires

    User->>Auth: 3. GET /auth/me (Expired Token)
    Auth-->>User: 401 Unauthorized

    User->>Auth: 4. POST /auth/refresh { refreshToken }
    Auth-->>User: 200 OK { access_token (Fresh 15m) }

    User->>Auth: 5. Retry original GET /auth/me with fresh token
    Auth-->>User: 200 OK

The Sandbox Authentication Endpoints

Playground API by Niles Labs provides built-in JWT authentication simulation endpoints under /api/v1/auth:

Endpoint	Method	Payload / Headers	Description
`/api/v1/auth/login`	`POST`	`{ username, email, password }`	Authenticates user; returns signed 15-minute `access_token` and 7-day `refresh_token`.
`/api/v1/auth/register`	`POST`	`{ name, username, email }`	Creates user in your session overlay and returns auth tokens.
`/api/v1/auth/refresh`	`POST`	`{ refreshToken }`	Validates refresh token and issues a fresh `access_token`.
`/api/v1/auth/me`	`GET`	`Authorization: Bearer <token>`	Verifies JWT signature and returns the authenticated user profile.
`/api/v1/auth/me`	`PATCH`	`Authorization: Bearer <token>`	Updates profile attributes within the caller's session overlay.

Implementing the Silent Refresh Interceptor with Axios

Let's implement a production-grade Axios client that automatically catches 401 Unauthorized errors, performs a silent token refresh, and retries the failed request.

1. The Authenticated HTTP Client (`httpClient.js`)

// src/services/httpClient.js
import axios from 'axios';

const BASE_URL = 'https://playground.nileslabs.com/api/v1';

// In-memory token storage (Best practice for XSS mitigation)
let accessToken = null;
let refreshToken = localStorage.getItem('playground_refresh_token');

export const setTokens = (access, refresh) => {
  accessToken = access;
  refreshToken = refresh;
  if (refresh) {
    localStorage.setItem('playground_refresh_token', refresh);
  } else {
    localStorage.removeItem('playground_refresh_token');
  }
};

export const getAccessToken = () => accessToken;

// Create Axios Instance
export const apiClient = axios.create({
  baseURL: BASE_URL,
  headers: { 'Content-Type': 'application/json' },
});

// Request Interceptor: Attach Bearer token
apiClient.interceptors.request.use((config) => {
  if (accessToken && !config.headers.Authorization) {
    config.headers.Authorization = `Bearer ${accessToken}`;
  }
  return config;
});

// Response Interceptor: Catch 401 and handle silent refresh
apiClient.interceptors.response.use(
  (response) => response,
  async (error) => {
    const originalRequest = error.config;

    // Check if error is 401 and we haven't already retried
    if (error.response?.status === 401 && !originalRequest._retry && refreshToken) {
      originalRequest._retry = true;

      try {
        // Request fresh access token
        const refreshRes = await axios.post(`${BASE_URL}/auth/refresh`, {
          refreshToken: refreshToken,
        });

        const newAccessToken = refreshRes.data.access_token;
        setTokens(newAccessToken, refreshToken);

        // Update Authorization header and retry original request
        originalRequest.headers.Authorization = `Bearer ${newAccessToken}`;
        return apiClient(originalRequest);
      } catch (refreshErr) {
        // Refresh token failed or expired -> log out user
        setTokens(null, null);
        window.location.href = '/login';
        return Promise.reject(refreshErr);
      }
    }

    return Promise.reject(error);
  }
);

2. The React `AuthContext` Provider (`AuthContext.jsx`)

// src/context/AuthContext.jsx
import React, { createContext, useContext, useState, useEffect } from 'react';
import { apiClient, setTokens, getAccessToken } from '../services/httpClient';

const AuthContext = createContext(null);

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  // Fetch current user on startup if token exists
  useEffect(() => {
    const initAuth = async () => {
      const storedRefresh = localStorage.getItem('playground_refresh_token');
      if (storedRefresh) {
        try {
          // Attempt token refresh on boot
          const refreshRes = await apiClient.post('/auth/refresh', {
            refreshToken: storedRefresh,
          });
          setTokens(refreshRes.data.access_token, storedRefresh);

          // Fetch authenticated profile
          const meRes = await apiClient.get('/auth/me');
          setUser(meRes.data);
        } catch {
          setTokens(null, null);
        }
      }
      setLoading(false);
    };

    initAuth();
  }, []);

  // Login action
  const login = async (username, password) => {
    const res = await apiClient.post('/auth/login', { username, password });
    setTokens(res.data.access_token, res.data.refresh_token);
    setUser(res.data.user);
    return res.data.user;
  };

  // Logout action
  const logout = () => {
    setTokens(null, null);
    setUser(null);
  };

  return (
    <AuthContext.Provider value={{ user, login, logout, loading }}>
      {children}
    </AuthContext.Provider>
  );
}

export const useAuth = () => useContext(AuthContext);

3. Protected Route Wrapper (`ProtectedRoute.jsx`)

// src/components/ProtectedRoute.jsx
import React from 'react';
import { useAuth } from '../context/AuthContext';

export default function ProtectedRoute({ children }) {
  const { user, loading } = useAuth();

  if (loading) {
    return <div style={{ padding: '2rem' }}>🔒 Verifying session...</div>;
  }

  if (!user) {
    return (
      <div style={{ padding: '2rem', color: '#dc2626' }}>
        <h3>🚫 Access Denied</h3>
        <p>Please log in to view this protected dashboard.</p>
      </div>
    );
  }

  return children;
}

3 Best Practices for Frontend JWT Security

Keep Access Tokens in Memory: Never store short-lived access tokens in localStorage where they are vulnerable to Cross-Site Scripting (XSS). Store access tokens in a JavaScript variable or React Context.
Prevent Refresh Token Storms (Queue Retries): If multiple simultaneous requests fail with 401, ensure only one /auth/refresh request is triggered while other pending requests wait in a queue.
Handle Expired Refresh Tokens Gracefully: If the refresh token itself is invalid or expired, immediately clear client state and redirect the user to the login screen with a friendly message.

Conclusion

Authentication doesn't have to be a blind spot in your frontend development workflow. By pairing a robust Axios interceptor with a real JWT sandbox that verifies tokens and simulates refresh lifecycles, you can test and bulletproof your authentication flows without writing a line of backend auth code.

Test JWT login, refresh tokens, and protected routes with Playground API by Niles Labs.

Compare building a modern React CRUD application with REST versus GraphQL. Understand query shapes, state mutations, and implementation patterns

Nilesh Kumar — Sat, 17 Oct 2026 03:15:00 +0000

Whenever I start a new client project or evaluate an architecture for a team, I inevitably get asked the same question:

"Should we build our frontend using REST or GraphQL?"

A few months ago, I was architecting a dashboard feature that needed to display user profiles, their published articles, and nested comment threads.

The REST advocates pushed for standard endpoints (/users, /posts, /comments), while frontend engineers worried about waterfall network requests (GET /users/1, then GET /users/1/posts, then GET /posts/:id/comments). The GraphQL advocates wanted a single query, while the backend team worried about schema complexity.

When I wanted to build a quick side-by-side prototype to settle the debate with real code, I ran into an absurd roadblock: I couldn't find a single mock backend that supported both REST and GraphQL queries on the exact same underlying dataset with mutation support.

I had to either spend an entire weekend building two separate mock servers, or give up on an authentic side-by-side comparison.

That frustration was a huge driver behind adding a native GraphQL gateway to Playground API — allowing developers to query the exact same data via REST or GraphQL side-by-side with zero setup.

In this post, we're skipping the theoretical internet debates. I'll show you how to build the exact same React CRUD feature using both approaches against a unified, live backend sandbox.

The Scenario: A User Profile with Posts and Comments

Let's build a user profile screen that needs to display:

User details (name, email, company)
The user's published blog posts
The latest comments on each post

Let's look at how REST and GraphQL approach this data requirement.

Approach 1: The REST Workflow

In standard REST architecture, resources are organized around distinct URL endpoints.

Fetching Data in REST:

To get the user and their related posts and comments, a REST client typically executes sequential or parallel HTTP GET requests:

1. GET /api/v1/users/1           ──► Fetches User profile
2. GET /api/v1/users/1/posts     ──► Fetches User's posts
3. GET /api/v1/posts/10/comments ──► Fetches Comments for Post 10

The Advantage: Simple, intuitive, leverages standard browser and CDN caching, uses native HTTP status codes (200, 404, 500).

The Friction: Multiple network roundtrips (under-fetching) or downloading unused fields (over-fetching).

React REST Code Example:

// Fetching with REST
async function loadUserDataREST(userId) {
  const [userRes, postsRes] = await Promise.all([
    fetch(`https://playground.nileslabs.com/api/v1/users/${userId}`),
    fetch(`https://playground.nileslabs.com/api/v1/users/${userId}/posts?_limit=3`)
  ]);

  const user = await userRes.json();
  const posts = await postsRes.json();
  return { user, posts };
}

Approach 2: The GraphQL Workflow

In GraphQL, client applications query a single endpoint (/api/v1/graphql) using a declarative query language that requests only the exact fields needed.

Fetching Data in GraphQL:

With GraphQL, the entire nested data graph is retrieved in a single POST request:

query GetUserProfile($userId: ID!) {
  user(id: $userId) {
    name
    email
    company {
      name
    }
    posts {
      id
      title
      comments {
        id
        name
        body
      }
    }
  }
}

The Advantage: Zero over-fetching, single network roundtrip, strictly typed schema.

The Friction: All requests are POST to /graphql, requiring specialized client libraries (Apollo Client, URQL, or custom fetchers) to handle caching and error parsing.

React GraphQL Code Example:

// Fetching with GraphQL
async function loadUserDataGraphQL(userId) {
  const query = `
    query GetUser($id: ID!) {
      user(id: $id) {
        name
        email
        company { name }
        posts {
          id
          title
        }
      }
    }
  `;

  const response = await fetch('https://playground.nileslabs.com/api/v1/graphql', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      query,
      variables: { id: userId }
    })
  });

  const { data, errors } = await response.json();
  if (errors) throw new Error(errors[0].message);
  return data.user;
}

Comparing CRUD Mutations: REST vs. GraphQL

Let's compare creating a new post:

REST Mutation (`POST /api/v1/posts`):

const res = await fetch('https://playground.nileslabs.com/api/v1/posts', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    title: 'New Post via REST',
    body: 'Content...',
    user_id: 1
  })
});
const createdPost = await res.json();

GraphQL Mutation (`mutation CreatePost`):

const mutation = `
  mutation AddPost($title: String!, $body: String!, $user_id: ID!) {
    createPost(title: $title, body: $body, user_id: $user_id) {
      id
      title
      body
      user {
        name
      }
    }
  }
`;

const res = await fetch('https://playground.nileslabs.com/api/v1/graphql', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    query: mutation,
    variables: { title: 'New Post via GraphQL', body: 'Content...', user_id: 1 }
  })
});
const { data } = await res.json();
const createdPost = data.createPost;

Notice the key difference: in GraphQL, you can request nested fields (like user { name }) immediately within the mutation response, eliminating follow-up queries.

When to Choose REST vs. GraphQL

Decision Factor	Choose REST	Choose GraphQL
Project Complexity	Simple to moderate CRUD apps	Complex apps with deeply nested relations
Caching Requirements	Heavy reliance on HTTP/CDN caching	Client-side normalized caching (Apollo / Urql)
Bandwidth Sensitivity	Standard web applications	Mobile apps where every byte counts
Learning Curve	Lowest (Standard browser `fetch`)	Requires understanding schemas & queries
Tooling Overhead	Zero tooling required	Code generation, schema compilation

Testing Both in a Single Sandbox

Finding a sandbox that supports both modern REST filtering and a live GraphQL gateway with mutation persistence is usually difficult.

Playground API by Niles Labs offers dual REST and GraphQL gateways over the exact same underlying dataset:

REST Endpoints: https://playground.nileslabs.com/api/v1/posts
GraphQL Endpoint: https://playground.nileslabs.com/api/v1/graphql
Interactive GraphiQL IDE: Visit https://playground.nileslabs.com/api/v1/graphql in your browser to inspect the full schema, types, and documentation interactively.

Any record created via GraphQL is instantly accessible via REST GET /posts, and vice versa.

Conclusion

Neither REST nor GraphQL is universally "better"—they are tools tailored for different architectural priorities. By testing both approaches against a unified, stateful sandbox, you can make informed decisions based on concrete code and real network performance rather than internet dogma.

Compare REST and GraphQL hands-on with Playground API by Niles Labs.

AI Can Build Your React UI in Seconds. What About the Backend?

Nilesh Kumar — Fri, 16 Oct 2026 03:15:00 +0000

A few weeks ago, I opened Cursor and gave Claude a single prompt:

"Generate a modern task management dashboard with filtering, search, pagination, and a modal form to create tasks."

In under fifteen seconds, it delivered hundreds of lines of polished Tailwind JSX, responsive grid layouts, and lucide-react icons. I clicked preview, and my jaw dropped. It looked like something a high-end design agency would spend weeks polishing.

Then I tried to actually use it.

I filled out the "Create Task" form, clicked submit, and refreshed the browser. Everything vanished. The data immediately reset to the initial dummy state.

The AI had done what AI coding tools always do: it stuffed a hardcoded useState([ ... ]) dummy array right at the top of the component. There were no HTTP calls, no loading skeletons, no real error handling, and zero data persistence.

AI coding assistants are world-class at generating user interfaces in seconds, but you are immediately slammed into that familiar wall: you still need a backend. And spending three days setting up Node.js, Express, Docker, and PostgreSQL just to test an AI prototype completely destroys the speed advantage of using AI in the first place.

That frustration led me to plug my AI-generated prototypes directly into Playground API — giving AI-generated frontends an instant, stateful cloud REST & GraphQL backend with zero setup.

In this post, I'll show you how to take any AI-generated UI and wire it up to a persistent, production-grade sandbox API in under 5 minutes.

The "Static Array" Trap of AI Code Generators

When an AI model generates a React application, it almost always uses one of two patterns:

Pattern A: In-Memory `useState` Constants

// Typical AI-generated component state:
const [tasks, setTasks] = useState([
  { id: 1, title: "'Fix navigation bug', status: 'In Progress' },"
  { id: 2, title: "'Update dependencies', status: 'Done' }"
]);

The Problem: There are no network requests, no HTTP status codes, no latency, no pagination queries, and all state is wiped on browser refresh.

Pattern B: Connecting to Stateless Echo Endpoints

// AI pointing to JSONPlaceholder:
await fetch('https://jsonplaceholder.typicode.com/todos', {
  method: 'POST',
  body: JSON.stringify(newTask)
});

The Problem: The POST request echoes a fake ID, but subsequent GET queries never return the new record. The generated app feels broken.

Bridging the Gap: Giving AI Models an Authentic API Sandbox

To turn an AI-generated UI into a truly functional, clickable prototype, you need to provide the AI with a stateful API contract in your prompt.

Instead of letting the AI invent dummy arrays, instruct it to connect directly to Playground API by Niles Labs.

The Universal AI System Prompt for Stateful Backends

Add this context block to your AI coding prompts in Cursor, Claude, ChatGPT, or v0:

Please build this React application using real HTTP requests against Playground API:
- Base REST URL: https://playground.nileslabs.com/api/v1
- Endpoints available: /posts, /users, /todos, /comments
- Supports CRUD: GET, POST, PUT, PATCH, DELETE
- All POST/DELETE mutations persist across subsequent GET calls in the user's session
- Supports pagination: ?_page=1&_limit=10 (with X-Total-Count response header)
- Supports full-text search: ?q=keyword
- Supports latency simulation: ?_delay=1000 for loading skeletons
- Supports error simulation: ?_status=500 for error boundaries

When given this context, the AI model writes real fetch or TanStack Query hooks that interact with a live, persistent cloud sandbox.

Example: AI-Generated Functional React Todo App

Here is an example of the clean, production-ready code an AI model generates when instructed to use a stateful sandbox:

// src/components/AITodoManager.jsx
import React, { useState, useEffect } from 'react';

const API_BASE = 'https://playground.nileslabs.com/api/v1';

export default function AITodoManager() {
  const [todos, setTodos] = useState([]);
  const [newTitle, setNewTitle] = useState('');
  const [loading, setLoading] = useState(true);
  const [submitting, setSubmitting] = useState(false);

  // 1. Fetch Todos with pagination
  const fetchTodos = async () => {
    setLoading(true);
    try {
      const res = await fetch(`${API_BASE}/todos?_page=1&_limit=6`);
      const data = await res.json();
      setTodos(data);
    } catch (err) {
      console.error('Failed to load todos:', err);
    } finally {
      setLoading(false);
    }
  };

  useEffect(() => {
    fetchTodos();
  }, []);

  // 2. Add Todo (persists in session)
  const handleAddTodo = async (e) => {
    e.preventDefault();
    if (!newTitle.trim()) return;

    setSubmitting(true);
    try {
      const res = await fetch(`${API_BASE}/todos`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          title: newTitle,
          completed: false,
          user_id: 1,
        }),
      });
      const created = await res.json();
      // Prepend or re-fetch: the item is now in the sandbox!
      setTodos(current => [created, ...current]);
      setNewTitle('');
    } catch (err) {
      alert('Error creating todo');
    } finally {
      setSubmitting(false);
    }
  };

  // 3. Toggle Complete
  const toggleTodo = async (id, currentStatus) => {
    try {
      await fetch(`${API_BASE}/todos/${id}`, {
        method: 'PATCH',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ completed: !currentStatus }),
      });
      setTodos(todos.map(t => t.id === id ? { ...t, completed: !currentStatus } : t));
    } catch (err) {
      console.error('Failed to toggle status:', err);
    }
  };

  return (
    <div style={{ maxWidth: '520px', margin: '2rem auto', padding: '1.5rem', border: '1px solid #e2e8f0', borderRadius: '12px', fontFamily: 'sans-serif' }}>
      <h2 style={{ margin: '0 0 1rem 0' }}>🤖 AI-Generated Task Sandbox</h2>

      <form onSubmit={handleAddTodo} style={{ display: 'flex', gap: '8px', marginBottom: '1.5rem' }}>
        <input
          type="text"
          placeholder="What needs to be done?"
          value={newTitle}
          onChange={(e) => setNewTitle(e.target.value)}
          style={{ flex: 1, padding: '10px', borderRadius: '6px', border: '1px solid #cbd5e1' }}
          disabled={submitting}
        />
        <button 
          type="submit" 
          disabled={submitting}
          style={{ padding: '10px 16px', background: '#3b82f6', color: '#fff', border: 'none', borderRadius: '6px', cursor: 'pointer' }}
        >
          {submitting ? 'Adding...' : 'Add'}
        </button>
      </form>

      {loading ? (
        <p style={{ color: '#64748b' }}>Loading persistent tasks...</p>
      ) : (
        <ul style={{ listStyle: 'none', padding: 0, margin: 0 }}>
          {todos.map(todo => (
            <li 
              key={todo.id}
              onClick={() => toggleTodo(todo.id, todo.completed)}
              style={{
                display: 'flex',
                alignItems: 'center',
                padding: '12px',
                borderBottom: '1px solid #f1f5f9',
                cursor: 'pointer',
                textDecoration: todo.completed ? 'line-through' : 'none',
                color: todo.completed ? '#94a3b8' : '#1e293b'
              }}
            >
              <input 
                type="checkbox" 
                checked={Boolean(todo.completed)} 
                readOnly 
                style={{ marginRight: '12px' }}
              />
              <span style={{ flex: 1 }}>{todo.title}</span>
              <span style={{ fontSize: '11px', color: '#94a3b8' }}>#{todo.id}</span>
            </li>
          ))}
        </ul>
      )}
    </div>
  );
}

Why This Matters for AI-Driven Product Development

Instant Stakeholder Demos: AI-generated frontends can be hosted immediately on platforms like Vercel and sent to investors, clients, or product managers as functional, interactive web apps.
True E2E Validation: You can verify whether the AI generated proper error handling, pagination state, and form validation against real HTTP status codes.
Effortless Handoff to Backend Teams: Because the AI structured the frontend around real REST or GraphQL endpoints, your backend team has a ready-made specification to implement.

Conclusion

AI tools have solved the UI generation challenge. The missing link was a zero-configuration, stateful backend layer. By pairing your favorite AI coding assistant with a stateful sandbox, you can generate fully functional, persistent prototypes in seconds.

Give your AI models a stateful backend with Playground API by Niles Labs.

Stop Waiting for the Backend: A Frontend Developer's Guide to API Prototyping

Nilesh Kumar — Thu, 15 Oct 2026 03:15:00 +0000

I spent years stuck in the same frustrating cycle during sprint planning.

Every Monday morning, our product manager would introduce an exciting new feature — say, a customer analytics dashboard with interactive filters, CRUD management, and real-time updates.

The backend engineers would estimate their database migrations and API endpoints at 4–5 days. And as a frontend engineer, I'd get hit with that dreaded phrase:

"You can start building and integrating the UI once our backend endpoints are deployed to staging on Friday."

That meant Monday through Thursday was spent twiddling thumbs or building static mockups, followed by a frantic weekend scramble when the backend was finally delivered (often with slight payload mismatches).

I hated feeling blocked. I wanted to build fully functional, interactive frontend interfaces on Monday morning — with real pagination, stateful CRUD, and error handling — without having to wait on a backend team.

That exact bottleneck inspired me to create Playground API, giving frontend engineers an instant, stateful cloud sandbox so they could prototype against a live API contract from day one.

In this guide, I'll walk you through the Contract-First workflow that completely changed how I build software and eliminated the backend bottleneck forever.

The Waterfall Trap vs. Parallel Track Development

When teams develop sequentially, every delay in the backend blocks the frontend. When teams develop in parallel, both teams agree on a shared API Contract on day one:

gantt
    title Sequential vs Parallel Development
    dateFormat  YYYY-MM-DD
    section Sequential (Waterfall)
    Backend API Development     :a1, 2026-09-01, 5d
    Frontend Blocked Waiting    :crit, a2, 2026-09-01, 5d
    Frontend Rushed Dev         :a3, after a1, 3d
    section Parallel (Contract-First)
    Define API Contract (Day 1) :done, b1, 2026-09-01, 1d
    Backend Development         :b2, after b1, 4d
    Frontend Prototyping Sandbox:active, b3, after b1, 4d
    Seamless Integration & QA   :b4, after b2, 1d

By decoupling the frontend from the physical backend implementation, frontend engineers can:

Validate user experience and design assumptions early.
Build realistic error and loading states.
Share interactive staging demos with product managers and stakeholders days ahead of schedule.

The 4 Steps to Successful Frontend API Prototyping

Step 1: Agree on the API Contract

Before writing code, both teams establish the endpoint paths, HTTP verbs, payload shapes, and status codes. For example:

GET /api/v1/posts?_page=1&_limit=10 → Returns paginated posts.
POST /api/v1/posts → Body: { title: string, body: string, user_id: number }.
DELETE /api/v1/posts/:id → Returns 200 OK.

Step 2: Connect to a Zero-Config Stateful Sandbox

Instead of building a temporary Node.js Express server on your machine that only you can access, use a hosted stateful sandbox like Playground API by Niles Labs.

Playground API provides pre-seeded datasets (users, posts, comments, todos) with full support for:

CRUD mutations that persist per session
Sorting (?_sort=title&_order=asc)
Pagination (?_page=1&_limit=10)
Latency injection (?_delay=1000)
Error simulation (?_status=500)

Step 3: Abstract Your API Layer with an Environment Variable

Always isolate your base API URL in an environment configuration file:

// src/config/api.ts
export const API_BASE_URL = 
  process.env.NEXT_PUBLIC_API_URL || 'https://playground.nileslabs.com/api/v1';

// src/services/postService.ts
import { API_BASE_URL } from '../config/api';

export interface Post {
  id: number;
  title: string;
  body: string;
  user_id: number;
}

export async function getPosts(page = 1, limit = 10): Promise<Post[]> {
  const res = await fetch(`${API_BASE_URL}/posts?_page=${page}&_limit=${limit}`);
  if (!res.ok) throw new Error(`HTTP error ${res.status}`);
  return res.json();
}

export async function createPost(payload: Omit<Post, 'id'>): Promise<Post> {
  const res = await fetch(`${API_BASE_URL}/posts`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(payload),
  });
  if (!res.ok) throw new Error('Failed to create post');
  return res.json();
}

Step 4: The Zero-Friction Switch to Production

When Friday arrives and the backend team deploys their service, you don’t need to rewrite your React components or modify fetch hooks.

You simply update your .env.production file:

# Before (Prototyping Sandbox)
NEXT_PUBLIC_API_URL=https://playground.nileslabs.com/api/v1

# After (Production Backend Ready)
NEXT_PUBLIC_API_URL=https://api.yourcompany.com/v1

Because your frontend was developed and tested against real HTTP requests, headers, and status codes, the switch is seamless.

Concrete Example: Building an Interactive Admin Panel

Here is how straightforward it is to prototype an interactive user list with real-time deletion against a sandbox:

// src/components/AdminUserList.jsx
import React, { useState, useEffect } from 'react';

const API_URL = 'https://playground.nileslabs.com/api/v1';

export default function AdminUserList() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);

  const fetchUsers = async () => {
    setLoading(true);
    const res = await fetch(`${API_URL}/users?_limit=5`);
    const data = await res.json();
    setUsers(data);
    setLoading(false);
  };

  const handleDeleteUser = async (id) => {
    // Delete against sandbox overlay
    await fetch(`${API_URL}/users/${id}`, { method: 'DELETE' });
    // Re-fetch or filter locally: the deleted user is gone from the session!
    setUsers(users.filter(u => u.id !== id));
  };

  useEffect(() => {
    fetchUsers();
  }, []);

  if (loading) return <p>Loading team members...</p>;

  return (
    <div style={{ maxWidth: '600px', margin: '2rem auto', fontFamily: 'sans-serif' }}>
      <h2>👥 Team Members (Prototype)</h2>
      <table style={{ width: '100%', borderCollapse: 'collapse' }}>
        <thead>
          <tr style={{ background: '#f1f5f9', textAlign: 'left' }}>
            <th style={{ padding: '8px' }}>Name</th>
            <th style={{ padding: '8px' }}>Email</th>
            <th style={{ padding: '8px' }}>Action</th>
          </tr>
        </thead>
        <tbody>
          {users.map(user => (
            <tr key={user.id} style={{ borderBottom: '1px solid #e2e8f0' }}>
              <td style={{ padding: '8px' }}>{user.name}</td>
              <td style={{ padding: '8px' }}>{user.email}</td>
              <td style={{ padding: '8px' }}>
                <button 
                  onClick={() => handleDeleteUser(user.id)}
                  style={{ color: '#ef4444', background: 'none', border: 'none', cursor: 'pointer' }}
                >
                  Remove
                </button>
              </td>
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
}

Summary

Waiting for backend APIs creates unnecessary friction and delays project delivery. By establishing early API contracts and developing against a stateful sandbox, frontend engineers gain the autonomy to build polished, fully-tested user interfaces from day one.

Unblock your frontend team today with Playground API by Niles Labs.

Introducing the All-New Playground API: Stateful Mocking, Stripe Parity & 70+ Interactive Guides

Nilesh Kumar — Fri, 02 Oct 2026 13:21:16 +0000

We have all been there. You are building a frontend feature in React, Next.js, Vue, or Flutter. The backend API is not ready yet, or you are running an automated Playwright test in CI.

You plug in a traditional fake API like JSONPlaceholder or DummyJSON. Everything looks fine until you need to test actual CRUD mutations:

// 1. You create a new post
await fetch('https://jsonplaceholder.typicode.com/posts', {
  method: 'POST',
  body: JSON.stringify({ title: 'New Article', body: 'Content', userId: 1 })
});

// 2. You re-fetch your list...
const res = await fetch('https://jsonplaceholder.typicode.com/posts');
const posts = await res.json();
// ❌ Your created post is nowhere to be found!

Static mocks return a fake id: 101, but they do not persist state. When you refresh the page or trigger an optimistic UI update, your data disappears.

Today, we are thrilled to announce a complete, ground-up redesign of Playground API — the free, stateful mock REST & GraphQL sandbox built with per-session virtual mutation overlays.

🌟 What's New in the Reimagined UI?

1. Interactive "Try-It" Live Playground

You no longer have to open Postman or write boilerplate code just to test an endpoint. The new landing page features an embedded, full-featured interactive API playground. Execute queries, mutate resources, and observe real-time persistence with a single click.

# Test it right now in your terminal:
curl -X POST "https://playground.nileslabs.com/api/v1/posts" \
  -H "Content-Type: application/json" \
  -H "X-Playground-Identity: devto-test-session" \
  -d '{"title": "Dev.to Launch Post", "body": "Persists in your sandbox!", "user_id": 1}'

Query with the same X-Playground-Identity header, and your post is right there waiting for you!

2. 70+ Dedicated Guides Across 15 Modular Categories

The documentation has been completely restructured into 15 focused categories with visual sequence diagrams, live execution consoles, and multi-language snippets (Fetch, Axios, cURL, Python, SDK):

Mock Commerce & Billing: Stripe-compatible Payment Intents, 3DS challenge modals, and deterministic test cards (simulate insufficient funds, expired cards, and card declines).
Virtual Communications: In-browser virtual email mailbox and SMS terminal to inspect transactional OTP codes and magic links in real time.
Real-Time WebSockets & SSE: Interactive echo bots, chat broadcasting, and real-time GraphQL subscriptions.
Chaos Engineering & Fault Injection: Dial in network latency from 1ms to 5000ms, simulate rate limits (429 Too Many Requests), or inject random chaos jitter.
JWT Auth & Refresh Loops: Simulated authentication loops with concurrency mutex locks and clock skew drift.

3. Official TypeScript SDK

Install our zero-dependency isomorphic SDK:

npm install playground-api

import { PlaygroundClient } from 'playground-api';

const client = new PlaygroundClient({
  baseUrl: 'https://playground.nileslabs.com/api/v1',
  credentials: 'include' // Automatic session cookie persistence
});

// Full type safety across all resources
const posts = await client.posts.list({ page: 1, limit: 10 });
const newPost = await client.posts.create({ title: 'Built with SDK', body: 'Awesome!', userId: 1 });

4. Machine-Readable by Design (AI & Agent Ready)

Whether you are using Cursor, Windsurf, Copilot, ChatGPT, or Claude to build user interfaces, Playground API provides machine-readable specifications:

https://playground.nileslabs.com/llms.txt (llmstxt.org standard)
https://playground.nileslabs.com/openapi.json (OpenAPI 3.0 inline schema)
https://playground.nileslabs.com/.well-known/ai-plugin.json (Agent discovery manifest)

Check It Out Now!

The new UI is live, open, and requires no registration or API keys:

👉 Explore the new UI: https://playground.nileslabs.com

👉 Browse the Documentation: https://playground.nileslabs.com/docs

👉 GitHub Repo: https://github.com/nileslabs/playground_api

Give it a spin and drop your feedback in the comments below! What features would you like to see next?

How to Test Slow APIs and Network Latency in Frontend Applications

Nilesh Kumar — Thu, 01 Oct 2026 03:15:00 +0000

I once pushed a frontend feature to production that I thought was completely bulletproof.

On my MacBook connected to high-speed fiber Wi-Fi, every API response resolved in under 15 milliseconds. Modals snapped open instantly, animations were silky smooth, and I felt proud of the work.

Then I opened the staging preview link on my phone while riding the train on a spotty 3G connection.

It was an absolute trainwreck:

Skeleton loaders flashed violently for 40 milliseconds, causing jarring layout shifts.
Because I hadn't properly disabled the submit button during in-flight requests, a double-tap created duplicate database records.
Fast typing triggered an asynchronous search race condition, where an earlier query resolved after a later query, painting outdated search results on the screen.
Stale network requests kept running in the background long after I navigated away.

Localhost had completely deceived me.

When I tried to test realistic latency during development, browser DevTools network throttling felt clumsy — it throttled the entire browser tab, slowing down Vite/Webpack hot module reloading and external scripts. I didn't want to choke my whole browser; I just wanted to simulate latency on specific API requests (like adding ?_delay=1500 or an X-Simulate-Delay header).

That exact frustration led me to build on-demand network delay simulation directly into Playground API.

In this article, I want to walk through the real-world techniques I use now to test latency, conquer async race conditions, and build resilient loading states before pushing to production.

Why Latency Breaks Frontend Applications

Real-world API latency is unpredictable. A response can take 200ms, 1500ms, or 8000ms depending on geographic distance, mobile network handoffs, and database load.

When API latency is introduced, frontend applications face three classic bugs:

1. The Autocomplete Race Condition

Consider a search bar. The user types "react", and then quickly types "react native".

Timeline:
t=0ms:  Request A ("react") dispatched  ───────────── (Takes 1800ms) ───────────► Resolves at t=1800ms
t=100ms: Request B ("react native") dispatched ── (Takes 400ms) ──► Resolves at t=500ms

If Request B finishes at 500ms and updates the screen, but Request A finishes at 1800ms and overwrites the screen, the user ends up looking at results for "react" even though the search input says "react native".

2. Layout Shift (Cumulative Layout Shift - CLS)

If data loads without placeholder skeleton loaders that match the exact aspect ratio of the incoming content, the page content jumps when data arrives, causing a jarring user experience.

3. Missing Request Cancellation

If a user switches tabs or navigates away while a 2000ms query is in flight, the unresolved Promise might attempt to update state on an unmounted component or waste unnecessary mobile bandwidth.

Simulating Network Delay on Demand

Instead of relying on browser DevTools global throttling (which slows down all asset downloads, CSS, and images simultaneously), you can throttle specific API requests using latency simulation parameters.

Playground API by Niles Labs allows you to inject millisecond delays into any endpoint:

// Via Query Parameter (e.g. 1500ms delay):
GET https://playground.nileslabs.com/api/v1/posts?_delay=1500

// Via HTTP Header:
X-Simulate-Delay: 2000

This lets you test slow API endpoints in isolation while keeping the rest of your web application running at full speed.

Building a Race-Condition-Proof React Search Component

Let's build a search-as-you-type React component that combines:

Shimmer skeleton loading state
AbortController for active request cancellation
Artificial latency simulation for QA testing

// src/components/SearchAutocomplete.jsx
import React, { useState, useEffect, useRef } from 'react';

export default function SearchAutocomplete() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);
  const [loading, setLoading] = useState(false);
  const [delayMs, setDelayMs] = useState(1200); // Default simulated delay

  // Keep a reference to the active AbortController
  const abortControllerRef = useRef(null);

  useEffect(() => {
    if (!query.trim()) {
      setResults([]);
      setLoading(false);
      return;
    }

    // Cancel any in-flight request before starting a new one
    if (abortControllerRef.current) {
      abortControllerRef.current.abort();
    }

    // Create a new AbortController for this request
    const controller = new AbortController();
    abortControllerRef.current = controller;

    const performSearch = async () => {
      setLoading(true);
      try {
        const url = `https://playground.nileslabs.com/api/v1/posts?q=${encodeURIComponent(query)}&_delay=${delayMs}`;
        const res = await fetch(url, { signal: controller.signal });

        if (!res.ok) throw new Error('Search failed');
        const data = await res.json();
        setResults(data);
      } catch (err) {
        if (err.name === 'AbortError') {
          console.log(`Cancelled stale query for: "${query}"`);
        } else {
          console.error(err);
        }
      } finally {
        // Only turn off loading if this was the latest controller
        if (abortControllerRef.current === controller) {
          setLoading(false);
        }
      }
    };

    // Debounce input by 250ms
    const debounceTimer = setTimeout(performSearch, 250);

    return () => {
      clearTimeout(debounceTimer);
      controller.abort();
    };
  }, [query, delayMs]);

  return (
    <div style={{ maxWidth: '500px', margin: '2rem auto', fontFamily: 'sans-serif' }}>
      <h3>⚡ Latency-Tolerant Search</h3>

      {/* Simulator Latency Control */}
      <div style={{ marginBottom: '1rem', fontSize: '13px', color: '#64748b' }}>
        <label>Simulated Latency: </label>
        <select value={delayMs} onChange={(e) => setDelayMs(Number(e.target.value))}>
          <option value={0}>0ms (Instant Localhost)</option>
          <option value={500}>500ms (Fast 4G)</option>
          <option value={1500}>1500ms (Slow 3G)</option>
          <option value={3000}>3000ms (High Latency Satellite)</option>
        </select>
      </div>

      {/* Search Input */}
      <input
        type="text"
        placeholder="Search posts (e.g. 'qui', 'optio')..."
        value={query}
        onChange={(e) => setQuery(e.target.value)}
        style={{ width: '100%', padding: '10px', boxSizing: 'border-box', borderRadius: '6px', border: '1px solid #cbd5e1' }}
      />

      {/* Skeleton Loading State */}
      {loading && (
        <div style={{ marginTop: '1rem' }}>
          {[1, 2, 3].map((n) => (
            <div 
              key={n} 
              style={{
                height: '40px',
                backgroundColor: '#e2e8f0',
                borderRadius: '4px',
                marginBottom: '8px',
                animation: 'pulse 1.5s infinite ease-in-out'
              }}
            />
          ))}
        </div>
      )}

      {/* Results List */}
      {!loading && (
        <ul style={{ listStyle: 'none', padding: 0, marginTop: '1rem' }}>
          {results.map((post) => (
            <li key={post.id} style={{ padding: '8px', borderBottom: '1px solid #f1f5f9' }}>
              <strong>#{post.id}</strong> {post.title}
            </li>
          ))}
          {query && results.length === 0 && (
            <li style={{ color: '#94a3b8' }}>No matching posts found.</li>
          )}
        </ul>
      )}
    </div>
  );
}

3 Best Practices for Latency-Resilient Web UIs

Always Implement Debouncing and AbortController: Every search bar or live filter should debounce keypresses by 200–300ms and cancel previous unresolved HTTP requests using AbortController.
Prevent Double-Submissions on Slow Mutations: Whenever a user clicks "Submit Form", immediately disable the button and show a spinner. On a 2000ms slow connection, impatient users will repeatedly click buttons if feedback is missing.
Use Skeleton Screens Instead of Plain Spinners: Skeleton screens preserve layout height and prepare the user’s eyes for incoming content, drastically reducing perceived latency.

Conclusion

A performant web application is not just one that runs fast on localhost—it is one that handles slowness gracefully. By actively injecting network latency into your mock APIs, you can expose race conditions, refine skeleton loaders, and build rock-solid loading states before shipping to users.

To simulate network latency in your own development workflows, try Playground API by Niles Labs.

How to Test API Error States in React Without a Real Backend

Nilesh Kumar — Wed, 23 Sep 2026 03:15:00 +0000

A painful lesson I learned the hard way early in my developer career: frontend code that only tests the "Happy Path" is code waiting to blow up in production.

I had just shipped a sleek React dashboard for a client. In my local environment, everything looked flawless: fast 200 OK responses, perfectly formatted JSON payloads, and smooth animations.

Within 48 hours of launch, the support emails started pouring in. An external microservice timed out, returning a 500 Internal Server Error, and my application crashed into a completely blank white screen. A user had an expired session, and my UI got locked in an infinite loading spinner instead of redirecting to login.

I wanted to kick myself. But when I sat down to actually test these failure states during development, I hit another wall: how are you supposed to test error handling with mock APIs?

Dummy APIs only ever return 200 OK. To simulate a 500 server crash, a 401 unauthorized, or a 400 validation error, I had to either go into my Express controllers and manually write throw new Error(), hack mock interceptors, or literally yank my Ethernet cable.

I thought: Why can't I just send a header like X-Simulate-Status: 500 or append ?_status=401 to any mock endpoint and test my React Error Boundaries instantly?

That frustration drove me to bake on-demand error simulation directly into Playground API.

In this guide, I'll share the exact patterns and techniques I use today to bulletproof React applications against 400, 401, 404, and 500 error states before they ever touch production.

The Common HTTP Error Codes Every React App Must Handle

Before diving into code, let's categorize the common HTTP status codes frontend applications encounter:

Status Code	Meaning	Expected Frontend Behavior
`400 Bad Request`	Malformed input / validation failure	Display field-level inline error messages.
`401 Unauthorized`	Missing or invalid auth token	Redirect to Login modal or trigger silent token refresh.
`403 Forbidden`	Insufficient permissions / RBAC	Show "Access Denied / Upgrade Plan" screen.
`404 Not Found`	Resource does not exist	Render a friendly "Item Not Found" card with a back button.
`429 Too Many Requests`	Rate limit exceeded	Display countdown timer based on `Retry-After` header.
`500 Internal Server Error`	Unhandled server crash	Render an Error Boundary fallback with a "Retry" button.

How to Simulate API Errors on Demand

Instead of editing server routes to throw fake errors or hardcoding if (debug) throw new Error() inside React components, you can use on-demand error simulation headers and query parameters.

Playground API by Niles Labs supports built-in error simulation using either query parameters or HTTP headers on any endpoint:

// Via Query Parameter:
GET https://playground.nileslabs.com/api/v1/posts?_status=500
GET https://playground.nileslabs.com/api/v1/users/1?_status=404

// Via HTTP Header:
X-Simulate-Status: 403
X-Simulate-Status: 429

When this parameter or header is sent, the server immediately halts standard execution and responds with the requested HTTP status code and a structured RFC 7807 error payload.

Building a Robust React Error Boundary & Retry Component

Let’s build an interactive user profile card in React that gracefully handles 404 Not Found, 500 Server Error, and network failures with a manual recovery and retry flow.

1. The Data Fetcher with Error Parsing (`userService.js`)

// src/services/userService.js
const BASE_URL = 'https://playground.nileslabs.com/api/v1';

export async function fetchUserProfile(userId, forcedStatus = null) {
  // If forcedStatus is provided, append ?_status=XXX for testing
  const url = forcedStatus 
    ? `${BASE_URL}/users/${userId}?_status=${forcedStatus}` 
    : `${BASE_URL}/users/${userId}`;

  const response = await fetch(url);

  if (!response.ok) {
    let errorDetails = 'Unknown error occurred.';
    try {
      const errorJson = await response.json();
      errorDetails = errorJson.message || errorJson.error || response.statusText;
    } catch {
      errorDetails = response.statusText;
    }

    const error = new Error(`Request failed with status ${response.status}`);
    error.status = response.status;
    error.details = errorDetails;
    throw error;
  }

  return response.json();
}

2. The React Component with Status-Specific UI States

// src/components/UserProfileCard.jsx

import React, { useState, useEffect, useRef } from 'react';
import { fetchUserProfile } from '../services/userService';

export default function UserProfileCard({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);
  const [simulatedStatus, setSimulatedStatus] = useState('');

  // Used to prevent stale API responses from updating the UI
  const requestIdRef = useRef(0);

  const loadUser = async (status = simulatedStatus) => {
    const requestId = ++requestIdRef.current;

    try {
      setLoading(true);
      setError(null);

      const data = await fetchUserProfile(
        userId,
        status || null
      );

      // Ignore this response if a newer request has started
      if (requestId !== requestIdRef.current) {
        return;
      }

      setUser(data);
    } catch (err) {
      // Ignore stale errors from older requests
      if (requestId !== requestIdRef.current) {
        return;
      }

      setError({
        status: err.status,
        message: err.details || err.message,
      });

      setUser(null);
    } finally {
      // Only the latest request controls the loading state
      if (requestId === requestIdRef.current) {
        setLoading(false);
      }
    }
  };

  useEffect(() => {
    loadUser();
  }, [userId, simulatedStatus]);

  return (
    <div
      style={{
        maxWidth: '480px',
        margin: '2rem auto',
        border: '1px solid #cbd5e1',
        borderRadius: '8px',
        padding: '1.5rem',
        fontFamily: 'sans-serif',
      }}
    >
      <h3>👤 User Profile Inspector</h3>

      {/* Simulator Toolbar for QA / Testing */}
      <div
        style={{
          background: '#f8fafc',
          padding: '10px',
          borderRadius: '6px',
          marginBottom: '1rem',
        }}
      >
        <label
          style={{
            fontSize: '13px',
            fontWeight: 'bold',
          }}
        >
          Simulate API Status:
        </label>

        <select
          value={simulatedStatus}
          onChange={(e) => setSimulatedStatus(e.target.value)}
          style={{
            marginLeft: '8px',
            padding: '4px 8px',
          }}
        >
          <option value="">Normal (200 OK)</option>
          <option value="400">400 Bad Request</option>
          <option value="401">401 Unauthorized</option>
          <option value="403">403 Forbidden</option>
          <option value="404">404 Not Found</option>
          <option value="500">500 Internal Server Error</option>
        </select>
      </div>

      {/* Loading State */}
      {loading && (
        <div style={{ color: '#64748b' }}>
          ⏳ Fetching user profile...
        </div>
      )}

      {/* Error State Handler */}
      {!loading && error && (
        <div
          style={{
            backgroundColor:
              error.status === 404 ? '#fffbeb' : '#fef2f2',
            border:
              error.status === 404
                ? '1px solid #fde68a'
                : '1px solid #fecaca',
            borderRadius: '6px',
            padding: '1rem',
            color:
              error.status === 404 ? '#92400e' : '#991b1b',
          }}
        >
          <h4>
            {error.status === 404
              ? '🔍 User Not Found (404)'
              : error.status === 401
              ? '🔒 Session Expired (401)'
              : error.status === 403
              ? '🚫 Access Denied (403)'
              : `⚠️ Server Error (${error.status})`}
          </h4>

          <p
            style={{
              margin: '8px 0',
              fontSize: '14px',
            }}
          >
            {error.message}
          </p>

          <button
            onClick={() => {
              // Explicitly request the normal API response.
              // This avoids relying on the old React state value.
              setSimulatedStatus('');
              loadUser('');
            }}
            style={{
              padding: '6px 12px',
              background: '#0f172a',
              color: '#fff',
              border: 'none',
              borderRadius: '4px',
              cursor: 'pointer',
            }}
          >
            🔄 Reset & Retry
          </button>
        </div>
      )}

      {/* Success State */}
      {!loading && !error && user && (
        <div>
          <h4>
            {user.name} (@{user.username})
          </h4>

          <p>📧 {user.email}</p>
          <p>🏢 {user.company?.name}</p>
        </div>
      )}
    </div>
  );
}

Testing the Reset & Retry Flow

Error handling shouldn't stop at displaying an error. The recovery path needs to be tested too.

For example, when the user receives a simulated 500 error:

Select 500 Internal Server Error.
Confirm that the error UI appears.
Click Reset & Retry.
Verify that the simulator returns to Normal (200 OK).
Confirm that the user profile is displayed again.
Make sure an older failed request cannot overwrite the successful response.

This last case is particularly important when multiple requests can be in flight at the same time. A stale response should never be allowed to overwrite the result of a newer request.

The requestIdRef in the example above provides a simple way to ignore responses from older requests.

3 Golden Rules for Frontend API Error Handling

Never Show Raw JSON Exceptions to End Users: Always parse backend error payloads into human-readable action steps (e.g. "We couldn't find that article. Check the link or return home.").
Always Provide a Recovery Action: Every error state should have a "Retry", "Refresh", or "Back to Safety" CTA button. Never leave a user stuck on a dead-end screen.
Log Unhandled Errors to Monitoring (Sentry / LogRocket): If an error is unexpected (such as a 500 error), catch it in a top-level React <ErrorBoundary> component and dispatch the telemetry before rendering a fallback card.

Conclusion

Testing error states is just as important as testing happy paths. By leveraging simulated HTTP error statuses in your sandbox API, you can stress-test edge cases, error boundaries, and user feedback mechanisms before your code ever touches production.

To test error states and simulate HTTP failures in your application, start with Playground API by Niles Labs.

What If Your Mock API Actually Remembered Your POST Requests?

Nilesh Kumar — Thu, 17 Sep 2026 17:14:15 +0000

A while ago, I was deep into building a new frontend project.

I had spent hours polishing the interface — the form validation was tight, the loading states looked smooth, and I was finally ready to test the full CRUD (Create, Read, Update, Delete) workflow.

The backend wasn't ready yet, so like any developer, I reached for a popular free dummy API to wire up my requests.

I filled out the creation form, clicked "Submit", and opened Chrome DevTools to see what happened.

The Network tab lit up green: POST /posts → 201 Created with { id: 101, title: "My New Post" }.

I felt that quick spike of dopamine. It worked!

...Or so I thought.

I navigated back to the dashboard to watch the new item render in the list. Nothing was there.

I refreshed the page. Still nothing.

I manually fired a GET /posts/101 — and got hit with a 404 Not Found.

Then I tested the delete button: DELETE /posts/1 returned 200 OK, but the second I reloaded the browser, that exact same post was right back in my table, completely untouched.

The Moment I Realized How Broken This Was

I sat back in my chair, staring at the screen, genuinely annoyed.

Here we are in modern web development with sophisticated frontend frameworks, reactivity, and query caching — yet every public mock API we use still behaves like a dumb echo chamber from 2012. They take your JSON payload, slap a fake id: 101 on it, pretend everything went great, and instantly discard your data into a black hole.

To test a simple button in my UI, I was suddenly stuck with two bad options:

Stop frontend work and spend 3–4 hours building a throwaway backend: Spin up Node.js, Express, SQLite, Docker, and write migrations just to test a prototype.
Litter my codebase with fake client-side hacks: Write temporary useState overrides or mock localStorage adapters that don't test real HTTP headers, status codes, or network behavior — code I'd later have to untangle and rip out.

I had run into this exact wall on almost every side project, client MVP, and tutorial I'd ever worked on.

And that night, I couldn't stop asking myself:

"Why hasn't anyone built a mock API that actually remembers what you send it? Why can't each developer get an isolated, zero-config sandbox in the cloud that persists POST, PATCH, and DELETE requests across their session?"

I waited for a tool like that to exist. When I couldn't find one, I decided to build it myself: Playground API.

The idea was simple: build a stateful REST and GraphQL sandbox that acts like a real production backend. When you create an item, it stays created. When you update a field, it stays updated. When you delete a record, it's gone — all isolated to your browser session with zero credentials, zero databases, and zero config.

Here is why that changes everything for frontend prototyping.

The Illusion of Memory in Frontend Prototyping

When testing frontend applications, there are three common workarounds developers use to fake backend memory:

Local Component State (useState / Pinia / Vuex): You store mock data in client-side arrays. Every time you refresh the page or open a new browser tab, all your modifications reset to initial mock constants.
localStorage / IndexedDB Mocks: You write custom adapter wrappers that save items to localStorage. While this persists across reloads, it does not test actual HTTP serialization, headers, HTTP status codes, or asynchronous server latency.
Disposible Local Servers (json-server / Express): You run a local server file on your machine. This works, but it cannot be easily shared with team members, designers, or QA testers reviewing your pull request deployment on Vercel or Netlify.

None of these approaches deliver the experience frontend engineers actually want: a live, hosted cloud API that remembers mutations per session without requiring local database setup.

What "Stateful API Mocking" Looks Like in Action

A stateful mock API bridges the gap between static dummy JSON and full production backends. It functions by creating an isolated sandbox for your browser session.

Here is the exact lifecycle:

sequenceDiagram
    autonumber
    actor Dev as Frontend Client
    participant API as Playground API Sandbox

    Dev->>API: 1. POST /posts { title: "New Feature Launch" }
    API-->>Dev: 201 Created { id: 101, title: "New Feature Launch" }

    Note over API: Stored in caller's Virtual Session Overlay

    Dev->>API: 2. GET /posts/101
    API-->>Dev: 200 OK { id: 101, title: "New Feature Launch" }

    Dev->>API: 3. PATCH /posts/101 { title: "Updated Title" }
    API-->>Dev: 200 OK { id: 101, title: "Updated Title" }

    Dev->>API: 4. DELETE /posts/101
    API-->>Dev: 200 OK { message: "Resource deleted" }

    Dev->>API: 5. GET /posts/101
    API-->>Dev: 404 Not Found

Every standard HTTP verb functions exactly as it would on a production server:

POST → GET: Newly created records immediately appear in collection lists and single-resource queries.
PATCH / PUT → GET: Updated fields reflect on subsequent queries.
DELETE → GET: Deleted items return 404 Not Found and are excluded from pagination counts.

Step-by-Step Code Walkthrough

Let's test this directly against Playground API by Niles Labs. You can run this directly in your browser console or Node.js environment:

const BASE = 'https://playground.nileslabs.com/api/v1';

async function runStatefulDemo() {
  // Step 1: Create a Todo item
  console.log('--- 1. Creating a Todo ---');
  const createRes = await fetch(`${BASE}/todos`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      title: 'Review PR #204',
      completed: false,
      user_id: 1,
    }),
  });
  const createdTodo = await createRes.json();
  console.log('Created:', createdTodo);

  // Step 2: Retrieve the newly created Todo by ID
  console.log('\n--- 2. Fetching Created Todo by ID ---');
  const getRes = await fetch(`${BASE}/todos/${createdTodo.id}`);
  const fetchedTodo = await getRes.json();
  console.log('Fetched:', fetchedTodo);

  // Step 3: Toggle the completion state via PATCH
  console.log('\n--- 3. Updating Todo via PATCH ---');
  const patchRes = await fetch(`${BASE}/todos/${createdTodo.id}`, {
    method: 'PATCH',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ completed: true }),
  });
  const updatedTodo = await patchRes.json();
  console.log('Updated Status:', updatedTodo.completed); // true

  // Step 4: Delete the Todo
  console.log('\n--- 4. Deleting the Todo ---');
  const deleteRes = await fetch(`${BASE}/todos/${createdTodo.id}`, {
    method: 'DELETE',
  });
  console.log('Delete status:', deleteRes.status); // 200

  // Step 5: Verify it is gone
  console.log('\n--- 5. Verifying Deletion ---');
  const verifyRes = await fetch(`${BASE}/todos/${createdTodo.id}`);
  console.log('Status on deleted item:', verifyRes.status); // 404 Not Found
}

runStatefulDemo();

Multi-Tab & Multi-Client Session Isolation

A common question is: If multiple developers or automated test suites use the API simultaneously, will their POST requests overwrite each other?

No. Stateful sandbox engines use session isolation:

In Browser: An HTTP-only session cookie automatically identifies each browser sandbox.
In CI/CD & Automated Tests (Playwright / Cypress): You can pass a custom header X-Playground-Identity: test-runner-suite-1 to maintain an isolated sandbox across parallel test runners.
Resetting State: Whenever you want a clean slate, a simple DELETE /session/reset request flushes your session overlay and restores the default seed dataset.

Why This Changes Frontend Development

When your mock API behaves like a real backend:

Interactive Client Demos Work: You can send a live preview link (e.g. on Vercel) to stakeholders or clients, and they can click around, create posts, toggle todos, and delete items without finding broken empty states.
Realistic Query Invalidation: Tools like React Query, SWR, and Redux Toolkit Query behave naturally when invalidating query caches.
No Database Maintenance: You spend zero minutes configuring Docker, spinning up Postgres instances, or writing migration scripts for throwaway prototypes.

Conclusion

Mock APIs should do more than echo your requests. By remembering mutations across the entire HTTP lifecycle, stateful sandboxes make frontend prototyping feel authentic and production-ready from the very first commit.

To experiment with persistent mutations in your next application, start testing with Playground API by Niles Labs.

DEV Community: Nilesh Kumar

How to Test Cursor-Based Pagination & Infinite Scroll in React Without a Backend

1. The Cursor Endpoint Contract

JSON Response:

2. Integrating with TanStack React Query (useInfiniteQuery)

3. Interactive Pagination Studio

Conclusion

How to Test Multipart File Uploads & Cloud Storage CDN in React Without an S3 Bucket

1. Uploading a Single File with FormData

JSON Response:

2. Simulating Upload Latency & Progress Bars

3. Bulk Uploads & Multi-File Validation

4. Live Interactive Upload Studio

Conclusion

Learn how to test native WebSockets, Socket.io, room messaging, typing indicators, and SSE streams in frontend apps without running local WS servers.

1. Comparing Real-Time Transport Protocols

Protocol Comparison Matrix

2. Connecting to the Live Real-Time Gateway

The Standard Message Schema

3. Building a Real-Time React Chat Component

4. Testing the Built-in Support Bot Simulator

5. Summary & Key Takeaways

Zero-Config GraphQL Prototyping: Nested Queries, Relations & State Mutations

The Power of Nested Relational Resolvers

Exploring the Live GraphQL Gateway & GraphiQL IDE

Executing GraphQL Queries in React with Zero Dependencies

Executing Stateful GraphQL Mutations

The GraphQL Mutation:

Complete React Implementation:

3 Core Tips for GraphQL Frontend Prototyping

Conclusion

How to Test JWT Authentication and Silent Token Refresh in React Without a Backend

The Standard JWT Authentication Architecture

The Sandbox Authentication Endpoints

Implementing the Silent Refresh Interceptor with Axios

1. The Authenticated HTTP Client (httpClient.js)

2. The React AuthContext Provider (AuthContext.jsx)

3. Protected Route Wrapper (ProtectedRoute.jsx)

3 Best Practices for Frontend JWT Security

Conclusion

Compare building a modern React CRUD application with REST versus GraphQL. Understand query shapes, state mutations, and implementation patterns

The Scenario: A User Profile with Posts and Comments

Approach 1: The REST Workflow

Fetching Data in REST:

React REST Code Example:

Approach 2: The GraphQL Workflow

Fetching Data in GraphQL:

React GraphQL Code Example:

Comparing CRUD Mutations: REST vs. GraphQL

REST Mutation (POST /api/v1/posts):

GraphQL Mutation (mutation CreatePost):

When to Choose REST vs. GraphQL

Testing Both in a Single Sandbox

Conclusion

AI Can Build Your React UI in Seconds. What About the Backend?

The "Static Array" Trap of AI Code Generators

Pattern A: In-Memory useState Constants

Pattern B: Connecting to Stateless Echo Endpoints

Bridging the Gap: Giving AI Models an Authentic API Sandbox

The Universal AI System Prompt for Stateful Backends

Example: AI-Generated Functional React Todo App

Why This Matters for AI-Driven Product Development

Conclusion

Stop Waiting for the Backend: A Frontend Developer's Guide to API Prototyping

The Waterfall Trap vs. Parallel Track Development

The 4 Steps to Successful Frontend API Prototyping

Step 1: Agree on the API Contract

Step 2: Connect to a Zero-Config Stateful Sandbox

Step 3: Abstract Your API Layer with an Environment Variable

Step 4: The Zero-Friction Switch to Production

Concrete Example: Building an Interactive Admin Panel

Summary

Introducing the All-New Playground API: Stateful Mocking, Stripe Parity & 70+ Interactive Guides

🌟 What's New in the Reimagined UI?

1. Interactive "Try-It" Live Playground

2. 70+ Dedicated Guides Across 15 Modular Categories

3. Official TypeScript SDK

4. Machine-Readable by Design (AI & Agent Ready)

Check It Out Now!

How to Test Slow APIs and Network Latency in Frontend Applications

2. Integrating with TanStack React Query (`useInfiniteQuery`)

1. Uploading a Single File with `FormData`

1. The Authenticated HTTP Client (`httpClient.js`)

2. The React `AuthContext` Provider (`AuthContext.jsx`)

3. Protected Route Wrapper (`ProtectedRoute.jsx`)

REST Mutation (`POST /api/v1/posts`):

GraphQL Mutation (`mutation CreatePost`):

Pattern A: In-Memory `useState` Constants

1. The Data Fetcher with Error Parsing (`userService.js`)