Conversational commerce is already common in markets where messaging apps function as digital storefronts. In Nigeria, WhatsApp often serves as the primary channel through which small businesses interact with customers, share menus, and coordinate orders. However, unlike markets such as Brazil and India, where payments are natively integrated into WhatsApp, Nigerian businesses typically rely on third-party Payment Service Providers (PSPs). This separation requires developers to orchestrate messaging workflows, payment initiation, and transaction confirmations across multiple systems.

To explore how these systems interact in practice and serve our customers, we built a small pilot application called Jollof Boss — a WhatsApp-native food ordering service built with WhatsApp Cloud APIs and integrated with a Nigerian PSP (Paystack). The pilot instrumented the full order-to-payment lifecycle across pickup and delivery workflows, allowing us to observe latency, workflow coordination, and integration patterns between messaging infrastructure and payment services.

This article shares technical observations from that pilot, focusing on developer implementation patterns encountered when integrating WhatsApp Cloud messaging workflows, catalog-based ordering, webhook-driven order events, and external payment providers. The goal is to provide practical insights that may help developers design similar conversational commerce systems.

System Overview

The Jollof Boss system implemented a WhatsApp-native food ordering workflow covering the full order lifecycle:

Customer → Menu → Order → Payment → Merchant/Customer Notification

The architecture connects messaging infrastructure with payment processing while keeping the entire experience within the WhatsApp conversation.

Technology Stack

The pilot was implemented using the following components:

1. WhatsApp Cloud APIs: messaging, catalog menus, order events
2. Spring Boot Backend: workflow orchestration and state management
3. Paystack PSP integration: payment authorization and confirmation
4. Webhook Architecture: event-driven transaction lifecycle

Architecture

The system was implemented using an event-driven orchestration model as shown in the architecture diagram below.

Observed Transaction Metrics

During the pilot deployment, the backend recorded timestamps across each stage of the ordering workflow.

These metrics are instrumentation observations from a small pilot deployment, not platform benchmarks.

Across both workflows, payment completion represented the largest portion of transaction time. Most of this delay was attributable to user interaction steps such as authentication and payment interface navigation.

Key Implementation Observations

During the development of the conversational ordering workflow, several recurring integration patterns emerged.

These patterns reflect how developers currently coordinate messaging workflows, catalog data, and payment integrations when building conversational commerce systems on WhatsApp.

1. Catalog Menus Are Application-Defined

Interactive catalog menus using the WhatsApp product_list message type require developers to define menu sections and product identifiers directly within the API payload.

Example request:

{
  "type": "interactive",
  "interactive": {
    "type": "product_list",
    "header": {
      "type": "text",
      "text": "Jollof Boss Menu"
    },
    "body": {
      "text": "Choose a meal"
    },
    "action": {
      "catalog_id": "158747027232639",
      "sections": [
        {
          "title": "Jollof Rice Packs",
          "product_items": [
            { "product_retailer_id": "4ru83njoue" }
          ]
        }
      ]
    }
  }
}

In practice, applications become responsible for managing:

• menu section structure
• product groupings
• product identifiers

This often leads developers to maintain local representations of the catalog in order to compose menus dynamically.

Possible Direction

One potential improvement would allow merchants to define menu sections directly in Meta Commerce Manager, enabling applications to retrieve structured catalog layouts dynamically instead of composing menus in the application layer with hard-coded sections and product identifiers.

Merchants could also mark sections as active or out-of-stock without requiring application updates.

2. Order Payloads Contain Product IDs but Not Product Names

When a customer places an order, WhatsApp sends an order webhook event containing product identifiers, quantities, and prices.

Example payload:

{
  "catalogId": "158747027232639",
  "productItems": [
    {
      "productRetailerId": "q44n1fqt6z",
      "quantity": 1,
      "itemPrice": 13000,
      "currency": "NGN"
    }
  ]
}

However, the payload does not include human-readable product names.

To generate readable confirmations, such as:

1 × 5-Litre Bowl Jollof Rice  
1 × Fried Chicken  
Total: NGN 17,000

Applications typically resolve product names through one of two ways:

Catalog API lookups resolving each productRetailerId through additional API calls or

Local catalog caches for maintaining a synchronized local copy of the catalog.

Both approaches introduce additional complexity in the application layer.

Possible Direction

Including product names directly in the order payload could simplify order confirmation workflows.

Example:

{
  "productRetailerId": "q44n1fqt6z",
  "productName": "5-Litre Bowl Jollof Rice",
  "quantity": 1,
  "itemPrice": 13000,
  "currency": "NGN"
}

This could reduce catalog lookup requests, backend orchestration logic and response latency in conversational workflows

3. Merchant Inputs Often Require Free-Text Parsing

Some conversational workflows require merchants to provide operational values before payment can proceed. In the delivery workflow, the merchant needed to provide a delivery fee based on the customer’s location.

Since WhatsApp Cloud APIs currently do not support structured merchant input fields, the pilot collected this value through formatted free-text messages.

Example format:

DeliveryFee-PhoneNumber = 5000-234XXXXXXXX

Backend workflow:

Merchant message received
        ↓
Validate format
        ↓
Parse delivery fee
        ↓
Generate payment link

While effective, this approach introduces:

• fragile parsing logic
• strict message formatting requirements
• additional backend validation logic

Possible Direction

Structured input fields similar to a Call-To-Action (CTA) Button interactive template could simplify operational workflows that require merchant-provided values.

Conceptual example:

{
  "messaging_product": "whatsapp",
  "to": "<merchant_number>",
  "type": "template",
  "template": {
    "name": "request_delivery_fee",
    "language": { "code": "en" }
  },
  "cta_input": {
    "fields": [
      {
        "name": "delivery_fee",
        "label": "Delivery Fee (NGN)",
        "type": "number",
        "required": true
      }
    ]
  }
}

Structured inputs could support workflows requiring operational values such as:

• delivery fees
• preparation times
• stock confirmation
• discount values

Final Thoughts

This pilot demonstrates how conversational commerce workflows can be implemented using WhatsApp Cloud APIs and external payment providers.

Messaging delivery, webhook handling, and payment integrations operated reliably within an event-driven architecture.

The primary engineering effort centred on coordinating messaging events, catalog data, merchant inputs, and payment lifecycle events across systems. These patterns are not blockers, but they shape how developers currently design conversational commerce systems on WhatsApp.

The implementation observations documented here reflect a small pilot deployment but highlight patterns developers may encounter when building conversational commerce systems on WhatsApp.

Project Context & Further Reading

This project forms part of the Jollof Boss conversational commerce pilot.

A broader discussion of the ecosystem implications is available in the Techpoint Africa article.

These observations are also published in the GitHub repository README for developers who prefer reviewing them in a repository format.

Even in the shadows,
you are here with me,
holding and guiding me
through the darkest of nights.

Even in the silence,
I hear your voice in my heart

When all is lost,
You keep whispering to me
about the future yet to unfold,
and the past we’ve shared -

The history we’ve had
is written in the scars of my heart,
and our memories
are deeply ingrained in them.

Even in the shadows,
I hear your footsteps,
and smell your perfume.

The warmth of your skin
comforts me in the coldest of nights,
but it’s never enough
to satisfy my longing for you — 
my love and my light.

I am lost without you,
and I tremble and fall
a thousand times
without you by my side.

But even on my deepest lonely days,
you’re here with me,
walking by my side.

At yonder bank, we shall meet

Oh fairest of them all

Bon voyage!

Introduction

DigitalOcean App platform is a Platform-as-a-service (Paas) that allows developers to publish code directly to DigialOcean servers without worrying about the underlying infrastructure. The Platform supports two ways to build an image for your app: Cloud Native Buildpacks and Dockerfiles.

When an app is deployed to the App Platform either via GitHub or DockerHub, it defaults to using Dockerfile if one is present in the root directory or specified app spec. Otherwise, the App Platform checks your code to determine what language or framework it uses. If it supports the language or framework, it chooses an appropriate resource type and uses the proper buildpack to build the app and deploy a container.

Java/Spring boot is not supported out of the box on the App platform hence developers rely on a Dockerfile for deployment. This sometimes could be a daunting challenge as there is little documentation about it and it depends on the level of Docker expertise of the developer.

In this article, you’ll learn how to deploy a Spring Boot app with a Docker to the DigitalOcean App platform. You’ll build a Spring Boot app that saves and retrieves messages from a postgres database, set instructions in the Dockerfile, push the code to a GitHub repository, then configure the application as a DigitalOcean app, attach a PostgreSQL database and deploy the app.

Prerequisites

For this tutorial, you’ll need the following:

• Java 8 version or greater installed on your local machine.
• Git installed on your local machine. You can follow the tutorial Contributing to Open Source: Getting Started with Git to install and set up Git on your local computer.
• A local machine with Docker installed. Your local machine can be running any Linux distribution, or even Windows or macOS. For Windows and macOS, install Docker using the official installer. If you have Ubuntu 16.04 running on your local machine, but Docker is not installed, see How To Install and Use Docker on Ubuntu 16.04 for instructions.
• A local machine with Maven installed. Your local machine can be running any Linux distribution, or even Windows or macOS. For macOS, See How to install Maven on Mac OS by Pankaj. For Linux See How to install Maven on Linux (Ubuntu) by Pankaj.
• Spring Boot Command Line Tool which you can use to quickly prototype with spring without an IDE. See Installing the Spring Boot CLI for details on how to install the CLI, Maven, Gradle and an spring boot example.
• Spring Boot based development projects by reading Spring Boot Tutorial by Rambabu Posa.
• Spring Data JPA by reading Spring Data JPA by Pankaj
• Postgresql Database by reading What is PostgreSQL by Mark Drake. See How To Install and Use PostgreSQL for details on how to install and use PostgreSQL.
• A DigitalOcean account.
• An account on GitHub, which you can create by going to the Create your Account page.

Step 1 — Create a Spring Boot Application

In this step, you’ll create a Spring Boot application using the Spring Boot CLI. You should explore the various installation options.

Note: If you encounter the error below, please install OpenJDK 17
‘LinkageError` mismatch (that the JRE was being set up with Java 11/bytecode 55 but needed to be run with Java 17/bytecode 61

To start, initialize a new Spring Boot project using the init command. The init command lets you create a new project by using the start.spring.io without leaving the shell, as shown below:

spring init --build=maven --java-version=17 --dependencies=web,data-jpa,postgresql spring-boot-docker

The --build flag indicates the build type which could be maven or gradle. The --java-version flag indicates the preferred Java version. The --dependencies flag shows the list of project dependencies. This project uses the spring-boot-starter-web, spring-boot-starter-data-jpa and postgresql database driver.

Essentially, the above command creates a spring-boot-docker directory with a Maven-based project.

The output of the init command indicating the project creation is shown below:

Using service at https://start.spring.io
Project extracted to '/Users/your directory/spring-boot-docker'

You can list the capabilities of the Spring Boot CLI service by using the --list flag to list all dependencies as shown below.

spring init --list

At this point, your project is set up in a new directory. Switch to the new directory:

cd spring-boot-docker

You have now created a springboot project and you are currently in the project folder. In the next section, you’ll add a custom Java class managed by Spring Data JPA that will store data in the postgresql database.

Step 2 — Add Model Class

In this step, you’ll create a Message Java class that will hold messages for our application. the Message class will contain two fields: Id and body.

Since you’re in your project directory, navigate to the project root directory using this command:

cd src/main/java/com/example/springbootdocker

Create a new Message.java file:

touch Message.java

Open the Message.java file:

nano Message.java

Add the Message class to hold the ID and body of the message:

package com.example.springbootdocker;

//import javax.persistence.*;
import jakarta.persistence.*;
@Entity
@Table(name = "message")
public class Message {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "id", nullable = false)
    private Long id;
    private String body;
    public Long getId() {
        return id;
    }
    public void setId(Long id) {
        this.id = id;
    }
    public String getBody() {
        return body;
    }
    public void setBody(String body) {
        this.body = body;
    }
}

The above is a simple Message.java class that has the Id and body as the only fields with their corresponding getter and setter methods.

If you are using Java 17, you need to change the import statement from import javax.persistence.*; to import jakarta.persistence.*.

The @Entity annotation specifies that the Message class is an entity and is mapped to a database table.

The @Id annotation specifies the primary key of the entity and the @GeneratedValue provides for the specification of generation strategies for the values of primary keys.

You have now created a Message class mapped to the postgres database that will hold messages. In the next step, you’ll create a repository layer that will provide the mechanism for storage, retrieval, search, update and delete operations on the Message entity.

Step 3 — Add Repository Layer

In this step, you’ll create a Java interface annotated with the @Repository annotation. This annotation is used to indicate that the class provides the mechanism for storage, retrieval, search, update and delete operations on the Message entity. For more details on @Repository annotation, see Spirng @Repository Annotation by Pankaj.

In your project directory, create a MessageRepository.java file:

touch MessageRepository.java

Open the MessageRepository.java file:

nano MessageRepository.java

Add the MessageRepository Interface which extends JpaRepository:

package com.example.springbootdocker;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

@Repository
public interface MessageRepository extends JpaRepository<Message, Long> {}

The MessageRepository interface extends the JpaRepository which takes the Message class created in the previous step and the Long data type since the Id specified in the Message class is of type Long.

You have now created the repository layer for data accesss. In the next step, you’ll create a controller layer that’ll expose methods to save and retrieve messages via a RestFul webservice call.

Step 4 — Add Controller Layer

In this step, you’ll create a spring boot controller class that will expose two methods to save and retrieve messages from the database.

Still in your project directory, create a MessageController file:

touch MessageController.java

Open the MessageController.java file:

nano MessageController.java

Add the MessageController classs which exposes two methods to save and retrieve messages.

package com.example.springbootdocker;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;
import java.util.Optional;
@RestController
@RequestMapping("/message")
public class MessageController {
 
    @Autowired
    MessageRepository messageRepository;
    @GetMapping("/{id}")
    public Optional<Message> getMessage(@PathVariable("id") Long id) {
        return messageRepository.findById(id);
    }
    @PostMapping
    public Message saveMessage(@RequestBody Message message) {
        return messageRepository.save(message);
    }
}

The @RestController annotation is a convenience annotation that is itself annotated with @Controller and @ResponseBody. This annotation is applied to a class to mark it as a request handler. Spring RestController annotation is used to create RESTful web services using Spring MVC. Spring RestController takes care of mapping request data to the defined request handler method. Once response body is generated from the handler method, it converts it to JSON or XML response. See Spring RestController by Pankaj for more details on @RestController.

So far, you have been able to create a Message Entity, Message Repository layer as well as the Message controller class. To be able to save and retrieve messages per the preceeding steps, you need to add some database configurations for the postgres database. You’ll achieve this in the next step.

Note: You might need to change the import statements to match yours.

Step 5 — Add Postgres Database Configuration

In this step, you’ll add database credentials to the application.properties file which was created in step 1. The database credentials ensures that a secure database connection can be made to the database.

Navigate to the resources directory from the project root directory using this command:

cd src/main/resources

Open the application.properties file.

nano application.properties

Add the following properties:

spring.datasource.url=jdbc:postgresql://localhost:5432/<changeme>
spring.datasource.username=<changeme>
spring.datasource.password=<changeme>
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true

Note: You need to change the credentials for your database.

The spring.datasource.url specifies the host, port and the database name. The spring.datasource.username refers to the name of your database and the spring.datasource.password refers to the password.

spring.jpa.properties.hibernate.dialect makes hibernate generate better SQL for the chosen database.

spring.jpa.hibernate.ddl-auto is a Hibernate feature that controls the behaviour in a more fine-grained way. it could be create, create-drop, validate or update

spring.jpa.show-sql shows the sql in the logs for debugging.

In this step, you’ve added the necessary database configuration to the application.properties file. You're now ready to test your application locally. In the next step, you'll test your application.

Step 6 — Test Spring Boot App Locally

In this step, you’ll test the save and retrieve methods exposed in the controller in step 4.

For this, you’ll use curl command.

To run the app, navigate to the project root directory and run the command below:

mvn spring-boot:run

The output of the command indicating that the project is running is shown below:

o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2022-11-24 08:29:03.159  INFO 50443 --- [           main] c.e.springbootdocker.DemoApplication     : Started DemoApplication in 1.399 seconds (JVM running for 1.526)

To save a message, run the command below in a new terminal shell:

curl -X POST http://localhost:8080/message -H 'Content-Type:  application/json' -d '{"body":"Hello world, I am making progress so far"}'

The above request saves a new message record to the database, the output is shown below:

{"id":1,"body":"Hello world, I am making progress so far"}%

To retrieve a message by id, run the command below:

curl -X GET http://localhost:8080/message/1

The above request retrieves an existing message by id from the database, the output is shown below:

{"id":1,"body":"Hello world, I am making progress so far"}%

So far, you have created an application that’s working locally. In the next step, you’ll create a Dockerfile that will handle the build and deployment process.

Step 7 — Add a Dockerfile

In this step, you’ll add a Dockerfile to manage the build and deployment process.

Docker is an open-source platform for building, deploying, sharing and managing containerized applications. Developers can install the apps from a single package and get them up and running in minutes.

To Dockerize our Spring Boot App, a Dockerfile is used. The Dockerfileis a text document containing all the commands and instructions a user could call on the command line to assemble an image. A Docker image is composed of a stack of layers, each representing an instruction in our Dockerfile.

DigitalOcean App platform will rely on the Dockerfile for build instructions during deployment.

See this article for more information on Docker and this article for how to install Docker.

For this application, you’ll create a Dockerfile in the app's root directory using the following command:

touch Dockerfile

Open the Dockerfile:

nano Dockerfile

Add the following commands to the Dockerfile in order to build the image for the application.

FROM eclipse-temurin:11-jdk-jammy as builder
WORKDIR /opt/app
COPY .mvn/ .mvn
COPY mvnw pom.xml ./
RUN ./mvnw dependency:go-offline
COPY ./src ./src
RUN ./mvnw clean install -DskipTests

FROM eclipse-temurin:11-jre-jammy
WORKDIR /opt/app
EXPOSE 8080
COPY --from=builder /opt/app/target/*.jar /opt/app/*.jar
ENTRYPOINT ["java","-Dspring.profiles.active=prod", "-jar", "/opt/app/*.jar" ]

The above Dockerfile uses a multi-stage build process by copying results from one image to another. The first stage extracts the dependencies while the second stage copies the extracted dependencies to the final image.

The command FROM eclipse-temurin:11-jdk-jammy as builder defines the base image from the Eclipse Temurin project, one of the most popular official images with a build-worthy JDK. The Eclipse Temurin project provides code and processes that support the building of runtime binaries and associated technologies.

Note: that Java 11 is specified for the app build, which matches the Java version in step 1

The second command WORKDIR /opt/app creates a working directory of a Docker container at any given time. Any RUN, CMD, ADD, COPY, or ENTRYPOINT command will be executed in the specified working directory.

COPY .mvn/ .mvn command copies files from a local source location to a destination in the Docker container.

RUN ./mvnw dependency:go-offline runs the spring boot application. The resulting committed image will be used for the next step in the Dockerfile. dependency:go-offline goal resolves all dependencies including plugins and reports and their dependencies. After running this goal, you can safely work in offline mode.

RUN ./mvnw clean install tells Maven to do the clean phase in each module before running the install phase for each module. This clears any compiled files you have, making sure that you're really compiling each module from scratch.

Notice that the first image is labelled builder. We use it to run eclipse-temurin:11-jdk-jammy, build the JAR, and unpack it.

The second layer of the multi-stage build process contain the build configuration and the source code for the application while the earlier layer contain the complete Eclipse JDK image. This small optimization saves us from copying the target directory to a Docker image.

Finally, an ENTRYPOINT lets you configure a container that runs as an executable. It corresponds to your java -jar target/*.jar command.

For more information on Dockerfile commands, see Docker Explained: Using Dockerfiles to Automate Building of Images by O.S Tezer.

So far you have created a Dockerfile that contains the necessary commands needed to build a Docker image. In the next step, you'll build the Docker image locally.

Step 8 — Build Docker Image

In this step, you’ll build the Docker image locally based on the set of commands as specified in the Dockerfile.

To build a docker image, ensure your `Docker’ instance is running before you run this command:

docker build -t spring-boot-docker .

The docker build command builds Docker images from the Dockerfile and a context. A build's context is the set of files locates in the specified PATH or URL.

The output of the build command indicating that the successful build of the Docker image is shown below:

[+] Building 846.9s (16/16) FINISHED                                                                                                                                                                                  
 => [internal] load build definition from Dockerfile                                                                                                                                                             0.0s
 => => transferring dockerfile: 37B                                                                                                                                                                              0.0s
 => [internal] load .dockerignore                                                                                                                                                                                0.0s
 => => transferring context: 2B                                                                                                                                                                                  0.0s
 => [internal] load metadata for docker.io/library/eclipse-temurin:11-jre-jammy                                                                                                                                  4.7s
 => [internal] load metadata for docker.io/library/eclipse-temurin:11-jdk-jammy                                                                                                                                  4.7s
 => [stage-1 1/3] FROM docker.io/library/eclipse-temurin:11-jre-jammy@sha256:94a23660199bda9133dff36ef811446d9866859946de3b6fea03ba3dca6618bc                                                                    0.0s
 => [internal] load build context                                                                                                                                                                                0.0s
 => => transferring context: 1.26kB                                                                                                                                                                              0.0s
 => [builder 1/7] FROM docker.io/library/eclipse-temurin:11-jdk-jammy@sha256:ff15d0a337affefa41a3619cb5d8626c11e0d38c84e85ac3b0fafc5f86ff68e9                                                                    0.0s
 => CACHED [stage-1 2/3] WORKDIR /opt/app                                                                                                                                                                        0.0s
 => CACHED [builder 2/7] WORKDIR /opt/app                                                                                                                                                                        0.0s
 => CACHED [builder 3/7] COPY .mvn/ .mvn                                                                                                                                                                         0.0s
 => CACHED [builder 4/7] COPY mvnw pom.xml ./                                                                                                                                                                    0.0s
 => [builder 5/7] RUN ./mvnw dependency:go-offline                                                                                                                                                             819.9s
 => [builder 6/7] COPY ./src ./src                                                                                                                                                                               0.0s
 => [builder 7/7] RUN ./mvnw clean install -DskipTests                                                                                                                                                          21.6s 
 => [stage-1 3/3] COPY --from=builder /opt/app/target/*.jar /opt/app/*.jar                                                                                                                                       0.1s 
 => exporting to image                                                                                                                                                                                           0.1s 
 => => exporting layers                                                                                                                                                                                          0.1s 
 => => writing image sha256:0f5e9737106234ca975fd9b38e50e5e461872eb959b8fde1854adbfebb74b415                                                                                                                     0.0s 
 => => naming to docker.io/library/spring-boot-docker                                                                                                                                                            0.0s

In this step, you have successfully built a Docker image locally. In the next step, you'll push the app to a GitHub repository.

Step 9 — Push Code to GitHub

To deploy your app, App platform retrieves your source code from a specified Github repository.

Login to your GitHub acocunt and create a new public or private repository called spring-boot-docker. This automatically initializes the repository with git which enable you to push the code directky to GitHub.

To initialize the local repository, add the command:

git init

You’ll need to add the repository to your local project using this command:

git remote add origin https://github.com/your_name/spring-boot-docker

Next, switch to the main branch using the following command:

git branch -M main

Add all the project files to git using this command:

git add .

After adding the files, commit the files using:

git commit -m "commit message"

Finally, push to code to your Github repository using this command:

git push -u origin main

Once prompted, enter your GitHub credentials. If done successfully, you’ll receive a success message similar to:

Enumerating objects: 29, done.
Counting objects: 100% (29/29), done.
Delta compression using up to 10 threads
Compressing objects: 100% (21/21), done.
Writing objects: 100% (29/29), 60.07 KiB | 15.02 MiB/s, done.
Total 29 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/Ikhiloya/spring-boot-docker.git
 * [new branch]      main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.

In this step, you created a GitHub repository and pushed your code to that repository. In the next step, you’ll create a DigitalOcean app and deploy from your GitHub repository.

Step 10 — Deploy App to DigitalOcean App Platform

In this step, you’ll learn how to deploy your project from the GitHub repository to DigitalOcean App platform.

To start, login to your DigitalOcean account, click on the Create button and select Apps from the drop down menu:

You’ll be prompted to link your preferred GitHub repository which will require you to authorize DigitalOcean to be able to access your repositories. Choose the spring-boot-docker repository you created earlier and click on next as shown below:

You’ll notice that App platform has detected the Dockerfile from the project repository. You can choose Edit plan if you want to change the plan.

Click Next to proceed to add Environment Variables which enables all resources to have access to variables at build time and runtime.

For now, you don’t need to add anything to the Environment variables as you have not attached a database which will be discussed later.

Click Next to select your preferred app name and region that’s closest to your physical location.

Click Next again to review your app’s resources after which you can click on Create Resources to get your app running.

This effectively deploys the application using the Dockerfile you created. Since you have not attached a database, you'll have a database connection error:

org.postgresql.util.PSQLException: connection to localhost:5432 refused .....

To fix this error, you need to attach a database and add the database credentials as environment variables.

Step 11 — Attach a Postgresgl Database

In this step, you’ll attach a database and add the database connection parameters as Environment variables. This will effectively eliminate the database connection error observed in the previous step.

Click the Create button and select Database; select a postgres database and your preferred plan.

Click Next to view the database credentials.

You need to add the database credentials as environment variables as key-value pairs. Navigate to the Settings tab of your app, click on the app component and edit the Environment Variables with the following:

SPRING_DATASOURCE_URL=jdbc:postgresql://<host>:<port>/<dbname>?sslmode=require
SPRING_DATASOURCE_USERNAME=<changeme>
SPRING_DATASOURCE_PASSWORD=<changeme>

Click on save and this will trigger the deployment process. Once the deployment is successful, you’ll see an output like this:

o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2022-11-24 08:29:03.159  INFO 50443 --- [           main] c.e.springbootdocker.DemoApplication     : Started DemoApplication in 1.399 seconds (JVM running for 1.526)

In this step you have learnt how to attach a database and add the database credentials as environment variables. In the next step, you’ll be able to test using the live url.

Step 12 — Test App using Live Url

In this step, you’ll obtain the app’s live url and test the endpoints to save and retrieve messages.

Click on the Apps tab, navigate to your app and copy the app’s live url.

To save a message, use the following command:

curl -X POST https://your-app-url/message -H 'Content-Type:  application/json' -d '{"body":"Hello world, I am making progress so far"}'

The above request saves a new message record to the database, the output is shown below:

{"id":4,"body":"Hello world, I am making progress so far"}%

To retrieve a message by id, run the command below:

curl -X GET https://your-app-url/message/4

The above request retrieves an existing message by id from the database, the output is shown below:

{"id":4,"body":"Hello world, I am making progress so far"}%

So far, you have been able to test the app using the app’s live URL.

Conclusion

In this tutorial, you have learnt how to deploy a Spring Boot App using a Dockerfile to DigitalOcean App platform, attach a database and test using the live URL.

You can find the source code for this project in this GitHub repository.

GitHub - Ikhiloya/spring-boot-docker

You can find the Markdown version of this article in this gist.

For further information, please visit the official App Platform product documentation.

I yearn for your presence

To be with you one last time

My soul beckons for your warm embrace

To lock my lips to every spot on your face

Don’t go! Please stay with me.

I can feel your presence in my heart

You’re in my every thought

Although you belong to yours

I wait to steal one final glance at you

Don’t go! Please stay with me.

An annotation is a form of syntactic metadata that provides data about a program but is not part of the program itself. Annotations have no direct effect on the operation of the code they are added to.

In Java, annotations can also be embedded in and read from Java class files generated by the Java compiler which allows annotations to be retained by the Java virtual machine at run-time and read via reflection.

Annotations can be used for the following:

• Detect errors or suppress warnings e.g @Override and@SuppressWarnings.
• Compile-time and deployment-time processing e.g code generation tools.
• Runtime processing.

This article shows how to leverage custom annotations to mark specific web service requests for caching in Retrofit. This is because we usually have a single Retrofit instance to make web service requests to the server. Therefore, it is necessary to devise a means of identifying requests that should be cached.

Use Case

Consider an app that displays a list of payment types (Cash, Bank Transfer, Bitcoin, Card, e.t.c.) which is fetched from a server.

Since the list of payment types rarely change, it makes sense to cache this request to reduce the number of backend calls for this resource. This and such-like requests would qualify for caching.

The Challenge

Having identified requests that qualify for caching, how do we ensure that only such-like requests are retrieved from the cache when there is no internet connection?

That is, how do we “mark” such requests as Cacheable.

The Proposed Solution

To solve this problem, the following are needed:

1. A cache to store and retrieve the resource.
2. A network interceptor to cache requests when the network is available.
3. A custom annotation to mark requests as Cacheable.
4. An offline interceptor to cache requests when the network is unavailable.
5. An OKHttp client and a Retrofit instance.

Step 1: Create a Cache

We simply create a cache of size 5MB to store and retrieve the server’s resources.

Please see the reference section for resources on caching in android.

Step 2: Create a Network Interceptor

This interceptor is called when there is a network connection and helps to fetch cached resources without making a network call to the server.

The max-age is set to 5 seconds which specifies the maximum age of a cached response. If the cached response’s age exceeds maxAge, it will not be used and a network request will be made.

To learn more about interceptors please see the links below:

• OkHttp Interceptors
• OkHttp Interceptors with Retrofit

Step 3: Create Custom Annotation

In this step, create a custom runtime annotation with the target set to Function. This annotation would be added to specific requests which would ensure that they are cached. The annotation is added to the Invocation class and made available at runtime.

@Retention(AnnotationRetention.RUNTIME) ensures that the annotation is available at runtime.

@Target(AnnotationTarget.FUNCTION) ensures that the annotation is applied to methods or functions such as the web service request abstract method.

@MustBeDocumented is a meta-annotation that ensures the annotation is included in the generated documentation for the element to which the annotation is applied.

Retrofit automatically adds an invocation to each OkHttp request as a tag. You can retrieve the invocation in an OkHttp interceptor for metrics and monitoring.

Step 4: Create an Offline Interceptor

This interceptor is called when there is no network connection. It intercepts the request and fetches the cached resource without making a call to the server.

In this interceptor, we check if the particular request is marked for caching. That is, we check if the request contains the Cacheable annotation. If the request contains the annotation, the stale cached response is retrieved otherwise it is not.

The first step is to retrieve the Invocation object from the request by tag. This is because Retrofit automatically adds an invocation to each OkHttp request as a tag.

Then, we can get the Cacheable annotation from the invocation instance.

Lastly, we check if the annotation is of type Cacheable before caching the request.

The full offline interceptor code is shown below:

Responses can be retrieved when the freshness lifetime has not exceeded the maxStale duration (7 days in this case). Once the maxStale duration is exceeded, responses can no longer be retrieved.

Step 5: Create OKHttp client and a Retrofit instance

The final step is to create the OKHttp client and retrofit that would contain the interceptors and caching mechanism.

With this, we can comfortably mark our request with the Cacheable annotation.

Unit Test

To ensure that the above implementation works as expected, the unit test below helps to check if the Cacheable annotation is injected for specific requests.

Alternative Solution

Another solution to this challenge is to add a custom header to the request and then check if the added header is present in the interceptor.

The offline interceptor would be:

Conclusion

In this article, we have seen how to use custom annotations to mark specific requests that require offline caching.

The concept presented in this article has been around for a while and it can be applied to different scenarios. Do well to explore other applications.

You can find the source code in the repository below.

Ikhiloya/RetrofitAnnotationBasedCaching-Kotlin

Thanks for reading and feel free to leave your comments and suggestions.

References

1. Oracle Java Annotations
2. Retrofit tips: Passing custom parameters from Retrofit’s request to OkHttp’s interceptor by Ryben Ahanesian
3. Custom Annotations with Retrofit 2 by André Tietz
4. Good way to unit test Retrofit interface declaration.

Resources on caching in android

1. Caching With Retrofit — Store Responses Offline by Bapusaheb Patil
2. Android Retrofit OkHttp Offline Caching
3. Retrofit Caching Example and Why it SUCKS
4. Cache-Control

Annotation-Based Offline Caching in Retrofit was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Firebase provides a powerful, simple, and cost-effective object cloud storage service. Also, the Firebase SDK adds Google security to file uploads and downloads. The SDK can be used to store images, files, videos, and other user-generated content.

This article seeks to achieve the following:

• Leverage Firebase storage to upload and download files in an existing spring boot server deployed on Heroku.
• Externalize Firebase service account configuration.

In my previous article, the Strategy design pattern was used to develop a spring-boot application that uploads and downloads files using either local file storage or AWS storage implementation depending on the specified profile(development or production).

The base code contained in this repository has a file storage contract for upload and download of files represented by an abstract class.

This article will show how to integrate Firebase storage with the existing spring boot application.

The Implementation

The implementation of Firebase storage involves the following steps:

1. Setup a Firebase project.
2. Add Firebase Admin SDK to the server.
3. Add Firebase Storage strategy implementation.

Let’s dive into the details of each step…

1. Setup Firebase project

To use Firebase, you need to create a Firebase project from the Firebase developers console which you can find here. Follow the project setup wizard to create a new project.

Once the project is created, navigate to the project settings on the firebase console, and on the service account tab, click “generate new private key” to generate a new private key that is contained in a configuration JSON file.

The configuration file is a JSON file that contains security keys with which the server authenticates with Firebase storage programmatically via the unified Admin SDK.

2. Add Firebase Admin SDK

The Firebase Admin SDK is used to interact with Firebase from a privileged environment to perform realtime file upload and download amongst other functions as contained in the documentation.

Furthermore, to use Firebase admin SDK, the following is needed:

• A Firebase project, which you have created in step 1.
• A configuration file with the service account credentials which you have obtained in step 1.

Proceed to add the Firebase admin SDK maven dependency to the spring-boot server:

<dependency>
  <groupId>com.google.firebase</groupId>
  <artifactId>firebase-admin</artifactId>
  <version>6.14.0</version>
</dependency>

The next step is to initialize the Admin SDK in the application that lets you use Firebase storage.

Note that the bucket name and project id can be gotten from the configuration file.

From the above, note that the file path to the service account configuration file was added. This is certainly not the best way to go as you do not want the file committed to source control. This will be handled in a later section.

3. Add Firebase Storage Strategy

Create a class that extends the existing storage strategy and provide firebase storage implementation for upload and download.

The upload method accepts a multipart file, creates a BlobInfo object before uploading the file to Firebase storage as can be seen below.

To download a file, pass the file name of an uploaded file to the firebase Storage service which returns a Blob object once the file is found.

The FirebaseStorageStrategy class can be seen below.

Deploying to Heroku

Deploying the application to Heroku will fail because Heroku does not support the file system as such the service account configuration file cannot be used. Also, you wouldn’t want to commit the configuration file to source control.

How can this be fixed?

Proposed Solution

The following steps can be taken to initialize the SDK in code without reading from a file.

1. Create environment variables to hold the values contained in the service account configuration file. The same environment variable should be created on Heroku as part of the config vars.

From the JSON structure above, create environment variables to hold the values.

2. Create a class to hold the contents of the service account configuration file.

3. Set the values of the environment variables from step 1 to the class fields from step 2.

4. Serialize the created object from step 3 to a JSON string using Jackson.

5. Convert the serialized JSON string to an input stream.

6. Finally, initialize the SDK with the input stream object from step 5.

The modified FirebaseStorageStrategy class can be seen below.

Conclusion

From the use case explained, it can be seen that it is quite easy to integrate Firebase storage with spring boot and deploy to Heroku with an externalized configuration file.

Many thanks to Frank Akogun of the Lagos Java User Group for his valuable insights.

You can find the source code in the repository below.

Ikhiloya/spring-boot-strategy-design-pattern-

Thanks for reading 😊

More Resources

• How to secure your Firebase project even when your API key is publicly available by Devesu
• Firebase Admin Setup
• Cloud Storage

Spring Boot with Firebase Storage was originally published in Analytics Vidhya on Medium, where people are continuing the conversation by highlighting and responding to this story.

The android work manager API runs deferrable, guaranteed background work when specified constraints are satisfied. The API also supports both asynchronous one-off and periodic tasks. For more about Android WorkManager, please read the following articles:

• Introducing WorkManager by Pietro Maggi
• WorkManager Basics by Lyla Fujiwara
• Periodic Tasks with Android WorkManager by Ikhiloya Imokhai

A Periodic WorkRequest is used to perform recurring deferrable tasks. This executes periodically with the first execution happening immediately the given Constraints are satisfied. For example, you may want to periodically backup your data, download fresh content in your app, push local data to a remote server, or upload logs to a server when constraints such as network availability, battery, or storage are satisfied.

A deferrable task is one that does not need to be executed immediately.

The WorkManager API does not support chaining of PeriodicWorkRequest which makes it quite difficult to maintain a particular order for related dependent tasks as is done for a OneTimeWorkRequest.

In this article, I will show with an example of how we can maintain some sort of order or chaining between dependent related tasks for periodic work requests.

The Use Case

Let us consider an app to be used for the collection of personal data from a community in some remote location. Due to the anticipated network constraint of the location, the app is expected to work offline and push the data to a remote server when there is sufficient network coverage.

The pushing or posting of local data to a remote server when there is sufficient network coverage passes for a deferrable task and as such a Periodic Work request can be used to perform such operation.

The app is to capture each person’s data as well as information about their beneficiaries. It follows that a person can have more than one beneficiary which is a typical one-to-many relationship as can be seen below:

From figure 1, a Beneficiary cannot exist without a Person, hence, the creation of a Beneficiary presupposes that a Person must have been created.

For the offline app, the local data source(Android Room in this case) would be the single source of truth. As such, the primary key identifier for data stored locally would drive every CRUD operation we perform on the data.

Furthermore, we can deduce the following from figure 1 for the Person entity:

• localId : This is the primary key for the “person” entity. It identifies the record in the local database.
• id : This is the primary key for the record in the remote database. It is null until the record is pushed to the remote database after which it is updated locally with the record id value from the remote.
• state : This is used to know whether or not the local data has been pushed to the remote. It is set to pending when the data is resident in the local storage after which it is updated to synced state once the data is pushed to the remote.

The data class for Person is shown below:

Similarly, we can deduce the following from figure 1 for the Beneficiary entity:

• localId : This is the primary key for the “beneficiary” entity. It identifies the record in the local database.
• id : This primary key for the record in the remote database.
• personLocalId : This represents the foreign key in the person-to-beneficiary relationship locally.
• state : This is used to know whether or not the local data has been pushed to the remote. It could either be pending or synced

The data class for Beneficiary is shown below:

The Challenge

Since we have resolved to use a Periodic WorkRequest, how then do we ensure some form of order for the parent-child relationship that exists between the Person and Beneficiary entities?

That is, how do we ensure that the Person(parent) entity is pushed to the remote before the Beneficiary(child) entity is pushed.

This is necessary because the remote backend API requires that a Beneficiary is created with the remote id of the Person entity.

The above presents a daunting challenge since periodic work requests cannot be chained. To solve this, we need to device a means to ensure that the order of precedence as explained in the preceding paragraph is followed.

The Proposed Solution

To solve this problem, we will take the following steps:

1. Create an abstract Worker Contract class that extends Android Worker and defines our custom rules.
2. Create worker classes for Person and Beneficiary that extends from the Worker Contract class defined in step 1.
3. Create Periodic work requests using the worker classes created in step 2.

Let’s dive into the details of each step.

Step 1: Create a Worker Contract

This is an abstract class that defines the rules for pushing data stored locally to the remote data source. The contract shows the various conditions that must be met before an entity can be pushed to the remote. The class extends Android Worker and overrides the doWork() method wherein the rules and order of execution of the periodic tasks are defined as can be seen in the code snippet below. It also contains various methods as explained with the comments shown in the code snippet below:

The WorkerContract is the “engine” of this solution, as it brings all the pieces together and ensures that the required order of precedence is adhered to strictly.

Depending on your scenario, your contract rules might be different.

Step 2: Create Worker classes

With the worker contract well defined, we need to create worker classes that provide a concrete implementation of the WorkerContract for both Person and Beneficiary entities.

The PersonWorker extends from the WorkerContract and provides the logic for pushing Person data to the remote server. The code snippet below explains the PersonWorker class.

As can be seen from the saveCallResult method, once the local data is pushed successfully, the local data state and the remote id are updated accordingly.

Similarly, the BeneficiaryWorker implementation is shown below. Here, the hasParentRelationship method is set to return true because it is the child entity. Once the hasParentRelationship method returns true , we need to check if the Person entity associated with the Beneficiary via the personLocalId field has been pushed to the remote. This is done via the checkParentStatus() method which returns a boolean value depending on the state of the parent entity. This is shown in the code snippet below:

Step 3: Create Periodic Work Requests

In this step, we will create periodic work requests for each worker since we have successfully defined our rules via the WorkerContract and also created concrete implementations of the WorkerContract.

First, we need to define the network constraints as shown below. That is, we want to push the local data once there is network connection.

The periodic work request for saving a person is shown below.

Similarly, the Beneficiary work request is shown below:

From the work requests above, note that we used a unique periodic work request to ensure that only one PeriodicWorkRequest of a particular name can be active at a time. For our case, we only want one operation to be active at a time; if there is a pending one, we will let it run to completion, otherwise, we insert the new work.

Result

Essentially, the person and beneficiary workers would start at the same time and will be executed as soon as the defined constraints are met. However, the Beneficiary worker would not be able to push data to the remote data source until the related person entity has been pushed as specified by the entity-relationship and the Worker Contract. By this, we can achieve a sense of order and precedence in the execution of the periodic tasks.

Note that the solution presented in this article is by no means a general one. It is only specific to this use case. However, it gives a general idea as to how problems of the kind may be solved.

Output

You can find the source code for the android client and spring-boot backend in the repository below.

Ikhiloya/WorkManager-Dependent-Periodic-Task

Thanks for reading and feel free to leave your comments and suggestions.

References

• Introducing WorkManager by Pietro Maggi
• Periodic Work Request
• WorkManager Basics by Lyla Fujiwara
• Schedule tasks with WorkManager
• Getting started with WorkManager
• Background work with WorkManager codelab
• Recurring Work
• Periodic Tasks with Android WorkManager by Ikhiloya Imokhai

Extending Android WorkManager for Dependent Periodic Tasks was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Strategy design pattern is a behavioral software design pattern that defines a family of algorithms, encapsulates each one, and makes them interchangeable[1]. It enables the selection of the clients at runtime. The Strategy pattern is flexible since it defers the decision about which algorithm to use until runtime.

To find out more about the Strategy design pattern and the ideal scenarios for use, please see the reference section.

In this post, I’ll explain how I leveraged the strategy design pattern to solve my challenge.

Problem statement

To be able to handle multiple email clients and storage types depending on the environment or profile in which the application is running.
My project requires that Gmail client and local file storage be used for sending mails and storing files respectively while working locally[dev-profile].

Also, I needed to use the SendGrid mail client and AWS storage service for sending emails and storing files respectively while in production[prod-profile].

In summary, here is what I want to achieve:
dev profile: Gmail client and local file storage should be used for sending emails and storing files.
prod profile: SendGrid client and AWS storage for sending mails and storing files.

This implementation is done using the Spring boot framework and leverages heavily on the inversion of control and dependency injection it provides.

We’ll explore these applications independently.

Let’s dive in…..

1. Email Implementation.

The diagram below shows the high-level design of the Strategy pattern for our email service.

The strategy pattern ensures that the appropriate email client is used to send emails depending on your active profile: dev or prod.
The fundamental concept of the strategy pattern is to aggregate a family of related entities such that the application knows the appropriate client to use at runtime. This eliminates the need to write boilerplate code to ensure that the right client is used.

Let’s define the various classes as shown in the diagram above

1. MailStrategy

This is an interface that contains the various method definition for an email client. It defines the contract for all other concrete implementation. An abstract class could also suffice.

2. SendGridEmailStrategy

This is a concrete implementation of the MailStrategy contract. It holds the logic for sending emails using the SendGrid client.

3. GmailStrategy

This is a concrete implementation of the MailStrategy contract. It holds the logic for sending emails using the Gmail client.

4. MailFactory

To ensure that the appropriate email client is used at runtime depending on the specified active profile, a factory is used. This leverages the factory creation design pattern to create the right mail client.

5. MailService

A typical service class that holds the logic for sending emails. It is in the service layer that the beauty of the strategy pattern is seen. It does not need to worry about the specific implementation of the different mail strategies rather it just programs to the MailStrategy interface and lets the appropriate implementation be called at runtime.

Remember the basic OOP principle:

“program to interface, not implementations”

2. File Storage Implementation.

The diagram below shows the high-level design of the storage strategy pattern implementation.

Similarly, let’s define the various classes as shown in the diagram above.

1. StorageStrategy

This interface defines the contract for file storage. All other concrete implementations must abide by this contract. It contains just a method to upload a file as can be seen below:

2. AwsStorageStrategy

This provides the amazon web service(AWS) specific concrete implementation of file upload. It encapsulates the logic for uploading files to the AWS storage as can be seen below. This implementation is called only when the prod profile is specified during the build.

3. FileStorageStrategy

This is called when the dev profile specified. It holds the logic for storing files using the local file system as can be seen below. It stores files to a specified folder locally.

4. StorageFactory

This performs a similar function as the MailFactory already explained.

5. StorageService

This is analogous to the MailService explained above. It is the service layer that holds the logic to upload files irrespective of the different implementations.

Conclusion

As can be seen from the above implementations, it is very easy to switch between the dev and prod profiles without having to worry about the necessary implementation as it is taken care of at runtime owing to the strategy design pattern.

You could easily switch profile in spring by running this command:

Viola all the implementation code remains intact.

You can find the source code in the repository below.

Ikhiloya/spring-boot-strategy-design-pattern-

Thanks for reading and your suggestions and comments are welcomed.

References

1. Head First Design Patterns

📝 Save this story in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.

Recently I started a small project which required authentication and authorization. As a Java developer familiar with spring boot, I decided to leverage on spring boot to deliver the goods.

One key decision I made early on was to use JWT for authentication and authorization as I have read about the stateless capacity of JWTs.

However, along the line, I encountered some issues and made some personal findings that form the core of this article.

Disclaimer: As the title suggests, the views expressed here are based on my experience with JWTs which is meant to elicit opinions and expand the discussion about JWTs and it’s inherent capacities.

I will begin by explaining how I set up the authentication and authorization in spring boot as well as the modifications made to circumvent the issues faced.

Note this project uses a Postgres data source

The code below shows the initial JWT filter.

Challenges
1. User Log out

One of the challenges I faced during this implementation was how to securely log out a user.

The Scenario

In this case, when a user logs out of the client app, the token is still valid if it’s not expired before logout. This poses a security threat as the valid token can be “hijacked” and used to access resources from an unknown client.
With this flaw, the whole idea of stateless authentication and authorization was defeated as there is no clear way of invalidating a token.

Remediation

To circumvent this issue, I had to make do with popular opinions and suggestions on this matter. Create an in-memory data source to store the token as part of blacklisted JWTs when the user logs out, authenticate against them for each request to the server and routinely delete expired tokens from the data source to reduce the sample size, hence improving search time for each request.

I achieved this seamlessly by checking if the token is already in the list of blacklisted tokens maintained. This is shown below although I used the Postgres database.

No doubt this works fine, but could potentially increase the response time for every request as the JWT blacklist is queried for every request. This was a cost I had to make do with.

2. Database Authentication not done for each request

Another funny behaviour I noticed whilst moving from my test environment to the UAT environment was that while requesting a resource, database authentication is not done. That is, only the validity of the token is checked and once a token is valid, voila! a resource is granted to the client. This may not be the usual case as the secret key used in the generation of the token should be securely protected but what if in extreme cases, the secret key is exposed. The attacker can easily generate a signed token and would be able to access a resource on your server.

The Scenario

In my case, the token I used for the test was able to access resources from my UAT server although both used the same secret for the token generation which should not have been. The point I’m trying to make here is that for each request there’s no authentication against the database to ascertain the validity of the principal in the token.

Remediation

To circumvent this, I added another layer of check to the JWT filter to do a check against the database for every request to the server. This again added another complexity as it may potentially lead to a lag in the server owing to the routine authentication against the database.

See below the code for the above implementation.

Questions

Considering the aforementioned scenarios, I would like to pose the following questions to my audience and developers experienced using JWTs.

1. What is the ideal use case of JWTs?
2. What security measures apart from the aforementioned can be used to safely secure apps using JWTs without compromising the stateless nature of JWTs?

Conclusion
Like I said ab initio, the opinions expressed herein are mine and based on the scenarios that played out whilst working with JWTs in spring boot.

Feel free to expand these issues so we can get a clearer perspective of the modus operandi of JWTs and potential pitfalls to avoid.

Thanks :)