Что такое CRUD

CRUD это короткое название для четырех действий с данными:

• Create: создать новую сущность.
• Read: прочитать одну сущность или список.
• Update: изменить существующую сущность.
• Delete: удалить сущность.

На интервью не останавливайтесь только на расшифровке. Сразу добавьте практический контекст. Почти любой экран с данными использует CRUD. Форма создания профиля, таблица пользователей, редактирование задачи, удаление комментария, сохранение черновика в IndexedDB. Все это варианты одной идеи.

В REST API CRUD часто объясняют через HTTP-методы:

POST   /tasks        # Create, создать задачу
GET    /tasks        # Read, получить список
GET    /tasks/42     # Read, получить одну задачу
PATCH  /tasks/42     # Update, изменить часть задачи
DELETE /tasks/42     # Delete, удалить задачу

Это хорошая базовая схема для ответа. Но важно сказать, что реальный проект живет по контракту API. Иногда создание выглядит не как простой POST /items, а как команда вроде POST /orders/42/cancel. Иногда сервер использует GraphQL mutation, RPC-метод или WebSocket-событие. Смысл CRUD остается, меняется транспорт и форма контракта.

Для Frontend Developer сильный ответ начинается там, где вы связываете CRUD с состоянием интерфейса. Недостаточно сказать "я вызову API". Пользователь видит не API, а экран. Кнопка должна блокироваться во время отправки, список должен обновиться, ошибка должна быть понятной и доступной, а удаление не должно превращаться в потерю данных.

Плохой пример. Так делать не стоит:

async function deleteTask(id: string) {
  setTasks((items) => items.filter((task) => task.id !== id));
  await api.deleteTask(id);
}

Проблема в том, что элемент пропадает до подтверждения сервера. Если запрос упадет, UI уже показывает неверное состояние. Если пользователь быстро удалит несколько задач, простой откат всего списка может вернуть не те элементы и перетереть более свежие изменения. Самый безопасный вариант для критичного Delete: менять список только после успешного ответа. Если нужен optimistic UI, добавьте точечный rollback.

async function deleteTask(task: Task) {
  setPendingDeleteIds((ids) => new Set(ids).add(task.id));

  try {
    await api.deleteTask(task.id);
    setTasks((items) => items.filter((item) => item.id !== task.id));
  } catch (error) {
    showError("Не удалось удалить задачу. Попробуйте еще раз.");
    focusTask(task.id);
  } finally {
    setPendingDeleteIds((ids) => {
      const nextIds = new Set(ids);
      nextIds.delete(task.id);
      return nextIds;
    });
  }
}

В кнопке удаления при этом стоит использовать pending-состояние. Отключите повторный клик, покажите загрузку и свяжите текст ошибки с местом, куда вернется фокус. Такой пример показывает практическое понимание. CRUD-операция заканчивается не в момент клика, а когда интерфейс и источник данных снова согласованы.

Самая частая ловушка в CRUD-вопросе это Update. Вы говорите, что Update это PUT или PATCH, но не объясняете разницу. Лучше ответить так: PUT часто используют для полной замены ресурса, а PATCH для частичного изменения. Но финальное правило задает API-контракт.

Почему это важно для фронтенда. Если форма редактирует только email, а вы отправите неполный объект через endpoint, который заменяет ресурс целиком, сервер может стереть имя, телефон или настройки пользователя. Это уже не теоретическая ошибка, а потеря данных.

На практике перед Update проверьте три вещи: какие поля нужно отправить, что сервер вернет в ответе и как обновить локальный кэш. Если есть версия записи, etag или поле updatedAt, учитывайте конфликт изменений, чтобы не перезаписать чужую правку старой копией.

CRUD можно реализовать и без сервера. Например, для списка задач в состоянии React, localStorage или IndexedDB. Это нормально для учебного проекта, демо, черновиков или офлайн-режима.

Но в ответе стоит назвать ограничение. localStorage не делает данные надежными и общими для всех устройств. Пользователь может очистить хранилище, открыть приложение в другом браузере или получить конфликт при синхронизации. Поэтому локальный CRUD не заменяет сервер, если данные важны и должны быть доступны нескольким пользователям.

Этот порядок помогает звучать практично на интервью. Вы показываете, что видите не только названия операций, но и жизненный цикл действия. Пользователь начал операцию, интерфейс отреагировал, запрос ушел, старые запросы не перезаписали новые данные, сервер ответил, состояние синхронизировалось, ошибка обработалась.

Если нужно дать короткий ответ, можно сказать так:

CRUD это Create, Read, Update и Delete, четыре базовые операции над данными. Во фронтенде они обычно проявляются как создание через форму, чтение списков и карточек, редактирование и удаление. В REST API это часто POST, GET, PUT или PATCH и DELETE, но я всегда смотрю контракт и обрабатываю состояния загрузки, ошибки, права и синхронизацию UI с сервером.