• Composants: transformer le DOM avec la même simplicité que si on le recréait de zéro avec d'autres avantages:
  • Encapsulation
  • Réutilisabilité
  • Testabilité
• SPA
  • Répond aux besoins d'UX de plus en plus exigents
  • Relativement faciles à développer depuis l'apparition des frameworks à componsants
  • Crée des difficultés supplémentaires
    • Référencement
    • Accessibilité
    • Premier chargement lent
• Les difficultés des SPA peuvent être mitigées via le SSR

• Quel langage de programmation pour le backend?
• API
  • Qu'est-ce qu'une API?
  • REST
  • Underfetching, overfetching
  • GraphQL
• Persistence de données
  • ORM

Contrairement au front-end où le JavaScript est pratiquement imposé, le choix est plus libre pour le backend, qui peut être écrit en Python, PHP, etc.

Endpoint

https://pokeapi.co/api/v2/pokemon/pikachu

Method

GET

Endpoint

https://api.nasa.gov/planetary/apod?api_key=DEMO_KEY

Method

GET

Endpoint

https://api.chess.com/pub/player/hikaru

Method

GET

REST est un style d'architecture web

• Architecture client/serveur
• Sans état
• Avec mise en cache
• En couches
• Avec une interface uniforme

En pratique, une API REST associe des URLs à des ressources, et le verbe HTTP décrit comment la manipuler. Ce type d'architecture est performant (grâce à la mise en cache) et scalable.

Voici un exemple typique de requêtes et de leur effets.

GET /users/

Obtient la liste des utilisateurs

GET /users/1

Obtient les informations sur l'utilisateur 1

POST /users/

Crée un utilisateur avec le corps

POST /users/2

Modifie l'utilisateur 2 avec le corps

DELETE /users/1

Supprime l'utilisateur 1

• Underfetching
• Overfetching
• Il faut connaître les URL
• L'API doit être documentée
• DX

• Objectif: flexibilité pour obtenir les données en une requête
• Développé par Facebook (2015) pour répondre aux exigences de l'application mobile
• Un seul point d'entrée
• L'API peut être explorée sans documentation
• Meilleure DX

• Fichiers
• Base de données relationnelles
• NoSQL

Vous avez eu un cours sur cela au premier quadrimestre, nous nous contenterons seulement de discuter l'aspect pratique dans le cas du Web.

• Que faire si l'on change de serveur de base de données (e.g. MariaDB $\to$ Postgres)?
• Que faire pour éviter les erreurs de sécurité telles que les injections SQL
• Comment manier les données plus rapidement?
• Comment écrire du code réutilisable et plus maintenable pour manipuler les données?

• Pour simplifier, une classe par table
• Une instance correspond à une entrée en DB
• Les tables correspondent à des classes qui héritent d'une classe mère (Model). La classe contient au moins les informations propres à la table comme son nom et la clé primaire

• La classe mère Model implémente des méthodes pour générer et exécuter quelques requêtes SQL typiques comme au slide précédent.

Un thème clair du cours est de séparer l'application en morceaux composables. Ceci permet une grande réutilisation pour servir des clients aux besoins différents (navigateur, application mobile). Cela permet également une collaboration d'une équipe avec des bagages techniques différents.

• Modèle (ORM) pour manipuler les données
• Morceler l'UI en petits composants
• Utiliser une API pour séparer les données du rendu

On appelle cette idée la séparation des préoccupations (separation of concerns).

• Composants et composition
• MVC, MVVM, MVW
• Flux
• File-based routing (une URL, un fichier)
• etc.

• ERP
• Projet avec un coeur open source
• Écrit en Python/TypeScript
• Architecture très modulaire
• SPA
• Emploi de leur propre framework de composants (Owl)
• Emploi de leur propre ORM