Archives par mot-clé : architecture

Choisir sa tech stack

Quand je démarre un nouveau projet, que ce soit à partir de zéro ou en reprenant une base existante, je me pose systématiquement la question de la technology stack à utiliser, c’est à dire l’ensemble des composants logiciels (et éventuellement matériels) à mettre en oeuvre. Ce sont les outils à disposition de l’ingénieur pour résoudre un ensemble de problèmes donnés.

C’est un choix important, qui doit être réfléchi, sans quoi le risque est de subir une stack inadaptée, que ça soit à cause de l’habitude (“on a toujours fait comme ça”) ou à cause de l’existant (“il y avait déjà deux briques logicielles écrites en Jython#.js”), avec les difficultés de développement, les limitations et les surcoûts qui vont avec.

Ce choix est d’autant plus important que les outils disponibles sont de plus en plus nombreux, et changent de plus en plus rapidement. Grâce à une simple connexion internet, je peux obtenir tous les éléments nécessaires pour faire tourner mon projet, et je peux également me former en ligne grâce à de la documentation, des guides de démarrage rapide, des projets open source dont je peux m’inspirer, ou des sites collaboratifs comme StackOverflow grâce auxquels des utilisateurs de tous les horizons pourront répondre à la moindre de mes questions techniques.

Continuer la lecture de Choisir sa tech stack

Introduction à une architecture orientée services

Capitaliser sur du code ; ça c’était avant

On ne le dira jamais assez : chaque projet informatique est unique. Il subsiste cependant des points communs d’un projet à l’autre. Des points que nous pouvons identifier pour anticiper les problématiques, et ainsi monter une solution qui bénéficie, de proche en proche, des expériences passées. On essaie donc de « capitaliser », comme les vils financiers, pour ne pas avoir à réinventer la roue.

Parmi les façons classiques de capitaliser, dans le monde du logiciel, il y a :
  • la reprise de composants logiciels existants. Soit par la reprise de binaires, soit par l’inclusion du code source existant au sein du projet. Il peut s’agir de l’utilisation de librairies existantes et éprouvées libres,… ou pas (jquery, winnovative pour la génération de rapports office, etc.)
  • la façon, la méthode d’assemblage de ces différents composants. Typiquement, sur une application web, nous allons identifier un front-end et un backend. On sait que l’on va devoir organiser le code   de façon à bien séparer les deux parties, on peut alors construire des « templates » de projet, afin de préparer en amont la future organisation du code. Aujourd’hui, de nombreux outils proposent de préconstruire  cette organisation (django en python, ou rails en ruby, par exemple).

Au final, le schéma d’une architecture d’application web se retrouve souvent sous la forme :
  • client JS + HTML
  • serveur web avec du code serveur type C#, Java, Python, Ruby, WhatElse,…
  • base de données PostRacle MySQLServer, EtTantD’autres…
Ensuite, il y a plein de façon de séparer les couches logiques : mais ça de nos jours, tout bon dev connaît ça par coeur   :  l’authentification (basic http, authentification par session/cookie, oauth, open id, etc.) , la méthode d’accès à la base, (direct ou orm) la génération de rapport, (office, csv, etc.). Tout ce joyeux monde est inclus comme un tout à l’éxecutable sous la forme de librairies internes. La partie runtime ne fait donc pas vraiment l’objet de séparation particulière, si ce n’est une organisation dans la façon de concevoir ces packages / namespaces, ou autre.

Bon, bien, bien. Et puis un jour, on se prend ça dans les dents.

Continuer la lecture de Introduction à une architecture orientée services