Stratégies et architectures front-end modernes

Transcript

1. Stratégies et architectures front-end modernes
2. Le front-end a une histoire longue et complexe dans le développement d’application
3. Durant longtemps, le travail à faire sur le browser était “suffisamment simple”
4. N’importe qui pouvait s’occuper de cela sans spécialisation quelconque
6. Beaucoup disait qu’un développeur, c’était simplement un graphiste travaillant sur un autre média
7. Une spécialisation en JavaScript ? Ridicule !
8. User Interface n.m. Quelque chose que l’on peut hacker et simplement faire fonctionner
9. Le JavaScript a changé la vision des gens à propos du front-end
10. Ce langage “jouet” que tout le monde ridiculisait est devenu une des forces qui régentent le web
11. L’apparition du cross-browser a apporté le besoin d’avoir des développeurs front-end
12. Aujourd’hui, les développeurs front-end sont dans les profils les plus recherchés au monde
13. Les deux UI layers
14. Malgré le “boom” de l’AJAX
16. Les front-ends ont toujours été vu comme ceux travaillant dans une fenêtre de browser
17. HTML, CSS, et JavaScript étaient leurs priorités principales
18. Ils ne touchaient que rarement au back-end, uniquement pour vérifier les outputs serveurs
19. Dans un sens, il y avait deux UI layers
20. Celui dans le browser lui-même
21. Et celui dans le serveur qui générait les données pour le browser
22. Les front-ends avaient peu de contrôle sur l’UI layer back-end
23. Et ils étaient redevables de l’ opinion des back-ends sur comment les choses devaient être faites
24. Une vision qui prenait rarement en considération les besoins front- ends
26. Dans une architecture d’ application web, l’UI layer du browser fut le seul domaine des front-ends
27. L’UI layer back-end était la place où les front-ends et les back-ends se rencontraient
28. Et le reste de l’architecture serveur fut là où les “tripes” de l’ application étaient
29. C’est là où se trouvaient le data- processing, le caching, l’ authentication
30. Et toutes les autres fonctionnalités critiques de l’application
31. Dans un sens, l’UI layer back-end (souvent à travers les templates) fut un léger layer dans l’ application serveur
32. Qui servait uniquement aux front- ends de couche intermédiaire à la business logic qu’ils utilisaient
33. Donc, le front-end était le browser
35. Et tout le reste était le back-end
37. Malgré le lieu de rencontre central entre les deux métiers, sur l’UI layer back-end
38. Ce fut assez proche de cela jusqu’ à 2011
39. L’arrivée de NodeJS
40. Quand NodeJS fut pour la première fois releasé
41. Cela a créé de l’enthousiasme chez les front-ends
42. Le même enthousiasme depuis que le terme AJAX fut déclaré
44. L’idée d’écrire du JavaScript sur le serveur (la place où, auparavant, ils étaient “obligés” d’aller)
45. Fut libératrice
47. Ils ne seraient plus contraints de faire avec le PHP, le Ruby, le Java, le Scala
48. Ou tout autre langage en plus de faire ce qu’ils devaient faire en front-end
49. Si le serveur pouvait être écrit en JavaScript
50. Alors le set complet de connaissances en langage serait limité à l’HTML, le CSS, et le JavaScript
51. Pour pouvoir délivrer une application complète
52. La promesse fut, et est toujours, très excitante
54. L’objectif derrière NodeJS n’a jamais été de tout remplacer sur le serveur en JavaScript
55. Même si en NodeJS il est possible de faire de puissantes applications
56. Cela n’en fait pas le choix pour toutes les situations
58. L’utilisation que les front-ends peuvent en faire c’est : libérer l’UI layer back-end du reste du back- end
60. Avec un grand nombre de compagnies allant vers le SOA et les interfaces RESTfuls
61. Il est maintenant faisable de séparer l’UI layer back-end dans son propre serveur
62. Si toute la business logic clé de l’ application est encapsulée dans des appels REST
63. Donc, tout ce dont les fronts-ends auraient besoin serait la capacité de faire des appels REST pour builder une application
64. Est-ce que les back-ends se préoccupent de comment les utilisateurs naviguent de page en page ?
65. Est-ce qu’ils se préoccupent de savoir si la navigation est faite en AJAX ou en full refresh ?
66. Est-ce qu’ils se préoccupent de savoir si les front-ends utilisent jQuery ou React ?
68. Ce pour quoi ils se préoccupent c’ est de comment la donnée est stockée, retournée, et manipulée
69. De façon sécuritaire et consistante
70. Et c’est ici que NodeJS donne aux front-ends un grand pouvoir
72. Les back-ends peuvent écrire leurs services REST dans n’ importe lequel des langages de leur choix
73. Les front-ends peuvent utiliser NodeJS pour créer l’UI layer back- end en pur JavaScript
74. Les front-ends peuvent fonctionner de la même manière qu’auparavant en faisant uniquement des appels REST
75. Le front-end et le back-end ont maintenant une parfaite séparation des concerns
76. Le front-end s’est étendu sur le serveur où l’UI layer NodeJS existe maintenant
77. Et où le reste du stack reste sous la responsabilité des back-ends
78. “Have no fear son.”
79. Cet empiètement du front-end dans ce qui était traditionnellement du back-end est effrayant pour certains
81. Beaucoup d’entre eux pensent encore que JavaScript n’est pas un vrai langage
82. Souvent, c’est à cause de cela que des organisations refusent d’ adopter NodeJS
83. L’UI layer back-end est un terrain contesté entre les front-ends et les back-ends
84. Il n’y a aucune raison pour que cela continue dans ce sens
85. Et surtout, uniquement par le fait que cela a toujours été ainsi
86. Encore aujourd’hui, dès que l’on entre sur le serveur, c’est la responsabilité des back-ends
87. C’est une guerre de territoire purement et simplement
89. Cela n’a plus de raison d’être ainsi
90. Séparer l’UI layer back-end de la business logic back-end fait beaucoup de sens dans une architecture large
91. Pourquoi les front-ends devraient se préoccuper du langage serveur nécessaire pour accomplir des fonctions business critiques ?
92. Pourquoi ce genre de décision fuite dans l’UI layer back-end ?
93. Les besoins front-ends sont fondamentalement différents de ceux back-ends
94. Si vous aspirez aux concepts d’ architecture comme le Single Responsibility Principle
95. La séparation des concerns
96. Et la modularité
97. Cela semble idiot que nous n’ ayons jamais effectué cette séparation auparavant
98. A part qu’auparavant, NodeJS n’ existait pas
99. Il n’y avait pas de bonne option pour les front-ends pour builder l’ UI layer back-end à leur manière
100. Si le back-end est en PHP, pourquoi ne pas utiliser du PHP templating ?
101. Si le back-end est en Java, pourquoi ne pas utiliser JSP ?
102. Il n’y avait pas de meilleur choix et les front-ends faisaient à contrecoeur car il n’y avait pas de réelle alternative
103. Maintenant, c’est le cas
104. NodeJS donne la possibilité aux front-ends de contrôler l’ensemble du UI layer
105. Ce qui leur permet de travailler de façon plus efficace
107. C’est leur métier de fournir une expérience front-end de qualité
108. Et cela leur est égal de savoir comment les back-ends process la donnée
109. Dites aux back-ends de fournir la donnée que les front-ends ont besoin, avec la business logic correspondante
110. Et les front-ends seront capables de concevoir de belles interfaces performantes et accessibles aux utilisateurs
111. Utiliser NodeJS pour l’UI layer back-end libère les back-ends d’ une liste de problématiques qui ne les concernent et intéressent pas
112. Le front-end et le back-end ne parlent ensemble qu’en données
113. Ce qui permet une itération rapide des deux domaines sans s’affecter tant que les interfaces RESTful restent intactes
114. L’isomorphisme et les Single Page Applications
115. Le JavaScript est maintenant un langage isomorphique
116. Cela veut dire que chaque ligne de code donnée (à quelques exceptions près) peut s’exécuter à la fois sur le client et le serveur
117. Le server-side rendering est optimal par exemple pour le SEO, le support d’anciens browsers, ou la perception utilisateur de la performance
118. L’isomorphisme s’accorde bien avec les Single Page Applications
119. Les Single Page Applications permettent des interactions clients riches et une navigation plus rapide
120. Donc, pourquoi ne pas utiliser les deux concepts ensemble ?
121. Tous les bénéfices de chaque et sans avoir de duplication de code
123. Du fait que l’isomorphisme englobe le client et le serveur, quel est son spectre ?
124. Avant
130. Il est difficile au début de discerner les composantes d’une architecture isomorphique
131. Du fait de l’environnement web, l’ HTTP a créé une division artificielle qui ne fait aucun sens entre le client et le serveur au niveau logique
132. On a toujours fait en sorte de dupliquer la logique sur le serveur car le browser était historiquement trop “instable”
133. Pas de support aux search engines et utilisateurs qui ne supportaient pas de JavaScript, limitations technologiques diverses
134. Le browser ne pouvait contenir toute la logique d’application
135. Du fait, la logique d’application est en partie sur le serveur, mais en développement d’application native, c’est un non-sens
136. En isomorphisme, du fait que le même codebase se retrouve partagé entre deux environnements
137. Cela prend du sens et ouvre de nouvelles perspectives
138. On conserve la performance du client, et la stabilité du serveur, pour le même objectif
139. Le client et le serveur ne sont plus que des APIs différentes, avec des comportements différents, qui partagent la même logique
140. Et la même architecture
141. React et Flux
142. Du fait de tout cela, le bon vieux pattern MVC ne fait plus de sens en isomorphisme
143. De nombreuses compagnies ont développé des frameworks ou librairies isomorphiques
144. React est une des librairies, développée par Facebook
145. On utilise React pour gérer la couche appelée View Layer
147. React est isomorphique, du fait qu’il utilise un Virtual DOM pour pouvoir builder des composants d’ interface
148. Ce Virtual DOM n’est simplement qu’une abstraction du DOM en JavaScript
149. Ce qui rend la possibilité de construire des composants DOM sur le serveur également
150. De plus, Facebook ont développé React Native qui reprend ce concept pour le développement d’ application native !
151. Cependant, React ne gère pas de router ou de logique d’application
152. C’est pour cela que Facebook a créé Flux
153. Flux est une architecture d’ application basée sur l’ unidirectionnal data-flow et le data-flow programming
155. Si un utilisateur interagit avec l’UI, une Action est créée dans un Action Creator
156. L’Action est ensuite envoyée au Dispatcher, qui est essentiellement un registre de callbacks
157. Le Dispatcher n’a pas d’ intelligence, mais il peut gérer des mises à jour synchrones
158. Si des callbacks sont inter- dépendants, il est capable de les lancer dans un ordre précis
159. Le Dispatcher peut être vu comme le hub de l’application
160. Le callback retourne l’Action aux Stores avec un Action Type
161. Les Stores sont le coeur de l’ application. Ce sont eux qui détiennent l’état de l’application
162. Ils communiquent avec les APIs pour demander les données nécessaires à l’application
163. Les Stores sont proches du Model dans un concept MVC
164. Ils s’enregistrent avec le Dispatcher en fournissant des callbacks
165. Chaque Store gère son propre domaine d’application
166. Du fait que le Dispatcher peut rendre les callbacks synchrones, les Stores peuvent attendre qu’un autre finisse avant de processer
167. Les Stores ont une sorte de switch statement sur l’Action Type
168. Quand les Stores ont fini de processer, un change event est broadcaster
169. En haut de la hiérarchie du View Layer, se trouvent des Controller- views qui handlent les change events
170. Ils peuvent récupérer les données qu’ils ont besoin via des méthodes publiques fournies par les Stores
171. Ensuite, les Views se self-render elle-mêmes à partir d’un seul objet de données
172. Il est possible d’avoir plusieurs Controller-views dans la hiérarchie, mais uniquement si nécessaire
173. Une Action peut être créée par un retour serveur autant que par une interaction utilisateur sur l’UI
175. Dans cette logique, les Stores communiquent avec les APIs et signent les contrats correspondants
176. Le modèle de données peut donc être plus ou aussi permissif que le contrat de l’API, selon les besoins de l’application
177. Dans le cas de l’isomorphisme, une requête HTTP peut initiée une Action, mais le flow reste le même
178. En somme, les front-ends n’ont jamais été à pleine capacité avant l’avènement de l’isomorphisme
179. Aujourd’hui, ils sont capables de fournir une UI robuste et performante, bâtie sur le même codebase, avec la même architecture
180. De plus, les back-ends seraient soulagés de la partie UI layer back-end
181. Et pour se focaliser sur leur vrai corps de métier
182. La communication entre les deux spécialisations serait simplement normalisée par les données
183. Chaque partie pourrait itérer sans attendre ou impacter l’autre
184. Merci !