2ndQuadrant is now part of EDB

Bringing together some of the world's top PostgreSQL experts.

2ndQuadrant | PostgreSQL
Mission Critical Databases
  • Contact us
  • EN
    • FR
    • IT
    • ES
    • DE
    • PT
  • Support & Services
  • Products
  • Downloads
    • Installers
      • Postgres Installer
      • 2UDA – Unified Data Analytics
    • Whitepapers
      • Business Case for PostgreSQL Support
      • Security Best Practices for PostgreSQL
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
  • Postgres Learning Center
    • Webinars
      • Upcoming Webinars
      • Webinar Library
    • Whitepapers
      • Business Case for PostgreSQL Support
      • Security Best Practices for PostgreSQL
    • Blog
    • Training
      • Course Catalogue
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
    • Books
      • PostgreSQL 11 Administration Cookbook
      • PostgreSQL 10 Administration Cookbook
      • PostgreSQL High Availability Cookbook – 2nd Edition
      • PostgreSQL 9 Administration Cookbook – 3rd Edition
      • PostgreSQL Server Programming Cookbook – 2nd Edition
      • PostgreSQL 9 Cookbook – Chinese Edition
    • Videos
    • Events
    • PostgreSQL
      • PostgreSQL – History
      • Who uses PostgreSQL?
      • PostgreSQL FAQ
      • PostgreSQL vs MySQL
      • The Business Case for PostgreSQL
      • Security Information
      • Documentation
  • About Us
    • About 2ndQuadrant
    • 2ndQuadrant’s Passion for PostgreSQL
    • News
    • Careers
    • Team Profile
  • Blog
  • Menu Menu
You are here: Home1 / Blog2 / 2ndQuadrant3 / Building Reactive PostgreSQL Repositories for Spring Boot Applications...
Muhammad Haroon

Building Reactive PostgreSQL Repositories for Spring Boot Applications – Part 2

August 26, 2020/0 Comments/in 2ndQuadrant, Haroon's PlanetPostgreSQL /by Muhammad Haroon

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.

Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Search

Get in touch with us!

Recent Posts

  • Random Data December 3, 2020
  • Webinar: COMMIT Without Fear – The Beauty of CAMO [Follow Up] November 13, 2020
  • Full-text search since PostgreSQL 8.3 November 5, 2020
  • Random numbers November 3, 2020
  • Webinar: Best Practices for Bulk Data Loading in PostgreSQL [Follow Up] November 2, 2020

Featured External Blogs

Tomas Vondra's Blog

Our Bloggers

  • Simon Riggs
  • Alvaro Herrera
  • Andrew Dunstan
  • Craig Ringer
  • Francesco Canovai
  • Gabriele Bartolini
  • Giulio Calacoci
  • Ian Barwick
  • Marco Nenciarini
  • Mark Wong
  • Pavan Deolasee
  • Petr Jelinek
  • Shaun Thomas
  • Tomas Vondra
  • Umair Shahid

PostgreSQL Cloud

2QLovesPG 2UDA 9.6 backup Barman BDR Business Continuity community conference database DBA development devops disaster recovery greenplum Hot Standby JSON JSONB logical replication monitoring OmniDB open source Orange performance PG12 pgbarman pglogical PG Phriday postgres Postgres-BDR postgres-xl PostgreSQL PostgreSQL 9.6 PostgreSQL10 PostgreSQL11 PostgreSQL 11 PostgreSQL 11 New Features postgresql repmgr Recovery replication security sql wal webinar webinars

Support & Services

24/7 Production Support

Developer Support

Remote DBA for PostgreSQL

PostgreSQL Database Monitoring

PostgreSQL Health Check

PostgreSQL Performance Tuning

Database Security Audit

Upgrade PostgreSQL

PostgreSQL Migration Assessment

Migrate from Oracle to PostgreSQL

Products

HA Postgres Clusters

Postgres-BDR®

2ndQPostgres

pglogical

repmgr

Barman

Postgres Cloud Manager

SQL Firewall

Postgres-XL

OmniDB

Postgres Installer

2UDA

Postgres Learning Center

Introducing Postgres

Blog

Webinars

Books

Videos

Training

Case Studies

Events

About Us

About 2ndQuadrant

What does 2ndQuadrant Mean?

News

Careers 

Team Profile

© 2ndQuadrant Ltd. All rights reserved. | Privacy Policy
  • Twitter
  • LinkedIn
  • Facebook
  • Youtube
  • Mail
Building Reactive PostgreSQL Repositories for Spring Boot Applications – Part... Advanced partition matching for partition-wise join Advanced partition matching for partition-wise join
Scroll to top
×