Pas de framework … Et maintenant ?

C’est décidé je vais créer mon propre framework à moi. Objectif : simplicité. Je vais donc créer un framework qui aura une double  approche : client et serveur ce qui à ma connaissance n’existe pas vraiment encore.

Quels sont les éléments à proposer ?

La première question à se poser : un framework pour quoi faire exactement ? quels sont les services qui vont être encapsulés dans ma nouvelle boîte à outil ? Hum, je vais tâcher de les lister comme ça afin de se donner une ligne directrice pour la suite :

En matière de traitement pur j’aurais par exemple :

• Sécurisation de l’application
• Connexion / Déconnexion
• Accès au filesystem (fichiers XML et surtout JSON)
• Accès à une base de données (persistence ?)
• Logs & Traces
• Asynchronisme (l’idée ici est de pouvoir lancer des traitements sans attendre le résultat … indispensable pour une application web non ?)

Sinon coté client si l’on veut séduire le regard il va nous falloir quelques éléments visuels:

• Ergonomie générale dans l’ère du temps
• Gérer l’affichage sur mobile nativement
• Afficher des graphiques (courbes, pie, barres, radar, etc.)
• Afficher des tableaux (voire permettre de la saisie façon Excel)
• Gérer la navigation (menu, sitemap, etc.)

Bon voilà ma liste de départ, il me parait évident qu’avec le temps elle va s’étoffer, mais on va commencer comme ça.

Que RESTe-t-il ?

La liste de course est terminée. Du moins pour le démarrage bien sur. Comme je l’ai précisé dans mon article précédent l’idée est de créer un framework moderne de type API. Vous me voyez arriver avec mes grand sabots ? qui dit moderne dit utilisation d’une architecture REST, je dirais même plus : RESTful. Au début je me suis dit que ça allait être aussi simple que les applications de type client-server. Erreur! ce type d’architecture implique beaucoup de différences avec l’ancienne approche de type JSP/ASP. En effet avec les applications REST on peut dire que le divorce client – server est bel et bien consommé 🙂 Disons que leur séparation ne fait plus aucun doute. C’est tant mieux car grâce à cette nette séparation il est beaucoup plus envisageable de réutiliser les traitements pour développer de nouvelles interfaces. L’ère des APIs est bien lancée.

En effet à compter de maintenant on va développer les traitements « métier » et les mettre à disposition via l’API. Cette dernière pourra être utilisée ensuite par les applicatifs (application mobile, portail, etc.) et ce via le protocole le plus universel du moment : REST. Le protocole est donc choisit, il faut le compléter avec le format d’échange maintenant. Evidemment le JSON s’impose naturellement. Le XML étant plus approprié je trouve pour de la configuration et non de l’échange de données (régime oblige).

Je récapitule:

L’API respectera une architecture de type RESTful et les formats d’échanges seront en JSON

MVC

Evidemment qui dit développement web dit envisager l’implémentation d’un mode MVC (Model View Controller). Personnellement j’aime beaucoup ce pattern, je le trouve propre et efficace sans son genre. Bon, comme on a dit que l’on développerait une application à la sauce API, il est évident que l’on va oublier les bons vieux frameworks du type Struts. On va aussi oublier les Angular et autre React, histoire de développer un framework qui s’adaptera comme un gant à notre framework server (avec par exemple la prise en compte directe des formats d’échanges client-server).

Mais bon, j’aime bien le concept principal du MVC. L’idée de toujours pointer vers le controller permet par exemple se simplifier considérablement la gestion de la sécurité. je vais donc garder quelqu’uns de ces concepts, mais pas tout 😉

Coté langage

Faisons simple et standard:

Java pour le framework server et Javascript pour le framework client

Bien sur, cela ne suffit pas car qui dit développement web dit accumulation de langages (arggg!) : nous aurons donc aussi de l’HTML5, du CSS et du SQL pour l’accès base de données.

Coté serveur, étant donnée que nous sommes sur de l’infrastructure Java, j’ai choisi Tomcat pour me simplifier la vie et surtout le déploiement.

Et l’environnement alors ?

J’allais oublier … avec quoi vais-je me lancer ? évidemment on peut la jouer puriste et prendre son notepad, mais bon je suis fénéant aussi donc quelle IDE ? On est sur du java ce qui raisonnablement nous met face à Eclipse et Netbeans. J’ai bien sur essayé les deux et mon choix (personnel) est sans équivoque … je démarre avec netbeans ! Un bon vieux netbeans sur ma fedora et hop c’est parti.