Anunciado na conferência SpringOne Platform em Washington DC, o R2DBC é uma API experimental projetada do zero para programação reativa utilizando banco de dados relacionais. O objetivo é tentar influenciar a especificação de acesso assíncrono a banco de dados (ADBA).
Palestrando no evento, Ben Hale, Cloud Foundry Java Experience Lead, disse que o R2DBC é projetado pensando em quatro princípios de design:
- Utilizar padrões e tipos de stream reativos;
- Ser completamente não blocante, até o banco de dados;
- Diminuir o driver SPI ao mínimo de operações que sejam específicas da implementação, independentemente da usabilidade;
- Possibilitar que múltiplas APIs "humanas" sejam construídas sobre o driver SPI.
Este é um exemplo de um simples SELECT demonstrado na apresentação de Hale:
O método connectionFactory.create() retorna um Mono de uma conexão. Hale explica que o resultado desta chamada é que "no fim, quando alguém se inscreve, o driver recupera uma conexão, executa a consulta e então para cada uma das linhas do resultado retorna um valor, digamos um inteiro, resultando em um Flux de inteiros como o resultado final, com um ciclo de vida em torno da conexão que só é aberta na inscrição e fechada ao concluir".
É claro, o cliente construído sobre a SPI pode simplificar o código ainda mais, e Hale mostra um exemplo de como os detalhes da implementação podem ser escondidos:
Aqui está um exemplo de são passados parâmetros para inserir um registro dentro de uma transação usando o SPI:
Porém, como o próprio Hale admite, isto não é ótimo, no entanto pode ser simplificado no cliente:
Existem algumas alternativas ao R2DBC. Uma é encapsular o JDBC em um pool de threads, mas isto não fornece contrapressão - filas ilimitadas irão esgotar os recursos e filas limitadas levarão a bloqueios. A outra é a ADBA. Falando cuidadosamente, Hale disse:
Nos engajamos desde o início com a equipe do ADBA, mas há muita controvérsia sobre se a classe CompletableFuture é realmente reativa, então deixamos de participar, o que levou ao esforço em volta do R2DBC. Mas agora que o R2DBC se provou e tem APIs funcionando, fomos convidados a voltar a contribuir. Portanto o ADBA pode eventualmente se tornar isto, e de alguma forma este é o objetivo final de um projeto como este.
Com relação a planos futuros, Hale deixa claro que o R2DBC é um experimento, e apesar de ser estável o suficiente para brincar, ele absolutamente não é destinado para uso em produção. É importante notar que existe um número considerável de pontas soltas, incluindo a falta de suporte a BLOB/CLOB, e no momento da escrita deste texto apenas um banco de dados - PostgreSQL - é suportado, mas Hale está ansioso para ver implementações para outros bancos de dados. Ele termina dizendo:
O Spring não cria especificações. Não somos líderes de especificação, bem como não as hospedamos. O único objetivo deste projeto é de alguma forma influenciar a especificação ADBA, e este é o melhor cenário possível. Mas não se enganem, eu não sou o tipo de pessoa que vai tolerar que a especificação ADBA seja ruim. Se eles não aceitarem nosso conselho, e não enxergarem que ser reativo é diferente de ser assíncrono, então isto será o que a equipe do Spring irá fazer.
O InfoQ está de novo filmando todas as sessões na SpringOne deste ano e todos os vídeos serão disponibilizados no site nos próximos meses. Para receber notificações das sessões publicadas, siga o tópico SpringOne Platform 2018.