Construit par Ubidreams et Dynamis Technologies, Nanoko est un processus de construction (de build) Javascript conçu pour offrir modularité et réutilisabilité, complémentant les outils existants plutôt que de les réinventer. InfoQ a pu échanger avec le fondateur d'Ubidreams, Romain Pellerin pour une analyse approfondie de la plate-forme.
INFOQ : Pourquoi devrais-je utiliser Nanoko au lieu d'ember.js ou angular.js pour les grandes applications côté client ?
Nanoko n'est pas un framework MVC ou MVVM. Contrairement à angular ou ember, Nanoko propose un processus de construction garantissant la reproductibilité de la construction (du build). Il intègre également les tests, l'agrégation, la minification et un tas de langages web tels que Less et CoffeeScript. Nanoko propose également un framework pour construire et exécuter des applications modulaires. Le principal bénéfice de Nanoko vient de la combinaison d'un processus de construction industrielle et d'un runtime modulaire. Nanoko ne se concentre pas sur un style d'architecture orientée interface utilisateur, mais adopte une orientation service qui rend le développement plus souple et l'intégration très facile.
INFOQ : Est-ce que Nanoko est actuellement utilisé dans toutes vos applications de production ? Si oui, quels sont les exemples ?
Oui. Ubidreams a développé une application multi-plateforme nommée "Gourmandise" pour Rémy Cointreau. Cette application est un catalogue mobile utilisé par la force de vente lors des rendez-vous clients. En plus de l'application iPad, une application web (CMS) a été développée en utilisant la pile Nanoko. Ce CMS fonctionne sur n'importe quel navigateur (y compris IE8). Faits intéressants : ces deux applications partagent 80% du même code source (Javascript), seule l'interface utilisateur diffère. Ces résultats sont obtenus grâce au type d'architecture proposé par Nanoko.
INFOQ : De quel type d'architecture se rapproche Nanoko ? MVC, MVM, MVVM, ou autre chose ? J'ai lu la FAQ et j'ai vu que Nanoko était complémentaire de frameworks MV* existants.
La position de Nanoko n'est pas de réinventer la roue. En fait, de nombreuses librairies Javascript font un travail incroyable. Ainsi, vous êtes libre de choisir votre modèle et les bibliothèques associées. Ensuite, vous les encapsulez dans un ou plusieurs composants Nanoko. Ces composants interagissent en utilisant une approche "faible couplage" proche des services web (mais sans la lourdeur). Nanoko facilite la création de n'importe quel type d'architecture. Par exemple, Ubidreams a mis en place un modèle MVC où :
- Les modèles sont basés sur la structure de données JSON récupérée d'un serveur
- Les vues sont implémentées en utilisant les composants Enyo et Twitter Bootstrap. Ces composants sont activés ou désactivés en fonction des caractéristiques du terminal / du navigateur.
- Les contrôleurs sont juste des composants Nanoko (en fait, le composant h-ubu) gérant les liens entre le modèle et les vues. Il peut également s'appuyer sur les services.
- Les services sont des fonctions réutilisables (tels que la sécurité, le réseau, l'ordonnancement) également mis en œuvre comme des composants Nanoko et utilisés par les contrôleurs.
INFOQ : Si Nanoko est complémentaire, il n'est pas réellement un framework à lui tout seul, mais une façon modulaire d'organiser vos applications. Est-ce bien cela ?
Oui, c'est une bonne vision des avantages de Nanoko. C'est plus une plate-forme qu'un framework comme angular.js ou backbone.js. Évidemment, une telle affirmation dépend de votre définition d'un "framework". Quoi qu'il en soit, il est probablement plus facile de voir Nanoko comme une plate-forme pour créer des applications modulaires à base de composants.
INFOQ : Nanoko n'est pas un framework. Êtes-vous d'accord ou non ? S'il vous plaît, expliquez-nous pourquoi.
Tout à fait d'accord. Nanoko vous permet de faire le pont entre des technologies hétérogènes. Derrière cela, Nanoko a pour but d'améliorer l'industrialisation des développements et leur efficacité.
INFOQ : Comment Nanoko interagit avec Maven ? En quoi Maven est-il meilleur que Grunt ?
Maven est au cœur de la chaîne d'intégration continue puissamment industrialisée de Nanoko. Nous pouvons aimer ou détester Maven. Le fait est que Maven a radicalement changé la façon dont les logiciels Java sont construits, dans le bon sens. Nous pensons que la rigueur et les conventions de Maven ouvrent la voie à l'industrialisation du développement web. Grunt donne beaucoup de liberté, comme Ant l'a fait il y a quelques années pour Java. Cependant, sans un cycle de vie strictement défini, une puissante gestion des dépendances et des référentiels d'artefacts d'entreprise, une telle industrialisation serait difficile sinon chaotique. Utiliser Maven signifie aussi utiliser le même système de construction pour le backend et pour la partie web de l'application. C'est un aspect très important à prendre en compte. De plus, les dépendances entre les deux deviennent très simples : juste une dépendance Maven. Et sans mentionner le processus de livraison et de gestion de la documentation qui placent Maven comme une pierre angulaire de la plate-forme Nanoko.
INFOQ : S'il vous plaît, expliquez-nous l'interaction de Nanoko avec le développement d'applications JEE. Comment cette technologie côté serveur est-elle compatible avec Nanoko ?
Nanoko n'est pas à proprement parler lié à JavaEE, ni à quelconque autre technologie backend. Mais l'intégration de la pile Nanoko avec ces technologies est simple. Nanoko promeut une orientation service, où les fonctionnalités sont disponibles comme des services ("as services"). Les serveurs "backend" exposent juste des services REST ou des web services. Il est donc simple comme bonjour d'intégrer ces services dans Nanoko : un composant expose exactement la même interface de service. Les autres composants ont juste à utiliser cet élément pour accéder aux fonctionnalités du serveur.
INFOQ : En quoi Nanoko est différent de node.js or require.js ?
Tout d'abord, Nanoko est compatible avec require.js et node.js. En fait, ils sont recommandés. Vous pouvez voir Nanoko comme un moyen de construire et de lier les modules require ou node. En utilisant l'orientation service, les modules interagissent en utilisant des services prédéfinis (nommés contrats dans Nanoko). Ce couplage faible permet de substituer un module par un autre (même lors de l'exécution). Vous pouvez voir rapidement les bénéfices d'une telle configuration : avoir des modules activés / désactivés en fonction des plates-formes et du contexte d'exécution, l'évolution asynchrone des modules, des tests plus faciles etc.
INFOQ : Qu'est-ce qui vous a décidé à rendre Nanoko open source ? Sous quelle licence ?
Nanoko est le résultat d'un effort collaboratif de plusieurs sociétés (Ubidreams, dynamis-technologies, Université Grenoble ...) ayant l'open-source comme une de leurs valeurs fondamentales. Donc, "ouvrir" ainsi le code source de Nanoko était naturel pour nous. Après avoir discuté avec les différents fondateurs, nous avons sélectionné le consortium OW2, comme nous sommes assez proches de la philosophie d'OW2. Le code source de Nanoko est sous la licence Apache 2.0 pour supprimer tous les obstacles à l'adoption business. Le code complet est disponible sur GitHub. Des versions sont publiées sur Maven Central, ce qui rend l'utilisation des composants Nanoko très simple.
INFOQ : D'où le projet est-il dirigé ?
Le projet est dirigé en France à la fois de La Rochelle (au siège d'Ubidreams) et de Grenoble (au siège de Dynamis technologies). Nanoko a rejoint le consortium open source OW2 pour atteindre une visibilité internationale. Grâce à l'appui fort et important de OW2 et de tous ses membres, l'avenir de Nanoko apparaît brillant.