11 articles tagués avec « php »

BowPHP est un framework requête/réponse — il excelle dans le HTTP : routage, validation, l'ORM Barry, sessions. Ce qu'il ne fournit délibérément pas, c'est un serveur WebSocket à longue durée de vie, car garder un socket ouvert pour chaque visiteur est un travail différent de celui qui consiste à répondre à une requête HTTP puis à passer à autre chose.

La bonne architecture n'est donc pas « faire faire du WebSocket à BowPHP ». C'est plutôt : laisser BowPHP faire ce dans quoi il est excellent — valider et persister les messages, et être la source de vérité — et placer à côté un tout petit serveur socket.io « bête », dont l'unique rôle est de diffuser les messages aux navigateurs connectés en temps réel.

C'est exactement ce que nous allons construire : un petit chat de groupe où BowPHP possède les données et un serveur Node d'une trentaine de lignes possède la connexion en direct.

Nous avons déjà couvert la liste de tâches rendue côté serveur — formulaires HTML, sessions, et tout le reste. Cette fois, nous allons construire son pendant en API : une API REST JSON sans état où les clients s'authentifient avec un JWT et où chaque tâche appartient à l'utilisateur qui l'a créée.

À la fin, vous aurez des points d'entrée d'inscription/connexion qui délivrent un jeton, et un ensemble complet de routes CRUD qui ne touchent jamais qu'aux tâches de l'utilisateur courant.

La plupart des applications sont essentiellement du HTML rendu côté serveur, avec quelques îlots d'interactivité riche — un widget de tableau de bord, un champ de recherche en direct, un formulaire en plusieurs étapes. BowPHP est livré avec un frontend moderne propulsé par Vite, ce qui vous permet de déposer un composant React ou Vue exactement là où vous en avez besoin, sans transformer toute votre application en application monopage.

Dans ce billet, nous allons brancher les deux : un compteur React interactif et un widget Vue, montés côte à côte dans un template rendu côté serveur.

La plupart des applications finissent par accumuler quelques tâches récurrentes : purger des données obsolètes, envoyer un récapitulatif nocturne, reconstruire un cache. La manière propre de les gérer consiste à créer une commande de console personnalisée que vous pouvez exécuter à la main, plus le planificateur pour l'exécuter automatiquement. Dans ce tutoriel, nous allons en construire une de bout en bout et la brancher correctement.

À la fin, vous disposerez d'une commande data:prune — avec des options, un mode de simulation (dry-run) et une sortie lisible — qui s'exécutera chaque nuit en production, en toute sécurité.

BowPHP fournit une organisation MVC propre, mais rien ne vous empêche de structurer une application plus vaste autour du Domain-Driven Design (DDD) (conception pilotée par le domaine). Le framework vous offre déjà les trois pièces sur lesquelles le DDD s'appuie : un conteneur pour lier les interfaces à leurs implémentations, le CQRS pour modéliser les cas d'usage, et un système d'événements pour publier les événements de domaine. Dans ce billet, nous allons les assembler en une architecture en couches et testable.

Nous allons modéliser un seul contexte délimité — Ordering — en gardant le domaine au centre et les détails du framework en périphérie.

La requête la plus rapide est celle que vous n'exécutez jamais. Dans ce billet, nous allons prendre un point d'entrée d'API lent et le rendre rapide grâce au cache de BowPHP — puis garder les données en cache correctes lorsque les enregistrements sous-jacents changent, et terminer en ajoutant un limiteur de débit léger. Tout ce qui suit fonctionne de la même manière, que vous soyez sur le pilote fichier, base de données ou redis.

À mesure qu'une application grandit, certaines responsabilités souhaitent vivre de leur côté — leur propre rythme de déploiement, leur propre montée en charge, leur propre équipe. La facturation en est un exemple classique. Dans ce billet, nous allons extraire la facturation dans un service distinct et faire dialoguer notre application Commandes avec celui-ci grâce au package bowphp/microservice via Redis.

Nous utiliserons les deux modes de communication offerts par le package :

• Requête/Réponse (RPC) avec send() — lorsque Commandes a besoin d'une réponse en retour.
• Fire-and-forget (Événement) avec emit() — lorsque Commandes veut simplement annoncer qu'un événement s'est produit.

Demander à vos utilisateurs d'inventer encore un mot de passe est une friction dont vous n'avez pas besoin. Dans ce billet, nous allons ajouter « Connexion avec GitHub » à une application BowPHP existante en utilisant le package officiel bowphp/soauth — puis persister l'utilisateur authentifié afin que le reste de l'application puisse l'utiliser.

Le même flux fonctionne exactement de la même manière pour Google, Facebook, GitLab, Instagram et LinkedIn : seules les informations d'identification changent.

BowPHP est un framework PHP léger et expressif construit autour d'une idée simple : vous donner tout ce dont vous avez besoin pour livrer de vraies applications — et rien contre quoi vous devez lutter. Si vous appréciez une API propre, des temps de démarrage rapides et une surface réduite que vous pouvez réellement lire de bout en bout, BowPHP mérite le coup d'œil.

Ce billet explique comment intégrer de manière sécurisée le téléversement de fichiers dans une application BowPHP : routes, contrôleurs, emplacement de stockage et diffusion des fichiers téléversés.