# La version 0.14 de Glowroot est dans les tuyaux

par Xavier Calland

Une occasion parfaite pour partager ce petit bijou qui fait partie de ma liste d’applications/utilitaires/bibliothèques indispensables pour les développeurs aux côtés, entre autres, de Meld, OhMyZsh, Git et JOOQ. 

Revenons-en à Glowroot, il est décrit comme une Opensource Java APM (application performance manager).

Le principe est assez simple, il s’agit d’un agent qui s’intègre à la JVM pour fournir tout un tas d’informations utiles sur le fonctionnement de l’application. Cela comprend notamment des informations sur la JVM (métriques de consommation de mémoire, etc), comme on pourrait le faire avec JMX.

Là où ça devient vraiment intéressant c’est le monitoring avancé permettant l’identification des traitements lents ou en erreur à travers la pose de sonde sur le code java exécuté pour indiquer où (i.e. dans quelles classes et méthodes) est passé le temps de traitement des différentes requêtes.

Glowroot arrive avec un certain nombre de plugins permettant de savoir par exemple les temps d’exécution des requêtes en base de données ou encore des appels à des API HTTP. Il est possible de compléter cela avec ses propres sondes en indiquant les classes et les méthodes à surveiller.

Vous l’aurez compris c’est un allié de taille et léger (un overhead généralement de quelques microsecondes) lorsqu’il s’agit de faire du diagnostic sur une application java qui fera rapidement ressortir

  • les requêtes lentes : « 90% des appels à l’URL XXX de notre API mettent 10 secondes à répondre »,
  • certains défauts de conception : « c’est étrange, le traitement d’un appel à notre API se traduit pas 1000 requêtes sur la BDD »,
  • les requêtes en BDD les plus utilisées et les plus lentes.

Le principal changement dans la version 0.14 (dont la beta 2 est sortie le 8 novembre) de Glowroot est le support de Java 17.

# Next.js et Gatsby sont dans un bateau

Par Guillaume Poittevin

Fin octobre deux Framework web au dessus de React ont fait une release majeure.

Next.js passe en version 12, avec au programme un nouveau compilateur écrit en Rust (comme de par hasard !), le support de React 18, une fonctionnalité de Middleware (en beta pour l’instant), et quelques améliorations que vous pouvez toutes retrouver dans l’annonce.

De son côté c’est Gatsby qui a annoncé une version 4, au menu de laquelle on retrouve l’ajout de la génération statique différée et du rendu côté serveur, le support pour React 18, l’ajout de la parallélisation du requêtage des contenus, et d’autres améliorations également disponibles dans le billet de blog associé.

Chez Atol Conseils et Développements nous utilisons les deux solutions et observons donc l’évolution depuis maintenant 2 ans de chacune d’entre elles. Premier constat, si les finalités au départ étaient assez éloignées au fur et à mesure des versions, Gatsby se rapproche de plus en plus de son concurrent, l’ajout du rendu côté serveur ou de la génération différée rendent désormais nécessaire d’avoir un serveur Node qui tourne en permanence, comme chez Next.js.

Mais le point qui m’interpelle le plus est côté business model, chez Gatsby la mise en avant intensive des nouvelles fonctionnalités disponibles si vous utilisez la solution d’hébergement maison (Gatsby Cloud), me laisse à penser que les évolutions à venir pourraient être moins nombreuses pour nous qui avons fait le choix de l’auto-hébergement. Je n’ai pas ce sentiment à la lecture des releases notes Next.js. L’avenir nous dira ce que ces deux solutions prendront comme décisions stratégiques et nous ne manquerons pas de vous faire part de nos observations.

# PHP 8.1

Par Guillaume Poittevin

Le 25 novembre 2021 une nouvelle version de PHP est sortie. Quelques nouveautés bienvenues sont de la partie : 

  • Les enums
  • Les propriétés en lecture-seule
  • L’utilisation de «new» à l’initialisation d’une classe
  • La gestion des intersections pour les types
  • Un type de retour «never»
  • Les constantes de class «final»
  • Et on peut «unpack» des tableaux avec des clés en chaîne de caractères

Toutes ces nouveautés sont expliquées dans la note de release.

On notera également une amélioration des performances (~ 23% sur Symfony par rapport à PHP 8.0).

Toutes ces évolutions, sans être des révolutions, déjà présentes dans d’autres langages, sont bienvenues et confirment la bonne direction que prend PHP ces dernières années.

# Et deux frameworks React de plus, deux !

Par Thomas Broyer

React est décidément à l’honneur en ce mois de novembre ! En plus du passage en beta de la version 18, deux nouveaux frameworks ont été annoncés et/ou mis en open source.

Shopify a lancé en developer preview Hydrogen, un framework conçu pour développer des magasins personnalisés, donc optimisé pour cette typologie de projets et avec des composants et hooks spécifiques à Shopify et son API. De son côté Remix, après un an  de sponsorware, est passé en open source.

Ces deux frameworks misent sur l’exécution serveur, sans aucune pré-génération, contrairement à Gatsby et Next.js.

Côté Shopify Hydrogen, on est plutôt avant-gardiste, avec l’utilisation des React Server Components (annoncés il y a un an tout juste et toujours expérimentaux), et très orienté performance : le framework est prévu pour pouvoir être déployé dans des environnements serverless at the edge, de type Cloudflare Workers (Shopify prépare d’ailleurs un environnement spécifique, Oxygen, qui sera dévoilé prochainement), et conçu pour faire du rendu serveur en streaming (pas de buffering). Shopify a d’ailleurs débauché des pointures : Ilya Grigorik qui a travaillé pendant plus de 10 ans sur la performance Web chez Google, et Dion Almaer, passé par Mozilla, Google, Palm, Walmart, etc. et à qui on devait le site de veille technologique Ajaxian lancé il y a plus de 17 ans.

Du côté de Remix, on mise plutôt sur une approche #UseThePlatform : des liens pour la navigation et des formulaires pour les envois de données, et le développeur conserve la main sur énormément de choses. Le rendu de la page est fait côté serveur puis celle-ci est hydratée côté client, ce qui signifie qu’une bonne partie de la page est “envoyée deux fois” (en HTML, résultat du rendu serveur, et en JS pour être exécutée côté client et hydrater le HTML), comme avec Gatsby par exemple. On se retrouve au final avec une Single Page Application (même si on a techniquement la possibilité de faire autrement, au prix d’un effort plus important) qui chargera les autres pages/composants dynamiquement sous la forme de scripts JS, la navigation étant gérée par React Router, créé par les mêmes développeurs.

Tweetez
Partagez
Partagez
0 Partages