Envoyé par
Gugelhupf
Je vais surement utiliser les types Mono et Flux si je travaille avec Repository, mais pas sur que toutes les bases relationnelles soit compatibles avec ce concept.
En fait, aucun SGBDR ne l'est. En tout cas pas via les drivers JDBC puisque l'API ne le supporte pas, et Spring Data JDBC/JPA sont basés dessus. Avec l'arrivée des briques bas-niveau de la programmation réactive dans Java 9 (
Flow), on peut espérer que l'API JDBC finisse par offrir ce type de support.
Envoyé par
Gugelhupf
Sinon je ne suis pas fan de la syntaxe nodejs.
Je suppose que tu veux parler de la nouvelle API de déclaration des endpoints ? Je dois avouer que je suis pas un grand fan non plus mais ca se veut dans la nouvelle approche apportée. Il est possible de faire de même pour remplacer les
@Configuration.
Je suppose que c'est pour plaire à ceux qui préfèrent les "scripts" aux "annotations".
Envoyé par
Gugelhupf
C'est juste une impression ou il y a un puissant lobby qui se cache derrière Kotlin ?
Pour faire simple, les dev Android ont été longtemps limités sur les versions de Java (langage et API) utilisables. Kotlin étant retrocompatible jusqu'à Java 6 cela a permis aux dev Android d'avoir accès à un langage moderne. Pour ceux qui ont de l'expérience avec Groovy, les langages sont très proches. Cependant Kotlin compile et est typé, ce qui permet d'être beaucoup plus productif.
Enfin dernier point, JetBrains oblige le tooling a très bien suivis. Il est même possible de l'utiliser en remplacement de
Groovy pour Gradle.
Dans le cadre spécifiquement de Spring, Sébastien Deleuze (notamment) a milité pour un support "natif" dans Spring. Il faut avouer que le concept de "
extension function" sont vraiment pas mal pour faciliter de l'intégration d'un framework tel que Spring et tous les autres librairies avec lesquelles il est susceptible de travailler.
0 |
0 |
