Sommaire :

SOMMAIRE :....................................................................................................................................................... 2

TABLE DES FIGURES :........................................................................................................................................... 2

INTRODUCTION.................................................................................................................................................. 3

PROBLÉMATIQUE................................................................................................................................................ 3

CHAPITRE 1 : WEB L’EVOLUTION PERMANENTE................................................................................................... 4

1. Introduction......................................................................................................................................................4
2. Evolution Coté Client........................................................................................................................................4
Pour Résumer.............................................................................................................................................................5
L’Evolution..................................................................................................................................................................5
3. Evolution Coté Serveur.....................................................................................................................................5
4. Conclusion........................................................................................................................................................6
CHAPITRE 2 : CACHE............................................................................................................................................ 7
1. Introduction......................................................................................................................................................7
2. Cache coté Serveur...........................................................................................................................................7
Redis......................................................................................................................................................................7
MemCached..........................................................................................................................................................7
Varnish..................................................................................................................................................................8
3. Cache coté Client..............................................................................................................................................9
Cookies................................................................................................................................................................10
AppCache............................................................................................................................................................10
4. Conclusion......................................................................................................................................................10
CHAPITRE 3 : SERVICE WORKERS....................................................................................................................... 11
1. Introduction....................................................................................................................................................11
2. Principe...........................................................................................................................................................11
3. Utilité..............................................................................................................................................................12
4. Conclusion......................................................................................................................................................12
CONCLUSION.................................................................................................................................................... 14

Table des Figures :

Figure 1 : Evolution du Web 1.........................................................................................................................................4
Figure 2 : Architecture Client-Serveur.............................................................................................................................6
Figure 3 : Redis................................................................................................................................................................7
Figure 4 : MemCached....................................................................................................................................................8
Figure 5 : Varnish Cache..................................................................................................................................................9
Figure 6 : Représentation Cache Coté Client..................................................................................................................9
Figure 7 : Role Service Workers.....................................................................................................................................11

Introduction
L’évolution informatique a mené à la diversification de son application et l’apparition de
nouveaux obstacles. L’intérêt de cette recherche et d’éclaircir un point majeur de l’optimisation
et l’amélioration de logiciels, généralement, et d’applications Web spécifiquement.

Problématique
Le Monde d’internet est de plus en plus peuplé par des pages uniques d’application (Single page
Application) et de serveurs dynamiques. La nécessité d’une connexion permanente avec les
serveurs pour l’échange de données croit au jours le jour.

Cette dépendance limite les possibilités hors connexion ou lors d’une utilisation d’une
connexion instable. Cela génère de la frustration pour l’utilisateur face à une application non
réactive et un délai d’attente conséquent. Après des implémentations primaires comme
AppCache, nait un besoin nouveau.

Les « Services Workers » sont l’évolution des caches simples révolutionnant la notion de
création d’application web. Ils offrent la possibilité de simuler une connexion serveur, facilité la
charge serveur et garder l’application fonctionnelle de façon limités.

Quels est le parcours qui nous a mener au « Service Workers » ?

Quels Rôles peuvent il jouer dans les applications du futur ?

Chapitre 1 : Web L’Evolution Permanente

• Introduction 
wop8AB7.tmpoleObject0.bin

Figure 1  : Evolution du Web 1

L’image ci-dessus est une partie de l’évolution d’internet qui montre l’intérêt qui est attribuer à
son développement et son amélioration. La quantité de donnée échanger fait paraitre un
problème important qui est la raison même de notre étude.
 • Evolution Coté Client
Il existe de nombreux langage de programmation capable de fonctionner coté client.
Pour mieux nous situer Intéressons-nous plus précisément à Javascript à travers une foire aux
questions :
Q : Qu’est-ce que Javascript ?
R : JavaScript est un langage de programmation de scripts principalement employé
dans les pages web interactives mais aussi pour les serveurs avec l'utilisation (par
exemple) de Node.js.
Q : Quelle est le Rôle de JavaScript ?
R : Javascript est la source même de l’interactivité et du dynamisme du Web. JavaScript est
parfois considéré comme l'une des technologies cœur du World Wide Web. Le
langage JavaScript permet des pages web interactives, et à ce titre est une partie
essentielle des applications web.
Q : En quelle années a-t-il été développer ?
R : Tout a commencé en 1995, un groupe de développeurs de Netscape (Navigateur) décide de
se lancer dans l’innovation du web en le rendant plus dynamique.
Q : Quel été les piliers de son fondement ?
R : L’un des principaux objectifs de Javascript d’être accessible au maximum de profession de
l’informatique et non pas seulement aux développeurs les plus aguerri. Donc il été nécessaire
que Javascript (à l’époque s’appelant Mocha) d’être rapide et simple.
Pour Résumer
Javascript est, pour simplifier, un code qui s’exécute coté client pour offrir une nouvelle couche
de logique qui permettent d’offrir différente fonctionnalité au paravent difficile à envisager.
Exemple : animations, validation, réactivité…
L’Evolution
Les Scripts qui à l’époque s’exécuter pour fournir de simple animations et réactivité dans une
page web on exploser pour devenir des « plateformes ». 
Javascript est un langage qui de nos jours et la base de presque tous les « Framework » coté
client renommé : React, Angular et VueJs. D’où le choix d’en parler dans cette étude.
Ces mêmes « Framework » offre la possibilité d’interagir de façon plus dynamique avec le
serveur à travers des requêtes. La capacité de sauvegarder les données reçues par le serveur
soit en les affichants ou les sauvegardant en mémoire limite les capacités du client.

• Evolution Coté Serveur

Comme pour le coté client, le nombre de langage est abondant comme PHP, java, Python etc…
Le langage utilisé n’est pas important pour notre étude car ils partagent tous le même concept
d’un serveur web.
L’échange se résume ainsi :
L’idée d’un serveur web est d’interagir comme un fournisseur de pages.
Après une requête HTTP de l’utilisateur vers un serveurs web, le serveur renvoie des fichiers
demandés communément html, css et Js.
wopA295.tmpoleObject1.bin

Figure 2 : Architecture Client-Serveur

Le Serveur n’est pas concerné par l’identité du client et de sa disposition avec les fichiers envoyé
du a la nature des requêtes http.
Cela est clairement un default qui a donc nécessité l’implémentation de fichiers plus au moins
temporaire pour nous offrir une certaine traçabilité.
A la recherche d’un candidat, la majorité se tourne vers une base de données. Or la limite de
connexion, la vitesse et les risques de sécurité non font pas un candidat valide pour le besoin
mentionné.

• Conclusion
Le Besoin d’une zone abstraite où des fichiers temporaires ou permanant dépendant du besoin
d’échange soit facilement accessible pour le client comme pour le serveur.
La solution : Un Cache.

Chapitre 2 : Cache

• Introduction
La nécessité de contre carré la nature http pour offrir un éventail de possibilité a l’utilisateur
comme les sessions permanentes, la customisation du contenu, une meilleur expérience UI etc.
… est donc apparu avec le boom de l’utilisation du web.

• Cache coté Serveur

L’utilisation d’un cache coté serveur c’est diversifier dans sa nature : fichiers, base de données
ou même en mémoire. Chacune de ces solutions introduit des avantages et des inconvénients.
Intéressons-nous a certaine des technologies communément utilisées :
Redis
Redis, est une base de données clé-valeur en mémoire qui est réputée pour ces hautes
performances et une flexibilité unique. Redis est capable de gérer les structures de donnée tel
les maps et listes de de façon native et rapide. Ceci est un avantage considérable comparé aux
solutions traditionnelles.
MemCached ne se limite pas seulement au cache mais joue un rôle intéressons aussi dans les
wopA2C5.tmpoleObject2.bin
systèmes de file d’attente ou d’abonnement/publication.
Figure 3  : Redis
 MemCached
Très similaire a un Redis, MemCached est son prédécesseur.
MemCached ce focalise seulement sur les caches. A travers un système de « caching » en
mémoire distribuer de clé-valeur, en retrouve de hautes performances et une rapidité éclaire.
Le Cache préserve le résultat des requêtes et tout autre donnée qui nécessite un accès
redondant.
Ainsi L’application Web coté serveur peut conserver ces ressources pour des taches nouvelles
et plus importante. wopA2F5.tmpoleObject3.bin
Figure 4 : MemCached

Varnish
Contrairement aux autres caches mentionnés plus haut, Varnish a une utilité plus spécifique.
Varnish joue le rôle d’un cache proxy-inverse. L’idée de Varnish est d’offrir un cache sur un
hardware diffèrent qui lui communique avec le serveur.
Ce Cache devient un délégué pour les charges répétitives de la base de données. Ceci offre une
performance plus importante que les solutions traditionnelles.

Ils existent d’autre solutions, comme un fichier simple, ou même des caches en base de
données.
Il est important de choisir un dénouement qui offre une balance entre : cout, performances et
utilité.
wopA315.tmpoleObject4.bin

Figure 5  : Varnish Cache

• Cache coté Client

L’idée d’utiliser a cache coté client est en elle-même que la suite logique de la limite d’échange
d’informations du début du web et dans l’espoir d’améliorer les performances.
Ceci a été accompli à travers les navigateurs web standard tel Mozilla Firefox, Google Chrome,
Microsoft Edge etc… wopA326.tmpoleObject5.bin
Figure 6 : Représentation Cache Coté Client

Cookies
La première forme primitive d’informations conservé depuis le serveur coté client a été sous la
forme de petit fichier ne dépassant pas une taille de 300ko. Permettant de conserver des
informations personnalisées, le serveur récupérer ces fichiers pour customiser le traitement.
De nombreuses limitations tels le manque de sécurité (modifications par un tiers ou
l’utilisateur) et la limite de taille on encourager au développement de nouveau concept.
AppCache
L’échange constant d’informations a nécessité la sauvegarde de ressource au niveau locale mais
offrant une « api » de haut niveau, supporté par les navigateurs qui diminue le trafic entre le
client et le serveur. Ce système offre une utilisation hors connexion ou une amélioration des
performances. A chaque requête effectuer le serveur vérifie l’existence de la ressource au
niveau du cache et n’envoie une requête que si le besoin d’une mise à jour et spécifié ou la
ressource n’est pas trouver.
Malgré cette nouvelle fonctionnalité, l’AppCache est toujours limites par un manque de
flexibilité et une logique simple qui ne prend pas en considération les situations de connectivité
lente ou de signal faible.
• Conclusion
Le cache est né d’un besoin d’améliorée et réduire le temps d’attente. La nature du cache peut
paraitre à première vue simple et le problème au quelle il s’adresse résolut, or, les exigences de
perfectionnements poussent toujours au progrès.

Chapitre 3 : Service Workers

La situation binaire de l’AppCache fait apparaitre le besoin d’une solution nouvelle plus
maniable. Ici entre en jeu les Service Workers.
• Introduction
Les services Workers sont une suite a l’AppCache pour offrir de nouvelles options et une
expérience plus riche pour les applications coté client.
• Principe
wopA346.tmpoleObject6.bin

Figure 7  : Role Service Workers

Un service Workers est un script qui est déclencher hors de la page mais au service de cette
dernière. Base sur javascript, certaines limitations comme l’accès au DOM oblige l’utilisation de
l’interface postMessage.
Il est aussi fort important de noter que le cycle de vie d’un service Worker unique est à prendre
en considération lors de l’utilisation. Quand, il n’est pas utilisé le service Worker est arrêter et
est redémarrer on cas de nécessité. Cette situation contraint à ne pas utiliser des variables
globales dans l’espoir de les utiliser dans le futur.
Le cycle de vie commence à l’atterrissage sur une page web qui contient un script qui déclenche
l’installation du service Worker. Ce dernier peut soit échouer soit réussir. En cas de réussite, le
service Workers sera « prêt » et mis en attente pour son appel si besoin. Le service peut
recevoir des messages de la page web et réagir ou peut être de nouveau mis en attente ou
totalement arrêté.

Du la nature sensible des échanges et responsabilités, le protocole utilisé avec le service

Workers doivent être HTTPS.
Un service Worker est considérer comme une API hautement capable de fournir moultes
capacités et amélioration au web.
 • Utilité
Considérer les services Worker comme des caches serait une erreur car leurs rôles ne se limite
pas à seulement ça.
Les services Workers nous offrent la possibilité de :
• Gérer des requêtes et de les intercepter. A première vue cela peut paraitre simple
d’utilisation, mais celle-ci peut être vu comme un proxy inverse coté client.
• La nature asynchrone permet de garder une certaine rapidité et performances.
• Une expérience hors connexion qui simule a la perfection une connexion serveur.
• « Caching » de ressource
• Nature modulaire du service worker offre un développement et une utilisation moins
difficile de l’application web.
• « Pre-fetching » de ressource.
• Un système de notification push.
• Synchronisation des données cache même en absence de l’utilisateur.
(Sources :)
• Conclusion
Service Workers sont considérer comme la nouvelle forme de cache coté client qui porte au
développement web une nouvelle perspective de gestions de donnée et a offrir de nouvelle
fonctionnalités.

[1] «Javascript,» 28 1 2020. [En ligne]. Available: https://fr.wikipedia.org/wiki/JavaScript.

[2] «Angular,» [En ligne]. Available: https://fr.wikipedia.org/wiki/Angular. [Accès le 2 3 2020].
[3] «ReactJs,» [En ligne]. Available: https://reactjs.org/. [Accès le 2020].
[4] «Vuejs,» [En ligne]. Available: https://vuejsdevelopers.com/. [Accès le 2020].
[5] «Language Server,» [En ligne]. Available: https://fr.wikipedia.org/wiki/Langage_serveur.
[6] «Stateless Protocol,» [En ligne]. Available:
https://en.wikipedia.org/wiki/Stateless_protocol. [Accès le 2020].
[7] «Redis,» [En ligne]. Available: https://redis.io/. [Accès le 2 3 2020].
[8] «MemCached,» [En ligne]. Available: https://www.memcached.org/. [Accès le 2 3 2020].
[9] «Varnish,» [En ligne]. Available: https://varnish-cache.org/. [Accès le 2 3 2020].
[10] «HTTP Cookies,» [En ligne]. Available: https://developer.mozilla.org/en-
US/docs/Web/HTTP/Cookies. [Accès le 2 3 2020].
[11] «Utiliser appcache,» [En ligne]. Available:
 https://developer.mozilla.org/fr/docs/Web/HTML/Utiliser_Application_Cache. [Accès le 2 3
2020].
[12] «Service Worker API,» [En ligne]. Available: https://developer.mozilla.org/en-
US/docs/Web/API/Service_Worker_API. [Accès le 2 3 2020].
[13] «Using Service Workers,» [En ligne]. Available: https://developer.mozilla.org/en-
US/docs/Web/API/Service_Worker_API/Using_Service_Workers. [Accès le 2 3 2020].
[14] M. Gaunt, «Service Workers : An introduction,» [En ligne]. Available:
https://developers.google.com/web/fundamentals/primers/service-workers/. [Accès le 2 3
2020].

Conclusion
Après cette brève exploration de l’univers qui entourent les services Workers et une découverte
des plusieurs rôles du cache nous terminons notre étude sur la réalisation que les cache sont et
seront toujours une part entière de l’informatique dans tous ces domaines mais surtout dans le
web.
L’évolution des caches dépend fortement de leurs contextes et de leurs environnements. Malgré
cela il y a un effort collectif à améliorer l’expérience utilisateur.