Conception BDD/API

[JMazat]

Contexte

Lié au ticket #24.

Séparé pour clarté/suivi.

[JMazat]

Document de conception "Server side"

Révision 1 du 9/10. Partie 1 pour validation.

Besoins

Stocker des données évolutives / en flux. Le site étant spécifié comme API first, stocker les données d'interface (statiques, multi-composant) à obtenir.

Pages concernées :

• Présentation (statique)
• Actualités (flux)
• Combats (évolutif)
• Encyclopédie (évolutif)
• Historique (statique)

Doit être évolutif pour accepter de nouvelles ressources / la boutique.

Doit être le plus simple possible car toute l'équipe devra la manipuler.

Ressources

about

Page "Présentation"

• Image
• Paragraphes

news

Page "Actualités".

news/summary

• Titre
• Résumé court
• Date

news/full

• Titre
• Paragraphes
• Date
• Image (facultatif)
• Auteur

fight

Page "Nos combats"

fight/summary

• Titre
• Résumé court

fight/full

• Titre
• Référent
• Paragraphe
• Image (facultatif)

encyclopedia

Page "Encyclopédie"

• Nom
• Espèce
• Taille min
• Taille max
• Poids
• Description
• Habitat
• Pays (liste)
• Sources
• Annecdotes

history

Page "Historique"

• Titre
• Paragraphe
• Image (facultatif)

image

• Image PNG/JPG
• Légende
• Alt (pour HTML)

person

• Nom
• Prénom
• Email
• Genre
• Tel (factultatif) 

country

• Nom
• Image (drapeau)

BDD

[JMazat]

A noter

• Pour rappel : agrégat (diamant vide) = au moins 0, composition (diamant plein) = au moins 1
• Pas de cardinalité indiquées car tout sera *..* (cf. note en haut à gauche)

Il faudrait valider l'UML avant que je spécifie l'API. Merci.

[LeVraiPicou]

je suis plus chaud de se reférrer aux cardinalités pour les tables d'agrégation, et je suis pas trop d'accord avec la table paragraphe, peut être que faudrait qu'on en parle j'ai peut être pas 100% saisi l'intêret

[JMazat]

• Pour les cardinalités : d'accord, c'était juste une proposition pour être plus flexible (on connait pas vraiment le contenu définitif du site)
• Pour la table PARAGRAPH : c'est simplement pour pouvoir dissocier les paragraphes et être libre sur le style du site (en mode on a plusieurs paragraphes, et on peut les mettre à la suite, dans des div séparées, mettre des images au milieu, etc.)

[LeVraiPicou]

pourquoi ne pas ajouter le champs content ou description sur les tables nécessaire ?

[LeVraiPicou]

et pour les cardinalités ça peu être voter stv on sait jamais des gens sont chaud

[JMazat]

pourquoi ne pas ajouter le champs content ou description sur les tables nécessaire ?

Comme ca on peut disposer les paragraphes comme on veut sans par exemple parser les fins de lignes.

Imagine qu'on veut séparer les paragraphes par un peu d'espace histoire que ce soit mieux à lire, c'est mieux d'avoir plusieurs lignes dans la BDD plutot que traiter les fins de lignes coté site par exemple.

[JMazat]

Document de conception "Server side"

Révision 1 du 11/10.

Besoins

Stocker des données évolutives / en flux. Le site étant spécifié comme API first, stocker les données d'interface (statiques, multi-composant) à obtenir.

Pages concernées :

• Présentation (statique)
• Actualités (flux)
• Combats (évolutif)
• Encyclopédie (évolutif)
• Historique (statique)

Doit être évolutif pour accepter de nouvelles ressources / la boutique.

Doit être le plus simple possible car toute l'équipe devra la manipuler.

Ressources

about

Page "Présentation"

• Image
• Paragraphes

news

Page "Actualités".

news/summary

• Titre
• Résumé court
• Date

news/full

• Titre
• Paragraphes
• Date
• Image (facultatif)
• Auteur

fight

Page "Nos combats"

fight/summary

• Titre
• Résumé court

fight/full

• Titre
• Référent
• Paragraphe
• Image (facultatif)

encyclopedia

Page "Encyclopédie"

• Nom
• Espèce
• Taille min
• Taille max
• Poids
• Description
• Habitat
• Pays (liste)
• Sources
• Annecdotes
• Image

history

Page "Historique"

• Titre
• Paragraphe
• Image (facultatif)

image

• Image PNG/JPG
• Légende
• Alt (pour HTML)

person

• Nom
• Prénom
• Email
• Genre
• Tel (factultatif) 

country

• Nom
• Image (drapeau)

BDD

API

API REST. Application en ExpressJS, corps et réponses en JSON. Fais le lien entre le site et la BDD

En lecture seule. La création/modification des données se fera directement avec la BDD.

Pas de gestion des droits d'accès mais il faudra une protection anti-DDOS.

Pas d'over-fetching : les ressources sont séparées, les réponses auront des ID (clefs primaires) qu'il faudra récupérer ailleurs.

Evolutions post-MVP

• Données de la boutique (à spécifier).
• Support HTTPS

[LeVraiPicou]

ça me va de toute façon on verra les evols nécessaires au moment voulu