DEV Community: Adrij Samanta

TanStack Query, Zustand, Firebase, Redis and NeonDB: The Data Architecture Behind IdeaPilot

Adrij Samanta — Sun, 25 Oct 2026 08:22:00 +0000

Lessons from building a React Native application for AI-powered project discovery, creation, and chat.

Building IdeaPilot taught me that choosing libraries is only part of designing an application. The more important decision is defining which layer owns each piece of data, how it changes, and where it should persist.

IdeaPilot uses React Native and Expo on the client, an Express backend for chat and resource APIs, Firebase for authentication and project-related data, and NeonDB for conversational history and semantic retrieval. TanStack Query and Zustand handle different aspects of client state, while Redis caches frequently accessed chat context.

Here is how these decisions fit together.

1. The architecture at a glance

Technology	Responsibility	Why it fits
TanStack Query	API data, caching, pagination, mutations	Manages the lifecycle of remote data
Zustand	Shared UI state, drafts, selected locally persisted data	Keeps client-owned state accessible across screens
Firebase Auth	User authentication	Provides identity tokens for authenticated backend requests
Cloud Firestore	Recommended ideas, saved ideas, AI-generated ideas, custom projects	Supports document-oriented, user-scoped application data
NeonDB + PostgreSQL + pgvector	Chat history, messages, embeddings	Combines relational storage with vector similarity search
Redis	Temporary chat and project context	Avoids repeated database lookups for active conversational context

These tools are not interchangeable. Each addresses a different requirement.

2. TanStack Query: Managing remote API data

Chat history, paginated messages, and project resources come from the Express API. I use TanStack Query to manage their loading states, cache lifetimes, pagination, and mutations.

For example, chat history uses a dedicated query:

export function useChatHistory(enabled: boolean) {
  return useQuery<Chat[]>({
    queryKey: ["chats"],
    queryFn: async () => {
      const { data } = await apiClient.get("/chats");
      return data;
    },
    staleTime: 1000 * 60 * 5,
    gcTime: 1000 * 60 * 30,
    enabled,
  });
}

Two settings serve different purposes:

staleTime determines how long fetched data is considered fresh. After five minutes, the data is stale, but that alone does not trigger a refetch.
gcTime determines how long an inactive query remains in the cache before garbage collection.

The cache is in memory by default; these settings do not persist it across application restarts.

For chat messages, useInfiniteQuery loads pages using a cursor returned by the API:

return useInfiniteQuery<MessagePage>({
  queryKey: ["messages", chatId],
  queryFn: async ({ pageParam = null }) => {
    const { data } = await apiClient.get(
      `/chats/${chatId}/messages`,
      { params: { cursor: pageParam } },
    );
    return data;
  },
  initialPageParam: null,
  getNextPageParam: (lastPage) => lastPage.nextCursor,
  staleTime: 1000 * 60 * 5,
  gcTime: 1000 * 60 * 15,
  retry: 3,
  enabled: chatId !== "new",
});

This avoids fetching the entire conversation at once. The UI requests another page when the user scrolls towards older messages.

TanStack Query also handles optimistic updates for chat operations such as renaming, pinning, and deleting. The general sequence is to cancel conflicting refetches, snapshot the existing cache, update it immediately, restore the snapshot on failure, and invalidate the query when the mutation settles.

onMutate: async ({ chatId, title }) => {
  await queryClient.cancelQueries({
    queryKey: ["chats"],
  });

  const previousChats =
    queryClient.getQueryData<Chat[]>(["chats"]);

  queryClient.setQueryData<Chat[]>(["chats"], (old) =>
    old?.map((chat) =>
      chat.id === chatId ? { ...chat, title } : chat
    ) ?? []
  );

  return { previousChats };
},

onError: (_error, _variables, context) => {
  if (context?.previousChats) {
    queryClient.setQueryData(
      ["chats"],
      context.previousChats
    );
  }
},

onSettled: () => {
  queryClient.invalidateQueries({
    queryKey: ["chats"],
  });
},

The benefit is a responsive UI without treating the optimistic result as permanent truth. The server remains authoritative, and invalidation reconciles the cache with the server response.

3. Zustand: Managing client-owned state

Not every state change needs an API request. Form drafts, selected dashboard tabs, and other shared client state have different lifecycles from remote API data.

For example, creating a project involves multiple form steps. Zustand keeps the draft available as the user moves between them:

const useCreateProjectStore = create<CreateProject>(
  (set) => ({
    project: INITIAL_PROJECT,

    update: (values) =>
      set((state) => ({
        project: {
          ...state.project,
          ...values,
        },
      })),

    reset: () => set({ project: INITIAL_PROJECT }),
  })
);

The store allows each step to update part of the draft without passing the entire form through multiple component layers. The draft can be reset after the workflow is complete or abandoned.

For selected data that should survive application restarts, Zustand's persistence middleware can use React Native's AsyncStorage:

persist(
  (set, get) => ({
    // State and actions
  }),
  {
    name: "workspace-storage",
    storage: createJSONStorage(() => AsyncStorage),
    partialize: (state) => ({
      projects: state.projects,
    }),
  }
);

The important detail is partialize: it controls which parts of the store are persisted. Transient values such as loading indicators do not need to be written to storage.

Persistence is not synchronization, however. A stored value can become outdated, and the application still needs a strategy for refreshing data and isolating state when users sign out or switch accounts.

4. Firebase: Authentication and project-related data

Firebase serves two distinct roles in IdeaPilot.

Firebase Authentication establishes user identity. Before making a backend request, the API client obtains the current user's ID token and attaches it to the request:

apiClient.interceptors.request.use(
  async (config) => {
    const token = auth.currentUser
      ? await auth.currentUser.getIdToken()
      : null;

    if (token) {
      config.headers.Authorization = `Bearer ${token}`;
    }

    return config;
  }
);

The Express backend verifies that token through Firebase Admin before allowing protected routes to proceed. This separates identity verification from individual controller logic.

Cloud Firestore stores idea and project documents. The application uses it for recommended ideas, user-generated AI ideas, saved ideas, and custom projects. User-specific records are organized under the corresponding user's document hierarchy.

Bookmarking illustrates how these layers work together. The Zustand store updates the interface immediately, while a service handles persistence:

const savedIdeaRef = doc(
  db,
  "users",
  userId,
  "savedIdeas",
  ideaId
);

if (isBookmarked) {
  await setDoc(savedIdeaRef, ideaData, { merge: true });
} else {
  await deleteDoc(savedIdeaRef);
}

The store catches a failed operation and restores its previous bookmark state. The service owns the Firestore operations; the store owns the client-facing state transition.

This separation makes each part easier to reason about. It also makes clear that a local optimistic update is not confirmation that a remote write succeeded.

5. NeonDB: Durable chat history and semantic retrieval

Chat has different data requirements from project documents. It needs ordered messages, durable conversation history, and a way to retrieve relevant context from earlier interactions.

For this, IdeaPilot uses NeonDB, a serverless PostgreSQL database, with Drizzle ORM and the pgvector extension.

The database schema stores chats and messages separately. Messages reference their chat, include a role and content, and can store a vector embedding:

export const messages = pgTable(
  "messages",
  {
    id: varchar("id", { length: 26 }).primaryKey(),
    chatId: varchar("chat_id", { length: 255 })
      .notNull()
      .references(() => chats.id, { onDelete: "cascade" }),
    senderId: varchar("sender_id", { length: 255 })
      .notNull(),
    role: roleEnum("role").notNull(),
    content: text("message_content").notNull(),
    embedding: vector("embedding", { dimensions: 768 }),
    createdAt: timestamp("created_at").defaultNow().notNull(),
  },
  (table) => [
    index("embeddingIndex").using(
      "hnsw",
      table.embedding.op("vector_cosine_ops"),
    ),
  ]
);

The HNSW index supports efficient approximate nearest-neighbour search using cosine distance. The embedding represents the semantic content of a message, allowing retrieval based on meaning rather than only exact keyword matches.

When a user sends a prompt, the backend generates an embedding and retrieves two kinds of context in parallel: the three most semantically similar messages and the four most recent messages.

const [semanticContext, recentMessages] = await Promise.all([
  db
    .select({ content: messages.content })
    .from(messages)
    .where(eq(messages.chatId, chatId))
    .orderBy(cosineDistance(messages.embedding, userEmbedding))
    .limit(3),

  db
    .select({
      role: messages.role,
      content: messages.content,
    })
    .from(messages)
    .where(eq(messages.chatId, chatId))
    .orderBy(desc(messages.id))
    .limit(4),
]);

return { semanticContext, recentMessages };

These retrieval strategies solve different problems. Recent messages preserve conversational continuity, while semantic retrieval can bring back relevant information from earlier in a longer conversation. Both are passed into the AI response-generation workflow.

After generating the response, the backend saves the user and assistant messages, including their embeddings, in a database transaction. This keeps the conversation's durable records together.

6. Redis: Caching active conversational context

NeonDB is the durable store, but not every request needs to repeat the same database lookup.

IdeaPilot uses Redis to cache lightweight chat context, including the current project ID and the latest preview message ID. The cache service follows a cache-aside pattern:

Look for the context in Redis.
If it is missing, retrieve it from PostgreSQL.
Populate Redis with an expiration time.
Update the database and refresh the cached value when the context changes.

The implementation uses a one-hour TTL for ordinary chat context and a 24-hour TTL when project context is present. Chat deletion also invalidates its cached context.

Redis is not the source of truth for the conversation. It is a performance layer in front of durable state, with a database fallback when the cache misses.

7. The separation-of-concerns principle

The most useful lesson from this architecture is that state ownership should follow data responsibility.

TanStack Query manages API request lifecycles, cache freshness, pagination, and server-backed mutations.
Zustand manages shared client state, drafts, and selected persisted data.
Service functions encapsulate operations such as reading and writing Firestore documents.
Firebase Auth establishes identity; the backend verifies the identity token.
NeonDB stores durable chat records and embeddings.
Redis temporarily caches frequently accessed conversational context.

These boundaries should remain explicit. If the same remote data is independently maintained in TanStack Query and Zustand, the application needs extra synchronization logic and risks inconsistent views. In IdeaPilot, Zustand also holds locally managed idea and bookmark collections, so those collections need deliberate refresh and rollback behavior rather than being treated as automatically synchronized server caches.

The same principle applies to persistence: storing a value locally does not make it authoritative, and caching a value does not make it durable.

Conclusion

IdeaPilot uses multiple data technologies because its data has different requirements—not simply to increase the number of tools in the stack.

TanStack Query provides a lifecycle for remote API data. Zustand keeps shared client state manageable. Firebase supports authentication and document-based project workflows, while NeonDB and pgvector support durable conversations and semantic retrieval. Redis reduces repeated lookups for active context.

The engineering decision is not just which library should I use? It is who owns this data, how does it change, and what guarantees does each layer provide?

That question leads to clearer boundaries, fewer synchronization problems, and a system that is easier to understand and evolve.

Explore the project: IdeaPilot GitHub repository

Managing Server State in React Native with TanStack Query: Optimistic Updates and Cache Invalidation

Adrij Samanta — Tue, 20 Oct 2026 08:56:03 +0000

Fetching data from an API is straightforward. Keeping it consistent across screens, handling failed requests, and avoiding unnecessary network calls is where things get more challenging.

Consider renaming a chat. Should the UI wait for the backend to respond before displaying the new title? What happens if the request fails? How do we keep the cached data synchronized with the server?

While building IdeaPilot, an AI-powered project ideation app built with React Native and Expo, I used TanStack Query to handle these problems. This article explores how I implemented query caching, infinite pagination, optimistic updates, and cache invalidation.

1. Why TanStack Query?

Not all application state is the same.

Server state comes from an external source, such as chat history fetched from an API.
Client state belongs to the application interface, such as whether a drawer is open.

Server state requires additional handling because it can become stale, requests can fail, and multiple components may need the same data.

TanStack Query provides a structured way to fetch, cache, update, and invalidate server data without manually managing every request.

2. Fetching and caching chat data

In IdeaPilot, I created reusable hooks for fetching chat history and messages.

Fetching chat history

export function useChatHistory(enabled: boolean) {
  return useQuery<Chat[]>({
    queryKey: ["chats"],
    queryFn: async () => {
      const { data } = await apiClient.get("/chats");
      return data;
    },
    staleTime: 1000 * 60 * 5,
    gcTime: 1000 * 60 * 30,
    enabled,
  });
}

Three options are particularly important:

queryKey identifies the cached data. Components using the same key can share the query's cached result.
staleTime determines how long data is considered fresh. Here, it is five minutes.
gcTime determines how long inactive query data is retained before garbage collection. Here, it is 30 minutes.

Freshness and cache retention are different. Data can become stale while still remaining in the cache.

Paginating chat messages

Long conversations should not require fetching every message at once. IdeaPilot uses useInfiniteQuery to retrieve messages in pages.

export function useChatMessages(chatId: string) {
  return useInfiniteQuery<MessagePage>({
    queryKey: ["messages", chatId],
    queryFn: async ({ pageParam = null }) => {
      const { data } = await apiClient.get(
        `/chats/${chatId}/messages`,
        { params: { cursor: pageParam } }
      );
      return data;
    },
    initialPageParam: null,
    getNextPageParam: (lastPage) =>
      lastPage.nextCursor,
    staleTime: 1000 * 60 * 5,
    gcTime: 1000 * 60 * 15,
    retry: 3,
    enabled: chatId !== "new",
  });
}

The chat ID is part of the query key, so each conversation has its own cache entry. The backend returns a nextCursor, which TanStack Query uses to fetch the next page.

The UI combines the pages for rendering:

const messages = useMemo(
  () =>
    chatMessages?.pages.flatMap(
      (page) => page.messages
    ) || [],
  [chatMessages?.pages]
);

This keeps pagination logic in the data-fetching layer while allowing the UI to work with a single message list.

3. Optimistic updates

An optimistic update changes the UI before the server confirms that an operation succeeded.

For example, when a user renames a chat, waiting for the API response before updating the title can make the interface feel slow. An optimistic update displays the new title immediately and restores the previous value if the request fails.

In IdeaPilot, the rename mutation follows four steps:

Cancel relevant queries.
Save the previous cache state.
Update the cache immediately.
Roll back on failure and invalidate the query when the mutation settles.

Step 1: Send the API request

mutationFn: async ({
  chatId,
  title,
}: {
  chatId: string;
  title: string;
}) => {
  const { data } = await apiClient.patch(
    `/chats/${chatId}/rename`,
    { title }
  );
  return data;
}

This performs the actual server operation. The optimistic behavior is handled separately through mutation callbacks.

Step 2: Cancel queries and save a snapshot

onMutate: async ({ chatId, title }) => {
  await queryClient.cancelQueries({
    queryKey: ["chats"],
  });

  const previousChats =
    queryClient.getQueryData<Chat[]>(["chats"]);

  // Apply the optimistic update.
}

Cancelling in-flight queries helps prevent an outdated refetch from overwriting the optimistic change.

The snapshot gives us a copy of the previous cache state that can be restored if the request fails.

Step 3: Update the cache

queryClient.setQueryData<Chat[]>(
  ["chats"],
  (old) => {
    if (!old) return [];

    return old.map((chat) =>
      chat.id === chatId
        ? { ...chat, title }
        : chat
    );
  }
);

The matching chat is updated immutably, and components observing the query can display the new title immediately.

The important distinction is that this changes the client-side cache, not the database. The server request must still succeed for the change to be persisted.

Step 4: Roll back on failure

onError: (_error, _vars, context) => {
  if (context?.previousChats) {
    queryClient.setQueryData(
      ["chats"],
      context.previousChats
    );
  }
}

If the request fails, the previous chat list is restored. This prevents the UI from showing an unsaved change as though it were successful.

Snapshot-based rollback is simple and effective for straightforward interactions, but overlapping mutations can complicate it. Restoring an older snapshot may accidentally undo a more recent change.

4. Cache invalidation

After the mutation settles, IdeaPilot invalidates the chat-history query:

onSettled: () => {
  queryClient.invalidateQueries({
    queryKey: ["chats"],
  });
}

Invalidation marks the matching cached data as stale. Active queries are normally refetched, allowing the cache to reconcile with the server.

This matters even after a successful optimistic update because the server may return normalized data or apply rules the client does not know about.

Optimistic updates improve responsiveness; invalidation helps restore consistency.

IdeaPilot applies the same pattern to pinning and deleting chats. When a chat is deleted successfully, its associated message query is also removed from the cache:

onSuccess: (_data, chatId) => {
  queryClient.removeQueries({
    queryKey: ["messages", chatId],
  });
}

This prevents the deleted conversation's messages from remaining in the query cache unnecessarily.

5. Optimistic updates for AI chat messages

Optimistic updates are also useful outside the useMutation lifecycle.

When a user sends a prompt in IdeaPilot, the application immediately inserts the user's message and an empty assistant placeholder into the message cache:

queryClient.setQueryData(
  ["messages", currentChatId],
  (oldData) => {
    // Preserve existing pages and parameters.
    // Insert the user message and assistant placeholder.
    // Return the updated infinite-query data.
  }
);

After the API request completes, the placeholder is replaced with the assistant's response. If the request fails, an error message is displayed instead.

This is a manual cache update that makes the chat interface feel responsive while the AI request is in progress.

One technical distinction: although the endpoint is named /stream, the current implementation waits for the completed response and then updates the placeholder. It does not render tokens incrementally as they arrive.

6. What works well and what deserves attention

This approach provides several benefits:

Shared cache: Multiple components can use the same server data.
Responsive interactions: Optimistic updates avoid waiting for the server before updating the UI.
Failure recovery: Snapshots allow the application to roll back unsuccessful mutations.
Controlled data fetching: Pagination avoids loading an entire conversation at once.

There are also important considerations when applying this pattern in larger applications.

Cache isolation: IdeaPilot currently uses ["chats"] for chat history and ["messages", chatId] for messages. Including the authenticated user's ID in relevant query keys and clearing or resetting cached data on account changes can help prevent stale data from appearing across sessions.

Concurrent mutations: Whole-cache rollback can conflict with overlapping operations. Applications with more concurrent updates may need narrower rollback logic or mutation serialization.

Testing: Both success and failure paths matter. Useful cases include failed renames, failed deletions, overlapping refetches, and account switching.

Retry behavior: Retrying requests that create messages requires care. Without appropriate idempotency handling, a retry could duplicate work.

These considerations help distinguish a responsive implementation from one that also handles more complex failure scenarios reliably.

Conclusion

Building IdeaPilot helped me understand that server-state management involves much more than fetching data.

TanStack Query provides a consistent approach to caching chat history, paginating messages, applying optimistic updates, recovering from failures, and reconciling cached data with the server.

The key takeaway is simple: use optimistic updates for responsiveness, rollback for failure recovery, and invalidation for reconciliation. Together, these techniques make API-driven React Native interfaces easier to manage without requiring every component to implement its own data-fetching logic.

Explore the implementation in the IdeaPilot GitHub repository.

This article describes the current implementation and discusses potential areas for refinement separately.