Comment imaginer et implémenter une plateforme (au sens Apple Store) from-scratch au sein d'un groupe média ? Quelle philosophie ? Quels principes ? Quelle architecture choisir ? Comment assurer la scalabilité des développements interne comme externe ? Nous aborderons aussi le tournant numérique du groupe par cette plateforme ouverte. Le développement d'un écosystème avec nos partenaires et filiales basé sur des contrats json-schema/open-api et les conséquences sur diverses dimensions.

1. Une plateforme moderne pour le groupe
SIPA/Ouest-France 🚀

2. François-Guillaume Ribreau
@FGRibreau
—
Architect & Head of development @Ouest-France (10 months 🎂)
—
🌟 Founded @Redsmin @ImageCharts @MailPopin
—
🚀 Trainer @EPSI_Nantes @UnivNantes
—
Ex-Bringr cofounder & CTO
Ex-Architect @iAdvize

3. I am quite convinced that in fact computing will become a
very important science. (🐶💩)
But at the moment we are in a very primitive state of
development; we don't know the basic principles yet
and we must learn them first.
If universities spend their time teaching the state of the
art, they will not discover these principles and that,
surely, is what academics should be doing.
— Christopher Strachey, 1969 (49 yrs ago)
(quote by Edsger W. Dijkstra)
https://bit.ly/2pMI7aJ
“
”

4. DONC(la slide suivante est la plus importante du talk 😉)

5. Deux principes
fondamentaux
—
Separation of Concerns
Single Source of Truth

6. Separation of Concerns
a-k-a "la séparation d'intérêt"
Tout organiser en terme de rôle, de responsabilité.
Chaque rôle résout un problème
"Quel est le rôle — la responsabilité —
de chaque chose ?"

7. ... des valeurs,
aux fonctions,
aux types,
aux modules,
à l'organisation du projet,
aux (micro)services,
aux clusters
aux datacenters, ...
corollaire : divide & conquer, OSI model, HTML/
CSS/JS, n-tier, ui components, (micro)services, ...

8. Single Source of Truth
a-k-a "unique source de vérité"
Une seule source de vérité,
une seule source d'état.
Tout part de la source de vérité,
ensuite nous en exposons des représentations
corollaire : event-sourcing / vue matérialisée,
master/slave, 3NF/FNBC, référentiels, ...

9. (EXEMPLE(avec des technologies et approches trendy 🤩)

10. Il n'y a pas si longtemps...
Une app
- portait sa configuration
(e.g. fichier)
- savait où envoyer ses logs
(e.g. socket, fichier)
- etc...
app.

11. Orchestrateur
L'orchestrateur :
- gère et injecte la configuration des
apps (SoC, SSOT)
- récupère les logs de stderr & stdout
de toutes les apps (SoC, SSoT)
L'application :
- récupère sa config via var. env. (SoC)
- log sur stderr / stdout (SoC)
app.
orchestrator
cluster-wide-logging
conf.

12. Au delà de l'orchestration...

13. Service Mesh
L'application délègue le paramétrage de:
- rate-limiting (SoC)
- l'access control (SoC)
- request-retries (SoC)
- etc...
Le service mesh standardise (de manière
agnostique), centralise, la gestion :
- rate-limiting (SSoT)
- l'access-control (SSoT)
- request-retries (SoC, SSoT)
app.
orchestrator
service-mesh

14. )

15. Avant de parler plateforme,
parlons CMS

16. des sites internets dans le monde
(60% des CMS installés)
27%
https://bit.ly/29KsVqn

17. Initialement une plateforme de blogging

18. Extensibilité via des plugins
Personnalisation via des thèmes

20. ------------
--------------
—
Separation of Concerns
Single Source of Truth

21. 1 BDD pour tout
(technique + fonctionnel)
(content + plugins + ...)
1 instance pour tout
(e.g. code, /upload, ...)
1 base de code pour tout
(technique + fonctionnel)
Approche monolithique

22. des sites internets dans le monde1%

23. Tentative de découplage
entre technique et fonctionnel
(node & modules)

24. Approche par module,
indépendants, juxtaposables, et combinables
possible dépendances inter-module

25. Node (structure & données),
module (traitement),
thème (présentation)

26. ------------
--------------
—
Separation of Concerns
Single Source of Truth

27. modulemodulemodulenode
modulemodulemodulemodule
presentation
1 BDD pour tout
(technique + fonctionnel)
(nodes + modules + ...)
1 instance pour tout (e.g. code, fs, ...)
~ 1 base de code pour tout
(technique + fonctionnel)
Approche monolithique, chaque module
à la connaissance d'où il se hook
(caché dans le code, non statique)
presentation
traitement

28. Autres CMS...
BDD monolithique,
codebase ~monolithique,
respecte SSoT
mais pas SoC jusqu'à un certain point...

29. Et c'est toujours la même histoire.

30. Mise en place d'un
CMS
monolithique

31. Evolutions par
petite touche...
🤩

32. Accumulation progressive de dette
(e.g. règles métiers implicites dans le code)

33. Jusqu'au point où les évolutions sont trop coûteuses 😫

34. Refonte. 💸 💸

35. Et en (micro)service ?
En headless CMS ?
En Content-API ?
(#spoiler nous allons y revenir 😉)

36. Historique des sites internets

37. www.ouest-france.fr
All-in-one
1998-2008
(Galaad, Prism)
❌ 1 codebase (❌ SoC)
✅ 1 database
✅ 1 back-office
❌ 1 release lifecycle
❌ 1 bug domain
Monolithe
de plus en plus difficile à
maintenir dans le temps.
Refonte. 💸

38. "L'effet balancier"

39. www.ouest-france.fr
EntrepriseEtudiant
...
...
Satellite network
2008-2017
(Drupal & Wordpress)
✅ N codebase (per website, (~ SoC))
❌ N database (SSoT)
❌ N back-office
✅ 1 release lifecycle
✅ 1 bug domain
Monolithes séparés
Facile de créer un nouveau site
Silos de données
Difficile de maintenir
une cohérence globale
(e.g. SSO, design (headers))
Refonte. 💸

40. 2017.
Refonte. 🚀

41. Refonte 2017 🚀
- (Ré)intégrer les différents sites et services
du groupe au sein d'une même plateforme
- Mise en place SSO, etc...
- Intégrer des partenaires externes
- Assurer une cohérence graphique (e.g. header)

42. All-in-one
1998-2008
(Galaad, Prism)
www.ouest-france.fr
www.ouest-france.fr
Entreprise
Etudiant
...
...
Satellite network
2008-2017
(Drupal & Wordpress)
Refonte 2017 🚀
?

43. All-in-one
1998-2008
(Galaad, Prism)
www.ouest-france.fr
www.ouest-france.fr
Entreprise
Etudiant
...
...
Satellite network
2008-2017
(Drupal & Wordpress)
Refonte 2017 🚀
Platform

44. All-in-one
1998-2008
(Galaad, Prism)
www.ouest-france.fr
www.ouest-france.fr
Entreprise
Etudiant
...
...
Satellite network
2008-2017
(Drupal & Wordpress)
Refonte 2017 🚀
Platform

45. Headless CMS
Content
API
Front
Widget
API
IAM ...
PartnersEditorial
Back-Office
Job done right?

46. ------------
--------------
—
Separation of Concerns
Single Source of Truth

47. Headless CMS
Content
API
Front
Widget
API
IAM
...
API
PartnersEditorial
Back-Office
Job done right?
ArticleDetail tmpl Widget1 tmpl Widget2 tmpl ... tmpl
porte
tous
les
tem
plates
(org.)
Non
indépendance
de l'équipe
Editorial
dev. pour chaque
partenaire à intégrer.
mélange des intégrations.
Bottleneck
❌
release-cycle
~indépendant
❌
évolutions
fonctionnelles
indépendantes
SoC
SSoT
SoC

48. Retour aux sources

49. Atomic design ⚛
Atoms, molecules, organisms, templates, and pages
Templates
Pages
Organisms
Molecules
Atoms
"atoms are the smallest functional unit"
SoC SSoT

50. Atomic design ⚛
Atoms, molecules, organisms, templates, and pages

51. Header
Trending
Breadcrumb
ArticleList
Weather
Funeral
Atomic design ⚛
Atoms, molecules, organisms, templates, and pages

52. “Pourquoi vous faut-il tant de temps pour mettre à jour les headers ?”
Header == un seul et unique composant ?
Un seul block ?

53. La cohérence est une conséquence de SSoT
Block configurable (e.g. theme) => cohérence

54. Block Header intégré au code-source du CMS ?
Et si ce block était indépendant du CMS ?
Gérer, administré en autonomie par une équipe ?

55. Naissance du concept de CMS Agnostic 🎉
Agnostic
CMS
“Pour qu'un CMS soit agnostique,
le fonctionnel métier doit vivre en dehors”
block(fonctionnel)
block(fonctionnel)
block(fonctionnel)
block
(fonctionnel)
block
(fonctionnel)
block
(fonctionnel)

56. CMS
Product Team
Agnostic
CMS
Back-office
Editorial
Product Team
Header
(API)
Footer
(API)
ArticleList
(API)
ArticleDetail
(API)
Chaque block serait donc une API ?
✅ cycle de dev ~indépendant
✅ domaine de bug ~indépendant
❌ aucune garantie sur la consistence des API
❌ une API —par définition— ne porte pas ses templates (présentation)
❌ aucune garantie sur la cohérence graphique globale
❌ le CMS doit avoir la connaissance de chacune des APIs (SoC)
❌ le Back-office doit avoir la connaissance de chacune des APIs (SoC)
❌ n'explique pas comment scale les développements interne / externe
❌ security & privacy by design ?
Partner 2
Funerals
(API)
Partner 1
Weather
(API)
Partner X
...
(API)
Partner X
...
(API)
Partner X
...
(API)
#inverseConwayLaw #(micro)services #containers #kubernetes

57. Utilisons des conventions !
Comment garantir des API consistantes ?

59. API HTTP/REST
Contract
Il nous faut un contrat 📜 pour chaque Block qui défini :
- (meta) son nom, sa version
- (configuration) comment le paramétrer
- (view) ses thèmes (templates + assets)
- (state) comment appeler le composant
- (et plus encore...)
Garantir des API consistantes ?
Header

60. Un service qui fourni 1...N Block(s) au CMS
Agnostique est un BlockProvider
API BlockProvider
Contract
Header
Block
Agnostic
CMS
http/json low-barrier entry
BlockProvider register
& configuration

61. (internal team)
production env.
(external team)
prod. env.
(partner team)
prod. env.
(partner team)
prod. env.
Navigation
BlockProvider
Editorial
BlockProvider
Weather
BlockProvider
Funeral
BlockProvider
Agnostic
CMS
BlockProvider register
& configuration
Header
Trending
Breadcrumb
ArticleList
Weather
Funeral
...
BlockProvider
...
BlockProvider
...
BlockProvider
Back-Office
(RIA/SPA)
Admin.API
Presentation

62. Platform = Eat your own dog food

63. Le schéma du BlockProvider
est décrit en json-schema
API BlockProvider
Contract
Header
Block

64. ... permet de générer un validator-cli #rust
API BlockProvider
Contract
Header
Block
validator-cli
CMS
Agnostic
schemasSSoT
SoC

65. ... permet de générer la documentation
#WiP /
https://github.com/FGRibreau/json-schema-
documentation
SSoT

66. sans oublier le block-runner
exécution d'un BlockProvider en local/CI
SoC #WiP /
BlockProviderConfig
Schem
a
SSoT

67. Première traction (et autonomie)
en interne et à l'externe 🎉

68. Partner 1
Chaque Block est exposé via un API BlockProvider
✅ cycle de dev indépendant
✅ domaine de bug indépendant
✅ garantie sur la consistence des API
✅ le BlockProvider par définition porte sa présentation
❌ aucune garantie sur la cohérence graphique globale
✅ quand le CMS sait gérer 1 BlockProvider il sait tous les gérer
❌ le Back-office doit avoir la connaissance de chacune des APIs
(SoC)
✅ un BlockProvider est identique, qu'il soit développé en interne
ou en externe, modèle scalable
❌ security & privacy by design ?Météo
BlockProvider
CMS Team
Agnostic
CMS
Back-office
Editorial Team
Header
(BlockProvider)
Footer
(BlockProvider)
ArticleList
(BlockProvider)
ArticleDetail
(BlockProvider)Partner 2
Funerals
(BlockProvider)
Partner 1
Weather
(BlockProvider)
Partner X
...
(API)
Partner X
...
(API)
Partner X
...
(BlockProvider)

69. Comment rendre l'administration des Blocks scalable ?

70. Administration des Blocks scalable = json-schema + ui-schema => GUI
https://github.com/mozilla-services/react-jsonschema-form
✅ Configuration (technique) : OpenAPI (ex. swagger)
✅ Configuration (fonctionnel) : ui-schema
✅ Contrôle complet par l'équipe en charge du BlockProvider
SSoT
Le Back-office a uniquement la connaissance de
comment afficher le ui-schema de chaque Block provenant
des BlockProviders (BlockProviderConfig schema)
oC

71. Comment garantir la cohérence graphique?
Impossible de passer à l'échelle
sans guidelines (design system)
https://github.com/ouest-france/sipaui
#html
#mustache
#view
SoC

72. Comment (proposer un premier niveau pour) garantir
la sécurité 🔑 et la vie privée 1 ?
Etape de validation (auto + manuel) la soumission d'un Block :
- (auto) enregistrement des assets dans notre CDN
- (auto) validation des performances
- (manuel) inspection des templates (suivi des guidelines)
- (manuel) inspection des JS/CSS pour usage
dangereux (inclusion de JS externes, appel externes
etc..) & fuite donnée
SSoT

73. CMS Team Editorial Team
Navigation
BlockProvider
Editorial
BlockProvider
Chaque block
est un BlockProvider
✅ cycle de dev indépendant
✅ domaine de bug indépendant
✅ garantie sur la consistence des BlockProviders (json-schema)
✅ le BlockProvider par définition porte ses templates (présentation)
✅ garantie sur la cohérence graphique globale (guidelines + validation)
✅ quand le CMS sait gérer 1 BlockProvider il sait tous les gérer
✅ le Back-office n'a que la connaissance du contrat d'un
BlockProvider
✅ un BlockProvider est identique, qu'il soit développé en interne ou
externe, modèle scalable
✅ security & privacy by design
Agnostic
CMS
Back-office
Partner 1
Météo
BlockProvider
Partner 2
Funerals
(BlockProvider)
Partner 1
Weather
(BlockProvider)
Partner X
...
(API)
Partner X
...
(API)
Partner X
...
(BlockProvider)

74. QoS
Progressive degradation
Static rules engine
Routing engine
ACL
Auditability
PageLayout
ConfigMap
Caching techniques
BlockProvider Testability
Monitoring
Smoke-tests
Versioning
Authorization
Block reusability
Scalability
SSoT SoC
Et d'autres choix guidés par SSoT & SoC
Static Graph Resolution
Performance
(e.g. referential transparency)
To be continued...

75. Free plans for Redis
administration & monitoring
at redsmin.com
We are looking for Front-end Developers
twitter.com/iadvizetech
Questions?
@FGRibreau
No more server-side rendering pain,
1 url = 1 chart
image-charts.com