File Persistence with JSON

File Persistence with JSON: Making Tasks Survive Server Restarts

Welcome back! You’ve built a clean backend foundation: Routes call services Services call repositories Your validation + response formatting is consistent The last missing piece (before we shift hard into frontend work) is persistence—because right now, restarting the server wipes everything. In this lesson, you’ll replace “memory-only” storage with a simple but realistic persistence layer: a JSON file on disk. You’ll implement a fileTaskRepository that reads/writes data/tasks.json, wire the service layer to use it, and seed the JSON file with nicer sample tasks so your API (and soon your UI) has meaningful data to work with.

Previously…

In the previous lesson, you introduced the Repository Pattern and implemented mapTaskRepository using a Map . That gave you: clean separation swap-ability Now we’ll take advantage of that design: introduce a new repository implementation (fileTaskRepository) switch the service layer to use it without changing route code or API contracts

How we’ll use Codex CLI in this lesson

This is the final backend-focused lesson, so the goal is to make a small number of high-impact changes with tight prompts: Implement the file repository in one file Switch taskService.ts to use it Seed data/tasks.json with better sample tasks A good prompt format: Codex, modify only the files I list: src/lib/repositories/fileTaskRepository.ts src/lib/services/taskService.ts data/tasks.json Implement file persistence using JSON exactly as described, and keep all exports and signatures unchanged. Show full updated contents for each modified file.

Persisting tasks with a file-backed repository

The core of persistence is simple: read the JSON file into memory make a change write it back In this project, the file-backed repository is implemented in src/lib/repositories/fileTaskRepository.ts .

Reading and writing the JSON file

This repository uses Node’s fs/promises for async file operations and path to create a stable file path to data/tasks.json. TypeScript// src/lib/repositories/fileTaskRepository.ts import fs from 'fs/promises'; import path from 'path'; import type { Task } from '@/lib/tasks'; import type { TaskRepository } from './taskRepository'; const FILE_PATH = path.join(process.cwd(), 'data/tasks.json'); let nextId = 1; async function read(): Promise<Task[]> { try { const raw = await fs.readFile(FILE_PATH, 'utf8'); const tasks = JSON.parse(raw); nextId = tasks.length > 0 ? Math.max(...tasks.map(t => t.id)) + 1 : 1; return tasks; } catch (e) { return []; } } async function write(tasks: Task[]): Promise<void> { await fs.writeFile(FILE_PATH, JSON.stringify(tasks, null, 2)); } FILE_PATH uses process.cwd() to anchor the path at your project root, then points to data/tasks.json. This is a simple, container-friendly way to ensure the file location is predictable. read() is defensive: if the file is missing, invalid, or unreadable, it returns [] instead of crashing your API That keeps your backend stable even if the data file gets wiped or corrupted during development. nextId is recalculated after reading tasks by finding the maximum existing id. This prevents ID collisions across restarts, which is the main thing that “breaks” when you move from memory to persistence.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Implementing the repository methods

Now the repository exposes the same interface as your in-memory repository, but every operation reads from and writes to disk.

TypeScript

// src/lib/repositories/fileTaskRepository.ts
export const fileTaskRepository: TaskRepository = {
  async getAll() {
    return await read();
  },

  async getById(id) {
    const tasks = await read();
    return tasks.find(t => t.id === id) ?? null;
  },

  async create(data) {
    const tasks = await read();
    const task = { id: nextId++, ...data };
    tasks.push(task);
    await write(tasks);
    return task;
  },

  async update(id, updates) {
    const tasks = await read();
    const index = tasks.findIndex(t => t.id === id);
    if (index === -1) return null;
    const updated = { ...tasks[index], ...updates };
    tasks[index] = updated;
    await write(tasks);
    return updated;
  },

  async delete(id) {
    const tasks = await read();
    const filtered = tasks.filter(t => t.id !== id);
    if (filtered.length === tasks.length) return false;
    await write(filtered);
    return true;
  },

  async filterByCompletion(completed) {
    const tasks = await read();
    return tasks.filter(t => t.completed === completed);
  },
};

// src/lib/repositories/fileTaskRepository.ts
export const fileTaskRepository: TaskRepository = {
  async getAll() {
    return await read();
  },

  async getById(id) {
    const tasks = await read();
    return tasks.find(t => t.id === id) ?? null;
  },

  async create(data) {
    const tasks = await read();
    const task = { id: nextId++, ...data };
    tasks.push(task);
    await write(tasks);
    return task;
  },

  async update(id, updates) {
    const tasks = await read();
    const index = tasks.findIndex(t => t.id === id);
    if (index === -1) return null;
    const updated = { ...tasks[index], ...updates };
    tasks[index] = updated;
    await write(tasks);
    return updated;
  },

  async delete(id) {
    const tasks = await read();
    const filtered = tasks.filter(t => t.id !== id);
    if (filtered.length === tasks.length) return false;
    await write(filtered);
    return true;
  },

  async filterByCompletion(completed) {
    const tasks = await read();
    return tasks.filter(t => t.completed === completed);
  },
};

Every method starts from the same place: await read() so you’re always working with the latest persisted state. That’s the key difference from an in-memory store, where state “lives” in variables.

create() assigns a unique ID using nextId++, pushes to the array, then writes the full array back to disk. It’s not the most scalable approach, but it’s perfect for learning and for small demos.
update() and delete() return null / false when a task isn’t found, rather than throwing. That’s important because your API routes can translate those results into proper HTTP status codes (like 404) consistently.

Switching the service layer to file persistence

Because you already adopted the repository pattern, swapping storage is deliberately boring:

change the repository import + assignment
leave the service API intact

That wiring is in src/lib/services/taskService.ts.

TypeScript

// src/lib/services/taskService.ts
import type { Task } from '@/lib/tasks';
import { fileTaskRepository } from '@/lib/repositories/fileTaskRepository';
// Before: import { mapTaskRepository } from './mapTaskRepository'

const repo = fileTaskRepository;

export const getAllTasks = async () => repo.getAll();
export const createTask = async (data: Omit<Task, 'id'>) => repo.create(data);
export const getTaskById = async (id: number) => repo.getById(id);
export const updateTask = async (id: number, updates: Partial<Task>) => repo.update(id, updates);
export const deleteTask = async (id: number) => repo.delete(id);
export const filterTasksByStatus = async (completed: boolean) => repo.filterByCompletion(completed);

// src/lib/services/taskService.ts
import type { Task } from '@/lib/tasks';
import { fileTaskRepository } from '@/lib/repositories/fileTaskRepository';
// Before: import { mapTaskRepository } from './mapTaskRepository'

const repo = fileTaskRepository;

export const getAllTasks = async () => repo.getAll();
export const createTask = async (data: Omit<Task, 'id'>) => repo.create(data);
export const getTaskById = async (id: number) => repo.getById(id);
export const updateTask = async (id: number, updates: Partial<Task>) => repo.update(id, updates);
export const deleteTask = async (id: number) => repo.delete(id);
export const filterTasksByStatus = async (completed: boolean) => repo.filterByCompletion(completed);

The exported service functions keep the same names and signatures, so your API routes don’t need to change at all. This is the practical payoff of separating “business operations” from “storage mechanics.”

The only real change is const repo = fileTaskRepository;. That single line is the “switch” that moves you from ephemeral memory to persistence.

Keeping everything async ensures that callers already handle the correct shape of “real world” operations, even if the current implementation is just a JSON file.