Développeur
Technical reference
Local installation, Prisma commands, schema migrations, and security for TradeJourney.
TradeJourney relies on PostgreSQL for data storage and Docker for production deployment. This guide covers local development and production deployment.
Prerequisites
- Docker and Docker Compose installed
- Node.js ≥ 20 and pnpm
.envfile configured
Local development
1. Start PostgreSQL
docker compose -f ./docker-compose.dev.yml up -d
2. Configure environment variables
cp .env.example .env
Or via the provided script:
Linux/mac
./env-create.sh
Windows
./env-create.ps1
3. Generate Prisma clients
rm -rf generated
pnpm prisma generate --schema=prisma/auth/schema.prisma
pnpm prisma generate --schema=prisma/data/schema.prisma
4. Initialize the database
./scripts/reinit.sh
This command deletes existing data. Only use during the first installation or if you want to start from scratch.
5. Start the application
npm run dev
The application is accessible at http://localhost:3000.
Default credentials: admin@mail.fr / admin
Stop the database
docker compose -f docker-compose.dev.yml down
Useful commands
Prisma
# Open Prisma Studio
pnpm prisma studio --schema=prisma/auth/schema.prisma
Tests
# Run all tests
pnpm test
# Run a specific file
pnpm test tests/mt5-parser.test.ts
Docker
# View logs
docker compose logs -f [service]
# Restart a service
docker compose restart [service]
# Clean unused volumes
docker volume prune
Security
In production
- Change
POSTGRES_PASSWORDto a strong password. - Change
JWT_SECRETto a long random key. - Do not expose the PostgreSQL port (5432) publicly.
- Use HTTPS with a reverse proxy (Nginx, Caddy, Traefik).
- Limit PostgreSQL connections by IP if possible.
In development
- Never commit the
.envfile. - Use different passwords between dev and prod.
- Do not use the same JWT key across environments.
Schema migrations
TradeJourney uses an incremental migration system for the multi-tenant database (user data). This allows adding or modifying columns without losing existing data.
Create a migration
- Back up the current schema
cp prisma/data/schema.prisma prisma/data/schema.prev.prisma.bak
- Edit the schema in
prisma/data/schema.prisma, then regenerate:
pnpm prisma generate --schema=prisma/data/schema.prisma
- Generate the SQL script
pnpm prisma migrate diff \
--from-schema-datamodel prisma/data/schema.prev.prisma.bak \
--to-schema-datamodel prisma/data/schema.prisma \
--script | sed 's/"public"\."/"SCHEMA_PLACEHOLDER"."/g' \
> scripts/migrations/XXX-description.sql
- Record the migration in
scripts/migrations/migrations.json
scripts/migrations/migrations.json
{
"migrations": [
{
"version": 2,
"name": "XXX-description",
"description": "Migration description",
"file": "XXX-description.sql",
"date": "YYYY-MM-DD"
}
]
}
Migrations are applied automatically at each user connection. Just restart the server for them to be taken into account.
Always test a migration on a development database before applying it in production, and make a backup beforehand.