Où s'exécute ton code — navigateur, serveur et applications mobiles

Cet article traite de l'endroit où s'exécute le code que tu écris.

Il y a trois endroits : dans le navigateur, dans le serveur, et dans l'application installée sur un téléphone.

Le code d'une application Web s'exécute à deux endroits : le navigateur et le serveur

Le logiciel qui lit le HTML sur l'appareil de l'utilisateur et dessine l'écran est le navigateur (browser), et un ordinateur préparé pour accepter des requêtes à tout moment est un serveur (server).

Les navigateurs les plus répandus sont Chrome, Safari, Edge et Firefox.

Le langage qu'un navigateur lit et exécute directement est JavaScript.

my-app est fait de quatre fichiers : les deux de l'écran forment le frontend, et server.js, qui reçoit les réservations, est le backend.

Quand un utilisateur ouvre l'URL, seuls les deux fichiers de l'écran arrivent sur l'appareil.

Même à l'intérieur des fichiers d'un seul my-app, l'endroit où ils s'exécutent se répartit entre deux cadres.

Seuls index.html et app.js arrivent sur l'appareil, et ensuite seules des données circulent entre les deux cadres.

Des trois lignes qui suivent, celle du milieu n'existe qu'à l'intérieur du navigateur, et la dernière qu'à l'intérieur de l'environnement d'exécution du serveur.

console.log("Réserver");
console.log(navigator.language);
console.log(process.version);

Si tu exécutes ces trois lignes dans le navigateur, les résultats se répartissent ainsi.

Le code d'une application Web se répartit entre deux endroits

index.html et app.js, qui construisent l'écran, arrivent sur l'appareil de l'utilisateur et s'exécutent dans le navigateur.

server.js, qui reçoit les réservations, ne sort pas du serveur public : c'est donc de ce côté que tu écris le texte que tu ne montres pas aux autres.

Pour rendre l'application utilisable sur téléphone, tu la gardes en application Web ou tu fais une application native

Les téléphones aussi ont un navigateur.

my-app fonctionne tel quel si tu ouvres l'URL dans le navigateur d'un téléphone.

C'est la première méthode, et il n'y a pas besoin de refaire le code.

Le logiciel qui gère, à l'intérieur d'un appareil, le lancement des applications, l'écran, les communications et les fichiers est l'OS (Operating System) ; sur un téléphone, c'est iOS ou Android.

La deuxième méthode est l'application native (native app : une application posée directement sur l'OS et exécutée là), que tu construis séparément pour iPhone et pour Android et que tu distribues par l'App Store et Google Play.

Poser une application sur un appareil pour qu'elle puisse être lancée depuis l'OS, c'est l'installation (install).

Comme le montre le schéma, une application native se pose sur l'OS, tandis qu'une application Web s'exécute sur le navigateur contenu dans cet OS.

Un programme ou un appareil qui envoie des requêtes à un serveur est appelé client ; on parle aussi de côté client pour ce qui s'exécute sur l'appareil, et de côté serveur pour ce qui s'exécute sur le serveur.

Le choix se fait en comparant les points forts et les points faibles.

Depuis un navigateur, tu n'as accès qu'aux fonctions que le navigateur fournit ; quand tu veux utiliser plus largement les fonctions de l'appareil, tu fais une application native.

C'est pareil quand tu veux que l'application soit trouvée par la recherche des boutiques ; si aucun des deux cas ne s'applique, tu la gardes en application Web.

Il existe aussi un moyen de construire, à partir d'un seul code source, des applications pour plusieurs OS, et son nom est traité dans le prochain article.

Quelle que soit la façon de la livrer, server.js reste commun

Si tu la gardes en application Web, il suffit d'ouvrir l'URL dans le navigateur d'un téléphone pour qu'elle fonctionne.

Une application native se construit séparément pour iPhone et pour Android et s'installe depuis une boutique, mais quel que soit ton choix, server.js et reserve.db restent posés sur le serveur public.

Ce qui change entre une application qui tourne sur ta machine et une application en ligne

Le my-app que tu as construit ne s'ouvre encore que depuis ton ordinateur.

L'intérieur de ton ordinateur, vu comme un endroit où exécuter du code, s'appelle le local.

Le numéro à la fin du http://localhost:3000 que tu ouvres en local sert à distinguer les destinataires à l'intérieur d'un même ordinateur, et il est traité dans l'article « Ce qui se passe quand tu entres une URL » de ce cours.

L'intérieur du cadre est ton ordinateur, une seule machine, et le navigateur, server.js et reserve.db s'y trouvent tous.

Une fois en ligne, le contenu de cette machine unique se répartit à deux endroits, mais les acteurs de chaque rôle ne changent pas.

Les noms des fichiers qui s'exécutent sont les mêmes en local et après la mise en ligne.

Déplacer les quatre fichiers ensemble vers un serveur public, hors de ton ordinateur, voilà ce qu'est le déploiement.

Les quatre fichiers passent sur le serveur public, et il ne reste sur ton ordinateur que le navigateur.

Depuis n'importe quel appareil, ouvrir le même example.com affiche le même écran.

Tant qu'elle reste en local, l'application n'accepte pas les requêtes venues de l'extérieur, donc les autres ne peuvent pas s'en servir depuis leur appareil.

localhost:3000 désigne l'appareil sur lequel tu l'as saisi, donc le saisir depuis le téléphone d'un collègue n'atteint pas ton ordinateur.

Ce que contient le travail de mise en ligne est traité dans l'article « Déploiement et variables d'environnement — de ce qui marche chez toi à la mise en ligne » de ce cours.

Change l'endroit où tu la poses, et tu changes qui peut l'utiliser

Le my-app que tu as fait tourner en suivant les étapes d'un livre pour débutants ne s'ouvre que depuis l'intérieur de ton ordinateur, c'est-à-dire en local.

Déplace les quatre fichiers vers un serveur public et les appareils des autres peuvent l'ouvrir aussi : ce travail, c'est le déploiement.