DEV Community: Bruno Mendola

Build Like a Pro, Spend Like a Student

Bruno Mendola — Thu, 29 May 2025 10:14:50 +0000

Coding Like a Boss on a Zero-Dollar Budget (Open Source Dev Edition)

Build Like a Pro, Spend Like a Student — How I’m using world-class dev tools — for free — to power open-source projects that shine.

Ever felt like building something awesome, but your wallet stared back at you like “lol nope”?

Yeah, same here.

Open-source devs live in a strange paradox: we’re building software that literally powers the world, but most of us are doing it in our spare time, without any budget, often with laptops held together by duct tape and sheer willpower.

So how do you give your open-source project that enterprise-grade glow without spending a dime?

Well, it turns out we’re living in a golden age of free tools — good ones, not janky trialware or open-core “gotchas.” Here’s what I use, and how it helps me build projects like Querity without burning a cent.

🐙 GitHub: Where It All Begins

GitHub is way more than just a place to version source code and forget it exists. If you dig in, it gives you tooling that some companies charge serious money for:

Branch protection rules : Enforce code reviews and CI checks before merging.
Built-in issue tracking : It’s not Jira, and that’s exactly why we love it.
Actions : Want CI/CD pipelines that just work? GitHub Actions will run your tests, build your docs, deploy your site — all with a few YAML lines.
Dependabot : Opens PRs to keep your deps updated and your project secure — it’s like a clingy intern, but actually useful.
Security scanning : Quietly catches vulnerabilities so your project doesn’t make the news for the wrong reasons.
GitHub Pages : Want a slick site for your docs or landing page? Click, click, boom — your project has a web presence.

All of the above is free of charge for open-source projects!

🔍 SonarCloud: Your Judgy Best Friend

This one is for the devs who like their code with a side of guilt.

SonarCloud is like having that one teammate who catches everything — duplicate code, complexity, missing coverage — and won’t let you merge anything that smells off.

Best part? It’s free for public repos and integrates beautifully with GitHub Actions.

💻 JetBrains IDEs: Writing Code Like a Rockstar

JetBrains doesn’t just make good IDEs — they make IDEs that feel like magic.

If you’ve ever used IntelliJ IDEA, WebStorm, or PyCharm, you know what I mean. And guess what? If you’re working on a non-commercial open-source project, you can get a free license.

You’ll get smart refactors, insane autocomplete, and a UX that makes you forget Eclipse ever existed.

📦 Publishing Like a Pro (for Free)

After your code passes every check and review, it’s time to ship it.

Maven Central
npmjs

Both let you publish open-source packages for free, assuming you follow their rules — mostly around proper metadata, signing, and licensing. Nothing too scary.

Once you’re in, people can pull your package into projects worldwide with a single line in their pom.xml or package.json.

🛠️ A Day in the Life of a Modern OSS Dev

Let’s say you’re working on a library. Here’s how a typical workflow might look:

Push code to GitHub
GitHub Actions run your tests and linters
SonarCloud checks for bugs, smells, and missing tests
Dependabot nags you about old dependencies
You fix everything inside IntelliJ like a wizard
You publish to Maven Central or npmjs
Docs are auto-updated and deployed with GitHub Pages

All this — for $0.

Seriously. You don’t need a VC-backed dev environment to build amazing software anymore. Just a bit of setup, and you’re rolling with a dream team of free tools.

🎉 Case Study: Querity

I got to experience all this firsthand with Querity — an open-source Java library I built to simplify querying databases (SQL and NoSQL) from REST APIs.

It takes care of filtering, sorting, and pagination — and it powers a React-based query builder UI too. If you’re a Java dev working with REST and databases, check it out!

And if it makes your life easier? Toss a ⭐️ my way. It helps.

🚀 Final Thoughts

Open source is more than code. It’s a mindset — building things that matter and sharing them with the world.

Thanks to these powerful, free tools, you don’t need a massive budget to do that anymore. Just curiosity, caffeine, and a bit of consistency.

If you’re thinking about starting your own OSS project, this is the best time in history to do it.

Go build something great.

Stop Hammering Screws: Tech Choices That Make Sense

Bruno Mendola — Tue, 29 Apr 2025 14:52:08 +0000

“If the only tool you have is a hammer, every problem looks like a nail.”

— Probably every senior dev after debugging a junior’s code

In the software world, I constantly see teams reach for their favorite stack — regardless of whether it’s the right fit for the job. A new module? Same stack. A quick tool for internal use? Same stack. A real-time data pipeline? Yep… same stack.

The result? Overengineered solutions, underwhelming performance, and developers silently sobbing into their keyboards.

And I get it. Even I — someone who’s worked with BASIC, Pascal, shell scripting, C, Delphi, PHP, Java, Spring, .NET, Angular, React — have made that mistake. It’s easy to fall in love with the tool you know best. But the longer I’ve worked in software (especially building ERP systems for demanding industries), the more I’ve learned a hard truth:

No tool is good for everything. Every tech decision is a trade-off.

Let’s dig into that.

What Happens When the Tool Dictates the Architecture

You know this scenario:

A team is asked to build a small reporting dashboard.

They reach for their usual weapons: Spring Boot, full REST API, PostgreSQL, React frontend, maybe even Docker and a CI/CD pipeline.

Was the problem complex? Not really.

Did it need all this? Definitely not.

But that’s what they know. So now you’ve got a monstrous mini-project with 12 moving parts, when a single-page app with a SQLite file might have done the job in half a day.

Meme Intermission 🧠

Junior Dev: “We need to build a blog.”

Senior Dev: “Just use WordPress.”

Junior Dev after 6 months of building their own CMS from scratch in Rust with a GraphQL backend, React frontend, and blockchain integration:

Start From Requirements, Not Comfort Zones

If you build enterprise systems like I do, you’ve probably noticed:

Some parts of your system need rock-solid consistency → relational DBs make sense.
Some areas need blazing-fast search over massive documents → Elastic or vector DBs might be right.
For highly dynamic UI interactions? React or similar makes a difference.
For quick internal tools? Even low-code might work better than a full-stack solution.

But I still see devs trying to solve everything with Spring Boot + PostgreSQL + Angular. Or Node.js + MongoDB + React. Or even .NET for things that don’t even touch Windows.

Why? Familiarity. Comfort. Fear of risk.

The irony? Choosing the wrong tool out of comfort is a bigger risk than learning something better suited.

Why It’s All Trade-offs

There’s no magic bullet. Everything has pros and cons:

React gives you flexibility — and 10,000 decisions to make before writing a button.
Spring is powerful — and occasionally eats your weekend debugging autoconfiguration.
MongoDB is fast and flexible — until you realize you needed transactions.
PostgreSQL is reliable — until you’re denormalizing like crazy just for performance.

Once you’ve been around enough stacks (and I’ve seen quite a few), you stop asking “What’s the best?” and start asking “What fits this problem?”

Meme Intermission #2 📈

Dev 1: “Why did you rewrite the app in Go?”

Dev 2: “Because Go is fast and can scale to billion users.”

App:

A Better Way to Think

Here’s how I encourage my team (and remind myself) to evaluate tech choices:

✅ 1. What are the real needs?

Is the data relational? Will it scale? Does it need to be real-time? How often will it change?

✅ 2. Who will maintain it?

The best tech in the world is useless if the team hates working with it — or worse, doesn’t understand it.

✅ 3. Is this solving the problem or just showing off?

If the tech stack is starting to look like a spaceship for a paper plane problem, step back.

✅ 4. Can we evolve this later?

Start simple. Prove the value. Then scale. A good MVP is often a smart script or monolith, not a distributed system.

Closing Thoughts

If you take anything from this article, let it be this:

Each job its tool. Each tool its trade-off.

Don’t chase trends. Don’t cling to what you know just because you know it. You don’t need to know everything, but you do need the wisdom to know when to look beyond your comfort zone.

The best developers I’ve worked with aren’t the ones who know 10 languages — they’re the ones who know how to choose.

🧰 Be a software carpenter. Pick the right tool.

🎯 Aim for solutions, not stacks.

💪 Don’t fear the change when you can lead the change.

Introducing Querity React Components: Streamline Your Frontend Query Interfaces

Bruno Mendola — Wed, 09 Apr 2025 07:16:16 +0000

In a previous article I introduced Querity, a Java library designed to simplify querying both SQL and NoSQL databases using a unified language. Querity makes exposing data through REST APIs effortless.

Building upon that foundation, I’m excited to announce Querity React Components , a set of React components that bring the same ease of use to your frontend applications.

Available on npm:

@queritylib/react

and of course GitHub:

https://github.com/queritylib/querity-react

Why Querity React Components?

Integrating query capabilities into frontend applications can be challenging: queries for real world use-cases can get complex, and creating an interface to support that kind of complexity can take some effort.

With Querity React Components , you can easily create user interfaces that allow users to construct and execute queries, seamlessly interacting with your Querity-powered backend.

Key Components

The library offers two primary components:

QuerityField : A text input component for entering and validating queries.
QuerityBuilderUI : A visual interface for visually building complex queries without manual input.

Installation

To get started, install the package using npm or yarn:

npm install @queritylib/react

yarn add @queritylib/react

Usage

Wrap your application with the QuerityComponentsProvider to provide necessary components and styles:

import {useState} from 'react';
import {
  QuerityComponentsProvider,
  defaultQuerityComponents,
  QuerityField,
  QuerityBuilderUI
} from '@queritylib/react';
import '@queritylib/react/themes/default/style.css';

function App() {
  return (
    <QuerityComponentsProvider value={defaultQuerityComponents}>
      <QueryInterface />
    </QuerityComponentsProvider>
  );
}

function QueryInterface() {
  const [query, setQuery] = useState('');
  const [data, setData] = useState([]);

  const fetchData = async (query: string) => {
    const response = await fetch(`/api/data?q=${query}`);
    // error handling omitted
    const responseData = await response.json();
    setData(responseData.items);
  }

  return (
    <>
      <QuerityField
        value={query}
        placeholder="Enter your query"
        onChange={(q) => setQuery(q)}
        onEnter={() => fetchData(query)}
        onInvalidQuery={(error) => console.error('Invalid query:', error)}
      />
      <QuerityBuilderUI
        query={query}
        onChange={(q) => setQuery(q)}
      />
      <table>
        <tr>
          <th>ID</td>
          <!-- other headers omitted -->
        </tr>
        {data.map((item) => (
          <tr>
            <td>${item.id}</td>
            <!-- other columns omitted -->
          </tr>
        ))}
      </table>
    </>
  );
}

export default App;

In this setup:

QuerityField provides a text input for users to enter queries, with handlers for change events, submissions, and validation errors.

QuerityBuilderUI offers a visual interface for constructing queries, with the possibility of infinitely nesting the conditions and a handler for query changes.

As you can see, the two components can communicate with each other via a shared state, so the changes to one are reflected on the other.

The optional import of the default theme (@queritylib/react/themes/default/style.css) gives a nice look-and-feel to the components. Alternatively, you can create a custom stylesheet and avoid this import (see next section).

Here’s how QuerityBuilderUI looks with the default theme :

Querity React Components styled with default theme

Customization

Querity React Components are designed to be flexible and can be customized to fit your application's styling needs. By overriding the default components provided to the QuerityComponentsProvider, you can integrate with various CSS frameworks like Tailwind CSS , MUI , or Bootstrap.

For example, to customize components with Tailwind CSS:

import {
  QuerityComponentsProvider,
  defaultQuerityComponents,
  QuerityField,
  QuerityBuilderUI
} from '@queritylib/react';

const customComponents = {
  ...defaultQuerityComponents,
  Input: (props) => <input {...props} className={`${props.className} border p-2`} />,
  Select: (props) => <select {...props} className={`${props.className} border p-2`} />,
  Button: (props) => <button {...props} className={`${props.className} bg-gray-200 p-2 cursor-pointer mr-1`} />,
  Checkbox: (props) => (
      <label className="inline-flex items-center cursor-pointer">
        <input type="checkbox" {...props} className="sr-only peer"/>
        <div 
            className="relative w-11 h-6 bg-gray-200 peer-focus:outline-none peer-focus:ring-4 peer-focus:ring-blue-300 dark:peer-focus:ring-blue-800 rounded-full peer dark:bg-gray-700 peer-checked:after:translate-x-full rtl:peer-checked:after:-translate-x-full peer-checked:after:border-white after:content-[''] after:absolute after:top-[2px] after:start-[2px] after:bg-white after:border-gray-300 after:border after:rounded-full after:h-5 after:w-5 after:transition-all dark:border-gray-600 peer-checked:bg-blue-600 dark:peer-checked:bg-blue-600"></div>
        <span className="ms-3 text-sm font-medium text-gray-900 dark:text-gray-300">{props.label}</span>
      </label>
  )
};

function App() {
  return (
    <QuerityComponentsProvider value={customComponents}>
      <QueryInterface />
    </QuerityComponentsProvider>
  );
}

// ...

A final look to the result:

Querity React Components styled with Tailwind CSS

In a similar way, you could instead integrate MUI components, that have a totally different way of declaration.

Querity React Components makes the job easy!

See it in action at Querity Demo… and of course find the code in the querity-demo GitHub repo.

Conclusion

If you enjoyed this post about @queritylib/react, please don’t forget to

give it a⭐ on Github!

Querity React Components bridge the gap between your frontend and Querity-powered backend, enabling the creation of sophisticated query interfaces with minimal effort. By leveraging these components, you can provide users with powerful tools to interact with data, enhancing the overall user experience.

Explore the full documentation and get started with Querity React Components today:

@queritylib/react on npm

If you missed the first article about the Java backend with Querity, you can find it here: Easily query SQL and NoSQL databases in your Java application with one single language.

Easily query SQL and NoSQL databases in your Java application with one single language

Bruno Mendola — Thu, 13 Mar 2025 19:07:37 +0000

In this article you will get to know Querity, an open source Java query builder for SQL and NoSQL, and hopefully discover that it can be useful for you.

Of course you’ve already created some Java web application that expose some REST APIs to query a database, right?

Let’s say that your frontend is something like this, and you have to create a backend with REST APIs to provide the data to display:

Example of a frontend application with data displayed in a grid

With Java and Spring Web / Spring Data is easy: use Spring Initializr to create a draft application, add a JPA entity, a JpaRepository and you’re good to go.

Ok, let’s see some code!

A Maven configuration file (pom.xml)…

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.4.3</version>
    <relativePath/> <!-- lookup parent from repository -->
  </parent>

  <groupId>my.demo</groupId>
  <artifactId>spring-data-jpa</artifactId>
  <version>0.0.1-SNAPSHOT</version>

  <name>spring-data-jpa-demo</name>
  <description>spring-data-jpa-demo</description>

  <properties>
    <java.version>21</java.version>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>

    <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
      <optional>true</optional>
    </dependency>

    <dependency>
      <groupId>com.h2database</groupId>
      <artifactId>h2</artifactId>
      <scope>runtime</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
      </plugin>
    </plugins>
  </build>

</project>

and a Spring Boot Application class…

@SpringBootApplication
public class MyApplication {
  public static void main(String[] args) {
    SpringApplication.run(MyApplication.class, args);
  }
}

This is what you’ll get for free using Spring Initializr.

By now you’ll have a ready-to-run empty application connected to an H2 in-memory database. Let’s fill it!

We add a JPA entity…

@Entity
@Table(name = "`order`")
@Getter @Setter
@EqualsAndHashCode(callSuper = true)
@ToString
public class Order extends AbstractPersistable<Long> {
  private Long orderNumber;
  private ZonedDateTime placementDate;
  private Currency currency;
  private BigDecimal totalPrice;
}

a JPA repository…

@Repository
public interface OrderRepository extends 
    JpaRepository<Order, Long>, JpaSpecificationExecutor<Order> {
}

a data structure for our response…

public record Result<T>(List<T> items, long totalCount) {
}

a service for our business logic…

@Service
public class OrderService {
  private final OrderRepository repository;

  private OrderService(OrderRepository repository) {
    this.repository = repository;
  }

  public Result<Order> getOrders(int page, int pageSize) {
    Page<Order> orders = repository.findAll(PageRequest.of(page - 1, pageSize));
    return new Result<>(orders.toList(), orders.getTotalElements());
  }
}

and a REST controller to handle HTTP requests to a GET endpoint…

@RestController
@RequestMapping("/api/orders")
public class OrderController {
  private final OrderService service;

  public OrderController(OrderService service) {
    this.service = service;
  }

  @GetMapping
  public Result<Order> getOrders(
      @RequestParam int page, @RequestParam int pageSize) {
    return service.getOrders(page, pageSize);
  }
}

Directly exposing the JPA entities from the controller may not be a good idea, because it forces you to keep the transaction open for the duration of the request; usually you want to map the entities to DTO (data transfer object) classes in your service.

But let’s keep it simple for now.

Start the application with ./mvnw spring-boot:run and your application will be up and running in your local host.

Just a simple test with cURL…

curl http://localhost:8080/api/orders?page=1&pageSize=20

and you’ll get a JSON response like this:

{"items":[],"totalCount":0}

Fair enough… the database is empty. But you get the point.

We have a REST API that returns a paginated list of orders.

Spoiler: if you’ll get to the end of the article, you’ll find the link to the repo of the demo application, that has an in-memory database with 1000 records.

Welcome to the real world

Usually, in a real world scenario you need to filter the orders by some value of the entity fields.

Cool. You add some more query parameters to the API, and then your service will have to invoke the repository by passing the filtering info.

In Spring Data JPA this is done with a Specification. So your service method will become something like this…

public Result<Order> getOrders(Long orderNumber,
                               ZonedDateTime placementDateFrom, ZonedDateTime placementDateTo,
                               Currency currency,
                               BigDecimal totalPriceFrom, BigDecimal totalPriceTo,
                               int page, int pageSize) {
  Specification<Order> specification = (root, query, criteriaBuilder) -> {
    List<Predicate> predicates = new ArrayList<>();
    if(orderNumber != null)
      predicates.add(criteriaBuilder.equal(root.get("orderNumber"), orderNumber));
    if(placementDateFrom != null)
      predicates.add(criteriaBuilder.greaterThanOrEqualTo(root.get("placementDate"), placementDateFrom));
    if(placementDateTo != null)
      predicates.add(criteriaBuilder.lessThanOrEqualTo(root.get("placementDate"), placementDateTo));
    if(currency != null)
      predicates.add(criteriaBuilder.equal(root.get("currency"), currency));
    if(totalPriceFrom != null)
      predicates.add(criteriaBuilder.greaterThanOrEqualTo(root.get("totalPrice"), totalPriceFrom));
    if(totalPriceTo != null)
      predicates.add(criteriaBuilder.lessThanOrEqualTo(root.get("totalPrice"), totalPriceTo));
    return criteriaBuilder.and(predicates.toArray(new Predicate[0]));
  };
  Page<Order> orders = repository.findAll(specification, PageRequest.of(page - 1, pageSize));
  return new Result<>(orders.toList(), orders.getTotalElements());
}

Ok, but consider that this is a very simplified entity class with 4 fields only.

Now think to do this for all the fields of a “real world entity class”, then remember to update the filter every time you add a new field, also support filtering by nested fields (for example on order rows), and finally support the sorting of the results.

It’s starting to look like a less simple task.

Also the REST API documentation will be messy at that point… how many parameters can you add before it being unreadable?

Here comes Querity

Querity is a Java query builder that helps you querying the database with one simple query language.

It works with SQL databases (like the one in this example) and NoSQL databases such as MongoDB and Elasticsearch.

You don’t have to manage a REST API that gets more and more complex, you don’t have to continuously change your business logic when you add more fields… with Querity you will immediately get filtering, sorting and pagination with very few lines of code.

Just add the depedencies to your project…

<dependency>
  <groupId>io.github.queritylib</groupId>
  <artifactId>querity-spring-data-jpa</artifactId>
  <version>3.1.0</version>
</dependency>
<dependency>
  <groupId>io.github.queritylib</groupId>
  <artifactId>querity-parser</artifactId>
  <version>3.1.0</version>
</dependency>

And your REST controller can be immediately simplified by having only one query string as request parameter:

@GetMapping
public Result<Order> getOrders(
          @RequestParam(name = "q", required = false) String query) {
  return service.getOrders(query);
}

Your service is also greatly simplified, because all the logic of creating the Specification is inside Querity:

//...
import io.github.queritylib.querity.api.Querity;
import io.github.queritylib.querity.api.Query;
import io.github.queritylib.querity.parser.QuerityParser;
//...

@Service
public class OrderService {
  private final Querity querity;

  public OrderService(Querity querity) {
    this.querity = querity;
  }

  @Transactional(readOnly = true)
  public Result<Order> getOrders(String query) {
    Query q = query != null ?       
        QuerityParser.parseQuery(query) : // parse query language
        Query.builder().build(); // create an empty query if null
    List<Order> items = querity.findAll(Order.class, q);
    Long totalCount = querity.count(Order.class, q.getFilter());
    return new Result<>(items, totalCount);
  }
}

You’ll never need to touch that method again. Why? Because the query string that you’re receiving from the REST API can do filtering, sorting and pagination on whatever field is inside your entity!

Let’s complicate the domain model to see the real advantages. We will add order rows and customer infos…

@Entity
@Table(name = "`order`")
@Getter @Setter
@EqualsAndHashCode(callSuper = true)
@ToString(exclude = "rows")
public class Order extends AbstractPersistable<Long> {
  private Long orderNumber;
  private ZonedDateTime placementDate;
  private String ipAddress;
  private Currency currency;
  @JoinColumn(name = "billing_customer_id", referencedColumnName = "id")
  @OneToOne(cascade = CascadeType.ALL)
  private CustomerInfo billingCustomer;
  @OneToOne(cascade = CascadeType.ALL)
  @JoinColumn(name = "shipping_customer_id", referencedColumnName = "id")
  private CustomerInfo shippingCustomer;
  @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
  private List<OrderRow> rows = new ArrayList<>();
  private BigDecimal totalPrice;
}

@Entity
@Getter @Setter
@EqualsAndHashCode(callSuper = true)
@ToString(exclude = "order")
public class OrderRow extends AbstractPersistable<Long> {
  @ManyToOne
  @JsonIgnore
  private Order order;
  private Long rowNumber;
  private String sku;
  private String description;
  private Long quantity;
  private BigDecimal unitPrice;
  private BigDecimal totalPrice;
}

@Entity
@Getter @Setter
@EqualsAndHashCode(callSuper = true)
@ToString
public class CustomerInfo extends AbstractPersistable<Long> {
  private String firstName;
  private String lastName;
  private String email;
  @Embedded
  private Address address;

  @Embeddable
  @Getter @Setter
  @EqualsAndHashCode
  @ToString
  public static class Address {
    private String streetAddress;
    private String city;
    private String postalCode;
    private String country;
  }
}

Our domain model now looks like this:

Without implementing any new line of code, we are now be able to run this kind of queries:

orderNumber=500

placementDate>="2024-07-01T00:00:00.000Z" page 1,10

shippingCustomer.address.country="Italy"

distinct and(rows.totalPrice>1000,currency="EUR") sort by placementDate desc page 1,20

As you can see, we’re even able to filter by nested fields , like the order rows price or the shipping country.

Querity has a lot of other features, and this article is not big enough to cover all of them in detail. Just to mention two of them, there’s a module to support queries deserialization from JSON in Spring Web MVC; and also support for DTOs , because you may not want to expose the database entities to the presentation layer.

We’ve used a SQL database and JPA for this tutorial, but you can switch to MongoDB or Elasticsearch just by changing the imported module. The query language will not change.

Even Spring is not mandatory: if you have a Jakarta EE application, you can import the querity-jpa module and leverage the plain Jakarta Persistence API.

A Java DSL is also available to create queries with a fluent syntax , so you can easily use Querity for your internal business logic.

Just like this:

Query query = Querity.query()
    .distinct(true)
    .filter(
      and(
        filterBy("rows.totalPrice", GREATER_THAN, 1000),
        filterBy("currency", EQUALS, "EUR")
      )
    )
    .sort(sortBy("placementDate", DESC))
    .pagination(1, 20)
    .build();

Conclusions

If you think that Querity could be useful for you, give it a⭐ on Github.

The full Querity documentation is available in its own website, with all the details about the features and the query language.

Last but not least, you can also see the code of the Querity demo application that inspired this post.

Have fun! 😎