DEV Community: Krishna Nayak

Why Exposing Persistence Entities in APIs Is a Dangerous Shortcut

Krishna Nayak — Sun, 28 Dec 2025 07:48:38 +0000

I recently revisited one of my old backend projects.

Everything was working fine. No errors. No failing APIs.

But while reading the code, one design decision immediately stood out — I had exposed persistence entities directly in API requests and responses.

At the time, it felt like a smart move. Looking back now, I realize it was a shortcut with hidden costs.

The Shortcut That Seemed Like a Smart Move

In the initial version, my controller looked something like this:
(Here, BookItem is a persistence entity class used for creating book records.)

@PostMapping("/books")
public BookItem create(@RequestBody BookItem bookItem) {
    return bookService.save(bookItem);
}

Why did this feel right?

The entity already had all the fields
No extra classes to write
Faster development

DTOs felt like unnecessary boilerplate. For a small project, this approach worked — and that’s exactly why it was misleading.

The First Problem: Clients Can Send Too Much

When an entity is used directly as a request body, every field becomes writable.

This means a client can:

Set database IDs manually
Modify fields they should never control
Send values meant only for internal logic

The framework doesn’t know intent — it simply maps fields. Without a boundary, the API trusts the client far too much.

The Second Problem: Leaking Sensitive Data

Entities are designed for persistence, not for exposure.
When returned directly in API responses, they often include:

Internal flags
Audit timestamps
Fields irrelevant or unsafe for clients

Once clients start consuming these fields, they become part of the public contract — even if you never intended them to be.

The Real Cost: Change Becomes Dangerous ‼️

This is the most critical problem — and the one that usually appears too late.

A Realistic Example

Initial Entity

@Entity
public class BookItem {
    @Id
    private String id;
    private String title;
    private String author;
    private int pages;
}

API Response

{
  "id": "123",
  "title": "Clean Code",
  "author": "Robert Martin",
  "pages": 464
}

Clients build their logic around this response.

Later: A Normal Business Change

You decide that pages is inaccurate and replace it with wordCount.

@Entity
public class BookItem {
    @Id
    private String id;
    private String title;
    private String author;
    private int wordCount;
}

You didn’t touch the controller. You didn’t change the API intentionally.

But the response now becomes:

{
  "id": "123",
  "title": "Clean Code",
  "author": "Robert Martin",
  "wordCount": 150000
}

What Just Happened?

pages disappeared
wordCount appeared
Clients break
Frontend crashes
Mobile apps fail

This happened because the entity was acting as the API.
Every internal refactor became a breaking change.
That is why this design is dangerous.

Why DTOs Solve This Problem

DTOs create a stable boundary between internal models and external consumers.

With DTOs:

Clients can send only allowed fields
Responses expose only safe data
Entities can change freely
APIs remain stable

Final Thought

Using entities directly in APIs often feels productive at first.

But the real cost appears later — when requirements change and refactoring becomes risky.

An entity is not an API.

DTOs may add a few extra classes, but they protect your system from silent breakage and future pain.

Token Bucket - Rate Limiter

Krishna Nayak — Sat, 09 Aug 2025 03:20:11 +0000

Token Bucket rate limiter is one of the popular rate-limiter algorithms use to control number of requests sent to server. It work by maintaining a bucket which hold fixed number tokens, which will be refilled at a constant rate time.

Each Request consume one token to processed.
If the bucket don't have tokens left, the request is either delayed or droped, depends on implementation.

Let have a high level understanding.
The bucket is full, holding a maximum number of tokens (let say, capacity is 5). Every time when a request comes in, it check whether there's a token in bucket. if yes, a token is out the request is allow to proceed. if no token is available, the request is denied/delayed, depending on implementation.

Meanwhile, system refill bucket with new token at a fixed rate(like 3 token/sec). But bucket can't hold more than it bucket capacity - so any extra tokens beyond that are discarded.

Let consider a scenario where, within the a second there were requests are made, say 3 request. Before allow these request to proceed, rate limiter mechanism will checks system bucket tokens. Since tokens are available, all three requests are allowed, and three tokens are consumed from the bucket. However, within that same second another 5 requests arrive, so again rate limiter mechanism, will check for availability of tokens. At this point, only contain 2 tokens remain, so only the first two requests are allowed and those token are consumed. The remaining three requests are denied or delayed due to insufficient tokens.

Now, no additional requests will permite until the bucket is refilled, which happen every one second, based on the defined refill rate.

At 01.00 second, the refill mechanism kicks in, adding 3 new tokens to the bucket. Immediately after that, 1 new request arrives, which is allowed by consuming 1 of the newly added tokens. Since tokens were available, the request proceeds, and no denial occurs. Moving to 02.00 seconds, no new requests arrive, so while the refill logic adds more tokens, none are consumed. The bucket now reaches its maximum capacity of 5 tokens. Again, no requests are denied, simply because none were received. At 03.00 seconds, the system attempts another refill, but since the bucket is already full, no new tokens are added. No requests arrive at this point either, so no tokens are consumed and no requests are denied. This idle period demonstrates how the token bucket patiently accumulates tokens during inactivity, preparing the system to handle upcoming bursts of traffic efficiently.

Now that we have developed concept of token bucket rate limiter behavior, it's time to shift our focus to how this implementation in code.

Core Components of the Token Bucket Algorithm in Code

Before we jump into the Java implementation, let’s break down what needs to be built:

Token Bucket Capacity – This defines how many tokens the bucket can hold at any time.
Refill Rate – Determines how many tokens to add per second.
Token Consumption – Each request checks if a token is available; if so, it’s consumed.
Refill Logic – The bucket must be topped up based on time elapsed since the last refill.

The class starts with two key configuration parameters: capacity and refillRate. The capacity represents the maximum number of tokens the bucket that can hold, while refillRate defines how many tokens should be added per second.

Internally, the class maintains a tokens counter to track the number of currently available tokens. Since all access to this variable is handled within synchronized methods, thread safety is ensured. It also keep tracks of last time bucket was refilled using lastRefillTimestamp, which stores the timestamp in nanoseconds (via System.nanoTime()), allowing for precise time-based calculations.

refill() method, whenever a request comes in, this method calculates how much time has passed since the last refill. If one or more full seconds have passed, it computes how many tokens should be added (tokensToAdd = secondsPassed * refillRate). Then, it updates the token count, ensuring it doesn't exceed the bucket's maximum capacity using Math.min(capacity, currentTokens + tokensToAdd). After that, lastRefillTimestamp is also updated with elapsed seconds to accurately track the time for the next refill cycle.

allowRequest() method is synchronized to ensure thread-safety. When a request arrives, it first refills the bucket. Then, if there's at least one token available, it decrements the token count and allows the request. Otherwise, the request is denied. This mechanism ensures that only a limited number of requests are allowed over time, enforcing both burst and sustained rate limits.

// TokenBucketRateLimiter.java
public class TokenBucketRateLimiter {

    private final int capacity;
    private final int refillRate; // tokens per second

    private int tokens;
    private long lastRefillTimestamp;

    public TokenBucketRateLimiter(int capacity, int refillRate) {
        this.capacity = capacity;
        this.refillRate = refillRate;
        this.tokens = capacity;
        this.lastRefillTimestamp = System.nanoTime();
    }

    private void refill() {
        long now = System.nanoTime();
        long elapsedTime = now - lastRefillTimestamp;

        long secondsPassed = elapsedTime / 1_000_000_000;

        if (secondsPassed > 0) {
            int tokensToAdd = (int) (secondsPassed * refillRate);

            tokens = Math.min(capacity, tokens + tokensToAdd);

            lastRefillTimestamp += secondsPassed * 1_000_000_000;
        }
    }

    public synchronized boolean allowRequest() {
        refill();

        if (tokens > 0) {
            tokens--;
            return true;
        }

        return false;
    }

}

To see the Token Bucket rate limiter in action, we will simulate a sequence of requests using the Main class. In this simple example, we create an instance of the TokenBucketRateLimiter with a bucket capacity of 5 tokens and a refill rate of 3 tokens per second. We then simulate 10 consecutive requests in a loop, each separated by a 100-millisecond of pause using Thread.sleep(100). This delay helps mimic how requests might arrive in a real-world application over a short period of time.

// Main.java
public class Main
{
    // Simulation of request
    public static void main(String[] args) throws InterruptedException {
        TokenBucketRateLimiter limiter = new TokenBucketRateLimiter(5, 3);
        for (int i = 0; i < 10; i++) {
            boolean allowed = limiter.allowRequest();
            System.out.println("Request " + (i + 1) + " allowed? " + allowed);
            Thread.sleep(100); // simulate requests over time
        }
    }
}

Now it’s your turn - try it out and see for yourself how the Token Bucket rate limiter behaves in different scenarios. You can tweak the capacity, change the refillRate, or even modify the request intervals in the Main class to observe how the system reacts under various traffic patterns.

If you have any additional insights, know alternative approaches, or spot potential improvements in this implementation, feel free to share them in the comments.

Thanks for reading — and happy coding! 🚀

Understand Rate Limiting – A Beginner-Friendly Overview

Krishna Nayak — Sun, 20 Jul 2025 07:19:44 +0000

Whenever we visit a website or call API too many times in short span. We might get blocked, or request get rejected. That's due to Rate Limiter.
But why it is important?

Let's understand with real life scenario.

Think of Coffee shop.
Only 5 customers can be served in every minute because that fast the coffee-maker can make coffee.
Now, if 10 customers come at once, chaos happens. So to deal with that shop introduce a token system - only 5 customers are allowed in each minute. The rest will wait.

That the rate limiter - in real life.

What is Rate Limiter in System Design?

Based on example, you might understood that, rate limiting in system design is a technique used to control the number of requests of users or client, within a time period.

we will check benefits of using a API rate Limiter:

1. Prevent resource starvation caused by Denial of Service (DoS) attack.

Let understand with an example/scenario, imagine of login api. POST /login.
Now an attacker write a script that sends 10,000 login requests per second to your API.

What will happens without rate Limiter?

server CPU spikes.
Database connections max out (because each request hits the user table).
Genuine users can't log in.
The login service crashes due to resource starvation (too many open threads, memory usage, DB locks).

So a rate limiter prevents DoS attacks, either intentional or unintentional, by blocking the excess call.

2. Reduce Cost

Limiting excess request means fewer servers and allocating more resources to high priority APIs. Rate limiting is extremely important for companies that use paid third party APIs.
For example, company charged on per-call basis for that following external APIs. so Limiting the number of calls is essentials to reduce costs.

3. Prevent servers from being overload.

To reduce server load a rate limiter is used to filter out the excess requests caused by bots or user's misbehaviour.

Algorithms/Strategies for Rate Limiting

Rate limiting can be implemented in various algorithms/strategies, each of the strategies have it own pros and cons. We will overview most common algorithms/strategies.

Token Bucket: This strategies is widely used for rate limiting. The concept is simple, imagine a bucket that get filled with token rate over time - Let's say, one token one second. Each token represents a persimmon to make a request. So, whenever the client/user request to service, the system first checks if there is token available on bucket.
- if token available, it's consumed and the request is allowed.
- if bucket is empty, meaning the token is been already been used - then the request get denied or delayed.

Leaking Bucket: The Leaking Bucket is another popular strategies for rate limiting. Just like a real bucket with small hole at the bottom, it process request by "leaking" them in steady and fixed rate, regardless of how many requests come in at once.Incoming requests are added to bucket (queue), and if the bucket is full, excess requests are either dropped or delayed.

Fixed Window Counter: The Fixed Window Counter strategies is basic rate limiting methods where we define the time window (suppose, 1 minute) and maximum number of request (Let's say 100). it keep the counter of each time window,and every request increases the count. If the number of requests exceeds the limit within that time window, further requests are blocked until the window resets. Once the minute is over, the counter resets back to zero, and a new time window begins.

Rate limiting is small topic but big in impact. It helps your system breathe during high traffic, stops abuse, and saves money on cloud bills.

Beginner’s Guide to the Singleton Pattern

Krishna Nayak — Sat, 26 Oct 2024 17:45:19 +0000

The Singleton Pattern is one of the most foundational concepts to grasp. It is classified as a creational design pattern and it is used to control the creation of objects, ensuring that only one instance of a particular class exists throughout the lifetime of an application.

In simpler terms, it ensures that a class is responsible for managing only one version of itself, and it gives global access to that single instance.

So when/why to use Singleton Pattern, this is the one of the most common question?

Before diving into the when/why using Singleton patterns, it’s important to understand the problem statements. Each design pattern is created in response to specific challenges faced by developers.

Problem Statement: Database Connection
We want to manage a single connection to a database throughout our application. Creating multiple connections can lead to conflicts and resource exhaustion.

// first instance
DataConnection dataConnection1 = new DataConnection();

//Second instance
DataConnection dataConnection2 = new DataConnection();

In this scenario, creating two instances of DataConnection can cause resource issues. Each instance may perform operations independently, leading to conflicts and unpredictable behavior if they attempt to access the same database resource simultaneously.
To solve this problem, we need the Singleton pattern.

When Should Do We Use Singleton Pattern?

The Singleton Pattern is indeed a popular, especially in software design, as it's a powerful tool but can be easily misused. Let have understanding of when it’s appropriate to use the Singleton Pattern:

When to Use the Singleton Pattern

When Only One Instance of a Class is Needed Globally

If we need a class that should have only one instance across the entire application, the Singleton Pattern is a best choice 👍 . This ensures that all parts of the application are working with the same instance, maintaining consistency and preventing duplicate instances that might waste memory.
When We Need Centralized Management of Shared Resources

Singletons are beneficial when there are shared resources, like configuration settings, caches, or logging tools, which are needed by multiple parts of the application. Centralized access and management simplify resource handling, especially for classes that need to be globally accessible and modifiable.
When We Want to Control Access to a Resource

Singletons allow controlled access to a single resource by encapsulating it within a class. This makes them helpful when only one connection or resource should be used at a time, like managing a file writer to ensure synchronized access or a shared network connection.
In Multithreaded or Parallel Applications

In applications with multiple threads, a Singleton can ensure that critical sections or shared resources aren’t accessed by more than one thread at a time. A properly implemented Singleton can provide thread-safe access, reducing the likelihood of race conditions and ensuring that only one instance of a shared resource is accessed concurrently.

Now, we understand about problem and when to use, let see how to address this problem.

UML Diagram of Singleton Pattern

The UML diagram typically includes the following components:

Singleton Class: This is the class that restricts instantiation. It usually has a private static instance variable to hold the single instance.
Constructor: The constructor is private to prevent direct instantiation from outside the class.
Public Static Method: This method provides access to the instance. If the instance does not exist, it creates one; otherwise, it returns the existing instance.

Here’s a simple representation of the UML diagram for the Singleton pattern:

Note:

-: Private access modifier (indicating that the instance variable and constructor are not accessible outside the class).
+: Public access modifier (indicating that the getConnection() method can be accessed publicly).

Java Implementation

Here’s an example of Singleton pattern implemented in Java:

public class DataConnection {
      private static DataConnection instance = null;

      /*
       * This private keyword in constructor 
       * is to prevent direct instantiation from
       * outside the class.
       */
      private DataConnetion() { }

      /*
       * static method so that we can call 
       * this method outside the class without
       * instantiation object
       */
      public static DataConnection getConnection() {
            if (instance == null) {
                  instance = new DataConnection();
            }
            return instance;
      }

      public void showMessage() {
            System.out.println("Database is connected");
      }
}

Now, if we want to get the instance of Database Connection, we call its static methods like this: DataConnection dataConnection = DataConnection.getConnection();.

public class Main {
      public static void main(String[] args) {
            /*
             * We can't directly initialize DataConnection
             * due to its private constructor.
             *
             * DataConnection dataConnection = new DataConnection();
             *
             * This would cause an error.
             *
             */

            DataConnection dataConnection = DataConnection.getConnection();
            System.out.println(dataConnection.hashCode()); // Example output: 112810359

            DataConnection dataConnection1 = DataConnection.getConnection();
            System.out.println(dataConnection1.hashCode()); // Example output: 112810359

            // Both variables, dataConnection and dataConnection1, refer to the same instance in memory.
      }
}

Conclusion

The Singleton Pattern is a foundational design pattern that ensures only one instance of a particular class exists across an application, By restricting the instantiation process and providing global access to a single instance, the Singleton pattern helps manage shared resources efficiently, such as database connections, configuration settings, and loggers. This pattern is especially useful in scenarios where consistency and controlled access to resources are crucial.

For more information and best practices on implementing the Singleton Pattern effectively, refer to this guide on DigitalOcean.

Understanding UML Class Diagrams: A Beginner’s Guide

Krishna Nayak — Fri, 18 Oct 2024 20:30:24 +0000

Designing systems clearly and accurately is crucial, and one of the most commonly used tools for this purpose is UML (Unified Modeling Language) diagrams.
Among various types of UML diagrams, Class Diagrams are essential for visualizing the structure of a system.
So our first question should be what is UML Class Diagram?

UML Class Diagram

A UML Class Diagram is, basically a blueprint that describes the structure of a system by showing its classes, attributes, operations (or methods), and relationships among objects.
In simpler terms, it a visual representation of how objects and classes within a system interact with each other.

Now that we have an understanding of what a UML Class Diagram is, the next step is to know about Key Elements of a Class Diagram.

Key Elements of a Class Diagram

The Key Elements of class diagram include:

Class
Attributes
Methods/Operations
Relationships

Class

The Class is the most fundamental element in a class diagram. It represents a blueprint for objects. Each class has three parts:

Class Name: The name of the class.
Attributes: The data stored in the class, often variables.
Operations (Methods): Functions or actions that the class can perform.

Attributes

The properties or data of a class, typically shown with their visibility (public, private, etc.).

[visibility] name: type [multiplicity] = defaultValue

name: The name of the attribute.
type: The data type of the attribute.
Visibility defines the access level of attributes and methods within a class.
- Public (+): The attributes and methods accessible from outside the class.
- Private (-): The attributes and methods accessible only within the class.
- Protected (#): The attributes and methods accessible within the class and its subclasses.
- Package (~): The attribute or method is accessible within the same package.
Multiplicity define, how many objects can participate in a relationship, such as "one-to-many" or "one-to-one."
- 1..* means one or more objects.
- 0..1 means zero or one object.
- 1 Exactly one instance
- 0..1 Zero or one instance
- 1..* One or more instances
- 0..*: Zero or more instances
default Value: (Optional) The initial value of the attribute.

Methods/Operations

Methods (or Operations) define the behavior of a class. They are the actions that the class can perform. In simple terms, it is the functions of the class.

[visibility] name(parameterList): returnType

name: The name of the method/operation.
parameterList: A comma-separated list of parameters, each specified as name: type.
returnType: The data type returned by the method.

Relationships in UML Class Diagrams

Relationships show how classes are connected and interact with one another within a system.

There are six main types of relationships between classes:

Association
Aggregation
Composition
Inheritance
Implementation
Dependency.

Association

Association represents a general relationship between two classes where objects of one class interact with objects of another. It’s just like saying, "these two things are connected in some way."

Aggregation

Aggregation is a special type of association that represents a "whole-part" relationship. This is used when one class (the whole) is made up of other classes (the parts) that can exist independently. In other words, the parts (other classes) can exist without the whole (that one class), so removing the whole doesn’t destroy the parts.

Composition

Composition is a stronger form of aggregation and represents a "whole-part" relationship as well. However, in composition, the parts cannot exist without the whole. This means that if the whole is deleted, the parts are also deleted because they depend on the whole for their existence.

Inheritance (Generalization)

Inheritance, also known as Generalization, like a “parent-child” relationship between two classes. In this relationship, one class (the child or subclass) inherits attributes and behaviors from another class (the parent or superclass). This helps reuse code and avoid duplication, as the child class automatically gets the characteristics of the parent class.

Implementation

Implementation is a relationship between a class and an interface. An interface defines abstract methods that a class must implement, but it doesn’t provide the actual code. When a class implements an interface, it agrees to provide specific functionality defined by that interface.

Dependency

Dependency is a relationship where one class relies on another class to function. It’s often temporary, meaning the dependency exists only when the operation is happening and doesn’t form a permanent relationship between classes.

Summary Table for Relationship in UML Class Diagrams:

Relationship	Description	Notation
Association	General connection between classes, without ownership.	Solid line
Aggregation	^#Whole-part relationship where parts can exist independently of the whole.	Dashed line with an open diamond on the “whole” side
Composition	^#Whole-part relationship where parts cannot exist independently of the whole.	Solid line with a filled diamond on the “whole” side
Inheritance	Parent-child relationship where the child inherits properties and behaviors from parent.	Solid line with an filled arrow to the parent class
Implementation	Class-interface relationship, where the class agrees to fulfill the interface's actions.	Dashed line with a filled arrow to the interface
Dependency	Temporary relationship where one class depends on another for a specific action.	Dashed line with an arrow from the dependent class

^# Whole refer to one class and Part refer to the made up of other class/classes. For example, A House class contains a Room class in a composition relationship — if the House is demolished, the Room is also demolished.

UML Class Diagrams also support some special elements like Enums, Interfaces, and Abstract Classes. These are denoted as show in the image.

Combined Example [library system UML class]

Element	Type	Relationships
User	Class	- Generalization: Member and Librarian are specialized versions of User.
Member	Class	- Implements Borrowable interface. - Aggregation with Book (A member can borrow multiple books).
Librarian	Class	- Association with Library (A librarian manages one library).
Book	Class	- Aggregation with Genre (Each book belongs to a specific genre). - Association with Author (Each book has one or more authors).
Author	Class	- Association with Book (An author writes one or more books).
Library	Class	- Composition with Catalog (A library contains a catalog). - Aggregation with Book (A library contains many books). - Aggregation with Member (A library can have multiple members).
Catalog	Class	- Composition with Library (The catalog is part of the library and can't exist without it). - Aggregation with Book (The catalog manages a collection of books).
Borrowable	Interface	- Implemented by Member (A member can borrow books).
Genre	Enumeration	- Aggregation with Book (Each book has a genre).

As become more familiar with UML Class Diagrams, we can gain a toolset to design more complex systems and communicate these designs effectively with other developers. With the user UML, we can create a blueprint that is clear and organized, making it easier to adapt in the future and supporting software that can grow and be maintained over time.

Advanced Query Techniques in Spring Data JPA

Krishna Nayak — Sat, 05 Oct 2024 00:30:00 +0000

We have explored the basics of Spring Data JPA and how method naming conventions make querying simple. If not, I highly recommend you to follow that blog first. In this second part, we'll dive deeper into more advanced query techniques, allowing you to leverage powerful combinations, sorting, pagination, and string-specific operations for better control over your data retrieval.

We are taking the same example as of Book Entity, having the attribute of the bookName, authorName, isbn, price, publishedDate, published.

Combining Conditions with Keywords

Spring Data JPA allows combining multiple conditions using the And and Or keywords to create more complex queries.

And: Combines conditions using the AND operator.

Book findByBookNameAndAuthorName(String bookName, String authorName);

This above method will execute a query that retrieves a book from the database where both the bookName and authorName match the values provided in the method's parameters.

If we search for the book title, i.e, bookName, "The Great Book" and the author is "A. qwerty". If such a book exists, it will return that record. Otherwise, it will return null.

The equivalent SQL query that the method would execute

SELECT * FROM Book
WHERE bookName = 'The Great Book' 
AND authorName = 'A. qwerty';

Or: Combines conditions using the OR operator. The OR operator in method names allows us to retrieve results where at least one of the conditions is met.

List<Book> findByBookNameOrAuthorName(String bookName, String authorName);

This method returns a list of Book objects where either the bookName or authorName matches the specified parameters. It does not require both conditions to be true. If a book matches either the name or the author, it will be included in the result list.

The corresponding SQL query for this method would look like

SELECT * FROM Book
WHERE bookName = 'The Great Book'
OR authorName = 'Albert Hero';

This query will return all books where either the title is "The Great Gatsby" or the author is "George Orwell". If a book matches either condition, it will be part of the result set.

Sorting and Pagination

Sorting: This allows us to control the order in which records are returned.

OrderBy: We can use OrderBy in our method name to specify sorting. For instance, if we want to get books sorted by their name in ascending order (A to Z), we can use:

List<Book> findByAuthorNameOrderByBookNameAsc(String authorName);

Here’s what each part means:

findByAuthorName: This retrieves books based on the author’s name.
OrderByBookNameAsc: This sorts the books by their name in ascending order (A to Z). If we want to sort in descending order (Z to A), we can replace Asc with Desc.

Pagination: This helps us to break down large sets of data into smaller chunks or "pages" to load more efficiently. This is useful when dealing with long lists of records, such as products, search results, or blog posts.

Pageable: Spring JPA provides a Pageable interface that allows us to retrieve a specific page of data with a defined number of records. It supports both pagination and sorting.

Page<Book> findByAuthorName(String authorName, Pageable pageable);

This method will return a page of books, filtered by the author’s name.

How to Use Pageable:

To paginate and sort data, we are passing a Pageable object when calling the method. For instance, if we want to get the second page with 10 books per page, sorted by book name in ascending order:

Pageable pageable = PageRequest.of(1, 10, Sort.by("bookName").ascending());

Page<Book> books = bookRepository.findByAuthorName("The Lost Hero", pageable);

PageRequest.of(1, 10, Sort.by("The Lost Hero").ascending()): This creates a pageable object that requests the second page (page index starts from 0) with 10 books per page, sorted by the bookName in ascending order.

Comparison Keywords

These are used to compare numeric values, dates, or other comparable data types. They help us filter data based on specific comparison criteria.

IsBefore / IsAfter: These are used for comparing date or time fields.

List<Book> findByPublishedDateAfter(LocalDate date);

The corresponding SQL query for this method would look like

SELECT * FROM Book WHERE publishedDate > '2024-01-01';

LessThan / GreaterThan / Between:These are used for numeric comparisons.

List<Book> findByPriceBetween(Double startPrice, Double endPrice);

The corresponding SQL query for this method would look like

SELECT * FROM Book WHERE price BETWEEN 10 AND 50;

String-Specific Operations

These operations are used to perform pattern matching and comparisons on string fields, similar to SQL's LIKE clause.

Containing: Used to perform a LIKE %hunted% operation, i.e., it look for partial matches.

List<Book> findByBookNameContaining(String keyword);

The corresponding SQL query for this method would look like, if the keyword value is hunted.

SELECT * FROM Book WHERE bookName LIKE '%hunted%';

StartingWith: This is used to check if a string field starts with a specific prefix.

List<Book> findByBookNameStartingWith(String prefix);

The corresponding SQL query for this method would look like, if the prefix value is The Lost.

SELECT * FROM Book WHERE bookName LIKE 'The Lost%';

EndingWith: This is used to check if a string field ends with a specific suffix.

List<Book> findByBookNameEndingWith(String suffix);

The corresponding SQL query for this method would look like, if the suffix value is Hero.

SELECT * FROM Book WHERE bookName LIKE '%Hero';

Boolean Fields

Spring JPA provides simple keywords for querying boolean fields directly.

IsTrue / IsFalse: This is used to query boolean fields where the value is either true or false.

List<Book> findByPublishedIsTrue();
List<Book> findByPublishedIsFalse();

The corresponding SQL query for this method would look like

SELECT * FROM Book WHERE published = TRUE;

In and NotIn

These keywords are used to check if a field matches any value in a collection or does not match any value in a collection.

In: This is used to find entities where the value of a field is included in a collection of values.

List<Book> findByBookNameIn(List<String> names);

The corresponding SQL query for this method would look like, if the list of the String names are these, 'The Lost Hero', 'Alice in Wonderland'.

SELECT * FROM Book WHERE bookName IN ('The Lost Hero', 'Alice in Wonderland');

NotIn: This is used to find entities where the value of a field is not included in a collection of values. Just an opposite of the In operation.

List<Book> findByBookNameNotIn(List<String> names);

The corresponding SQL query for this method would look like, if the list of the String names are these, 'The Lost Hero', 'Alice in Wonderland'.

SELECT * FROM Book WHERE bookName NOT IN ('The Lost Hero', 'Alice in Wonderland');

Top and First

These keywords are used to limit the number of records returned. We can retrieve the Top N or First N results, typically in combination with sorting.

Top:This is used to retrieve the top N records from a result set.

List<Book> findTop3ByOrderByPublishedDateDesc();

SELECT * FROM Book ORDER BY publishedDate DESC LIMIT 3;

First: This is used to retrieve the first N records from a result set, often sorted by a specific field.

List<Book> findFirst5ByOrderByBookNameAsc();

SELECT * FROM Book ORDER BY bookName ASC LIMIT 5;

Lets take an example of this method findFirst5ByOrderByBookNameAsc() and break it down into different parts to make it easier to understand:

find: This is the core part of the method, which tells Spring JPA that we want to retrieve data from the database.
First5 / First<Number>: This part of the method specifies that we want to get the first 5 records. We can replace the 5 with any number depending upon the choices or requirement. This is useful when we don’t need all the results, just a small number.
By: This keyword help to connects the "find" action with the field we want to search by.
OrderByBookName: This tell Spring JPA that we want to sort the results based on the bookName field. So, it will organize the books alphabetically (by their names) before choosing the first 5.
Asc: This stands for "ascending" order, which means sorting from A to Z (alphabetically). Suppose we wanted to sort from Z to A, we would use Desc (for "descending" order) instead.

In Summary, this method will find books in the database, sort them by their names in ascending order (A to Z), and return the first 5 records that meet this sorting criteria.

Conclusion

In this second part, we explored how Spring Data JPA allows us to create more advanced and flexible queries through method naming conventions. Combining conditions, pagination, sorting, comparison operators, and other powerful features provide the ability to construct complex queries without writing SQL. These conventions follow the "convention over configuration" principle, saving our time while offering immense flexibility.

When working with strings, numbers, dates, booleans, or collections, Spring Data JPA makes querying our database simpler and more intuitive. When our queries become too complex for method conventions, we can always fall back on custom queries using the @Query annotation. But for most use cases, these conventions are all we need to handle queries efficiently.

Spring Data JPA Method Naming Conventions: Build Queries Without Writing SQL

Krishna Nayak — Sun, 29 Sep 2024 03:38:57 +0000

Spring Data JPA has become one of the most popular frameworks for simplifying database access. It offers out-of-the-box solutions that allow developers to query databases with minimal effort-without writing complex SQL. One of the key features of Spring Data JPA is its method naming conventions, which allow developers to define repository methods that automatically generate queries based on the method signature.
We will explore the powerful naming conventions Spring Data JPA provides, and how they can be used to create simple and complex queries effortlessly.

How Does It Work?

When we define a method of findByBookName(String name) in a Spring Data. JPA repository, we’re not writing the actual SQL query. Instead Spring Data JPA uses the method name to automatically infer the query. It follows a set of well-defined conventions to generate queries at runtime, which means we don’t need to write manual code for basic operations.

Basic Query Method Keywords

Spring Data JPA has several method prefixes that form the foundation for query generation. Some of the most commonly used are:

findBy, queryBy, and readBy are the functionally identical in Spring Data JPA. They all retrieve entities based on a field and return null if no match is found. The difference lies in naming preference—developers can choose between them for better code readability or clarity, but their act of behavior remains the same.

Let suppose there is a Book entity, having the attribute of the bookName, authorName, isbn, price, publishedDate, published.

@Repository
public interface BookRepository extends JpaRepository<Book, Long> {
    Book findByBookName(String bookName);
}

Spring Data JPA takes care of the implementation under the hood, creating the necessary SQL query. If we need more complex queries, we can still define custom queries using the @Query annotation or a custom repository.

In this, Spring uses the field name bookName to match it to a property in our Book entity. This means the method findByBookName translates into a query like SELECT b FROM Book b WHERE b.bookName = :name.

Conclusion

By simply defining methods in a repository interface, we can effortlessly generate complex queries based on the method names and field attributes. Understanding the nuances of keywords like findBy, getBy, readBy, and others can help us to create readable, maintainable, and efficient data access layers in our application. With this minimal effort, Spring Data JPA simplifies the process of interacting with databases, reducing boilerplate code, and improving development speed.

CAP Theorem

Krishna Nayak — Tue, 02 May 2023 08:57:18 +0000

Let have brief understanding about, What is a CAP Theorem? The CAP theorem is a concept in computer science that describes the trade-offs that exist in building distributed systems.

The CAP Theorem revolve around the three concept which is from the CAP acronym, i.e. Consistency, Availability and Partition Tolerance.

Consistency

When a request is made. The system node always returns up-to-date information. This ensures that the information provided is accurate and reliable whenever a request is made. This makes the system trustworthy and reduces error risks. As a result, users are always provided with the latest version of the data.

Availability

The system always returns information, regardless of whether it is stable or not. It ensures that no matter what the circumstances are, users always have access to their data. Even though it provides inaccurate data, it is available to the public. But if it cannot handle any query it is unavailable.

Partition Tolerance

The system can continue operating during network partition. This means that the system can keep functioning even if there is a disruption in the network. For example, a server is down or a link may be down. This ensures that the system can continue to serve its users during a network partition.

What is CAP Theorem?

Now, We have basic idea about the CAP acronym. Let comeback to the CAP Theorem.

The CAP theorem states that you have only two properties in a distributed system but not all three.

In other words, it is not possible to achieve consistency, availability, and partition tolerance in a distributed system simultaneously. However, it is possible to prioritise two of these properties while sacrificing the third.

Consistency and availability

It is possible for a system to ensure consistency and availability, but no partition tolerance is possible. In other words, if the network has no partition, we can guarantee consistency and availability. This generally makes sense because when a network partition isn't happening the system is running normally and thus can have both consistency and availability because there's no need to make trade-offs. This means it can always respond to requests with the latest information.

Consistency and partition tolerances

Achieving both consistency and partition tolerance can be challenging, as these properties can sometimes be at odds with each other. Consistency requires that all nodes in a distributed system see the same data at the same time. Partition tolerance allows the system to remain operational in the event that some nodes fail or become inaccessible. Balancing the two is key to ensuring successful distributed operations. To maintain this balance, distributed systems must have rules in place to prevent data inconsistency and maintain availability in the event of a failure. Additionally, they must have mechanisms in place to ensure nodes stay in sync.

Availability and partition tolerances

Availability refers to the percentage of time a system is operational. Partition tolerance refers to the ability of a system to continue functioning despite the failure of one or more of its components. High availability and partition tolerance are important characteristics of distributed systems. Together, they enable systems to remain available even in the face of component or network failure. This ensures that distributed systems are robust and reliable, and can continue to function even in the event of an outage or disruption. This makes distributed systems more resilient and better able to handle large workloads.

The CAP theorem states that it is impossible for a distributed system to simultaneously guarantee all three of the following characteristics: Consistency, Availability, and Partition tolerance. This theorem implies that a distributed system can only achieve two of the three characteristics, as one must be sacrificed in order to meet the other two. This has important implications for the design of distributed systems, as developers must choose the two characteristics they wish to prioritise.