DEV Community: Dhruv garg

Stop Hammering Your Database: A Guide to Request Coalescing

Dhruv garg — Sun, 07 Sep 2025 13:50:16 +0000

As we already know, the bottleneck is mostly the database instead of your application code for the majority of products. so let’s look at one of the ways in which we can reduce load on database and make everything faster using easy and smart trick. i.e. Request Coalascing. I first heard about it in a blog by discord

Request Coalascing is a way in which we only make 1 call to DB for all the concurrent calls for the same data, and then return same result to all the callers.

Let’s look at the code and run some benchmarks.

Benchmark Setup:

Macbook pro m3
Autocannon as benchmarking tool
Redis and Postgres for database
Fastify server (it’s criminal to use express nowadays)

Even though I am using node.js for this experiment, same pattern can be implemented in any language.

Redis Benchmarks

I will be using redis for this this test, so that we can see that even for fastest in-memory store, how much difference it makes to use request coalascing. The effect of it will be much larger for other databases or IO operations which take longer to process. We will also be running redis docker image on local, so that this test is easy to replicate and the latency due to network operation is minimal.

Run Redis on local using docker:

docker run -d --name redis -p 6379:6379 redis

Let’s first take the base case:

import Fastify from "fastify";

import Redis from "ioredis";

const fastify = Fastify({});

const redis = new Redis("redis://127.0.0.1:6379", {

  noDelay: true,

  keepAlive: 100000,

});

fastify.get("/test", async function (request, reply) {

  const res = await redis.get(request.url.slice(1));

  reply.send(res);

});

fastify.listen({ port: 3000 }, function (err, address) {

  if (err) {

    fastify.log.error(err);

    process.exit(1);

  }

  console.log("Server is now listening on", address);

});

When you run benchmark for this, you will observe:

> node --experimental-strip-types base.ts

(node:87719) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time

(Use `node --trace-warnings ...` to show where the warning was created)

Server is now listening on http://[::1]:3000

❯ autocannon -d 10 -c 5000 --renderStatusCodes http://0.0.0.0:3000/test

Running 10s test @ http://0.0.0.0:3000/test

5000 connections

┌─────────┬───────┬───────┬────────┬────────┬──────────┬───────────┬─────────┐

│ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │

├─────────┼───────┼───────┼────────┼────────┼──────────┼───────────┼─────────┤

│ Latency │ 12 ms │ 92 ms │ 151 ms │ 169 ms │ 92.57 ms │ 118.16 ms │ 9943 ms │

└─────────┴───────┴───────┴────────┴────────┴──────────┴───────────┴─────────┘
┌───────────┬─────────┬─────────┬────────┬─────────┬──────────┬──────────┐

│ Stat │ 1% │ 2.5% │ 50% │ 97.5% │ Avg │ Stdev │

├───────────┼─────────┼─────────┼────────┼─────────┼──────────┼──────────┼

│ Req/Sec │ 37,343 │ 37,343 │ 48,735 │ 51,199 │ 47,670.4 │ 3,738.22 │

├───────────┼─────────┼─────────┼────────┼─────────┼──────────┼──────────┼

│ Bytes/Sec │ 20.7 MB │ 20.7 MB │ 27 MB │ 28.4 MB │ 26.5 MB │ 2.08 MB │

└───────────┴─────────┴─────────┴────────┴─────────┴──────────┴──────────┘
┌──────┬────────┐

│ Code │ Count │

├──────┼────────┤

│ 200 │ 476742 │

└──────┴────────┘

Now, the version with request coalascing:


import Fastify from "fastify";

import Redis from "ioredis";

const fastify = Fastify({});

const redis = new Redis("redis://127.0.0.1:6379", {

  noDelay: true,

  keepAlive: 100000,

});

const pendingPromises = new Map<string, Promise<string>>();

fastify.get("/test", async function (request, reply) {

  const key = request.url.slice(1);

  const inFlight = pendingPromises.get(key);

  if (inFlight !== undefined) {

    return reply.send(await inFlight);

  }

  const promise = redis.get(key);

  pendingPromises.set(key, promise);

  const res = await promise;

  pendingPromises.delete(key);

  reply.send(res);

});

fastify.listen({ port: 3000 }, function (err, address) {

  if (err) {

    fastify.log.error(err);

    process.exit(1);

  }

  console.log("Server is now listening on", address);

});

When you run benchmark for this, you will observe:


❯ node --experimental-strip-types requestCoalascing.ts

(node:87719) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time

(Use `node --trace-warnings ...` to show where the warning was created)

Server is now listening on http://[::1]:3000

❯ autocannon -d 10 -c 5000 --renderStatusCodes http://0.0.0.0:3000/test

Running 10s test @ http://0.0.0.0:3000/test

5000 connections

┌─────────┬───────┬───────┬────────┬────────┬──────────┬──────────┬─────────┐

│ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │

├─────────┼───────┼───────┼────────┼────────┼──────────┼──────────┼─────────┤

│ Latency │ 30 ms │ 58 ms │ 106 ms │ 119 ms │ 64.46 ms │ 109.4 ms │ 9851 ms │

└─────────┴───────┴───────┴────────┴────────┴──────────┴──────────┴─────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬──────────┐

│ Stat │ 1% │ 2.5% │ 50% │ 97.5% │ Avg │ Stdev │

├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼──────────|

│ Req/Sec │ 66,815 │ 66,815 │ 68,351 │ 71,935 │ 68,960 │ 1,440.79 │

├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼──────────|

│ Bytes/Sec │ 37.1 MB │ 37.1 MB │ 37.9 MB │ 39.9 MB │ 38.3 MB │ 794 kB │

└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴──────────┘
┌──────┬────────┐

│ Code │ Count │

├──────┼────────┤

│ 200 │ 689591 │

└──────┴────────┘

Results

As we can see just by adding Request Coalascing:

we were able to process 44% more requests.
There was lower load on Redis servers. (we will see actual numbers with postgres test)
We even improved p99 latency from 169ms to 119ms.

Postgres Benchmarks

We will run this same test with Postgres as well to see the difference. Since It’s One of the most used database.

Setup:


❯ docker run --name post -e POSTGRES_PASSWORD=password -p 5432:5432 -d postgres:17.6-alpine

❯ psql -h localhost -p 5432 -U postgres


CREATE TABLE employees (

    employee_id SERIAL PRIMARY KEY,

    first_name VARCHAR(50) NOT NULL,

    last_name VARCHAR(50) NOT NULL,

    email VARCHAR(100) UNIQUE,

    phone_number VARCHAR(20),

    hire_date DATE NOT NULL,

    job_title VARCHAR(50),

    salary NUMERIC(10, 2),

    department_id INTEGER

);

INSERT INTO employees (first_name, last_name, email, phone_number, hire_date, job_title, salary, department_id) VALUES

('John', 'Doe', 'john.doe@example.com', '555-1234', '2020-01-15', 'Software Engineer', 75000.00, 101),

('Jane', 'Smith', 'jane.smith@example.com', '555-5678', '2018-03-20', 'Project Manager', 90000.00, 102),

('Peter', 'Jones', 'peter.jones@example.com', '555-9012', '2021-07-01', 'Data Analyst', 60000.00, 101),

('Alice', 'Brown', 'alice.brown@example.com', '555-3456', '2019-11-10', 'HR Specialist', 65000.00, 103),

('Robert', 'Davis', 'robert.davis@example.com', '555-7890', '2022-04-25', 'Marketing Coordinator', 50000.00, 104);


import Fastify from "fastify";

import postgres from "postgres";

const fastify = Fastify({});

const postgresClient = postgres({

  host: "localhost",

  port: "5432",

  database: "postgres",

  username: "postgres",

  password: "password",

  max: 10,

  prepare: true,

  keep_alive: 60,

});

const pendingPromises = new Map<string, Promise<string>>();

fastify.get("/coalesced", async function (request, reply) {

  const key = request.url.slice(1);

  const inFlight = pendingPromises.get(key);

  if (inFlight !== undefined) {

    return reply.send(await inFlight);

  }

  const promise = postgresClient`select * from employees`;

  pendingPromises.set(key, promise);

  const res = await promise;

  pendingPromises.delete(key);

  reply.send(res);

});

fastify.get("/base", async function (request, reply) {

  const res = await postgresClient`select * from employees`;

  reply.send(res);

});

fastify.listen({ port: 3000 }, function (err, address) {

  if (err) {

    fastify.log.error(err);

    process.exit(1);

  }

  console.log("Server is now listening on", address);

});

Benchmark Results - Base case


❯ autocannon -d 10 -c 5000 --renderStatusCodes http://0.0.0.0:3000/base

Running 10s test @ http://0.0.0.0:3000/base

5000 connections

┌─────────┬────────┬────────┬────────┬────────┬──────────┬───────────┬─────────┐

│ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │

├─────────┼────────┼────────┼────────┼────────┼──────────┼───────────┼─────────┤

│ Latency │ 136 ms │ 156 ms │ 192 ms │ 352 ms │ 163.7 ms │ 162.57 ms │ 9040 ms │

└─────────┴────────┴────────┴────────┴────────┴──────────┴───────────┴─────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬──────────┬──────────┐

│ Stat │ 1% │ 2.5% │ 50% │ 97.5% │ Avg │ Stdev │

├───────────┼─────────┼─────────┼─────────┼─────────┼──────────┼──────────┼

│ Req/Sec │ 24,639 │ 24,639 │ 30,623 │ 33,471 │ 30,391.2 │ 2,121.86 │

├───────────┼─────────┼─────────┼─────────┼─────────┼──────────┼──────────┼

│ Bytes/Sec │ 32.3 MB │ 32.3 MB │ 40.1 MB │ 43.9 MB │ 39.8 MB │ 2.78 MB │

└───────────┴─────────┴─────────┴─────────┴─────────┴──────────┴──────────┘
┌──────┬────────┐

│ Code │ Count │

├──────┼────────┤

│ 200 │ 303896 │

└──────┴────────┘

Benchmark Results - Request Coalesced case:


❯ autocannon -d 10 -c 5000 --renderStatusCodes http://0.0.0.0:3000/coalesced

Running 10s test @ http://0.0.0.0:3000/coalesced

5000 connections

┌─────────┬───────┬────────┬────────┬────────┬──────────┬──────────┬─────────┐

│ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │

├─────────┼───────┼────────┼────────┼────────┼──────────┼──────────┼─────────┤

│ Latency │ 99 ms │ 115 ms │ 129 ms │ 237 ms │ 117.2 ms │ 48.96 ms │ 2500 ms │

└─────────┴───────┴────────┴────────┴────────┴──────────┴──────────┴─────────┘
┌───────────┬────────┬────────┬─────────┬─────────┬──────────┬──────────┐

│ Stat │ 1% │ 2.5% │ 50% │ 97.5% │ Avg │ Stdev │

├───────────┼────────┼────────┼─────────┼─────────┼──────────┼──────────┼

│ Req/Sec │ 38,143 │ 38,143 │ 41,151 │ 45,439 │ 42,422.4 │ 2,217.76 │

├───────────┼────────┼────────┼─────────┼─────────┼──────────┼──────────┼

│ Bytes/Sec │ 50 MB │ 50 MB │ 53.9 MB │ 59.5 MB │ 55.6 MB │ 2.9 MB │

└───────────┴────────┴────────┴─────────┴─────────┴──────────┴──────────┘
┌──────┬────────┐

│ Code │ Count │

├──────┼────────┤

│ 200 │ 424220 │

└──────┴────────┘

Results

So for postgres we were able to:

process 40% more requests.
Reduce p99 latency from 352ms to 237ms.
But the real wins come for the resource usage, see the huge difference b/w both the cases.
- Measured these for 30 secs using OrbStack Activity Monitor (Not the best way maybe, but good enough to give the idea).

When to Use Request Coalascing?

High-Concurrency, Low-Cardinality Resources

This is the absolute ideal scenario. It means many users are requesting one of a small set of shared resources. So with a very small memory footprint on application server side, we can achieve our goal.

Some of the use cases:

Leaderboards: The global or daily leaderboard is the same for everyone.
Live Game Scores or Stock Tickers: Thousands of users request the same score or price simultaneously.
Application setup data: Which is usually same for most of the users, with some variance.
Trending products/items: Usually this is same for everyone. Otherwise cardinality is still on lower side.

Read Heavy Workload

Caching works perfectly for read heavy workload. Adding a layer of request coalascing in front of it, is like caching on steroids. Even for concurrent requests, your database does not get bombarded. Use cases where TTL is very short, Request coalascing will help even more.

When to Avoid it?

High-Cardinality or Unique Resources

Let’s say we want to fetch some data by user id. Which is going to be unique to the user, in this case request coalascing won’t really help. As that resource can not be served to any of the other concurrent requests. We will be adding all the unique items to memory for no reason. In this scenario particularly there will be performance degradation and resource usage hit instead.

How to optimise lambdas?

Dhruv garg — Wed, 21 Feb 2024 00:00:00 +0000

Introduction

Lambdas are function as a service (FAAS). It enables us to move fast without worrying about servers on our own.

It is very productive for a small team as it is much easier to manage serverless lambdas instead of managing servers/containers directly. you trade off the ability to tweak the machine on your own for simplicity.

It is also ideal for a use case in which you don’t know about incoming traffic load and spikes. when your product is in a growth phase and there can be sudden spikes, lambdas are able to handle it because of built-in auto-scaling. If we use servers we will need to over-provision resources which can cost more. You will need to use complex tools like Kubernetes (and others) for auto-scaling servers, which requires at least one DevOps personal on the team.

How does Lambdas work?

Whenever a lambda needs to be invoked, a firecracker micro virtual machine is started by AWS on dedicated EC2 instances for each customer. your code is downloaded, the runtime is set up on this virtual machine and then the request is handled. After some time if no requests come (it’s around 15 mins) then this container is removed.

Firecracker is a lightweight micro virtual machine which uses KVM (Linux Kernel-based Virtual Machine).

Challenges

That doesn’t mean it is a silver bullet to all the problems. Lambdas come with their own challenges. we will first understand these challenges and then see how we can resolve these. Some of those problems are:

Cold starts Cold starts happen when lambda is not invoked for some time or a new instance of lambda is created to handle more load. It can take 1-2 seconds which makes the first request handled by the lambda instance quite slow.

Managing connections to the database Since each lambda instance makes a new database connection, your database might get overwhelmed with huge number of connections if you have too many lambdas.
Debugging can be tough If you are following a microservice architecture and multiple lambdas are invoked to fulfill a user request, then it becomes hard to trace bugs.

Solutions

Provisioned Concurrency

we can set provisioned concurrency of lambdas which allows us to keep some instances of lambdas always warn and ready to go. This incurs some additional cost but lowers removes the cold start time.

so let’s say if we set provisioned concurrency for lambda as 5, then 5 instances of lambdas will always be warm and ready. so 5 concurrent requests can be handled without any cold start delay.

Another alternative to using provisioned concurrency to keep lambdas warm is to use a cron to trigger lambda you want to keep warm in some intervals.

Reuse database connections

Initialise database connections out of the handler function, so that you are not creating a database connection for each request. This will speed up the lambda by not waiting for a connection for each request and cleaning up after each request.

The only downside to this is that we can’t clean up the connection manually, to solve this we can use idle connection timeout. so that a connection can be reclaimed if it has been idle for some time (say 10 minutes)

Use database proxies

So consider your whole backend is running on lambdas. so you can easily have 100s of individual lambdas and considering there will be some concurrent requests, let’s say 10. That can mean 1000s of concurrent database connections which is poor resource utilization as each connection means additional RAM usage by the database (assuming Postgres).

So it’s better to use database proxies which will maintain a connection pool and our lambdas can use this connection pool maintained by proxy when required.

Use logging and monitoring tools

we use cloudwatch to monitor all the logs, resource utilization, and performance of the lambdas. we can also check how many cold starts are happening for a function using cloudwatch, specifically lambda insights in cloudwatch. this needs to be enabled manually and by default, it is turned off.

we use sentry.io for error tracking. we trigger a slack message whenever there is a new issue or some issue repeats a certain number of times in a time frame using sentry.

References:

Real world DS/Algo book recommendation needed

Dhruv garg — Tue, 04 Jan 2022 09:22:59 +0000

I want to study data structures and algorithms again. I am a computer science graduate and have studied these in past and I can solve easy/medium leetcode problems.

What I want to learn is where these are used in real-world problems, while building software.

In my experience, I have mainly directly used HashMap, Sets, Queues, and Arrays while building applications.

I know about graphs are very useful and are used in many practical problems like dependency injection graph, dependency resolution in tools like Gradle, routing algorithms. Tress in databases, AST in compiler design.
Is there any book which teaches data structures and algorithms like this, by telling about their practical applications also?

Is learning maven essential for Java developers?

Dhruv garg — Wed, 25 Nov 2020 11:19:36 +0000

I am wondering if maven and XML are essential to become a good java developer. I don't really like maven and prefer Gradle over it.

I still see maven being used heavily. For some of the examples, I have seen maven used in open-source projects like quarkus(Quarkus Gradle support is considered preview) and many others.

Even though while writing this question, it seems like Maven will be good to learn. I am still wondering what you fellas use and prefer. I personally find Gradle much more readable.

I wanted to know what others think about this? and whether someone uses Gradle for the production backend (I know it's used for android)? and if maven is must learn?

Is using Linux really productive?

Dhruv garg — Sun, 05 Jul 2020 12:55:30 +0000

I am now using Ubuntu for around 9 months, before that I was a windows user.

There are certainly many things in Ubuntu I love like custom themes, terminal, native docker support, and search bar without irritating web results (referring to the Windows search bar, getting web results when you just need to open a local app).

But the time I have to invest sometimes to get simple things working is just crazy. My Bluetooth doesn't work from time to time. Sometimes even audio doesn't work, keys like play/pause never work with Rhythmbox and suspend was working in ubuntu 19.10 version but it is again behaving weirdly in 20.04 (and never worked for me on 18.04). Many more similar problems.

Now the above problems are pretty common and after spending some hours(sometimes many hrs) things start to work. So why I am writing this post, because from last week Intellij Idea is freezing again and again because of some bug and I can't live without Intellij Idea.

Even though I can't think about moving away from ubuntu. I would like to hear your thoughts on this topic, dev community?

How to create REST API in quarkus?

Dhruv garg — Fri, 03 Jul 2020 02:58:30 +0000

I have finally decided to post my first article and I am trying to learn quarkus. So here I am writing this article for our first supersonic Quarkus application. We will develop a RESTful application using JAX-RS for a To Do application.

In recent, I have heard many times that java is going to be obsolete and many reasons for this are valid. But, no more if java community can come up with something like quarkus then I am sure java is not going anywhere. It is really an awesome framework and hopefully you will also say that after reading this article.

What is Quarkus?

Quarkus is a Kubernetes Native Java framework tailored for GraalVM and HotSpot. The goal of Quarkus is to make Java a leading platform in Kubernetes and serverless environments while offering developers a unified reactive and imperative programming model to optimally address a wider range of distributed application architectures.

Why quarkus?

Whenever someone thinks about java development. They think that application will take huge memory and it will be hard to develop campared to it's counterparts. But quarkus, let's you develop high performance applications that take very low space and is easy to work with because of features like live reload. Also wide array of extensions and libraries provided by quarkus team and community makes building quarkus application much easier and fun (yeah java can be fun 😅).

please go to this link for more information: https://quarkus.io/

summary:

less memory usage
fast startup time
live reload out of the box
uses standard java ee specifications. so if you are already familier with jakarta ee or even with spring you are good to go
Quarkus does not use reflection API.

let's build a simple TO DO list endpoints

For setting up Development environment

you will need :

JDK 8 or 11 with JAVA_HOME configured
GraalVM (If you want to build native image)
Apache Maven or Gradle
IDE (I prefer intellij Idea)

Getting started

The easiest way is to go to https://code.quarkus.io/ and download zip file of initial application with default config and these libraries

RestEasy implementation of JAX-RS
RestEasy JsonB

It is your choice to use maven or gradle. I will be using gradle.

The project Structure will look like this:

quarkus-project/                    
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradle.properties
├── gradlew
├── gradlew.bat
├── README.md
├── settings.gradle
└── src
    ├── main
    │   ├── docker
    │   │   ├── Dockerfile.jvm
    │   │   └── Dockerfile.native
    │   ├── java
    │   │   └── org
    │   │       └── quarkus
    │   │           ├── ExampleResource.java
    │   └── resources
    │       ├── application.properties
    │       └── META-INF
    │           └── resources
    │               └── index.html
    ├── native-test
    │   └── java
    │       └── org
    │           └── quarkus
    │               └── NativeToDoResourceIT.java
    └── test
        └── java
            └── org
                └── quarkus
                    └── ToDoResourceTest.java

The ExampleResource.java contains the REST Endpoint.
The docker folder contains two files for building app as container. Dockerfile.jvm to run application on JVM and Dockerfile.native to build native app.
The test and native-test for testing JVM and native application
The static resources are put inside resources folder, like index.html.
The application.properties is the yaml file used for configuration. e.g. Defining datasource and configuring database.

Building our ToDo API

For simplicity I will not be using database in this article and maybe show how to use it in next article.

You can try to run initial project using

./gradlew quarkusDev
./mvnw quarkus:dev

This will run app in dev mode which provides hot reload. so any change in code is instantly visible without restarting app. Go Ahead and try out this, by simply changing some text of return statement.

The initial project contain ExampleResource a simple hello end point that returns hello. Replace this with ToDoResource and add this code.

ToDoResource.java

This contains 6 EndPoints for basic CRUD operations:

GET /api/todo returns all tasks
GET /api/todo/{id} returns task with given id
POST /api/todo with ToDo json object body to create new task
POST /api/todo with task String body to create new task
PATCH /api/todo/status/{id} to mark task completed or non-completed
DELETE /api/todo/{id} deletes task with given id

@path Annotation specifies uri for endpoint. It is used to define base uri when declared at top of resource and specifies uri for specific API if specified over function. e.g. api/todo in this case is base uri and status/{id} is uri of changeStatus API.

@Produces Annotation tells which type of result is served by API. for e.g. JSON, plain text or HTML.

@Consumes Annotation tells which type of body is consumed by API. for e.g. JSON, plain text or HTML.

@Inject Annotation is used to inject Instanse of ToDoService using CDI. This enables us to just use the dependency/object we need without worrying about it's creation and lifecycle as it is managed by context and dependency injection system.

package org.quarkus;

import javax.inject.Inject;
import javax.validation.Valid;
import javax.ws.rs.*;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;

@Path("/api/todo")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class ToDoResource {

    @Inject
    ToDoService service;

    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    public Response newTask(@Valid ToDo task) {
        try {
            if (task == null) {
                return Response.status(400).entity("Task not provided").build();
            }
            return Response.ok(service.addTask(task)).build();
        }
        catch (Exception e){
            return Response.serverError().build();
        }
    }

    @POST
    @Consumes(MediaType.TEXT_PLAIN)
    public Response newTaskString(@Valid String task) {
        try {
            if (task == null) {
                return Response.status(400).entity("Task not provided").build();
            }
            return Response.ok(service.addTask(task)).build();
        }
        catch (Exception e){
            return Response.serverError().build();
        }
    }

    @GET
    public Response allTasks(){
        return Response.ok(service.allTasks()).build();
    }

    @GET
    @Path("/{id}")
    public Response task(@PathParam("id") String id){
        return Response.ok(service.getTask(id)).build();
    }

    @PATCH
    @Path("status/{id}")
    public Response changeStatus(@PathParam("id") String id){
        return Response.ok(service.changeStatus(id)).build();
    }

    @DELETE
    @Path("/{id}")
    public Response delete(@PathParam("id") String id){
        return Response.ok(service.delete(id)).build();
    }
}

ToDo.java

This is our POJO with constructors to initialize objects.

package org.quarkus;

import org.hibernate.validator.constraints.Length;

import javax.validation.constraints.Future;
import javax.validation.constraints.NotNull;
import java.util.Date;
import java.util.UUID;

public class ToDo {
    @NotNull
    public String id;

    @NotNull
    public String task;

    @NotNull
    public boolean isComplete;

    @NotNull
    public Date time;

    public ToDo(String task, Date time) {
        this.id = UUID.randomUUID().toString();
        this.task = task;
        this.isComplete = false;
        this.time = time;
    }

    public ToDo(String task, boolean isComplete, Date time) {
        this.id = UUID.randomUUID().toString();
        this.task = task;
        this.isComplete = isComplete;
        this.time = time;
    }

    @Override
    public String toString() {
        return "ToDo{" +
                "id='" + id + '\'' +
                ", task='" + task + '\'' +
                ", isComplete=" + isComplete +
                ", time=" + time +
                '}';
    }
}

TodoService.java

This class contains logic of application. It is ApplicationScoped which means only one instance of this class is created during lifetime of app and same instance is injected and reused wherever it is required by CDI system.

package org.quarkus;

import javax.enterprise.context.ApplicationScoped;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;
import java.util.Optional;

@ApplicationScoped
public class ToDoService {
    ArrayList<ToDo> list = new ArrayList<>();

    public ToDoService(){

    }

    public boolean addTask(String task){
        ToDo toDo = new ToDo(task, false, new Date());
        return list.add(toDo);
    }

    public boolean addTask(ToDo task){
        return list.add(task);
    }

    public List<ToDo> allTasks(){
        return list;
    }

    public ToDo getTask(String id){
        Optional<ToDo> item = list.stream().filter(toDo -> toDo.id.equals(id)).findFirst();
        return item.orElse(null);
    }

    public ToDo changeStatus(String id){
        ToDo todo = getTask(id);
        todo.isComplete = !todo.isComplete;
        return todo;
    }

    public boolean delete(String id){
        return list.remove(getTask(id));
    }
}

Now you can run the application using same command mentioned earlier. The output on terminal will look like this.

dhruv@dhruv-laptop:~/Programs/javaPrograms/to_do$ ./gradlew quarkusDev
Starting a Gradle Daemon (subsequent builds will be faster)

> Task :quarkusDev
Listening for transport dt_socket at address: 5005
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2020-07-02 19:03:56,518 INFO  [io.quarkus] (Quarkus Main Thread) to_do 1.0.0-SNAPSHOT on JVM (powered by Quarkus 1.5.2.Final) started in 6.566s. Listening on: http://0.0.0.0:8080
2020-07-02 19:03:56,578 INFO  [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated.
2020-07-02 19:03:56,579 INFO  [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, resteasy, resteasy-jsonb]
<=========----> 75% EXECUTING [41s]
> :quarkusDev

If you look closely you will see that it is also telling all installed features like cdi, resteasy, resteasy-jsonb in 3rd line after quarkus banner.

Building the native executable

Use below command to generate a native executable

      ./mvnw package -Pnative
      ./gradlew build -Dquarkus.package.type=native

The build will produce target/{package_name}-1.0-SNAPSHOT-runner. You can run it using: ./target/{package_name}-1.0-SNAPSHOT-runner on linux.

For more details on proper setup follow this

Conclusion

In this article we have covered, how to create simple REST Api in Quarkus and why quarkus enables us developers to build better applications.

You can find source code here. star repo if you like it.

Hope you liked this article and it helped you to learn something new. This is my first time writing on quarkus and posting Article/Blog online. Feel free to let me know if anything is wrong in comments, also tell in comments if you liked it.
You can connect with me on twitter or linkedin

Thanks for reading this article. Best of luck for learning Quarkus.

Which linux distro is best for general application development, docker and devops?

Dhruv garg — Wed, 30 Oct 2019 16:38:02 +0000

Hello dev community,

I have finally decided to move away from windows 10, I liked it but it is very limiting in terms of docker and devops, as I have read online and experienced many lags with windows.

So, I wanted to know in your opinion which linux distro will be best for general development (I do native android development), devops, docker etc.

I want to basically know which distro you would prefer.

I have found that centos and ubuntu are most popular.

please share your views on this

Thanks