Continuing the discussion from Part 1, Java applications provide a modular interface to the PostgreSQL databases, regardless of how you access them; via a JDBC or R2DBC. R2DBC repositories provide a rapid prototyping support for development, since they are lightweight and provide just-enough wrapper to perform database queries. When you mix the R2DBC with PostgreSQL’s SQL constructs, you can provide a suitable data-access layer in a web application. In the previous post, we wrote the Java application that utilizes PostgreSQL database and R2DBC repositories to boot up a Spring Boot application. Our core focus was:

1. To enable a reactive repository for PostgreSQL
2. Write a model layer in Java app that communicates with the PostgreSQL database
3. Create a RESTful frontend for the database

In this blog post, we will reuse the Spring Boot application that we authored previously to expose the CRUD methods and call them from our HTTP clients.

Note: This is the second part for our Reactive PostgreSQL repositories series in the multipart blogs for Spring Boot Reactive. Make sure you have read the part 1 of this series to set up the PostgreSQL database as well as the models in Java application.

Performing CRUD

You can use Postman to send the HTTP requests to our Java application. You should be able to use the http://localhost:8080/api/books endpoint to send all the requests. Remember that we mapped each HTTP verb (GET, POST, PUT, DELETE) to a specific CRUD operation that we will perform here.

Create Records

Let us create a record, we will use the JSON notation to upload the object and then let R2DBC create the record for us. I am only passing the title and the author details for a Book record, and PostgreSQL would create the record in the database since it uses SERIAL type; which automatically increments the values in a sequence.

This SERIAL approach is useful, in that we do not need to pass the values for the primary key from Java app (which might have collisions), instead we let PostgreSQL manage that.

We can verify the record in OmniDB as well (note that I created multiple records):

The interesting part is that we returned the Mono<Book> object, which was returned from the database with the updated primary key in Postman!

Read Records

Reading the records is as simple as querying; we will not use filtering and WHERE clause here. You send the GET request and that ultimately reads the records from database and returns the Flux<Book>. The Flux<Book> type contains multiple records in the range, which are the result of your query from the database. In the previous step, I went ahead and created multiple records in the database, thus the result in JSON is:

You can also see the results from OmniDB for the database state in the section above.

Update Records

Updating and creating the records is a similar process, only difference is when you are updating the records, you pass in the ID for the record that needs an update.

We can update the record using REST API, which updates our PostgreSQL database,

We can also verify the status in our PostgreSQL database using OmniDB:

Delete Records

Finally, we can delete the records, note that deleting the records returns a Mono<Void>. It would be nice to return a count of rows that were affected by the query; well, for now it just doesn’t return anything.

We can also verify the state in our PostgreSQL database using OmniDB:

A little something for you to try: Try removing the “block” method call from the Java app route, see the state in PostgreSQL database and then observe what happens!

In a nutshell, you will not find much difference from JPA or JDBC. But there are a lot of differences in JDBC and R2DBC, being reactive and non-blocking the first one.

Conclusion

PostgreSQL with the Reactive Spring Boot framework offers a lightweight solution to develop your web applications. Although, R2DBC does not have full feature-set like Hibernate for JPA, but R2DBC offers a good support for fluent method naming convention; that can be used to modify the underlying R2DBC behavior.

In this post, we used the sample Java Spring Boot application that we developed in the Part 1 of this series and explored the HTTP client engagement on top of that. We used OmniDB to query and validate the table contents for our PostgreSQL database.