https://github.com/iiivanpopov/beger
Beger Application Monorepo
https://github.com/iiivanpopov/beger
bun docker docker-compose hono postgresql react typescript
Last synced: 2 months ago
JSON representation
Beger Application Monorepo
- Host: GitHub
- URL: https://github.com/iiivanpopov/beger
- Owner: iiivanpopov
- Created: 2025-09-19T14:16:58.000Z (9 months ago)
- Default Branch: main
- Last Pushed: 2025-11-16T15:23:21.000Z (7 months ago)
- Last Synced: 2025-11-16T17:23:28.264Z (7 months ago)
- Topics: bun, docker, docker-compose, hono, postgresql, react, typescript
- Language: TypeScript
- Homepage:
- Size: 1.51 MB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Beger
## PREVIEW
[Youtube](https://youtu.be/rrAxZSjM4gM)
`Beger` - внутрішня система для обліку тестування друкованих плат і їх ремонту.
Проєкт оцифровує звичний робочий процес: внесення результатів тестування, фіксацію ремонтів та керування користувачами в одному місці.
## Призначення
Система потрібна для того, щоб не вести записи вручну в різних джерелах, а зберігати їх у спільній структурованій базі з розмежуванням доступу.
## Ключові можливості
- вхід до системи за обліковим записом;
- розмежування ролей `admin` і `user`;
- внесення результатів тестування плат;
- внесення записів про ремонт плат;
- перегляд останніх власних записів;
- керування працівниками для адміністратора;
- використання Google Sheets для зручного редагування варіантів плат;
- локалізація інтерфейсу: `uk`, `en`, `ru`.
## Ключові моменти в роботі системи
- результати тестування та ремонти ведуться окремо, бо це різні робочі сценарії;
- звичайний робочий працює лише зі своїми записами;
- адміністратор бачить загальні списки та керує користувачами;
- у формах використовуються довідники назв плат і дефектів;
- для щоденної роботи користувачеві показуються його останні 10 записів за останню добу, а для адміністратора є окремі загальні списки з посторінковим переглядом.
## Стек проєкту
### Клієнтська частина
- React 19
- TypeScript
- Vite
- TanStack Router
- TanStack Query
- React Hook Form
- Valibot
- React Intl
- Ky
- CSS Modules
### Серверна частина
- Bun
- Hono
- Drizzle ORM
- Valibot
### Інфраструктура
- PostgreSQL 18
- Redis 8
- Nginx
- Docker Compose
## Проблемні місця і прийняті рішення
1. Єдиний набір типів між клієнтською і серверною частинами. Проблема: у таких проєктах легко отримати розбіжності між типами даних на клієнті та на сервері. Рішення: типи й схеми експортуються з серверної частини через `apps/backend/public`, а пакет `apps/shared` використовує їх і в клієнтській частині.
2. Робота з таблицями через Google Sheets без зашивання значень у код. Проблема: назви плат і дефекти змінюються, а тримати їх у коді незручно. Рішення: сервер отримує CSV з Google Sheets, перетворює його на довідники й віддає клієнтові готові значення для автодоповнення.
3. Кешування довідників у Redis. Проблема: звернення до Google Sheets при кожному запиті було б повільним і залежним від зовнішнього сервісу. Рішення: довідники кешуються на сервері, тому інтерфейс отримує їх швидко, а навантаження на зовнішнє джерело зменшується.
4. Безпечне видалення записів. Проблема: звичайний користувач не повинен видаляти чужі записи або довільно змінювати історію. Рішення: для ролі `user` застосовано окремі безпечні сценарії видалення лише власних записів за останню добу, тоді як `admin` має повний доступ.
5. Автоматизація початкового запуску. Проблема: після розгортання потрібно не забути застосувати міграції та створити адміністратора. Рішення: у робочому середовищі сервер під час запуску виконує міграції та додає адміністратора, якщо його ще немає.
## Структура репозиторію
```text
apps/
backend/ API, авторизація, бізнес-логіка, схема бази даних, міграції
frontend/ інтерфейс, сторінки, форми, маршрутизація
shared/ спільні типи й контракти між частинами системи
assets/ зображення для документації
```
## Які дані зберігає система
### Результати тестування
- `pcbName` - назва плати
- `date` - дата запису
- `firstTry` - кількість плат, що пройшли з першого разу
- `failed` - кількість браку
- `total` - загальна кількість
### Ремонти
- `pcbName` - назва плати
- `defect` - дефект
- `note` - примітка
- `date` - дата запису
## Запуск
### 1. Створити `.env`
```bash
cp .env.example .env
```
Потрібно заповнити щонайменше такі змінні:
- `PORT`
- `JWT_ACCESS_SECRET`
- `JWT_REFRESH_SECRET`
- `ADMIN_PASSWORD`
- `DB_USER`
- `DB_PASSWORD`
- `SHEET_URL`
### 2. Запустити контейнери
```bash
docker compose up --build -d
```
Після запуску будуть доступні:
- веб-інтерфейс: `http://localhost`
- API: `http://localhost:/api`
Типове значення `PORT` у прикладі - `5333`.
Якщо змінюєте `PORT`, потрібно також оновити `apps/frontend/nginx.conf`, бо Nginx переспрямовує запити до API саме на цей порт.