Construire un SPA, une plateforme de trading en temps réel avec Vanilla PHP et JavaScript

DEV - 26/12
Le début : pourquoi Vanilla ? À une époque dominée par les frameworks—Laravel, Symfony, React,...

Le début : pourquoi Vanilla ?

À une époque dominée par les frameworks (Laravel, Symfony, React, Vue), j'ai pris ce que beaucoup considéreraient comme une décision controversée : créer une plateforme de trading complète en utilisant Vanilla PHP et Vanilla JavaScript. Pas de magie Laravel, pas de complexité React, pas d'enfer de dépendance npm. Juste du code pur et sans faille.

Étais-je fou ? Peut être. Mais à la fin de ce voyage, j'avais créé Tradity, une application Web progressive qui diffuse en direct les prix des crypto-monnaies, exécute les transactions en temps réel et se sent aussi rapide que n'importe quelle plate-forme basée sur un framework, tout en gardant un contrôle total sur chaque ligne de code.

C’est l’histoire de la façon dont la simplicité a vaincu la complexité et pourquoi parfois les anciennes méthodes sont les meilleures.

Chapitre 1 : La décision d'architecture

Le problème

Je voulais créer un simulateur de trading d'actions/crypto qui pourrait :

  • Diffusez les données de prix en temps réel depuis Binance
  • Gérez les connexions utilisateur simultanées sans transpirer
  • Travaillez hors ligne avec les fonctionnalités PWA
  • Soyez déployable n'importe où, de l'hébergement partagé au VPS
  • Rester maintenable par un seul développeur (moi !)

La tentation du cadre

Chaque tutoriel criait : "Utilisez Laravel ! Utilisez Next.js ! Utilisez [insérer le framework ici] !"

Mais les frameworks ont des bagages :

  • Verrouillage du fournisseur : que se passe-t-il lorsque Laravel 15 casse votre code Laravel 10 ?
  • Surcharge de complexité : ai-je vraiment besoin de 50 Mo de node_modules pour une application de trading ?
  • Courbe d'apprentissage : conventions-cadres et programmation fondamentale
  • Performance : les couches d'abstraction ajoutent de la latence, ce qui est essentiel dans le trading

La révélation vanille

Puis ça m'a frappé : PHP est déjà un framework. Il a un routage ($_SERVEUR['REQUEST_URI']), création de modèles (?php echo $data ?) et l'accès à la base de données (mysqli,AOP). JavaScript a une API de récupération, des modules ES6 et une prise en charge native de WebSocket.

Décision prise : c’est la pile vanille.

Chapitre 2 : Construire le backend : la puissance cachée de PHP

Le routeur API (aucun Laravel requis)

// index.php - Le cœur du backend $request = parse_data-url($_SERVER['REQUEST_URI'], PHP_URL_PATH); $méthode = $_SERVER['REQUEST_METHOD']; // Routage simple et explicite if ($request === '/api/auth/login' && $method === 'POST') { AuthController::login(); } elseif ($request === '/api/trades' && $method === 'GET') { TradeController::getTradeHistory(); } else { Response::error('Point de terminaison introuvable', 404); }
Entrer en mode plein écran Quitter le mode plein écran

Pourquoi c'est beau :

  • ✅ Zéro frais de routage
  • ✅ Flux de contrôle explicite
  • ✅ Débogage facile (pas de chaînes de middleware magiques)
  • ✅ Fonctionne sur n'importe quel serveur PHP 7.4+

Le modèle de couche de service

J'ai adopté une approche d'architecture propre :

Contrôleurs → Services → Modèles
Entrer en mode plein écran Quitter le mode plein écran

Exemple : exécuter une transaction

// Classe TradeController.php TradeController { fonction statique publique exécuterTrade() { $data = json_decode(file_get_contents('php://input'), true); // Le contrôleur ne gère que HTTP $result = TradeService::executeTrade( $data['user_id'], $data['symbol'], $data['type'], $data['amount'] ); Réponse :: succès ($ résultat); } } // TradeService.php - La logique métier réside ici class Trade...
[Courte citation de 8% de l'article original]