- UID
- 65
- Активность
- Офлайн
- Регистрация
- 5 Июн 2026
- Сообщения
- 3
- Реакции
- 4
- Баллы
- 3
Автор темы
- Автор темы
- #1
Всем привет. После новости о закрытии мультиплеера рейдж решил плавно перебраться со своими наработками в новый МП. По итогу прошло уже около двух недель и, в принципе, решил поделиться с вами. В данном случае здесь нет чего-то "ошеломляющего" или "интересных" систем, здесь лишь система логина, выбора персонажа (из 3-х созданных), создание внешности (не полная, в случае этого мода дизайн лица и выбор ДНК родителей; по желанию остальное можете допилить сами). Так же есть переделанный загрузочный экран и небольшие, простенькие дизайны на Vue - ничего сверхъестественного.
Стэк игрового мода:
Бэк: Node.js
Фронт: Vue.js
Стэк API:
Бэк: Node.js
API эндпоинты:
POST /api/auth/login # Вход в аккаунт
GET /api/accounts/count # Кол-во аккаунтов
GET /api/characters/:accountId # Список персонажей
POST /api/characters/:accountId # Создание персонажа (В коде не используется, но для будущего если вам надо - пожалуйста, пользуйтесь)
PUT /api/characters/appearance/:charId # Обновление внешности
PUT /api/characters/state/:charId # Обновление состояния
GET /api/character/:characterId # Получение персонажа
Почему именно API, а не "прямые", но экранированные запросы к БД? Ответа не последует, потому что решил для себя попробовать что-то новое и, вроде как, получилось вполне удачно. По времени запросов (если сервер и API стоят на одной машине) ничего не увеличивается, всё отрабатывает довольно шустро.
Теперь о плюсах использования API:
1. REST API с защитой через Bearer Token;
2. Лимитер запросов (макс. 10 запросов в 15 минут);
3. Безопасные HTTP заголовки через Helmet;
4. Полнотекстовое управление БД через Prisma;
5. Retry логика при сбоях в БД (POST, GET, PUT, etc.)
Примерная логика работы:
Прикладываю свои репозитории:
github.com
github.com
Если есть вопросы - задавайте, постараюсь на все ответить.
Стэк игрового мода:
Бэк: Node.js
Фронт: Vue.js
Стэк API:
Бэк: Node.js
API эндпоинты:
POST /api/auth/login # Вход в аккаунт
GET /api/accounts/count # Кол-во аккаунтов
GET /api/characters/:accountId # Список персонажей
POST /api/characters/:accountId # Создание персонажа (В коде не используется, но для будущего если вам надо - пожалуйста, пользуйтесь)
PUT /api/characters/appearance/:charId # Обновление внешности
PUT /api/characters/state/:charId # Обновление состояния
GET /api/character/:characterId # Получение персонажа
Почему именно API, а не "прямые", но экранированные запросы к БД? Ответа не последует, потому что решил для себя попробовать что-то новое и, вроде как, получилось вполне удачно. По времени запросов (если сервер и API стоят на одной машине) ничего не увеличивается, всё отрабатывает довольно шустро.
Теперь о плюсах использования API:
1. REST API с защитой через Bearer Token;
2. Лимитер запросов (макс. 10 запросов в 15 минут);
3. Безопасные HTTP заголовки через Helmet;
4. Полнотекстовое управление БД через Prisma;
5. Retry логика при сбоях в БД (POST, GET, PUT, etc.)
Примерная логика работы:
Код:
1. КЛИЕНТ (FiveM)
↓ (HTTP запрос с токеном)
2. BACKEND SERVER (identity-fivem-basic)
↓ (REST вызов)
3. API MICROSERVICE (identity-fivem-api)
↓ (SQL запрос)
4. БАЗА ДАННЫХ (PostgreSQL)
↓ (Кэш при необходимости)
5. REDIS (Быстрый кэш)
↓ (JSON ответ)
6. API (преобразование)
↓ (JSON ответ)
7. BACKEND (обработка)
↓ (Отправка клиенту)
8. UI (Vue 3 + Pinia)
↓ (Обновление состояния)
9. БРАУЗЕР/КЛИЕНТ
Прикладываю свои репозитории:
GitHub - 19teen-dev/identity-fivem-api: API для соединения Prisma с серверной частью (в частности с PostgreSQL)
API для соединения Prisma с серверной частью (в частности с PostgreSQL) - 19teen-dev/identity-fivem-api
GitHub - 19teen-dev/identity-fivem-basic: Базовый Roleplay мод с включенными ресурсами (PostgreSQL, Prisma и Redis)
Базовый Roleplay мод с включенными ресурсами (PostgreSQL, Prisma и Redis) - 19teen-dev/identity-fivem-basic
Если есть вопросы - задавайте, постараюсь на все ответить.