Front/Back : un piège pour les non-initiés
Attention au piège ! On peut parler de développement front-end ou back-end en évoquant la technologie respectivement sur le navigateur ou sur le serveur web. Mais on peut aussi parler de front-office ou de back-office. Et, dans ce cas, on distingue les populations d’utilisateurs : le front-office adressant les visiteurs d’un site et le backoffice les gestionnaires.
Quelle est la différence entre un framework et une librairie ?
Un framework n’est pas une librairie ! Si l’amalgame est assez facile à faire entre ces deux termes, c’est tout simplement parce que dans la plupart des cas, un framework inclut une
ou plusieurs librairies.
Ainsi, si une librairie peut être comparée à un ensemble de fonctionnalités, un framework quant à lui peut être perçu comme la structure complète d’un projet ! Ainsi le développeur va appeler une librairie pour disposer de fonctionnalités particulières. Par exemple, notre librairie Open Source Gotenberg permet de transformer n’importe quelle page HTML en document PDF.
Inversement, un framework va permettre de structurer le code pour le développeur en gérant de nombreux aspects tels que la sécurité par exemple. La différence entre un framework et une librairie est donc appelée « Inversion of Control (IOC) » ce qui signifie de manière concrète qu’un framework « contrôle » le code d’un développeur alors qu’une librairie est «contrôlée » par le code d’un développeur.
Parmi les frameworks les plus connus on retrouve : Symfony ou Laravel (PHP), Angular (Javascript), Django (Python), Ruby on Rails (Ruby), … Et cela marche pour tous les langages de programmation !
Architecture client/serveur ou 3 tiers
On oppose souvent les architectures client léger – ou architecture 3 (N) tiers – aux architectures client-serveur – ou client lourd. On parle de client lourd lorsque le matériel de l’utilisateur est utilisé pour les traitements tandis que l’on parle de client léger lorsque l’ensemble des traitements est effectué à distance (sur un serveur web par exemple).
Il y a fort fort longtemps, les débits réseaux ainsi que les ressources serveurs étaient faibles (dans les années 80-90). Une partie des traitements était donc déportée vers les clients (PC des utilisateurs). Depuis, avec l’amélioration des capacités des navigateurs et des connexions internet, les architectures client léger se sont imposées. Aujourd’hui, on revient un peu en arrière avec des traitements qui sont effectués sur les devices (le matériel) des utilisateurs en utilisant les navigateurs ou les OS des mobiles. On cherche à améliorer les performances ou pallier une déficience éventuelle de réseau.
Parfois, par extension ou facilité, on parle aussi d’architecture 3 tiers pour évoquer les différents composants physiques de la solution : le terminal (navigateur web ou téléphone), le serveur web et le serveur de données.
Le design pattern MVC
Il y a des problèmes en programmation qui reviennent tellement souvent qu’on a créé des bonnes pratiques (qui résolvent ces problèmes) que l’on a réunies sous le nom de design pattern. Le design pattern MVC ou Model-View-Controller (Modèle-VueContrôleur) est l’un des plus importants. Il s’agit d’un pattern qui sépare la logique du code en trois parties afin de clarifier la conception des développements :
- Le Contrôleur gère l’enchainement des pages, les URL… (le code PHP qui interroge le modèle et renvoie les éléments à afficher à la vue)
- Le Modèle gère la logique métier et les données (les requêtes SQL)
- La Vue affiche la page (le code HTML et quelques boucles et conditions PHP très simples, pour afficher par exemple des listes)
