Tutoriel pour développer une application en Scala

Tu veux passer à la vitesse supérieure avec Scala et construire une app concrète qui parle au monde du jeu vidéo (API de leaderboard, matchmaking, anti-cheat…)? On te prend par la main pour poser une base solide, coder propre et livrer un truc qui tourne.

Pourquoi Scala pour un projet orienté gaming (ou outils pour jeux) ?

Scala mixe programmation fonctionnelle et orientée objet sur la JVM. Résultat: un code expressif, testable et performant, parfait pour des services de jeu (scores, inventaires, chat, matchmaking) où la concurrence et la scalabilité comptent.

✅/❌ Scala pour ton app gaming

• ✅ Expressivité et immutabilité ⇒ moins de bugs sournois en prod
• ✅ Ecosystème JVM massif (librairies réseau, bases, monitoring)
• ✅ Concurrence avancée (Futures, IO, Actors) pour temps réel et I/O
• ✅ Performance souvent très correcte dès que c’est bien profilé
• ❌ Courbe d’apprentissage si tu viens d’un Java « impératif » pur
• ❌ Moins d’outils « game engine » natifs qu’en C#/C++ (utilise Scala pour le back ou du desktop 2D simple)
• ❌ Compilation parfois plus lente si le projet grossit (à surveiller avec l’incrémental)

💡 Commence par un service back-end utile au jeu (leaderboard, profil joueurs). Tu maîtrises les bases Scala en bossant sur un cas réel et réutilisable pour d’autres titres.

Prépare ton environnement sans galérer

• JDK: installe un JDK LTS récent (souvent 17+). Vérifie: java -version.
• sbt (build tool): sbt about pour confirmer l’install.
• Scala 3: recommandé pour démarrer (syntaxe moderne, outils actifs). scala -version si besoin.
• IDE:
  • IntelliJ IDEA + plugin Scala (auto-import sbt, debuggage facile)
  • ou VS Code + Metals (léger, parfait pour commencer)
• Git: versionne dès le début; crée un .gitignore adapté (target/, .bloop/, .metals/…)

Checklist rapide:

• Tu peux lancer sbt sans erreur
• L’IDE comprend le projet et propose l’auto-complétion
• Tu sais exécuter sbt run et sbt test

Démarre ton projet Scala en 10 minutes

1) Génère le squelette

• Crée un projet Scala 3 avec un gabarit officiel: sbt new scala/scala3.g8
• Structure type:
  • build.sbt (dépendances, options)
  • project/ (fichiers sbt internes)
  • src/main/scala/ (code app)
  • src/test/scala/ (tests)

2) Lance en local

• Exécute le main: sbt run
• Ajoute un premier test (ScalaTest ou MUnit) et lance sbt test

3) Ajoute les briques utiles

• HTTP: Play Framework, http4s, Akka HTTP
• JSON: Circe
• DB: Doobie (SQL natif), Slick (ORM-like)
• Concurrence/effets: Cats Effect (IO), Akka Actors/Streams selon le besoin
• Qualité: scalafmt (format), scalafix (lint/règles), scoverage (couverture)

Ton premier projet utile: une API de leaderboard

Objectif: un service HTTP simple pour stocker et récupérer les meilleurs scores d’un jeu. Parfait pour apprendre les bases et réutilisable sur n’importe quel titre.

Fonctionnalités minimales:

• POST /scores pour enregistrer un score { playerId, points }
• GET /scores?limit=10 pour retourner le top N
• Validation basique (points ≥ 0, playerId non vide)

Étapes concrètes:

1. Modèle: crée une data class Score(playerId: String, points: Int, at: Instant); privilégie l’immutabilité.
2. Stockage in-memory pour démarrer: une structure triée (par ex. une liste triée en desc), ou un PriorityQueue min pour garder le top N.
3. Routes HTTP:
   • Avec Play: un contrôleur expose les actions, mapping JSON via Circe ou Play JSON.
   • Avec http4s: définis des routes pures, décode/encode en JSON via Circe, exécute sous Cats Effect IO.
   • Avec Akka HTTP: directives pour routes, marshalling JSON via Circe/Spray JSON.
4. Validation: refuse les points négatifs, normalise playerId (trim, taille max). Réponds avec des statuts clairs (201, 400).
5. Tests: écris des tests d’API (routes) et de logique (tri, égalités). Ajoute des cas limites (gros scores, égalités, flood du même joueur).
6. Persistance: branche une vraie DB quand tout marche in-memory.
   • Dev: SQLite ou Postgres local
   • Prod: Postgres géré, indexe par points desc et playerId
7. Sécurité & rate limiting: protège POST /scores (clé d’API côté serveur de jeu, limite par IP/joueur).

💡 Astuce versionning: commence avec un in-memory propre et des interfaces (trait LeaderboardRepo). Tu passeras à Postgres sans réécrire toute la logique.

Quel framework/stack choisir ?

outil	pour quoi	points forts	à savoir
Play Framework	Apps web/HTTP complètes	Rapide à prendre en main, écosystème mature, websockets	Un peu plus « batteries incluses », opinionné
http4s	API pures et testables	100% FP, composable, top avec Cats Effect	Courbe FP plus marquée au début
Akka HTTP	Services performants, streaming	Performant, bien avec Akka Streams/Actors	API parfois plus verbeuse
Doobie	Accès SQL direct	Contrôle précis, typesafe	Nécessite d’écrire les requêtes SQL
Slick	Mapping style ORM	Plus déclaratif	Abstraction plus lourde selon les cas

Si tu vises du client lourd/desktop 2D simple, regarde LibGDX côté JVM (tu peux coder en Scala via wrappers/interop Java). Pour du front web, Scala.js te permet d’écrire du JS en Scala (utile pour un dashboard d’admin de ton jeu).

Concurrence, perfs et temps réel sans prise de tête

• I/O non bloquants: privilégie des libs asynchrones. En http4s/Cats Effect, utilise IO plutôt que des appels bloquants.
• Back-pressure: avec Akka Streams pour chat temps réel, events de partie, etc.
• Cache: top N en mémoire avec expiration; invalide intelligemment après insertion.
• Profiling: mesure avant d’optimiser. Regarde GC, latences p95/p99.
• Sérialisation: JSON pour la simplicité; binaire (CBOR/MessagePack) si tu dois réduire la latence/bande passante.
• Parallelisme maîtrisé: évite les var partagés; préfère collections immuables et structures sûres ou des Actors.

💡 En prod, une latence stable vaut mieux qu’un pic de perf. Surveille les p99 et ajoutes des timeouts/retry « idempotents ».

Qualité, packaging et déploiement

• Style & lint: scalafmt pour formater, scalafix pour règles (ex: éviter .get sur Option).
• Tests: mélange unitaires (tri, validation) + intégration (routes HTTP) + un peu de property-based (ex: générer des scores aléatoires et vérifier l’ordre).
• CI: GitHub Actions/ GitLab CI pour lancer sbt test + scalafmtCheck + scalafix --check.
• Packaging: sbt assembly pour un JAR autonome; ou image Docker (JDK runtime).
• Déploiement:
  • VPS simple (Systemd + JAR),
  • ou container sur un PaaS/Kubernetes.
• Observabilité: logs structurés (JSON), traces, métriques (requêtes/s, latences, erreurs). Des libs JVM courantes existent; configure des dashboards.
• Sécurité: valide les entrées, limite la taille du payload JSON, journalise sans données sensibles.

Aller plus loin pour le gaming

• Matchmaking: file d’attente en mémoire + priorité; persiste l’historique pour l’équilibrage.
• Anti-cheat basique: règles côté serveur (vérifie cohérence des points), taux d’upload suspect, signature côté client.
• Notifications: WebSocket/SSE pour updates en direct, ou file (Kafka/RabbitMQ) pour fan-out.
• Multiservices: découpe plus tard (scores, profils, chat). Partage un schéma d’événements propre.

💡 Garde le « mono-repo » au début (un module core, un api, un infra). Tu isoleras en microservices quand les besoins seront clairs et mesurés.