Architecture frontale à grande échelle pour les grandes organisations

(Daniel Ostapenko) ( 14 oct 2020)

Salut! Je souhaite discuter avec vous de la manière de gérer larchitecture Frontend dans les grandes organisations. Jai limpression quil ny a pas beaucoup darticles sur ce sujet et que cela nest pas bien expliqué.

Par grande organisation dans cet article, jentends les entreprises, dans lesquelles le nombre dingénieurs front-end commence à être plus grand que 15 et lentreprise a au moins plusieurs projets frontaux.

Je ne veux pas discuter des problèmes de gestion ou des problèmes de domaine métier, ceux qui sont couramment rencontrés dans ces grandes entreprises, mais concentrons-nous uniquement sur larchitecture Frontend à la place.

Larchitecture Frontend est impliquée dans trop de domaines de nos jours, donc pour commencer, je proposerais de la diviser en sections suivantes:

Schéma darchitecture frontale

1. Code visuel

Commençons par le sujet le plus simple, à mon avis, cest le code visuel de nos applications.

Très probablement parce que nous développons plusieurs applications frontales dans la même entreprise que nous les voulons avoir:

  • la reconnaissance de la marque
  • la même UI / UX

Pour y parvenir, nous avons besoin dun système de conception. Léquipe de conception doit mettre au point le système de conception et suivre ces directives de conception dans toutes les futures conceptions de produits. Même cela est déjà une tâche très complexe et nécessite de nombreuses discussions et alignements entre léquipe de conception, les ingénieurs et le produit.

Du point de vue frontal, nous devons fournir un outil pour mettre en œuvre et pour partager ce système de conception entre les ingénieurs. Une bonne solution pour cela peut être la création du package npm, qui sera représenté visuellement par un Storybook ou un outil similaire. À mon avis, il est très important davoir une ressource Web dédiée (avec URL) avec une documentation sur la façon dutiliser ce package. Cette ressource Web sera utilisée par les ingénieurs front-end et par les concepteurs et peut être un excellent point de référence dans conversations entre eux.

Visual Code

Résumé:

À ce stade, nous avons un système de conception et sa représentation dans un package et une documentation interactive pour cela. Nous partageons et adoptons ce package dans toutes nos applications frontales.

2. Structure du code

Parlons un peu sur lingénierie de base quotidienne. Nous implémentons de nouvelles fonctionnalités, corrigeons les bugs, refactorisons le code si nécessaire. Nous nous soucions de notre base de code, en essayant de la rendre agréable et facilement compréhensible. Mais que se passe-t-il lorsque nous commençons à avoir non pas 1, pas 2, mais des dizaines de petits ou grands projets dans lentreprise? Habituellement, les gens sont regroupés autour de certains projets et ne commencent à travailler quavec ce groupe de projets. De par notre nature humaine et le temps limité, généralement, nous ne pouvons pas nous occuper de plus de 2–3–5 projets à la fois. Donc, naturellement, nous commençons à avoir ces groupes dinfluences. Btw, merci à la NASA pour cette photo incroyable pour mon analogie 😃

Groupes dinfluences

Mais, nous commençons à avoir de plus en plus de cas, quand les gens se croisent -les équipes collaborent, doivent vérifier le code et les solutions de chacun, corriger certains bogues même dans dautres applications ou ajouter quelque chose dont ils ont besoin dans une application externe (externe pour leur groupe dinfluence). La mauvaise nouvelle – que ce processus se passe dans les grandes entreprises presque incontrôlé. La bonne nouvelle – nous pouvons vous aider à laméliorer.

Comment? Correct. En fournissant la même structure de code , les directives de codage et de structuration pour tous les projets dans lentreprise.

Examinons plus en détail ce que nous entendons par structure de code:

  • La structure des dossiers dans le projet
    Lorsque les ingénieurs se lancent dans un nouveau projet pour la première fois – ayant la même structure de dossiers que dans leur projet, où ils savent tout, aide beaucoup à naviguer et à rechercher.
  • Fichiers de configuration ou de support
    Fichiers comme package.json, .gitignore, .editorconfig, webpack.config, etc. Ils doivent toujours être au même endroit, dans chaque projet, et ils sont connectés aux fichiers de configuration des tests ou CI sils sont nécessaires.
  • Emplacement fixe des types de fichiers
    Si lemplacement des mêmes types de fichiers est le suivant toujours la même structure cela fonctionne aussi très bien. Par exemple, si le dossier du composant contient toujours un fichier style.css:
/Component
--/Component.tsx
--/style.css
--/index.ts
  • Structure interne des composants
    La structure à lintérieur des fichiers doit être la même: ordre des importations, des exportations, la position de la fonction publique , types, etc. Dans chaque type de fichier, vous devez savoir à quoi vous attendre.
  • Conventions de dénomination
    Cela inclut les noms des dossiers, fichiers, variables, fonctions, classes, types, etc.
  • Conventions de codage
    En général, je dirais que les conventions de codage sont une section très large, mais ici je veux juste inclure des choses qui ne rentrent pas dans le reste des sections, telles que ; ou not ; 😁 et similaires .

La même structure de code et le jeu doutils du projet dans la pratique sont très proches lun de lautre heu et sentraider pour coexister. Par ensemble doutils, jentends les outils CLI (amorçage de projet, linting, tests, etc.), les extensions IDE, etc. Nous discuterons du sujet de lensemble doutils dans les sections suivantes.

Structure du code

Résumé:

Après avoir appliqué cette section et lavoir adoptée, nous devrions avoir tous les projets de lorganisation avec la même structure de dossiers, les mêmes directives de dénomination, la même structure de fichiers, etc. Chaque développeur idéalement peut sauter dans nimporte quel autre projet et ne pas y être complètement perdu. Ce « complètement perdu » est également très connecté à la pile technologique qui est utilisée à lintérieur du projet, alors parlons-en.

3. Tech Stack

Semblable à la précédente , nous voulons avoir une pile technologique unifiée à travers les projets de lorganisation. Le raisonnement est très similaire – nous voulons que nos ingénieurs soient à laise avec tous les projets de lentreprise.

Dans les projets Frontend, les composants de la pile technologique peuvent être: le cadre, basé sur ce projet est construit, le langage principal, le processeur de styles, couche de données (ex. Apollo), gestion des états, tests, linting de code, système de construction, et autres.

Bien sûr, dans toutes les règles, il y a des exceptions. Et dans cette rubrique, je voudrais également faire une remarque, que parfois certaines technologies sadaptent parfaitement à certains projets spécifiques, même si ces technologies ne font pas partie de la pile technologique mondiale de lentreprise. Mais chaque fois que cette idée vient séloigner du com Vous devriez réfléchir à deux fois car le coût de la prise en charge de telles choses est très élevé, donc les avantages doivent être spectaculaires.

Mentionnons ici une pile technologique générique qui peut maintenant convenir à la plupart des projets ( bien sûr, il ne couvre quune partie de la vraie pile technologique, mais peut être un bon point de départ pour quelquun 🤷):

Stack

Après avoir défini la pile technologique dans notre entreprise et accepté, il existe également dautres piliers très importants du succès .

Premièrement – nous devons notez la pile technique dans le document . Le document, qui devrait être bien et facilement partagé entre les ingénieurs , afin quils puissent toujours se donner un lien comme preuve.

Deuxièmement – nous devrions à nouveau écrire et partager le document avec la manière comment les nouveaux projets doivent être lancés et amorcés, en utilisant la pile technologique définie .

Tech Stack

Résumé:

Après avoir mis en œuvre et adopté tout ce que nous « avons mentionné ci-dessus, vous devriez avoir tous vos projets au sein de lorganisation pour partager la même pile technologique. Idéalement, sans aucune différence. Pas idéalement – avec des différences insignifiantes. Si nous ajoutons également la section précédente, le code, les dossiers et la structure des fichiers devraient également être presque identique dans vos projets.Naviguer dans nimporte quel projet devrait donc être une tâche très facile. Bon 😊

4. Outillage

Ce sujet est très important. Nous utilisons maintenant des outils supplémentaires presque partout maintenant – pour le peluchage, la création de nos applications, CI, générateurs de composants et bien plus encore. C’est pourquoi je vois si nous pouvons choisir le bon outillage pour nos projets – c’est crucial. Bon outillage vs mauvais outillage (ou aucun outillage du tout), cest la même chose quune comparaison entre lautomatisation et les tests manuels .

Nous venons de parler précédemment dans les sections précédentes de la pile technologique et de la structure du code et avons mentionné que nous devons écrire beaucoup de documentation pour que les gens les suivent. Mais l’ensemble d’outils approprié peut vous donner la possibilité d ’ automatiser en suivant les directives de votre entreprise .

Pour Par exemple, si vous avez un style de codage spécifié, vous pouvez donner aux gens le jeu doutils de peluchage, qui par défaut suit ces règles. Si vous avez la pile technologique définie, alors un bon outil CLI vous donnera la possibilité de démarrer un nouveau projet avec ces technologies spécifiques de votre pile technologique en place.

Essayons de discuter des parties de votre architecture frontale peut être couverte par des outils:

  • Style et structure du code
    Comme nous lavons vu précédemment, cela peut être facilement automatisé par des outils
  • Amorçage de projet
    You don  » t besoin de créer une nouvelle structure de projet, dinstaller manuellement tous les packages nécessaires, etc.
  • Génération de composants
    La plupart du temps, un composant de votre application ne contient même pas un seul fichier, donc la création de fichiers, leur liaison / importation peut prendre du temps, donc cela peut être automatisé.
  • Démarrer et construire
    Bien sûr, la chose la plus évidente pour lautomobile mate – comment vous créez ou démarrez votre application.
  • Tests
    Le processus de création de votre application pour les tests et lexécution de tous les types de tests – unité, intégration, etc.
  • Gestion des dépendances
    Comme nous le savons, environ 80\% de notre code sont désormais des dépendances. Nous devons donc les tenir à jour et gérer cela dans une grande entreprise nest pas une chose facile à faire.
  • Dépendances entre projets
    Il est fort probable que nos projets ne fonctionnent pas de manière isolée et pourraient dépendre dautres projets ou être une dépendance pour un autre projet, nous pourrions donc avoir besoin doutils pour faciliter le processus de liaison, développement dans une combinaison de plusieurs projets (comme Bit , par exemple), etc.
  • CI
    CI est une partie essentielle de notre ensemble doutils de base quotidienne et lautomatisation et lunification de celui-ci peuvent être un travail très bénéfique pour votre organisation.

Si vous ne souhaitez pas développer votre propre ensemble doutils, je peux vous recommander le ensemble doutils NX , comme lun des candidats les plus intéressants. Aussi , il semble que les créateurs de Babel ont fait une solution similaire, que vous voudrez peut-être vérifier – Rome . Ces outils ne couvrent pas tout, mais une grande partie de ce dont nous avons parlé, ils peuvent donc être un bon point de départ.

Outillage

Résumé:

Imaginez à quel point notre architecture peut devenir une fois toutes les sections terminées et adoptées 🧙

Chaque projet est le même et maintenu et géré par le jeu doutils unifié. Chaque projet peut démarrer et se construire de la même manière. Les nouveaux composants sont générés au même endroit et avec les mêmes règles de dénomination.

Mais est-ce que cest « doux » ou a des inconvénients? Comme pour toute solution, elle a des inconvénients. Lun deux – il faut du temps pour intégrer de nouveaux ingénieurs dans votre entreprise. Mais si tout est fait de manière très naturelle (comme les gens sy sont déjà habitués dans dautres outils existants) et documenté, cela ne devient pas un gros problème lorsque vous le comparez aux avantages de la vitesse de développement, une opportunité pour les ingénieurs de travailler avec. nimporte quelle base de code facilement, etc.

5. Production

À propos de cette partie de larchitecture frontale, les ingénieurs sen soucient le moins.Peut-être parce que ce nest pas lié au codage lui-même la plupart du temps🤷 et probablement pas si excitant, mais pas le moins important ☝️

En production, nous devons généralement nous occuper des choses suivantes:

  • Analytics
    Toutes sortes dévénements de suivi différents, etc. Des choses comme Google Analytics , segment , HotJar , etc.
  • Surveillance de létat
    Cela inclut des éléments, comme les vérifications de létat, qui peuvent être même des tests exécutés en production, des rapports derreurs (comme Sentry ), etc.
  • Performances
    Ceci est un peu similaire à lélément précédent, mais plus axé sur les performances. Cela inclut la mesure du temps de réponse, la première peinture significative, etc. (probablement loutil n ° 1 – Phare )
  • Tests A / B
    Toutes sortes de solutions de test A / B ou indicateurs de fonctionnalités.
  • Mise en cache
    Des outils tels que Varnish , Cloudflare .

Tous peuvent être unifiés dans vos applications frontales au sein de lentreprise, ce qui simplifiera la vie de vos ingénieurs . Par exemple, en ajoutant des packages avec les configurations initiales prédéfinies et en ajoutant ces packages à votre projet damorçage.

Un autre élément de la production est la préparation du code, tel que:

  • Minification
    Minification de code uniquement 😄
  • Mappage des sources
    Les cartes des sources peuvent être nécessaires pour certains autres outils, comme Sentry.
  • Préparation des ressources
    Préparation des écrans avec différentes résolutions, recadrage dimages, etc.

Ce sont dexcellents candidats à ajouter à lensemble doutils dont nous disposons pour gérer les applications frontales, dont nous parlions dans la section Outillage.

Production

Résumé:

Idéalement, tous ceux-ci devraient être ajouté à chaque projet frontal par défaut lors de la phase de démarrage. Et les ingénieurs ne prendraient soin que dajouter les bonnes clés API aux bons endroits pour les outils.

6. Développement

Outil CLI

En partie, nous avons déjà discuté de lexpérience de développement dans la section Outillage, lorsque nous avons touché loutil CLI frontend. Loutillage unifié est une grande partie du quotidien des ingénieurs, mais pas tout.

API

Une API confortable pour travailler localement est la deuxième chose formidable que nous pouvons faire pour améliorer le développeur lexpérience et la vitesse de développement. Habituellement, servir lAPI localement pour les ingénieurs frontaux nest pas un processus trivial: cela peut inclure linstallation doutils ou de frameworks, quils ne peuvent pas connaître. Même si la configuration est ancrée, cela peut prendre énormément de temps. ressources des machines du développeur (si ce nest pas le cas – cela peut être considéré comme une configuration). Quelle peut être une solution dans ce cas – API servie externe. Il peut sagir dun serveur unique pour tous les ingénieurs ou dun mécanisme de démarrage facilement votre propre serveur dédié pour le développement.

CI

CI est la troisième grande partie. Je pourrais supposer que votre entreprise a déjà choisi un outil CI pour le frontend et utilise cet outil unique (ex. Cercle CI ,

Concourse CI , ou tout autre). Sinon – vous devriez unifier cela.

La configuration CI du projet particulier, à mon avis, devrait faire partie du travail de léquipe, qui travaille sur le projet. Cela donne des chances à CI dêtre stable parce quil y a des gens qui sont intéressés par CI pour travailler, lutiliser tous les jours, et qui ont le pouvoir et les compétences pour le réparer, le configurer et laméliorer.

Cependant, tout le travail ne doit pas être effectué par léquipe. Pour les applications frontales, il existe un ensemble de tâches assez spécifiques, qui peuvent être nécessaires. Surtout, si nous parvenions à unifier la structure des dossiers / codes, la pile technologique, etc. Donc, après un certain temps dans votre entreprise, il pourrait arriver que vous soyez en mesure de détecter ces modèles pour les étapes de votre outil CI, implémentez ces étapes comme une sorte de « blocs de construction » et donnez une opportunité à vos ingénieurs de simplement construire leurs pipelines CI à partir de ces « blocs de construction » unifiés.

Environnements de démonstration

Et enfin la dernière vérification de la fonctionnalité implémentée.Une fois que les ingénieurs ont tout fait et mis en œuvre, ils ont presque toujours besoin de vérifier à quoi cela ressemble et comment cela fonctionne et de le partager avec dautres ingénieurs, concepteurs ou autres parties prenantes. Pour de tels besoins, cela fonctionne très bien la version déployée temporairement de votre application pour le PR spécifique avec lURL fournie.

Application temporairement déployée
Application déployée temporairement

Cette solution accélère beaucoup la communication entre les différentes équipes et les personnes et je pense que cest juste un doit avoir. Cependant, cette version déployée temporairement doit être aussi proche que possible de la production, car elle peut également être un excellent outil pour vérifier certaines erreurs de surface ou bogues.

Cela peut être facilement ajouté à vos projets et automatisé si votre frontend les pipelines de processus de création et de déploiement dapplications sont unifiés. De plus, des outils tels que Kubernetes et Helm peuvent beaucoup aider dans la mise en œuvre.

Développement

Résumé:

Des flux de développement confortables et efficaces avec un seul outil CI avec des éléments de base pour créer Pipeline CI, avec des outils dinterface CLI unifiés et des environnements de démonstration. Tous ces éléments devraient rendre notre processus de développement aussi fluide que possible. Multipliez cela par le nombre dingénieurs que vous avez dans lentreprise et vous comprendrez à quel point cest bénéfique.

7. Modularité

Ce sujet est très vaste et peut nécessiter un article séparé, mais jessaierais de le parcourir brièvement.

Dans les grandes organisations, les bases de code énormes ne sont pas rares chose. Avec tous les problèmes connus qui les accompagnent, comme les pipelines CI lents, les problèmes de travail collaboratif, les tests lents, etc. Donc, la grande partie de larchitecture frontale est une décision sur la granularité que nous voulons voir des applications / modules frontend indépendants.

Nous avons actuellement 3 modèles principaux:

  • Monolith
    Un grand référentiel avec un seul projet et tout le code là-bas, toutes les équipes travaillent ensemble sur ce référentiel en même temps.
  • Monorepo
    Beaucoup de projets, mais toujours un gros dépôt ( monorepo dans le wiki ). Toutes les équipes travaillent toujours sur le même référentiel, mais avec des projets différents. Il existe déjà des opportunités de résoudre certains problèmes, que nous avons avec une approche monolithique, en exécutant des pipelines uniquement pour des projets spécifiques, les projets ont des suites de tests plus petites, etc. Des outils tels que Lerna peut vous faciliter la vie si vous choisissez cette approche.
  • Repo par projet
    Chaque projet a son propre référentiel et tous les éléments de support, comme les pipelines CI, les déploiements, etc.

Dans tous ces modèles, le projet peut signifier une application frontend indépendante, une page, module frontal indépendant, etc. Cela dépend de la granularité avec laquelle vous souhaitez décider de diviser vos applications frontales. Dans la plupart des cas, cette division doit être synchronisée avec la structure organisationnelle et la gestion des personnes souhaitées.

Le deuxième grand sujet après avoir décidé de diviser votre application sera de savoir comment relier ces éléments (si vous avez décidé pour diviser votre application).

Et voici les prochaines approches:

  • Composition au moment de la construction
    Vos projets peuvent être simplement des packages npm, installés et composés pendant la construction.
  • Serveur- composition latérale
    Cette approche inclut généralement le rendu côté serveur et la composition se déroulant sur un serveur. Des outils tels que Hypernova peuvent aider à mieux lorganiser.
  • Composition côté client
    Composition des projets dans le navigateur. Dans le blog de Martin Fowler, il y a une assez bonne explication de certaines approches – ici . Il est également très important de mentionner Module Federation , une nouvelle approche introduite dans Webpack 5 .
  • Composition de la route
    Super simple – chaque projet a sa propre URL et au « niveau Nginx » nous décidons où rediriger les utilisateurs.(désolé, pour une telle explication 😄 mais je pensais que ce serait la plus simple à comprendre)

Comme je lai déjà dit, il est très difficile de couvrir ce sujet dans un si petit format, mais jespère que vous avez au moins trouvé des idées intéressantes pour vous-même et que vous approfondirez vous-même les sujets 🙏🏻 .

Modularité

Résumé:

Nous avons trouvé un moyen de rendre nos équipes heureuses et productives en organisant les référentiels, en divisant nos projets en plus petits morceaux (très probablement), en rendant les équipes plus indépendantes les unes des autres.

Bienvenue au paradis 😁

8. Test

Il y a tellement de ressources disponibles sur les tests pour les applications frontales, donc jessaierais de ne pas entrer dans les détails, ce que vous pouvez easi trouver, mais se concentrer davantage sur les problèmes des grandes organisations et comment nous pouvons les résoudre.

Le premier dentre eux – chaque ingénieur comprend les techniques de test différemment, également quelle technique appliquer dans quelle situation, comment écrire  » bons ”tests, etc. Il est donc très logique de documenter assez précisément toutes les nuances et directives des niveaux de test utilisés dans lentreprise et les directives pour chacun dentre eux.

Niveaux de test possibles que vous souhaitez ont dans votre stratégie de test:

  • Tests unitaires
  • Tests dintégration
  • Tests E2E
  • … et autres

De plus, dans un deuxième temps, nous devons les unifier à travers différentes applications frontales de lentreprise, afin que les gens naient pas de questions sur comment et quoi tester lorsquils sont déplacés vers un autre projet.

Si vous avez réussi à unifier les niveaux et les approches de test, vous pouvez automatiquement aider à résoudre le deuxième problème – la configuration de linfrastructure de test. Chaque projet à lui seul doit le mettre en place et le configurer localement et sur CI une infrastructure de test. Par exemple, nous avons décidé dutiliser Cypress et quil doit être exécuté dans une image docker. Cela nécessite un certain temps pour être mis en place localement et sur CI. Si nous multiplions cela par le nombre de projets que nous avons – cela prend énormément de temps. Donc, la solution – unifier cela à nouveau et fournir des outils pour les projets. Cela semble facile, mais prend énormément de temps à mettre en œuvre.

Tests de temps non liés au développement

Je voulais aussi aborder une autre façon de tester vos applications après des fonctionnalités déjà implémentées et déployées. Et oui, surveiller bien sûr cela en fait partie 😁.

Nous avons déjà mentionné dans les sections précédentes la surveillance des erreurs et des performances pour les applications frontales, la surveillance du temps de disponibilité, la réponse à partir de différents emplacements.

Cest super aussi davoir Lighthouse sont exécutés sur votre site Web (peuvent être inclus dans les pipelines CI). Pour trouver plus facilement les goulots détranglement de performances, les problèmes daccessibilité et améliorer la qualité des pages Web en général.

Et le last – tests de production sur les flux commerciaux les plus importants. Ils fonctionneront probablement mieux si vous les exécutez directement sur le produit. sur lenvironnement, mais peut également être possible une modification lorsque nous pouvons exécuter de tels tests sur un environnement de test / de test, qui est très proche de celui de production ou même de le mettre en miroir. Il y a un très bel article sur ce sujet – (ici).

Test

Résumé:

Nous avons des directives de test claires avec des niveaux de test nécessaires définis pour chaque application frontend. Nous avons un seul pipeline CI pour chaque application et nous avons un seul outil CLI, qui permet dexécuter des tests localement.

Dernier mot

Jespère vraiment que vous avez trouvé quelque chose dintéressant dans ce article. Je suis vraiment désolé, que dans la plupart des sujets, je viens de gratter la surface des problèmes. Et nous serons ravis den discuter davantage, alors laissez vos questions dans les commentaires ou envoyez-moi un ping directement sur Twitter – @denieler .