2. Les speakers
Salmen ESSRIDI
Architecte e-Commerce
www.linkedin.com/in/salmen-essridi/
Amine TLILI
Directeur Marketing & Développement
www.linkedin.com/in/aminetlili/
Surtout lui
3. Allez sur www.menti.com et utilisez le code 41 98 80
PARTICIPEZ À CETTE PRÉSENTATION
Tout au long de la présentation, nous allons poser
quelques questions auxquelles vous pouvez tous
répondre (sans authentification)
Les résultats apparaitront en live
4.
5.
6.
7.
8. DECADE
30
ans
110
collaborateurs
3
bureaux en
France et Tunisie
+10
ans dans
l’e-commerce
?
LE SPÉCIALISTE DES PROJETS DE COMMERCE EN LIGNE
Aider les commerçants à
1. concevoir
2. réaliser
3. et réussir
leur projet e-commerce
et donc … c’est quoi votre métier ?
12. Innovation technique
Toutes les innovations et les
pratiques modernes dans les
nouvelles technologies sont
intégrées dans l’e-commerce :
• Mobilité
• VR / AR
• IOT
• Big Data
…
Innovation business
• Scénarios cross canal
• Ventes privées
• Marketplace
…
E-commerce - un secteur d’innovation
Chez DECADE, nous préparons une
grande innovation business :
Nous proposerons au marché une
nouvelle vision et génération de
commerce en ligne dès 2019
13. Plan
Les enjeux d’une solution e-commerce
Difficultés de la mise en place d’une solution e-commerce
L’approche API first
L’approche API first dans une expérience e-commerce
24. #1 La faisabilité & flexibilité
Plus élémentaire …
c’est plus flexible
Difficultés de la mise en place d’une solution e-commerce
25. « Tinythe only thing you need to know
about software developpment, project
management, and leadership. »
Chad Fowler – CodeMesh 2014
Besoin d’architectures plus élémentaires
#1 La faisabilité & flexibilité
Difficultés de la mise en place d’une solution e-commerce
26. Dépendance entre les tâches !
#2 Productivité non optimale
Difficultés de la mise en place d’une solution e-commerce
27. Besoin d’architectures plus « parallélisables »
La loi de Brooks : « Ajouter des personnes à un projet
en retard accroît son retard »
Difficultés de la mise en place d’une solution e-commerce
#2 Productivité non optimale
28. Difficultés de la mise en place d’une solution e-commerce
#3 La reproduction des bugs
29. Besoin d’architectures plus déboggables
Difficultés de la mise en place d’une solution e-commerce
#3 La reproduction des bugs
30. #4 Analyse des causes de ralentissement lors des pics
Difficultés de la mise en place d’une solution e-commerce
31. Besoin d’architectures plus traçables « monitorables »
Difficultés de la mise en place d’une solution e-commerce
#4 Analyse des causes de ralentissement lors des pics
32. Besoin d’architectures plus testables
Difficultés de la mise en place d’une solution e-commerce.
#5 Assurer une testabilité maximale
33. Besoin d’architectures ouvertes à l’hétérogénéité
Difficultés de la mise en place d’une solution e-commerce.
#6 Réalisation de fonctionnalités cross-devices
34. Compatibilité
Besoin d’« architecturer » le monde JS
Difficultés de la mise en place d’une solution e-commerce.
#7 Code coté-client difficile à maintenir
43. #3 L’API moderne - Architecture REST
Roy T. Fielding
Thèse en 2000 :
➢ Architectural Styles and
the Design of Network-based Software
Architectures
➢https://www.ics.uci.edu/~fielding/pubs/diss
ertation/top.htm
L’approche API first
60. Allez sur www.menti.com et utilisez le code 41 98 80
PARTICIPEZ À CETTE PRÉSENTATION
QUELQUES QUESTIONS DE
CONSOLIDATION
61.
62. Réponse
Quelle est la signature API pour récupérer les informations d’un client par un id ?
La signature la plus correcte est :
GET : /Api/Rest/Customers/{Id}
63.
64. Réponse
La signature API pour récupérer les produits ayants un attribut couleur « red » ?
GET : /Api/Rest/Catalog/Products/Color/red
65.
66. Réponse
La réponse http d’une tentative de lecture des informations magasin par un id non valide doit être ?
GET : /Api/Rest/Shops/{id_non_valide}
HTTP 400
67.
68. Réponse
La réponse http d’une tentative de lecture des informations magasin par un id valide mais non trouvé
? GET : /Api/Rest/Shops/{id_valide}
HTTP 404
69.
70. Réponse
On veut modifier la quantité d’un produit dans le panier quelles sont les signatures les plus
intéressantes ?
La signature la plus pertinente est :
PUT ( {pid : 123, qty : 2}) /Webusers/{id}/Cart
en récupérant les détails du panier en réponse
Car elle évite de faire deux appels HTTP
71.
72. Réponse
On veut supprimer la quantité d’un produit du panier quelles sont les signatures les plus
intéressantes ?
La signature la plus pertinente est :
PUT ({pid : 123, action : delete }) /Webusers/{id}/Cart
en récupérant les détails du panier en réponse
Car elle évite de faire deux appels HTTP
73.
74. Réponse
Comment gérer une session utilisateur face au « Stateless » ?
La bonne solution est de conserver le contexte
côté client
75.
76. Réponse
Y-a-t-il des impacts sur la performance à cause de la non utilisation de session ?
Oui, on risque de stresser les autres sources de
données comme la base de données si on se prive
de la session
77.
78. Réponse
Des solutions pour soulager le serveur de plusieurs appels ?
Activer la mise cache chez le consommateur
81. Plusieurs visions … laquelle est juste?
La conception des API est un art
Les contraintes de la mise en place d’une API REST
#1 Conception / Design
82. « Stateless » ( pas de conservation d’état )
un protocole sans état (en anglais stateless protocol) est un protocole de
communication qui n'enregistre pas l'état d'une session de communication
entre deux requêtes successives. La communication est formée de
paires requête-réponse indépendantes et chaque paire requête-réponse
est traitée comme une transaction indépendante, sans lien avec les
requêtes précédente ou suivante.
Wikipedia
Les contraintes de la mise en place d’une API REST
#2 Respecter le principe du « Stateless »
83. Comment gérer une session utilisateur face au « Stateless » ?
Les contraintes de la mise en place d’une API REST
#2 Respecter le principe du « Stateless »
84. Et les impacts sur la performance liés à la non utilisation de session ?
Session = Cache par client
Les contraintes de la mise en place d’une API REST
#2 Respecter le principe du « Stateless »
85. Beaucoup d’API, est-ce que ça ne fait pas beaucoup de va-et-vient ?
/! Charge sur le serveur
Les contraintes de la mise en place d’une API REST
#3 Charges importantes sur le serveur
86. Utiliser un cache client-side
Les contraintes de la mise en place d’une API REST
#3 Charges importantes sur le serveur
Des solutions ?
88. Plus élémentaires … plus d’expériences
Les bénéfices de la mise en place d’une API REST
#1 API élémentaire = plus de faisabilité
89. #2 Documentations / outils / standards
Les bénéfices de la mise en place d’une API REST
90. #3 Une meilleure productivité
Les bénéfices de la mise en place d’une API REST
91. #3 Une meilleure productivité
Les bénéfices de la mise en place d’une API REST
92. Plus « débogabilité »
#4 Rapidité d’identification des problèmes
Les bénéfices de la mise en place d’une API REST
93. Plus « monitorable »
#5 Monitoring plus fin
Les bénéfices de la mise en place d’une API REST
94. Plus testableOutil : OctoPerf
#6 Facilité des tests
Les bénéfices de la mise en place d’une API REST
95. Ouverte à l’hétérogénéité
#7 Architecture ouverte
Les bénéfices de la mise en place d’une API REST
96. Grâce aux Frameworks JS & évolution des standards JS
#8 Un monde bien modélisé client-side
Les bénéfices de la mise en place d’une API REST
97. Code côté client sur des bases PO & sur des principes de composition
#8 Un monde bien modélisé client-side
Les bénéfices de la mise en place d’une API REST