Dans les coulisses
Lego et iPhone : les plus fréquentes recherches de la clientèle
par Manuel Wenk
Team Isotopes : les Speed Demons de l'ingénierie
7/5/2018
Traduction: traduction automatique
Photos: Thomas Kunz
Lorsqu'il s'agit de vitesse brute, l'équipe d'ingénierie Isotopes évolue dans un champ de tension entre l'homme, la machine et l'avenir. Ils nous donnent un aperçu de leur travail.
Damian Frizzi est assis sur les blocs de béton chauffés par le soleil devant les bureaux de digitec. Lunettes de soleil, t-shirt gris. Il semble détendu, parle lentement, plaisante de temps en temps, s'éloigne du thème. Son thème, ce sont les millisecondes, la technologie et un peu d'oracle.
Damian est le responsable de l'ingénierie frontale et membre de l'équipe appelée "Isotopes", du nom de l'équipe de baseball de la ville fictive de Springfield dans "Les Simpson". Lui et son équipe, composée de huit ingénieurs, travaillent chaque jour à rendre la boutique encore plus rapide. Ils ne cherchent pas la chose qui éliminera les retards de dix secondes, mais des millisecondes. Si un processus n'a pas été allégé de telle sorte qu'aucune milliseconde de temps de calcul ne soit gaspillée, cela s'additionne sur digitec.ch.
Actuellement, les Isotopes travaillent sur un projet colossal : ils veulent convertir l'ensemble de la boutique.
Un regard sur l'histoire : Comment fonctionnaient les boutiques d'autrefois
"A l'époque préhistorique du Web 1.0, les sites Web fonctionnaient différemment d'aujourd'hui", explique Damian, un sourire malicieux sur le visage. Car c'est à cette époque, vers la fin des années 1990, que cette ère a pris fin. Préhistorique ? Pas du tout. Mais quand même déjà loin. Les personnes nées en 1999 peuvent passer l'examen de conduite depuis l'année dernière. C'est également en 1999 que le terme "Web 2.0" est apparu pour la première fois.
Les sites web d'autrefois fonctionnent ainsi : Vous envoyez une requête, en français une demande, à un site web, le serveur calcule, le serveur vous renvoie une page complète. Ensuite, vous cliquez sur un lien, le serveur recalcule la page, vous renvoie une nouvelle page complète. Cela signifie que chaque fois que vous cliquez sur un site web, une nouvelle page est chargée. Ce processus s'appelle le rechargement de page ou Server Side Rendering (SSR) et peut entraîner la ré-expédition à l'utilisateur de données qu'il a déjà demandées. Cela entraîne un temps de chargement plus long lors de la navigation sur la page Web.
Trop lent pour l'utilisateur et beaucoup trop lent pour les isotopes.
Ce que l'on appelle le rendu côté serveur a longtemps été le meilleur moyen de mettre en œuvre des pages web, car JavaScript n'était pas aussi développé qu'aujourd'hui. JavaScript, dont le but est de rendre les pages Web plus dynamiques, ne permettait cependant pas de faire beaucoup plus que des diaporamas d'images ou des widgets de sélection de dates au début du Web 2.0.
Les années ont passé et le développement de sites Web et d'affichages de plus en plus performants a poussé le Web traditionnel à ses limites. Aujourd'hui, les clients attendent des plateformes d'applications entièrement équipées. Avec des temps d'exécution JavaScript rapides et des normes HTML5 qui affichent des applications riches. En d'autres termes, tout ce à quoi vous êtes habitué sur Internet. Car JavaScript et HTML5 ne sont plus un luxe depuis longtemps, mais les Basics.
"C'est à ce moment-là que les développeurs ont changé leur fusil d'épaule", explique Damian. La puissance de calcul s'est de plus en plus déplacée du serveur vers le client, c'est-à-dire vers votre ordinateur. Les applications dites à page unique avec rendu côté client permettent d'interagir directement avec le site web sans passer par le serveur.
Damian se lance dans les explications : "Les Single Page Applications sont des applications qui reposent sur une structure HTML minimale et qui chargent des données - sur mesure pour l'utilisateur et son environnement - de manière asynchrone dans le navigateur."
Jusqu'ici, cela semble bien, mais c'est là que le travail des isotopes commence. Même le transfert de données asynchrone, bien que plus rapide que le Server Side Rendering continu, présente des obstacles, des défis et des particularités. Damian mentionne le Google Crawler, un petit programme qui parcourt le web à la recherche de nouveaux contenus. Il ne peut traiter les sites exécutés côté client que de manière limitée. La recommandation officielle de Google est d'afficher le contenu pertinent de la page directement avec et de ne pas le recharger. Sinon, la pertinence risque d'être dégradée et la page apparaîtra plus bas dans les résultats de recherche.
.
La performance initiale est également critique. Comme l'ensemble du Document Object Model (DOM), l'architecture d'un site, est construit sur le client, il faut un certain temps pour que les données soient demandées au serveur, traitées et rendues.
"Cela peut entraîner de longs temps de chargement, surtout pour les clients ayant une faible puissance de calcul, les vieux smartphones par exemple, ou une mauvaise connexion Internet", explique Damian.
Les animations de chargement interminables se produisent lors du premier chargement de la page.
La voie isotopique
Les isotopes évoluent dans cette zone de tension entre les exigences des utilisateurs - c'est-à-dire vos exigences - et celles de la technologie. De plus, il y a Google. Le géant de la recherche a bien sûr son mot à dire, que cela plaise ou non aux Isotopes.
"Nous voulons un mélange de la nouvelle approche et de l'approche traditionnelle : nous voulons que le serveur nous renvoie un document HTML complet lors de la requête initiale afin que le temps de chargement soit le plus court possible et que Google et consorts puissent continuer à explorer l'intégralité de nos contenus", Damian reprend son souffle un instant. Il est dans son élément, parle vite et respire moins. "Mais en plus, nous voulons profiter du boost de performance d'un SPA pour la suite de la navigation au sein de notre application."
.
Les Isotopes se sont assis et ont expérimenté des applications à rendu universel. En d'autres termes, que ce soit un humain ou un crawler, la page a du sens et peut être lue, catégorisée et évaluée par une machine. Pour cela, la logique d'affichage doit fonctionner correctement à la fois sur un serveur et un client. Cela a ses avantages.
"Non seulement nous évitons le surcroît de travail lié au développement pour un environnement, mais nous pouvons également contrôler de manière ciblée quel contenu doit être chargé et à quel moment", explique Damian.
Pour atteindre cet objectif, il faut fondamentalement résoudre deux problèmes majeurs:
- Frontale universelle isomorphique : les isotopes doivent construire une frontale qui peut être traitée et rendue à la fois par un serveur et un navigateur, et déployée dans le cloud comme une unité indépendante
- Recharger des données : Vous devez pouvoir consommer, persister temporairement et afficher des données dans le frontend à partir de n'importe quelle interface indépendante
Après les expérimentations et la définition des exigences, des souhaits et des limites, l'équipe de Damian Frizzi passe aux choses sérieuses. Il est temps de réinventer une boutique en ligne.
Un front-end universel
Les isotopes se lancent dans la bataille. Le moteur de rendu est rapidement choisi : React, développé par Facebook. Facebook et Instagram utilisent tous deux cette librairie JavaScript et y réalisent de très bonnes performances. React, parfois appelé React.JS ou ReactJS, prend en charge le rendu du côté du client et du serveur, a une grande communauté derrière lui et est largement accepté par les hommes et les machines. Il ne résout qu'un seul problème : le rendu et donc l'interaction avec le DOM.
"Enfin, React est très efficace. Avec un DOM virtuel et des correctifs ciblés."
Au React s'ajoute Node.js côté serveur. C'est une évidence, explique Damian. Les Isotopes peuvent ainsi programmer en JavaScript et profiter du savoir-faire existant.
.
Recharger les données
Les API, c'est-à-dire les interfaces de programme, sont la clé du succès lors du rechargement des données. Les isotopes de Damian doivent d'abord rattraper le présent.
"Actuellement, nous convertissons toutes les interfaces en API Web", dit-il. Il a du mal à réprimer un soupir. Car la transition n'est pas simple. Il en résulte une multitude d'interfaces qui doivent être demandées par le client. Pour éviter que chaque utilisateur ne doive envoyer un nombre incalculable de requêtes aux serveurs backend de digitec, nous avons opté pour une couche GraphQL entre le frontend et le backend.
Les avantages sont clairs : le client - c'est-à-dire l'ordinateur de l'utilisateur - n'a besoin d'interroger qu'un seul point d'accès et les développeurs front-end n'ont pas à s'occuper de l'implémentation des requêtes d'interface. Le serveur GraphQL réduit les données au minimum à l'aide de requêtes et de résolveurs de schéma. Ainsi, seules les données réellement nécessaires sont échangées entre le client et le serveur GraphQL. C'est un avantage, en particulier pour les connexions Internet lentes. Damian se projette dans l'avenir : "Plus tard, nous mettrons les données en cache au niveau de GraphQL", ce qui réduira les requêtes aux interfaces et permettra au client d'obtenir une réponse encore plus rapidement.
La vitesse. Les isotopes la recherchent.
Damian résume le cœur de la pile technologique actuelle de digitec:
- JavaScript (ES2015, ES2016)
- Node.js
- React
- Next.js
- GraphQL
- Apollo
- Enzymes
- Jest
- Docker
- Azure
- Kubernetes
- ASP.NET Web API
De là naît un prototype, c'est-à-dire l'endroit où les choses deviennent passionnantes.
Un aperçu du prototype
"Perturbé ? Pas de problème. Regardez ce prototype", dit Damian. Selon lui, l'amélioration des performances ne sera évidente que lorsqu'on la verra.
Damian est fier : "Et c'est exactement ce que font les isotopes"
.
Le résultat du prototype sera mis en ligne prochainement.
À ce propos, Team Isotopes veut que vous sachiez que notre équipe d'ingénierie cherche à se renforcer. Si vous souhaitez nous rejoindre, consultez les postes vacants suivants :
- Ingénieur logiciel junior
- Ingénieur logiciel
- Ingénieur logiciel senior
- Leader technique / Architecte Cloud
- Teamleader Software Engineering
En outre, il existe d'autres postes en ingénierie ici.
Si vous souhaitez en savoir plus sur la façon dont nous développons, consultez hier.
Journaliste. Auteur. Hackers. Je suis un conteur d'histoires à la recherche de limites, de secrets et de tabous. Je documente le monde noir sur blanc. Non pas parce que je peux, mais parce que je ne peux pas m'en empêcher.
Informatique
Suivez les thèmes et restez informé dans les domaines qui vous intéressent.
Tech
Suivez les thèmes et restez informé dans les domaines qui vous intéressent.
17 commentaires
later