Lors de la conférence Front-Trends 2013 la semaine dernière, Gregor Martynus a présenté une session intitulée "Look ma, no backend!" sur le développement d'applications uniquement coté client, en utilisant des composants coté serveur seulement lorsque le navigateur ne les implémentait pas. Cette approche est à l'opposé de la façon dont les applications web ont été développées jusqu'à maintenant : en se concentrant principalement sur la partie serveur d'une application puis en l'améliorant avec le développement de l'interface utilisateur. Un site web nommé noBackend a été lancé pour évangéliser davantage cette idée.
InfoQ a rencontré Gregor pour en savoir plus.
noBackend propose un concept d'écriture d'applications sans se soucier de la partie serveur, en quoi est-ce intéressant et quels en sont les motivations, les avantages ?
Nous sommes allés assez loin dans la simplification du processus de conception d'application. Pourtant dès que je crée une application je commence par réfléchir à la partie serveur : quelle technologie vais-je utiliser, quelle base de données. Le processus de conception d'une application est toujours dicté par le coté serveur et ses contraintes. Or je pense que cela ne doit plus être le cas. Je pense que, du point de vue utilisateur, la conception et l'expérience utilisateur d'une application est unique, personne ne s'intéresse à comment ça fonctionne derrière. noBackend tente de refléter cela en proposant un processus de conception axé sur l'interface utilisateur avec une totale liberté, puis de travailler ensuite coté serveur à partir de là.
Une application sans le coté serveur est-elle vraiment réalisable, quelles sont les limitations ?
Quand j'évoque noBackend, je ne pense pas à abandonner le coté serveur, le terme porte à confusion mais il est accrocheur.
Ce que je veux dire par noBackend c'est de ne plus penser à la partie serveur. Désormais vous ne devez plus vous souciez de ce que le navigateur est en mesure de faire ou pas. Ces lacunes peuvent être comblées par JavaScript maintenant, en cachant qu'en réalité ça parle à un serveur. Le développeur de l'interface ne doit plus s'en préoccuper. Ce qui lui donne plus d'autonomie.
D'un point de vue technologique, il y a 2 choses qui nécessitent une bonne connaissance coté client :
- CORS pour faire des requêtes AJAX indépendantes du domaine.
- le code asynchrone avec les callbacks, la gestion d'évènements et les promises.
Les deux existent déjà. Nous sommes donc prêt à le faire dès maintenant.
Votre site parle de dreamcode, qu'est-ce que c'est ?
Lorsque nous avons commencé à travailler sur Hoodie, nous avons démarré avec une API JavaScript dédiée au développeur client. C'est ce qui nous importait le plus. Sans se préocupper des aspects complexes derrière cette façade, cela devait être le plus simple possible pour le développeur. Nous avons décidé d'oublier toutes les contraintes et de se dire : "Ok, je veux authentifier un utilisateur, quel est le code JavaScript le plus simple pour faire ça." J'ai listé plusieurs autres cas d'utilisation sur notre site.
Un bon exemple est jQuery. L'équipe jQuery a réalisé un super boulot pour proposer une API qui soit simple et puissante et je pense que c'est la première raison de son succès.
Un autre point vraiment sympa à propos de dreamcode c'est que tous les développeurs peuvent le faire. L'expérience n'a pas d'importance, vous pouvez rêver le code. En fait, si vous débutez, vous avez même l'avantage de ne pas penser aux contraintes qui assomment les cerveaux des développeurs expérimentés.
Et dreamcode est l'outil pour piloter le processus de conception d'une application noBackend. Typiquement, vous demandez aux développeurs coté serveur ce dont vous avez besoin : comptes utilisateurs, envoi d'emails, chargement de fichier. Ils le réalisent et reviennent avec une API RESTful que les développeurs client vont exploiter avec des appels AJAX via jQuery par exemple. Désormais c'est le développeur client qui décrit le besoin exact de l'utilisateur avec dreamcode et cela devient l'interface entre client et serveur et les deux cotés peuvent travailler avec.
D'un point de vue serveur, dreamcode c'est :
- Juste un nouveau nom pour BDD/TDD
- Un successeur de l'API REST, plus simple à définir et plus flexible dès lors qu'il s'agit d'anticiper les futurs changements.
Quels sont les impacts au niveau sécurité du noBackend sur la partie serveur ? par exemple comment empêcher un utilisateur d'utiliser l'API d'email depuis la console JavaScript pour envoyer des spams.
Aucun. noBackend défini juste la manière la plus simple d'envoyer un email. Bien sûr je suis d'accord que les aspects de sécurité sont importants, quand il s'agit d'envoyer des emails ou de recevoir des paiements comme vous le dites. Je pense juste que l'API coté client n'a pas besoin de refléter cela. Cela devrait être super simple. La logique pour empêcher les SPAMs doit être définie coté serveur. Par exemple vous pouvez empêcher un utilisateur d'envoyer un email si il n'a pas de compte. Ou si il envoi plus de 10 email par minute. Ce sont des problèmes que les développeurs coté serveur ont résolu depuis longtemps, ils sont bons pour ça. Les développeurs coté client n'ont pas besoin de s'ennuyer avec ça, et c'est difficile pour beaucoup d'entre eux. Ça j'en suis sûr.
Si vous voulez faire le nouvel Heroku, mettez de coté l'enfer de la partie serveur, réalisé une superbe application coté client et puis prenez tout mon argent.
Quel est la relation entre noBackend et Backend-as-a-Service ? Les 2 idées semblent similaires.
Backend-as-a-Service est une sorte de noBackend mais vue d'un point de vue entreprise, alors que j'essaye d'utiliser noBackend pour remettre la vision développeur de l'expérience utilisateur sur le devant de la scène.
Par exemple, Firebase est un Backend-as-a-Service, comme l'est Parse, Kinvey ou Backendless. Puis il y a les solutions open-source que je considère comme des approches noBackend, par contre vous devez les héberger vous-mêmes ou c'est optionnel, comme hood.ie, remotestorage.io ou deployd.com
Certains services noBackend cités sur votre site (comme remotestorage.io et hood.ie) évoque la capacité de travailler hors ligne et de synchroniser lorsque l'accès internet revient. Est-ce important principalement pour les applications mobiles ou le mode déconnecté a une plus large audience ?
La capacité de travailler en mode déconnecté n'est pas (seulement) de permettre aux utilisateurs de travailler avec les applications lorsqu'ils n'ont pas d'accès internet. Cela élimine la latence. Et du coup améliore l'expérience utilisateur.
Prenez minutes.io par exemple. Il stocke tout ce que vous faites instantanément lorsque vous tapez, dans le cache de votre navigateur. Puis dans un second temps les données sont synchronisées coté serveur.
Est-ce la nouvelle manière de développer des application ou l'approche noBackend ne concerne-t-elle qu'une certaine catégorie d'application ?
Je pense que toute nouvelle technologie est seulement pour certains types d'applications. C'est une approche différente qui correspond bien aux applications gérant la majeure partie de leur logique coté client, là où l'expérience utilisateur est la caractéristique la plus importante.
C'est juste un nouvel outil que les développeurs doivent envisager, surtout les développeurs client, du fait que les solutions noBackend peuvent être de bons outils pour les aider à développer des applications qu'ils n'auraient pas été capable de développer eux-mêmes sans noBackend.
Le site noBackend liste un certain nombre de solutions serveur qui peuvent être utilisées pour mettre en oeuvre l'approche noBackend.