Avant que l'IA générative ne remplisse notre monde de textes volumineux, les humains s'appuyaient sur des notes laconiques et grammaticalement indifférentes pour aider les autres (et eux-mêmes) à naviguer dans le vaste océan du développement logiciel. Voici ce que j’ai jugé essentiel à propos d’Ember, tiré d’une note exhumée il y a des années :

• ember-data est une couche de persistance de type ORM qu'Ember utilise par défaut. Il utilise des modèles, des adaptateurs, des sérialiseurs et un magasin comme concepts fondamentaux. Lorsqu'une API n'est pas adaptée aux données Ember, il est possible d'utiliser un point de terminaison REST ad hoc ou un point de terminaison de style RPC.
• Le magasin renvoie des ressources enveloppées dans des « objets de promesse ». Ces proxys permettent aux ressources d'être chargées paresseusement et déclenchent des récupérations lors de l'accès à une relation qui n'est pas chargée. Faire cela en boucle est ce qui provoque N 1 requêtes.
• Les modèles Ember utilisent la liaison de données pour restituer automatiquement des parties du DOM lorsque le modèle de support change.
• Les applications Ember sont des « applications à page unique ». Le serveur Web renvoie une page HTML statique pour toutes les requêtes entrantes et une fois le JavaScript chargé, la requête est acheminée via les composants Ember qui effectuent des appels API vers l'un de nos innombrables microservices.
• Les composants sont l'abstraction de l'interface utilisateur fournie par Ember, qui combinent un modèle et un fichier JavaScript. Ember fournit également un conteneur d'injection de dépendances, des services (singletons gérés par le conteneur), des routes, etc.