Какие технологии используются в качестве альтернативы REST API?

А, ну так, значит, REST — это наш всеми любимый, проверенный временем дедок, на котором пол-интернета стоит. Но, блядь, как и любой дедок, он иногда тупит, тормозит и не всегда понимает, чего от него хотят. Особенно когда запросы становятся сложнее, чем «дай-ка мне список пользователей, васян».

Так вот, оказывается, есть другие ребята, которые в определённых ситуациях могут этого дедка в тапки загнать. И сейчас мы посмотрим, кто они такие и когда их звать на помощь.

1. GraphQL, или «Да не всё подряд тащи, ёпта!»

Представь: ты просишь у REST-сервиса данные о пользователе. А он тебе, такой добрый, вываливает всё: имя, почту, дату рождения, список друзей, историю покупок, размер обуви его собаки и последние пятнадцать постов в блоге. А тебе-то нужно только имя и аватарку! Это и есть over-fetching, или, по-нашему, тащить овердохуища лишнего.

GraphQL — это такой хитрожопый протокол, который говорит: «А ну-ка, клиент, сам сформулируй, что тебе надо, одним запросом». И сервер выдаст ровно это, без лишней хуйни.

• Суть в чём: Гибкость — пиздец. Меньше трафика, меньше нагрузка.

• Вот, смотри, как он просит:

  # Эй, сервак, дай-ка мне только имя и мыло юзера с айдишником "1".
  # Остальное нахуй не надо, я экономный.
  query GetUserById {
    user(id: "1") {
      name
      email
    }
  }

2. gRPC, или «Быстро, тихо, по-шпионски»

Если REST — это как отправлять друг другу открытки с текстом (JSON), то gRPC — это как общаться зашифрованными радиосигналами между подлодками. Создали его в Google, и он использует бинарный формат (Protocol Buffers) и быстрый протокол HTTP/2.

• Суть в чём: Скорость — просто ёперный театр. Идеален, когда у тебя куча микросервисов болтают между собой внутри одной системы, и им надо делать это часто и без потерь.

• Как это выглядит (объявление контракта):

  syntax = "proto3";
  
  // Объявляем сервис, как будто это интерфейс
  service UserService {
    // РПЦшка: "ПолучитьЮзера". Принимает один запрос, возвращает один ответ.
    rpc GetUser (UserRequest) returns (UserResponse);
  }
  
  // Сообщение-запрос. Типа "дай мне юзера с таким айди".
  message UserRequest {
    string id = 1; // Поле номер один
  }
  
  // Сообщение-ответ. Типа "держи, только имя и почту".
  message UserResponse {
    string name = 1;
    string email = 2;
  }

3. WebSockets, или «Давай поболтаем, не отходя от кассы»

REST — это как звонок в кол-центр: позвонил, спросил, получил ответ, положил трубку. Хочешь спросить ещё что-то — звони заново, блядь.

WebSockets — это когда ты пробиваешь прямой туннель к серверу и висишь на нём, как пиявка. Соединение постоянно открыто, и можно слать сообщения туда-сюда мгновенно, без этих церемоний «запрос-ответ».

• Суть в чём: Реальное время, низкие задержки. Для чатов, уведомлений, онлайн-игр — ни хуя себе удобно.

• Как это накидать на FastAPI:

  from fastapi import FastAPI, WebSocket
  
  app = FastAPI()
  
  @app.websocket("/ws") # Эндпоинт для твоего туннеля
  async def websocket_endpoint(websocket: WebSocket):
      await websocket.accept() # Принимаем соединение
      while True: # И висим в вечном цикле, слушаем
          data = await websocket.receive_text() # Получили что-то
          # И сразу же можем ответить
          await websocket.send_text(f"Сообщение получено: {data}")

Короче, когда что брать, чтобы не облажаться:

• GraphQL: Когда делаешь публичное API, к которому будут цепляться разные клиенты (мобила, веб, умный холодильник), и у всех них запросы, блядь, разные. Чтобы не плодить кучу REST-эндпоинтов под каждый чих.
• gRPC: Когда внутри твоей системы микросервисы друг другу ебашат запросы как сумасшедшие, и тебе критична скорость и эффективность. Для внутренней кухни — самое то.
• WebSockets: Когда нужно, чтобы данные летали туда-сюда без остановки в реальном времени. Чат, онлайн-трейдинг, multiplayer-игра — везде, где каждая миллисекунда на счету.

Выбирай с умом, а то потом будешь как Герасим — молча страдать, что накосячил с архитектурой.