Bâtiment EventPress Partie 1

Salut ! Juste un mot avant de commencer... Je n'ai pas écrit depuis longtemps. Je menaçais de le faire depuis des lustres, et j'ai finalement pensé que c'était un aussi bon sujet pour commencer qu'un autre. Je suis un peu rouillé mais je vais essayer de continuer et j'espère m'améliorer.

EventPress est probablement la chose la plus importante sur laquelle je travaille. Je suis impliqué depuis le tout début et l'application a connu une croissance exponentielle à travers 3 versions majeures au cours des 10 dernières années. La version 4 est maintenant sur la table et il y a quelques changements que j'aimerais modifier au fur et à mesure que nous y travaillons.

Tout d’abord, un peu d’histoire. EventPress appartient à HotPress Media et a été lancé parce qu'un client demandait une solution simple pour gérer les RSVP d'événements qui pourrait remplacer sa feuille de calcul Excel. Cette première version d'EventPress était moche. Il n’y avait aucune spécification, nous avons mené le projet sans plan approprié et nous nous sommes retrouvés avec un bol géant de spaghettis. Mais cela a fonctionné et cela a aidé à mettre un pied dans la porte de l’une des plus grandes entreprises d’Afrique du Sud.

La version 2 a été un grand pas en avant. Nous n'avons pas beaucoup changé l'interface, mais le cadre sous-jacent a subi un grand changement. EventPress a été déplacé vers Laravel (version 5 à l'époque), et bien qu'une grande partie du code de la version 1 soit passée à la version 2, la structure était bien meilleure et nous avons eu beaucoup moins de problèmes. Nous n'avions toujours aucune sorte de suite de tests à l'époque et nous testions essentiellement des éléments sur la base "ça fonctionne sur ma machine". Pas génial.

Index des événements version 2

---

La version 3 a apporté une refonte complète de l'interface utilisateur et Tailwind est devenu le framework CSS préféré. De nombreux codes ont été modifiés, même s'il restait encore une bonne quantité de code de la version 1 caché dans les coins sombres. Un grand changement par rapport à la version 3 était un tout nouveau système de distribution. Nous avons beaucoup appris sur l'envoi de courrier en masse pendant cette transition.

Une grande partie de l'interface utilisateur destinée au public était une copie directe de la version 2. Même aujourd'hui, une grande partie de ce que les participants voient est toujours du code de la version 2. Au lieu de cela, la version 3 a apporté beaucoup plus de structure à la base de code. Il y avait une certaine logique qui commençait à se manifester. Nous avons écrit des contrôleurs légers et nous sommes fortement appuyés sur le conteneur de services. La version 3 était également la première version d'EventPress à proposer une suite de tests.

Index des événements version 3

---

J'écris du code PHP depuis longtemps, mais je suis autodidacte. EventPress, c’était comme être jeté dans le grand bain sans aucune indication sur la façon de nager. Ce fut une courbe d’apprentissage énorme, mais cela m’a amené là où je suis aujourd’hui. J'ai construit cette chose moi-même avec très peu de contribution d'autres développeurs.

Cette fois-ci, je vais bloguer sur le développement d'EventPress 4. Non pas parce que je cherche l'approbation, mais parce que je veux l'enregistrer cette fois. Et peut-être que mes solutions pourraient aider d'autres développeurs solo. J'ai beaucoup appris sur la création et l'exécution de grandes applications PHP.

EventPress 4 va être une grande réécriture. Bien qu'une grande partie du code d'EventPress 3 se retrouve dans la version 4, il ne s'agira pas simplement d'un copier-coller. Je pense qu'il est temps de se débarrasser enfin de tous les éléments obsolètes qui sont restés depuis la version 1 ; Je veux une suite de tests plus robuste ; et je veux profiter de technologies plus récentes.

Mon plan est d'écrire quelque chose au moins une fois par mois pendant que j'y travaille. Je vais essayer de me forcer à continuer.

Alors tête première, dans la mêlée...

Par où commencer.

EventPress 4 ne recevra pas de nouvelle interface utilisateur. Nous utiliserons presque toute l'interface de la version 3, et peut-être juste quelques modifications mineures ici et là. L'interface utilisateur d'EventPress est construite à l'aide de Vue 3 et Tailwind et Inertia est notre colle de choix.

EventPress 4 sera une copie 1-to-1 des fonctionnalités de la version 3. Cela signifie qu'à mesure que la version 3 évoluera au cours des prochains mois, la version 4 devra évoluer en même temps. Pour l’instant, ce n’est qu’un peu de planification.

Pour commencer, j'ai regardé où la version 3 avait encore des difficultés et j'ai pris quelques notes sur la façon dont ces éléments pourraient être améliorés dans la version 4. J'ai eu une idée de la façon dont j'aimerais aborder la construction de cette version de ÉvénementPress. Il y a du familier et des nouveautés :

• Laravel 11
• Vue 3
• InertiaJS 2
• Laravel Octane sur FrankenPHP
• PHP 8.4
• MySQL (et SQLSRV pour nos clients d'entreprise)
• Caddy

Il y a des choix intéressants là-dedans, je sais. Celui d'Octane est important pour nous puisque nous n'avons jamais utilisé quelque chose comme ça auparavant. Octane est un package propriétaire pour Laravel qui permet d'exécuter votre application sur un serveur d'applications PHP. Swoole, RoadRunner et FrankenPHP sont pris en charge. Nous avons examiné les trois options et avons opté pour FrankenPHP pour le moment. Il est plus récent que les deux autres, mais offre de très bonnes performances. Swoole propose des travailleurs simultanés, ce qui est bien, mais ce n'est pas quelque chose dont nous pensons avoir besoin. Le problème, cependant, était que cela nécessitait l’installation de l’extension Swoole. Ce n’est pas quelque chose que nous pouvons attendre de nos clients entreprises. J'ai également une certaine expérience avec FrankenPHP, donc c'était logique.

Nous utilisons Nginx depuis des années. C'est génial et je ne saurais trop le recommander. Cependant, FrankenPHP est livré avec son propre serveur Caddy, nous expérimentons donc également cela. On ne s'en tiendra peut-être pas à Caddy, mais pour l'instant, c'est sur la liste.

PHP 8.4 n'est pas encore sorti, mais comme EventPress 4 ne sortira pas avant un certain temps, il était logique de commencer avec la dernière version possible. Au moment de la rédaction, PHP 8.4 est à environ un mois de sa sortie, nous utilisons donc la dernière version candidate.

InertiaJS 2, c'est à peu près la même histoire. Il est également en version BETA, mais comme nous sommes loin de sa sortie, il le sera probablement bien avant EventPress. De plus, nous avons exécuté InertiaJS 1 en version BETA pendant des lustres sans problème.

Analyse statique

Je suis un récent converti en analyse statique. Le plus que j'ai utilisé, ce sont les éléments que PHPStorm me donne sous forme de code. Pour EventPress 4, nous avons décidé d'y aller à fond et d'intégrer PHPStan dans le mix. PHPStan est un analyseur statique tiers pour PHP. C'est très simple à configurer et m'a aidé à éliminer quelques bugs dans un certain nombre d'autres projets.

En fonction de la taille d'EventPress, cela a également du sens ici. Pour que cela fonctionne, j'ai ajouté un script test:types Composer que je peux exécuter quand je le souhaite et qui peut être ajouté au script CI.

Code Linting

Je n'ai jamais exécuté de linter de code PHP. J'ai utilisé PHP Mess Detector à plusieurs reprises, mais je ne m'y suis jamais vraiment lancé. Pour EventPress 4, nous avons décidé qu'un linter aiderait à garder le code propre et cohérent. Nous avons opté pour le propre "Pint" de Laravel qui n'est en réalité qu'un wrapper autour de PHP-CS-Fixer et fournit un moyen très simple de garder notre code bien rangé. Encore une fois, j'ai ajouté les scripts lint et test:lint Composer pour faciliter son exécution.

Environnement de développement

Je travaille sur des machines Mac et Linux pendant le développement. J'ai un M1 Max sur mon bureau que j'ai depuis quelques années et quelques machines Linux disséminées dans le bureau. Mon pilote principal est le Mac et j'y effectue la plupart de mon travail de développement, mais tout mon code s'exécute sur des machines Linux. Généralement Ubuntu Server.

EventPress 4 ajoute quelques nouvelles pièces au puzzle, mais je pense que pour l'essentiel, je peux continuer à me développer comme je le fais actuellement. J'utilise Homebrew pour installer la plupart des outils et Laravel Valet pour exécuter des environnements de développement locaux. Je ne suis pas un utilisateur de Laravel Herd (c'est bien, mais je suis plutôt un utilisateur de Herd Pro et je ne peux pas justifier de dépenser 99 $ par an pour un outil qui fait déjà tout ce que je peux faire, juste un peu plus rapidement et enveloppé dans une belle interface utilisateur).

Mon plan est donc d'avoir un domaine eventpress4.test fonctionnant avec une base de données MySQL sur ma machine locale. J'utiliserai cet état pendant un certain temps au début du développement et je ferai juste quelques tests avec Octane tous les quelques jours environ. Une fois que nous aurons terminé la première partie, nous commencerons le développement en utilisant Octane plus régulièrement. Nous hébergerons un serveur de test exécutant l'application car nous avons l'intention de la faire fonctionner en production.

Conteneurs

EventPress n’a jamais été conteneurisé. Cependant, EventPress 4 ira probablement dans cette direction. Nous expérimentons encore quelques éléments, mais nous avons discuté avec certaines de nos entreprises clientes et nous pensons que cela contribuera à rendre le processus de déploiement beaucoup plus facile pour eux. Nous avons quelques premiers tests exécutant EventPress 3 dans un conteneur Docker, et nous pensons que ce sera la bonne décision pour toutes les versions d'EventPress à l'avenir.

GIT

Pendant des années, nous nous sommes fortement appuyés sur GitLab comme service CI/CD de choix. GitLab gère un certain nombre de pipelines CI complexes et effectue le déploiement pour presque tous les projets sur lesquels je travaille.

Cependant, je suis également un utilisateur de GitHub depuis de nombreuses années. Je l'ai utilisé principalement pour mon travail open source, mais j'ai récemment commencé à déplacer certains petits projets vers un compte GitHub payant et j'ai été très impressionné. Il y a quelques choses qui fonctionnent très différemment de GitLab, mais dans la plupart des aspects, je suis vraiment content.

Le code EventPress 4 sera donc hébergé sur GitHub et nous utiliserons Actions pour le pipeline CI et tous les déploiements.

Prêt, partez !

Je pense que c'est tout pour ce post. Il y a encore un peu de planification à réaliser, mais j'ai commencé à mettre du code et à écrire des tests. J'ai déjà une couche d'authentification de base (merci Laravel), bien que la plupart soient similaires à EventPress 3. Je montrerai du code dans la prochaine. Promesse !

Connexion à la première version 4

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!