Annoncée lors de la conférence SpringOne Platform à Washington DC, R2DBC est une API expérimentale entièrement neuve pour une programmation réactive sur les bases de données relationnelles. L’objectif final est d’essayer d’influencer la spécification de l’accès asynchrone aux bases de données (ADBA).
S’exprimant lors de l’événement, Ben Hale, responsable de la Cloud Foundry Java Experience, a déclaré que R2DBC est conçu autour de quatre principes :
- Utiliser les types et les modèles de flux réactifs.
- Être complètement non-bloquant, jusqu’à la base de données.
- Réduire le pilote SPI à l’ensemble minimal d’opérations qui sont spécifiques à l’implémentation, indépendamment de la facilité d’utilisation.
- Permettre à plusieurs API "humaines" d’être construites sur le pilote SPI.
Voici un exemple tiré de la présentation par Hale pour une commande Select :
Le fichier connectionFactory.create() renvoie un Mono d’une connexion. Hale explique que le résultat de cette invocation est qu’"à la fin, quand quelqu’un s’abonne, il va chercher une connexion, exécute la requête, puis pour chacune de ces lignes renvoie la valeur, disons un entier, résultant en un flux d’entiers comme résultat final, avec un cycle de vie autour de la connexion qui est seulement ouvert sur abonnement et fermé quand elle est terminée".
Bien sûr, un client construit sur le SPI peut encore simplifier cela, et Hale a montré un exemple dont les détails sont maqués :
Voici à quoi ressemble un Prepared Insert à l’intérieur d’une transaction à l’aide du SPI :
Comme Hale l’a admis lors de sa présentation, ce n’est pas génial, mais encore une fois, cela peut être simplifié pour le client :
Il existe des solutions de rechange à R2DBC. L’une est d’encapsuler JDBC dans un pool de threads, mais cela ne permet pas de back pressure - les files d’attente illimitées mèneront à l’épuisement des ressources, et les files d’attente limitées mèneront au blocage. L’autre est ADBA. Parlant prudemment, Hale a dit :
Nous nous sommes engagés assez tôt avec l’équipe d’ADBA, mais il y a beaucoup de controverse pour savoir si CompletableFuture est réellement Réactif alors nous nous sommes désengagés ce qui a engendré notre initiative R2DBC. Mais maintenant que les efforts de R2DBC ont des preuves tangibles et des API fonctionnelles, nous sommes réinvités à nous engager. Ainsi, ADBA pourrait bien devenir cela, et dans une certaine mesure, c’est l’objectif final d’un projet comme celui-ci.
En ce qui concerne les plans d’avenir, Hale a clairement indiqué que R2DBC est un terrain de jeu expérimental, et bien qu’il soit assez stable pour jouer avec, il n’est absolument pas destiné à une utilisation en production. Il est important de noter qu’il existe un certain nombre de cas limites, y compris un manque de traitement BLOB/CLOB, et au moment de la rédaction de cet article, une seule base de données - PostgreSQL - est supportée, mais Hale est impatient de voir des implémentations pour les autres bases de données. Il a terminé en disant :
Spring ne produit pas de spécifications. Nous ne sommes pas des responsables des specs et nous n’hébergeons pas de spécifications. L’objectif de ce projet est d’influencer la spécification ADBA, et c’est le meilleur scénario possible. Mais ne vous méprenez pas, je ne suis pas le genre de personne qui va tolérer que les spécifications ADBA soient mauvaises. S’ils ne suivent pas nos conseils, s’ils ne voient pas que Réactif est différent d’être asynchrone, alors c’est quelque chose que l’équipe Spring fera.
InfoQ filme toutes les sessions de SpringOne cette année, et toutes les vidéos seront disponibles sur le site au cours des prochains mois. Pour recevoir les notifications au fur et à mesure que les sessions sont publiées, suivez le sujet SpringOne Platform 2018.