L’ère des primitives de plate forme est enfin arrivée

Dans le passé, l’écosystème Web évoluait à un rythme très lent. Les développeurs passeraient des années sans une nouvelle fonctionnalité linguistique ou sans contourner une étrange bizarrerie du navigateur. Cela a poussé nos responsables techniques à proposer des solutions créatives pour contourner les lacunes de la plateforme. Nous avons inventé le regroupement, les polyfills et les étapes de transformation pour que les choses fonctionnent partout avec moins de tracas.

Lentement, nous avons évolué vers une sorte de consensus sur ce dont nous avons besoin en tant qu’écosystème. Nous avons désormais TypeScript et Vite comme préférences claires, repoussant ainsi ce que signifie créer des expériences cohérentes pour le Web. Les frameworks d’applications ont construit des écosystèmes entiers sur eux : Démarrage solide, Nuxt, Remixeret Analogique sont des exemples d’outils incroyables construits avec de telles primitives. Nous pouvons dire que Vite et TypeScript sont des outils primitifs qui permettent la création d’autres personnes dans divers écosystèmes.

Les besoins de regroupement et de transformation étant quelque peu définis, il était tout à fait naturel que les auteurs du framework se tournent vers la couche suivante dont ils avaient besoin pour faire abstraction : le serveur.

Primitives du serveur

Les gens d’UnJS ont constamment construit des outils agnostiques qui peuvent être réutilisés dans différents écosystèmes. Grâce à eux, nous disposons désormais de frameworks et de bibliothèques tels que H3 (un framework de serveur Node.js minimal construit avec TypeScript), qui permet Nitro (un runtime de serveur complet alimenté par Viteet H3), qui à son tour a activé Vinxi (un regroupeur d’applications et un environnement d’exécution de serveur qui fait abstraction de Nitro et de Vite).

Nitro est déjà utilisé par trois frameworks majeurs : Nuxt, Analogiqueet Démarrage solide. Alors que Vinxi est également utilisé par SolidStart. Cela signifie que toute plate-forme qui prend en charge l’un d’entre eux sera certainement en mesure de prendre en charge les autres avec zéro effort supplémentaire.

Il ne s’agit pas de prendre une plus grosse part du gâteau. Mais faire en sorte que le gâteau soit plus gros pour tout le monde.

Les frameworks, les plateformes, les développeurs et les utilisateurs en bénéficient. Nous misons ensemble sur notre écosystème au lieu de travailler en silos avec nos solutions monolithiques. Permettre à nos développeurs-utilisateurs d’acquérir des compétences transférables et de véritablement choisir le meilleur outil pour le travail avec moins de dépendance vis-à-vis du fournisseur que jamais.

Le sans serveur rejoint la conversation

De telles initiatives ont probablement été remarquées par des plateformes sans serveur comme Netlify. Avec Primitives de plateformeles frameworks peuvent exploiter des solutions agnostiques pour des nécessités courantes telles que la régénération statique incrémentielle (ISR), l’optimisation d’image et la clé/valeur (kv) stockage.

Comme le nom l’indique, Primitives de la plateforme Netlify sont un groupe d’abstractions et d’aides mis à disposition au niveau de la plate-forme que les frameworks ou les développeurs peuvent exploiter lors de l’utilisation de leurs applications. Cela apporte des fonctionnalités supplémentaires simultanément à chaque framework. Il s’agit d’un changement important et puissant car, jusqu’à présent, chaque framework devait créer ses propres solutions et rétroporter ces stratégies vers les couches de compatibilité au sein de chaque plate-forme.

De plus, les développeurs devraient attendre qu’une fonctionnalité atterrisse d’abord sur un framework, puis que le support arrive sur la plateforme de leur choix. Désormais, tant qu’ils utilisent Netlify, ces primitives sont disponibles directement sans aucun effort ni temps de la part des auteurs du framework. Cela donne du pouvoir à chaque écosystème en une seule mesure.

Le sans serveur signifie que les développeurs d’infrastructures de serveurs n’ont pas besoin de s’en occuper. Ce n’est pas un abus de langage, mais un format de Infrastructure en tant que Service.

Comme indiqué précédemment, Primitives de la plateforme Netlify il y a trois caractéristiques différentes :

1. Image CDN
   UN réseau de diffusion de contenu pour les images. Il peut gérer la transformation de format et l’optimisation de la taille via des chaînes de requête URL.
2. Mise en cache
   Primitives de base pour leur exécution de serveur qui aident à gérer en douceur les directives de mise en cache pour les exécutions de navigateur, de serveur et de CDN.
3. Objets blobs
   Une option de stockage clé/valeur (KV) est automatiquement disponible pour votre projet via leur SDK.

Examinons rapidement chacune de ces fonctionnalités et explorons comment elles peuvent augmenter notre productivité avec une expérience fullstack sans serveur.

Image CDN

Chaque image dans un /public peut être servi via une fonction Netlify. Cela signifie qu’il est possible d’y accéder via un /.netlify/images chemin. Donc, sans ajouter pointu ou tout package d’optimisation d’image sur votre pile, déployant sur Netlifier nous permet de servir nos utilisateurs avec un meilleur format sans transformer les actifs au moment de la construction. Dans un Démarrage solideen quelques lignes de code, nous pourrions avoir un composant Image qui transforme d’autres formats en .webp.

import { type JSX } from "solid-js";

const SITE_URL = "https://example.com";

interface Props extends JSX.ImgHTMLAttributes<HTMLImageElement> {
  format?: "webp" | "jpeg" | "png" | "avif" | "preserve";
  quality?: number | "preserve";
}

const getQuality = (quality: Props["quality"]) => {
  if (quality === "preserve") return"";
  return `&q=${quality || "75"}`;
};

function getFormat(format: Props["format"]) {
  switch (format) {
    case "preserve":
      return"  ";
    case "jpeg":
      return `&fm=jpeg`;
    case "png":
      return `&fm=png`;
    case "avif":
      return `&fm=avif`;
    case "webp":
    default:
      return `&fm=webp`;
  }
}

export function Image(props: Props) {
  return (
    <img
      {...props}
      src={`${SITE_URL}/.netlify/images?url=/${props.src}${getFormat(
        props.format
      )}${getQuality(props.quality)}`}
    />
  );
}

Notez que le composant ci-dessus est encore légèrement plus complexe que l’essentiel car nous appliquons certaines optimisations par défaut. Notre getFormat méthode transforme les images en .webp par défaut. Il s’agit d’un format largement pris en charge, nettement plus petit que le plus courant et sans aucune perte de qualité. Notre get quality la fonction réduit la qualité de l’image à 75 % par défaut ; en règle générale, il n’y a aucune perte de qualité perceptible pour les grandes images tout en offrant une optimisation significative de la taille.

Mise en cache

Par défaut, la mise en cache Netlify est assez étendue pour vos artefacts habituels : à moins qu’il n’y ait un nouveau déploiement ou que le cache soit vidé manuellement, les ressources dureront 365 jours. Cependant, étant donné que les fonctions serveur/Edge sont de nature dynamique, il n’existe pas de mise en cache par défaut pour empêcher la diffusion de contenu obsolète aux utilisateurs finaux. Cela signifie que si vous disposez de l’une de ces fonctions en production, il est probable qu’il y ait une certaine mise en cache à exploiter pour réduire le temps de traitement (et les dépenses).

En ajoutant un en-tête de contrôle de cache, vous avez déjà effectué 80 % du travail d’optimisation de vos ressources pour mieux servir les utilisateurs. Quelques directives de contrôle de cache couramment utilisées :

{
  "cache-control": "public, max-age=0, stale-while-revalidate=86400"

}

• public: Stocker dans un cache partagé.
• max-age=0: la ressource est immédiatement obsolète.
• stale-while-revalidate=86400: si le cache est obsolète depuis moins d’un jour, renvoie la valeur mise en cache et revalidez-la en arrière-plan.

{
  "cache-control": "public, max-age=86400, must-revalidate"

}

• public: Stocker dans un cache partagé.
• max-age=86400: la ressource est fraîche pendant un jour.
• must-revalidate: si une requête arrive alors que la ressource est déjà périmée, le cache doit être revalidé avant qu’une réponse ne soit envoyée à l’utilisateur.

Note: Pour des informations plus détaillées sur les compositions possibles de Cache-Control directives, vérifiez les entrée mdn sur Cache-Control.

Le cache est un type de stockage clé/valeur. Ainsi, une fois que nos réponses sont définies avec un contrôle de cache approprié, les plates-formes disposent d’heuristiques pour définir ce que le key sera pour notre ressource dans le stockage du cache. La plateforme Web possède un deuxième en-tête très puissant qui peut dicter le comportement de notre cache.

Le Varier l’en-tête de réponse est composé d’une liste d’en-têtes qui affecteront la validité de la ressource (method et l’URL du point de terminaison sont toujours pris en compte ; pas besoin de les ajouter). Cet en-tête permet aux plates-formes de définir d’autres en-têtes définis par l’emplacement, la langue et d’autres modèles qui définiront la durée pendant laquelle une réponse peut être considérée comme fraîche.

Le Varier l’en-tête de réponse est un élément fondamental d’un en-tête spécial dans Primitive de mise en cache Netlify. Le Netlify-Vary prendra un ensemble d’instructions sur quelles parties de la demande une clé doit être basée. Il est possible de régler une clé de réponse non seulement par l’en-tête mais également par le valeur de l’en-tête.

• requête: varie en fonction de la valeur de certains ou de tous les paramètres de requête de requête.
• entête: varie selon la valeur d’un ou plusieurs en-têtes de requête.
• langue: varient selon les langues du Accept-Language entête.
• pays: varie selon le pays déduit d’une recherche GeoIP sur l’adresse IP de la demande.
• biscuit: varie selon la valeur d’une ou plusieurs clés de cookie de requête.

Cet en-tête offre un contrôle précis sur la façon dont vos ressources sont mises en cache. Autoriser certaines stratégies créatives pour optimiser les performances de votre application pour des utilisateurs spécifiques.

Stockage des objets blob

Il s’agit d’un magasin de clés/valeurs hautement disponible, idéal pour les lectures fréquentes et les écritures peu fréquentes. Ils sont automatiquement disponibles et provisionnés pour tout projet Netlify.

Il est possible d’écrire sur un blob à partir de votre environnement d’exécution ou de transmettre des données pour un magasin spécifique au déploiement. Par exemple, c’est ainsi qu’un Fonction d’action enregistrerait un certain nombre de aime en magasin avec SolidStart.

import { getStore } from "@netlify/blobs";
import { action } from "@solidjs/router";

export const upVote = action(async (formData: FormData) => {
  "use server";

  const postId = formData.get("id");
  const postVotes = formData.get("votes");

  if (typeof postId !== "string" || typeof postVotes !== "string") return;

  const store = getStore("posts");
  const voteSum = Number(postVotes) + 1)
    
  await store.set(postId, String(voteSum);

  console.log("done");
  return voteSum
  
});

Dernières pensées

Avec des primitives de haute qualité, nous pouvons permettre aux créateurs de bibliothèques et de frameworks de créer de fines couches d’intégration et des adaptateurs. De cette façon, au lieu de se concentrer sur le fonctionnement d’une plateforme spécifique, il sera possible de se concentrer sur l’expérience utilisateur réelle et des cas d’utilisation pratiques pour ces fonctionnalités. Les monolithes et les outils profondément intégrés ont du sens pour créer rapidement des plates-formes avec une forte dépendance vis-à-vis des fournisseurs, mais ce n’est pas ce dont la communauté a besoin. Parier sur la plateforme Web est une manière plus judicieuse et plus respectueuse de l’avenir.

Faites-moi savoir dans les commentaires ce que vous pensez des outils impartiaux par rapport aux configurations opiniâtres !

(je)