Neo4j/Reactive/Quarkus/GraalVM fame“ • This ^^ is a quote (and the pressure is high) • Official role: Maintainer of Neo4j-OGM and Spring Data Neo4j • We released Neo4j-OGM 3.2 in 2019, with 20 patch releases following • Not many changes in Spring Data Neo4j 5.x • Changed most everything in Spring Data Neo4j 6
$, % and & (no swimming this year… ') • Twitter addict… @rotnroll666 • Enjoys databases with declarative languages in general • Active in both Java and database communities • Likes Spring (wrote a best selling German book about it) • But enjoys other ecosystems too… (Not actually evil, though…)
causing issues? • Embedded • Dependency management is a nightmare • Bringing up the database from the mapper is the wrong abstraction layer • Close coupling between OGM and Neo4j versions • Definitely not native ready • HTTP • Not typesafe (we are working on that) • Bolt (Aka the Neo4j Java Driver) • Mostly naming, people mistake bolt-driver with the Java driver itself • Transactional functions (to some extend, later more)
than 20 releases in the last 2 years • Ticket numbers closed to about 4 or 5 • Stable API, ways to mark queries explicitly as r/w and r/o, supports multi database • Native ready since this month • Usage of bolt taught us it’s API and usage • Super flexible mapping, both a benefit and sometimes a PITA • Personal note: I do like maintaining it.
Neo4j 6 • Full support of the reactive story • • • • Neo4j native types • Dedicated ways of decomposing objects into maps to be stored on single nodes / relationships • Clean levels of abstracts (from low to high: Managed driver, Neo4j client, template, repositories, from client onwards with Spring TX Support) • • Compatible with GraalVM native • • Full support of immutable domain objects (Kotlin data classes, Java 16 records, Lombok Data classes) • Full support of all derived finder query building parts • Full support of find by example • • • • Performance •
Goals of SDN⚡RX • Full support of the reactive story • Neo4j native types • Dedicated ways of decomposing objects into maps to be stored on single nodes / relationships • Clean levels of abstracts (from low to high: Managed driver, Neo4j client, template, repositories, from client onwards with Spring TX Support) • Compatible with GraalVM native
support of the reactive story • Clean levels of abstracts (from low to high: Managed driver, Neo4j client, template, repositories, from client onwards with Spring TX Support) • Neo4j native types • Compatible with GraalVM native
• org.neo4j.driver.GraphDatabase is the general Driver factory • Instances of org.neo4j.driver.Driver are heavyweight objects and maintain a pool of physical connections • Open as few as possible and keep them around • All sessions are lightweight and basically a lease on connections • Don’t keep them around • Open and close as needed • Concepts are not 1:1 comparable to JDBC wording!
Fully non blocking, required changes in the Bolt server • Internally using • Netty and existing async behavior • Small parts build with Project Reactor • Build based on PULL_N and TX_STREAMING (See 7687.org, Server v4) • Externally adhering to https://www.reactive-streams.org • Publisher compliant with the TCK (See https://github.com/reactive-streams/ reactive-streams-jvm/tree/master/tck)
Better resource usage • More efficient use of threads (non blocking IO is key!) • Slightly less memory usage on the client side • Steep learning curve • All reactive libraries offer a plethora of operators • What is happens on LIMIT / cancel? • Resource handling can be tricky • Reactive context works awesome for user / tenancy information
Don’t use the publishers alone. • Officially under test are • Project Reactor https://projectreactor.io (Flux and Mono) • RxJava 2 https://github.com/ReactiveX/RxJava (Flowable and Observable) • Works with • SmallRye Mutiny! https://smallrye.io/smallrye-mutiny/ (Multi) • Helidons reactive implementation • Most efficient usage: With Project Reactor (no conversion required)
Better don’t do a take(n), skip here in case of multiple results. Also not the best idea to expose such a flow directly as an endpoint. take(n) is effectively a „cancel“ and so is an interrupted browser request. in such case a transaction would be rolled back!
project semantics, i.e. here Project Reactor, on a Flux • flatMap: Takes every item and maps it concurrently into a new Publisher • concatMap: Same as above, but one at a time • switchMap: Takes the next item, cancels the inner publisher and maps that item into a new Publisher • Different behaviors between libraries Flux/Mono are both Publishers (never null items, strict failures) Multi/Uni feel like Publishers, but only Multi is. Uni drops everything after 1st
written in Java, integrated with Hotspot VM through JVM Compiler interface • Language independent representation of guest languages: A graph • The Truffle framework for creating new interpreters for additional languages • The polyglot runtime • Native Image Speaking about GraalVM
executables or shared libraries • Restrictions apply • Classes / methods used via reflections must be enumerated in most cases • Same applies for resources • There’s an agent helping you todo this • Faster startup, lower memory overhead • Maybe less throughput than a fully warmed up JVM
the Neo4j Java driver? YES! • Netty needed some „support“ (a couple of substitutions, mainly inspired by our work with the Quarkus people) • SSL is kinda hard to get right, requires JNI and others enabled on native image generation • Tested to work with • Quarkus • Spring Boot (with SDN 6, currently in Beta) • Helidon (from Oracle, currently in Alpha, PR-Stage)
https://unsplash.com/photos/7p8cFwM0Y1s • Bookmarks by Kasturi Roy: https://unsplash.com/photos/bYy9hndOx0k • Goblet by Shannon Douglas: https://unsplash.com/photos/8yeyzVfMv0M • Graal and Neo4j polyglot by Oleg Šelajev for my Medium article: https://medium.com/graalvm/3-ways-to-polyglot-with-graalvm- fb28c1542b45