DEV Community: LeeLussh

Become a Better Java Developer: 19 Tips for Staying Ahead in 2024

LeeLussh — Wed, 08 May 2024 12:53:24 +0000

Recently I reached out to one of my fellow Java developers who is very experienced and has been working in the industry forever and asked for his thoughts about the observability improvements in JDK 21 and Spring Boot 3.2 and if he has already migrated from 17 to 21 and to Spring Boot 3.2.

This is the reply I got from him:

“Lately, I’ve been feeling quite rusty, my current job has me solely focused on building an IntelliJ plugin, it’s been almost two years now. And I’m concerned I’m not keeping up to date. I’ve promised myself to take a tutorial and learn everything from Java versions 17 to 21. With Java 22 nearly released and Spring 3.2 out, I’m not familiar with all the improvements. I’ve already heard about the exciting new features of Java 22 like the non-Java interop and access to important libraries like LAPACK and BLAS. These libraries power significant Python libraries like NumPy, offering new opportunities for Java.

I’m still working on version 17. I know many companies still use Java 8. But still, I’d love to experience the time-saving, memory-saving, or new possibilities opened up by new Java specs. I was over the moon when I heard about lambda function support. Some of the stuff in the latest release seems like black magic to me, but I know I will love it. It’s like a new level in my favorite video game.”

After talking with my friend, I decided to reach out to the folks on r/ExperiencedDevs on Reddit. I wanted to know if other developers experience similar feelings and if they have suggestions, aside from tutorials, to boost confidence as a Java developer. Here is the thread: if you want to check it out.

After posting my question and receiving so much solidarity, I shared it with my friend. He was very happy to know that he was not alone. We both felt that I should compile all the tips I received and create a post for developers who feel they are falling behind in staying current.

Source: Reddit

Here are the tips I got on becoming a better Java developer

Bump up the version number, and JetBrains IDEs auto-suggest most of the new changes. IntelliJ itself does a great job of telling you if you aren’t taking advantage of new language features.
Learn Kotlin: it might give you some interesting perspective (and the ability to shift jobs if the need arises, etc.). My understanding is that Java 17 and 21 are actually significantly better than 9 & 11, and adopt a lot of similar changes to what Kotlin introduced (other than null safety, because of backward compatibility)
Feeling rusty means a chance to grow. It’s a challenge, and that’s what keeps me from getting bored. Think about what you find most intimidating and incomprehensible about the entire computation stack. Learn deeply about that.
Look into how other languages/frameworks work. Sometimes, one framework has a long-standing issue everyone is complaining about, and there is just no such thing in another framework. It’s eye-opening how a better approach can make your life so much easier
Get familiar with Loom. That’s the most foundational change to Java in a very long time.
Read about Structured Concurrency in JDK 21: https://openjdk.org/jeps/428 it really is a leap forward in Concurrent Programming. There are two separate concurrency innovations. Both are major improvements. Virtual Threads. **This is final in JDK 21. This is basically what Golang (and others) do. You get the high performance of async/reactive programming without the programming complexity. **Structured Concurrency. This is still in preview in JDK 21. Golang has something similar (https://pkg.go.dev/golang.org/x/sync/errgroup), but IMO, the Java API is nicer.
Get some nice coverage from Oracle, they cover a lot of the new features and changes to the Java ecosystem with 21. For the most part, the features added have use cases you may or may not need, so you should take the time if you need to; otherwise, just get some general understanding and updates from Oracle’s Java Day presentations. They were pretty interesting talks too. Not so dull.
Learn Groovy and later on Scala. After learning Scala, you will probably never want to program in Java again. Also, Scala pays better than Java or Kotlin and is much nicer to program when you learn it. But there are fewer jobs than in Java.
Check out https://advancedweb.hu/a-categorized-list-of-all-java-and-jvm-features-since-jdk-8-to-21/. Looks like some nice features, but a lot of them are relatively minor. Unnamed variables, for example. Great, I use that in other languages already, but nothing that changes too much. I like that they added sealed classes.
Practice Continuous Feedback during the Dev Cycle. Collect data about your code so you can identify issues before reaching prod, understand test results, and make the right design decisions.
Try Ktor for the following reasons:
- Easier upgrades since there aren’t interdependencies
- No “magic”, the code you write is the code that is run. AOP can be a nightmare to debug
- WAY more performant. Spring Kafka is an order of magnitude slower than using the Apache API
- The dependency tree is about 1/3rd the size for the same functionality -Startup time is basically instantaneous
Build a side project: If you’re looking for projects to build, try https://codingchallenges.fyi/ it’s really good.
Take observability seriously, and get familiarized with observability tools and techniques. Understand profiling, monitoring, tracing, and debugging. Explore tools like JVisualVM, JProfiler, and Continuous Feedback.
Stay in touch with the community – Java is a mature community with many Java champions who are very helpful. Solidarity and shared knowledge can boost your confidence.
Find a JUG around your location and attend the meetups so you can get updates and also mingle with some awesome talented people.
Read professional developer blogs and also follow these devs on social for updates. Here is a good list of 10 developer blogs related to Java and related topics: This article also contains some websites like Foojay and Digma which deliver high-quality content for developers.
Follow influencers on social media like Piotr Mińkowski, a Solution Architect at Red Hat. He writes about Java, Spring, Kotlin, microservices, & K8s. Also, Josh Long, a Spring Developer Advocate (@Java_Champions & @Kotlin @GoogleDevExpert) @VMwareTanzu https://YouTube.com/@coffeesoftware for updates about Spring Boot.
Sign up for Rodrigo Graciano’s weekend reading list, where he shares the best Java articles of the week. Here is the website: https://graciano.dev/.
I saved the best for last, as I knew people would associate “feeling rusty” with Rust: ‘If you are feeling quite Rusty, might I recommend you take up my Lord and Savior- Rust”

Final Words:)

I’m sure that some of you can relate to the situation and find these tips valuable. And again there’s a supportive community out there ready to help out, and that’s great!

Ping me on our Slack Channel if you have any other tips that you want to share.

Try Digma

Is It Worth Learning Spring Boot in 2023

LeeLussh — Wed, 22 Nov 2023 10:55:29 +0000

In this blog, I’ll outline why learning and mastering Spring Boot in 2023 is a worthwhile endeavor, even though there may be a few differing opinions. I’ll also explore how Spring Boot compares to other backend technologies and alternative Java frameworks.

10 REASONS WHY LEARNING SPRING BOOT IS WORTH IT IN 2023

Hey folks, I’m currently in the process of exploring backend technologies, particularly for startups where time-to-market is crucial. As I started my research to find a technology that complements my existing knowledge, my heart was leaning toward Spring. However, there was a common concern that kept cropping up – many voices in the community seemed to echo the same sentiment: Spring Boot is sluggish in terms of development speed.

In my case, it’s even more confusing because I have a similar level of proficiency in Django, Node, and Spring. So, I decided to put them to the test, not with simple to-do lists or hello-world apps, but with a complex part of my app. And frankly, my experience led me to a different conclusion. I strongly disagree with the idea that Spring is slower when it comes to development speed. In fact, quite the opposite.

To make my decision-making process even more difficult, I also get a choice of between the alternatives in building backend apps on Java like Quarkurs, Micronaut, VertX, Play + Akka, Dropwizard, etc. and the list can be even bigger if to include Kotlin, Scala and Clojure frameworks.

I know that Spring/Boot does have a lot of problems to overcome. But the same counts for other ones as well. But the development speed part seems unjustified. So I continued my research and got more opinions. Based on my results and the different POVs of different Java SE and EM.

The answer is yes, in 2023, and most likely will be in 2033 as well. Spring is everywhere!

In this blog, I’ll list the reasons it is worth learning Spring Boot in 23 and how it compares to other backend technologies and alternative Java frameworks.

1. SPRING REMAINS VIABLE, AND ITS TRACK RECORD OF STAYING CURRENT AND RELEVANT IS IMPRESSIVE

Many experienced developers I’ve had the privilege to speak and work with, who have been deeply involved in the world of Java and Spring for many years, readily admit that the release of Spring Boot was nothing short of a relief.

The burden of configuring every aspect of a Spring application was overwhelming, especially for newbies, and Spring Boot’s introduction marked a turning point. It brought simplicity and efficiency to Java development, allowing developers to shed the burden of a lot of boilerplate code and focus on what truly mattered: writing robust business logic.

But it doesn’t stop there. What truly sets Spring Boot apart is its ability to evolve. It’s not merely a technology of the past. Instead, it has continually adapted to meet the ever-changing demands of modern software development.

Spring Boot’s journey, marked by continuous innovation, a dynamic and supportive community, and an inherent commitment to staying at the forefront of technology trends, is a testament to its reliability.

Spring Boot now provides enterprise-ready features and integrates well with the microservices and cloud-native trend, providing a platform that’s perfectly suited for building scalable, distributed applications in a cloud-centric world.
According to the recent developer ecosystem survey JetBrains, Spring Boot and Spring MVC keep their leading positions as the most used web frameworks for developing in Java.

2. THE ECOSYSTEM INTEGRATES WITH EXISTING POPULAR LIBRARIES

<dependencies>
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-data-jdbc</artifactId>
   </dependency>
   <dependency
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-data-jpa</artifactId>
   </dependency>
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-graphql</artifactId>
   </dependency>
   <dependency>
     <groupId>com.mysql</groupId>
     <artifactId>mysql-connector-j</artifactId>
     <scope>runtime</scope>
   </dependency>

   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-test</artifactId>
     <scope>test</scope>
   </dependency>
   <dependency>
     <groupId>org.springframework.amqp</groupId>
     <artifactId>spring-rabbit-test</artifactId>
     <scope>test</scope>
   </dependency>
   <dependency>
     <groupId>org.springframework.graphql</groupId>
     <artifactId>spring-graphql-test</artifactId>
     <scope>test</scope>
   </dependency>
 </dependencies>

As a developer in the present day, you’ll find yourself juggling many tools and libraries to build applications. These tools range from programming languages, frameworks, and libraries to databases, database connectors like Hibernate and JPA, and messaging systems like Apache Kafka and RabbitMQ.

Let’s say you’re building a web application. You might use a programming language like Python, a backend web framework, a front-end framework, and a database like PostgreSQL. You may also need to tap into various third-party APIs for functionalities like payment processing, user authentication, and sometimes geolocation services. It is your job as a developer to make all of these components work seamlessly together.

Modern frameworks like Spring Boot make your work as a developer much easier. Instead of trying to integrate these tools yourself each time you’re developing a new product, Spring Boot really makes your life as a developer much easier by streamlining the process of incorporating these technologies into your project.

This reduces the time you’d have to spend integrating them by yourself and makes you a more efficient developer.

If you have been following developments in the tech space in the last couple of years, you can actually attest that Spring Boot has done well in keeping up with new libraries and tools that have emerged. Whether you’re working with GraphQL for powerful query languages, reactive programming with Spring WebFlux, or cloud-native technologies such as Docker and Kubernetes, Spring Boot integrates seamlessly, making it an excellent choice for modern development.

3. SPRING IS EVERYWHERE – PERSONAL OR CORPORATE

When I reflect on my developer journey, I can’t help but appreciate how Spring Boot has become an integral part of my career. It’s a framework that bridges the gap between my personal passion projects and the projects we are doing at work.

What struck me as remarkable was the seamless transition between my personal and corporate development experiences. This means that the skills I practice in personal projects using Spring Boot are directly transferable to my work in the corporate world. This means you can use Spring Boot anywhere.

So whether you want to build a simple personal project or a large enterprise application at your workplace, Spring Boot is the go-to framework that rises to the occasion.

In the corporate world, Spring Boot’s adoption has been remarkable. It’s not just a framework of choice; it’s become a standard and the backbone of many enterprise-level applications.

Its reliability, community support, and mature ecosystem of integrations also make it the go-to solution for building scalable, maintainable, and enterprise-grade applications.

4. SPRING BOOTS TESTABILITY

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
@SpringBootTest
public class ProductServiceTest {
    @Autowired
    private ProductService productService;
    @Test
    public void testProductCreation() {

        Product product = new Product("Sample Product", 10.0);
        // Act
        Product savedProduct = productService.createProduct(product);
        // Assert
        assertNotEquals(0, savedProduct.getId());
        assertEquals("Sample Product", savedProduct.getName());
        assertEquals(10.0, savedProduct.getPrice(), 0.01);
    }
}

Testing is every developer’s best friend, right? Well, it should be, but let me take you back to when it was more like a nagging headache than a relief.

In my early days as a developer, writing tests was a daunting exercise, especially while I was still trying to master the basic concepts of programming. Setting up test cases felt like solving a riddle and catching exceptions was always a constant struggle. The process was so cumbersome that I felt discouraged from writing thorough tests and would often find ways to evade them.

Fast forward a few years, when I started working with the Spring Boot framework writing unit, and integration tests became less of a headache and more of a satisfying routine. I would also encourage you to choose a framework with good features that enhance writing tests to help you along.

Spring Boot is an excellent choice for developing applications with robust testing features.

For the following reasons:

Spring Boot integrates seamlessly with popular testing frameworks like JUnit, Mockito, and Spring Test.
Spring Boot provides a wide range of testing annotations, including @SpringBootTest, @DataJpaTest, and @WebMvcTest, which help configure the application context for specific types of testing, streamlining the process.
Spring Boot allows you to leverage the vast ecosystem of Spring Frameworks, such as Spring Security for security testing and Spring Data for database-related testing.
Spring Boot support for mocking frameworks like Mockito gives you access to utilities for generating test data, enabling you to build even more robust applications.
Spring Boot integrates well with TestContainers to fast-track your integration tests.
If you’re building a distributed application, testing is non-negotiable.

5. MONITORING AND OBSERVABILITY

When I started my programming journey back in college I started by developing basic single-page applications, which were relatively straightforward and had limited complexity. These single-page applications typically had a simple front end, minimal data processing, and a single server handling requests. With this type of application, it was easy to pinpoint issues and make adjustments on the fly.

However, as time has gone by, my projects have grown in scope and complexity, and I now find myself dealing with more complicated applications. These applications mostly feature multiple microservices, databases, external integrations, and complex business logic.

Over this time, as the complexity of the systems I work on increases, I’ve learned to value metrics, logs, and distributed tracing.

Spring Boot, especially Spring Boot 3, offers built-in observability capabilities that make it easier for you to monitor, diagnose, and gain insights into the internal state of your applications in production environments. Here are some Spring Boot features that you can leverage to observe and monitor your applications:

Actuator Endpoints.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

/actuator/health endpoint that provides information about the health of your application
/actuator/metrics provides detailed metrics on various aspects of your application, such as memory usage, garbage collection.
The /actuator/info endpoint lets us expose custom application information.
/actuator/env provides access to the application’s environment properties, which can be useful for troubleshooting configuration issues.
You can also build your custom endpoints to help you expose specific data or trigger actions.

Metrics Collection – Micrometer integration. I’ve seen how the rise of microservices and cloud-native architectures has made monitoring these distributed systems absolutely necessary. This is where Micrometer comes into play, presenting itself as the go-to “SLF4J” for application metrics.

Micrometer is like an all-around utility belt for application metrics, ready to support a wide range of monitoring systems. It’s like a multipurpose tool for developers, enabling us to collect valuable insights from our applications without being locked into a particular monitoring solution.

It’s all about giving us the flexibility to choose the right tool for the job and ensuring that we’re not confined to a single system. For instance, you can work with tools such as Prometheus, Datadog, InfluxDB, and more.

Micrometer also has a rich set of instrument types, such as gauges, counters, timers, and distribution summaries.

2023-03-05 10:57:51.112  INFO 45469 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet Engine: Apache Tomcat/7.0.52
2023-03-05 10:57:51.253  INFO 45469 --- [ost-startStop-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2023-03-05 10:57:51.253  INFO 45469 --- [ost-startStop-1] o.s.web.context.ContextLoader            : Root WebApplicationContext: initialization completed in 1358 ms
2023-03-05 10:57:51.698  INFO 45469 --- [ost-startStop-1] o.s.b.c.e.ServletRegistrationBean        : Mapping servlet: 'dispatcherServlet' to [/]
2023-03-05 10:57:51.702  INFO 45469 --- [ost-startStop-1] o.s.b.c.embedded.FilterRegistrationBean  : Mapping filter: 'hiddenHttpMethodFilter' to: [/*]

The significance of logging has grown over time from a mere debugging tool to a way that you can build reliable, maintainable, and efficient software.

In my experience with Spring Boot, it’s great to know that it relies on Commons Logging for its internal logs but remains flexible when it comes to the underlying log implementation. It’s like having the best of both worlds!

Out of the box, Spring Boot provides default configurations for Java Util Logging, Log4J2, and Logback. In each scenario, the loggers come pre-configured to display log messages on the console, and you also have the option to direct the logs to a file if needed.

If you’re using the ‘Starters,’ Spring Boot sets up Logback for your logging needs by default. What’s cool is that it takes care of Logback routing too, ensuring that even if you have dependent libraries that use different logging frameworks like Java Util Logging, Commons Logging, Log4J, or SLF4J, everything will work harmoniously.

So, you’ve got the freedom to choose your preferred logging framework, but Spring Boot’s default setup with Logback simplifies things, making it easy to get started without worrying about compatibility issues with other libraries.

'dispatcherServlet' to [/]
2023-03-05 10:57:51.702  INFO 45469 --- [ost-startStop-1] o.s.b.c.embedded.FilterRegistrationBean  : Mapping filter: 'hiddenHttpMethodFilter' to: [/*]

Distributed Tracing with OpenTelemetry. Let’s say you’re a relatively new developer responsible for maintaining a large e-commerce platform. One day, you receive a report from the customer support team indicating that some customers are experiencing issues during the checkout process. Users are complaining about orders not being processed, and they’re unable to complete their purchases.

Without proper observability tools and distributed tracing, you don’t have end-to-end visibility into the request flow. You’re blind to the interactions between microservices and it becomes hard to trace how each request is handled, and where are the errors and bottlenecks.

OpenTelemetry is today considered the standard for tracing with a wide range of OSS and commercial tools to support it such as Jaeger, Zipkin, and enterprise APMs. Fortunately, Spring has extensive support for OTEL across its many projects and libraries. Spring Boot supports both the OTEL agent instrumentation – a very quick and unobtrusive way to get started in dev and test, as well as the more performant Micrometer Tracing library.

If you need an extra shortcut in bootstrapping OpenTelemetry (OTEL) to your spring application or want to integrate all of that important data into your dev process, consider free developer tools such as Digma. Digma is a Continuous Feedback(CF) tool that is meant to streamline the work of collecting and processing data about your code from OTEL observability sources. Digma runs locally as an IDE plugin and collects data about your code, from traces to logs and metrics, while you’re coding. This means you can catch issues and get insights in real-time.

6. SIMPLICITY AND RAPID DEVELOPMENT

Choosing the right tool at the onset of any project is a strategic decision with far-reaching consequences. It can affect everything from the development process and performance to security, scalability, and user experience.

Equally, choosing the right framework can significantly impact your learning curve and early experiences. Spring Boot is an excellent choice if you’re just starting your coding adventure due to its “convention over configuration” philosophy.

Spring Boot reduces Spring’s verbose and complex setup. This means that as a beginner, you can focus on coding your application’s core logic without getting lost in a sea of configuration files. With Spring Boot, you can create self-contained, executable JAR files, making deployment very easy. There’s no need to manage application servers or complex deployments.

Spring Boot also offers preconfigured templates or collections of dependencies that simplify setting up and configuring an application; these are known as Spring Boot starters. These starters are designed to look at your classpath and the beans you’ve configured and make reasonable assumptions about what might be missing. They then automatically add the necessary components, libraries, and configurations to get your application up and running quickly.

7. MICROSERVICE SUPPORT

You may have heard many conversations lately that microservice architectures are the ‘new normal,’ way of developing applications.

It’s true, they’re cool. The idea of breaking down monolithic applications into smaller, independently deployable services makes sense. So, inspired by the hype, I joined a discussion on Reddit about microservices. It started with enthusiasm, but as the thread grew, a theme emerged – the “Death by a Thousand Microservices.“

As developers shared their experiences, it was evident that managing many microservices can be a real headache. The challenge of orchestrating and monitoring all these components can lead to complexity overload.

Spring Boot comes to the rescue. I’ve found that its features make working with microservices far less intimidating. Spring Boot’s integration with Spring Cloud provides tools for service discovery, load balancing, and distributed configuration. These features simplify the creation and management of microservices, ensuring they work seamlessly together.

Other features that I and many other Java developers appreciate when working with Spring Boot include support for containerization technologies like Docker and orchestration platforms like Kubernetes, seamless integration and interoperability with many technologies and extensive documentation.

8. EMBEDDED SERVERS

<dependency>
     <groupId>org.apache.tomcat.embed</groupId>
     <artifactId>tomcat-embed-core</artifactId>
     <version>8.5.23</version>
     <scope>compile</scope>
</dependency>
<dependency>
     <groupId>org.apache.tomcat.embed</groupId>
     <artifactId>tomcat-embed-el</artifactId>
     <version>8.5.23</version>
     <scope>compile</scope>
</dependency>
<dependency>
     <groupId>org.apache.tomcat.embed</groupId>
     <artifactId>tomcat-embed-websocket</artifactId>
     <version>8.5.23</version>
     <scope>compile</scope>
</dependency>

9. SPRING BOOT IS OPEN SOURCE

The open-source nature of Spring Boot is something that has resonated deeply with me and many other developers. What I love about the open-source nature of Spring Boot is that it levels the playing field for everyone. So regardless of whether you’re a student, a newbie in technology, or an experienced developer, you have access to the same code, the same documentation, and the same opportunities for contribution as anyone else.

Open source promotes transparency. So you’re not just working with a black-box solution, but you can investigate how the framework works under the hood and even make modifications as you deem fit. It also means that there are no costs attached. You can use the framework freely for personal projects, side hustles, or enterprise-grade applications without worrying about costs.

Finally, one of the most fulfilling aspects is that you can contribute through bug fixes, documentation improvements, and even new Spring Boot features.

10. COMMUNITY AND SUPPORT

I have been a developer for a little over a decade, and I have lost count of the number of times I have sought and received support from different communities. These communities are distributed across different platforms such as Reddit, Twitter, and Stack Overflow.

As a developer, it is often easy to get carried away with the notion that staying indoors in your small room and coding around the clock in isolation is the way to progress. However, the reality of software development is quite the opposite. The field of programming is collaborative in nature, driven by the constant exchange of ideas and a team approach to solving complex issues.

Being part of a community is very helpful, especially when you’re just starting your coding journey.

Spring Boot has been around for a while and has a thriving ecosystem of developers, architects, and experts who constantly share ideas and resources and help each other solve problems. Due to its open-source nature, developers can also share ideas that improve the Spring Boot framework, and you can also participate.

SPRING BOOT VS QUARKUS

I came across an engaging discussion on Reddit that revolved around the topic of “Micronaut vs others (Spring Boot, Quarkus, and co.).” Developers are actively exploring different alternatives when it comes to selecting a framework for building microservices.

SPRING BOOT VS. DJANGO OR NODE JS.

In my experience and career, I have also come to appreciate the unique strengths and trade-offs of different technologies. Many developers seem to share similar opinions when comparing Spring Boot to other frameworks outside of the Java ecosystem.

The Java ecosystem has a relatively higher initial learning curve but stands out for its robustness and extensive libraries. Spring Boot excels in scenarios where reliability and scalability are important. However, one trade-off is the slightly longer startup times compared to other frameworks.

Python and Django, on the other hand, offer a delightful experience for web development, particularly in projects where developer productivity and rapid iterations are essential.

Python may not be as performant as Java in certain situations, it has a readable and clean code syntax. Django has shown that it’s an excellent choice for content management systems, web applications, and situations where getting a project up and running quickly is a priority.

Node.js, with its JavaScript backbone, has been my go-to for real-time applications and microservices. Its performance, especially for I/O-bound and real-time scenarios, is exceptional.

My experience with Node.js is that it is a perfect choice where speed and scalability are paramount, particularly when building real-time applications like chat platforms. Besides, the ability to use a single language for both client and server makes your life even easier.

CONCLUSION: IT IS WORTH LEARNING SPRING BOOT

Spring Boot is still the leading framework in the Java world, and it doesn’t seem to change anytime soon.

Spring Boot is still very relevant. If or when it is surpassed by something else, you will learn portable concepts that will likely be used in other frameworks. Until then, the marketplace has opportunities for Spring Boot knowledge now and well into the future. Moreover, with the new Spring Boot releases, I’d say that Spring Boot is likely to stay the de-facto Java framework for the next few years at least.

It’s also important to note the growing relevance of frameworks like Micronaut and Quarkus, which offer unique advantages for specific types of projects. Exploring these alternatives and understanding when to apply them can further enhance your abilities as a developer.

FAQ

What is Spring Boot, and why should I consider learning it in 2023?

Spring Boot is a popular open-source Java framework that makes it easier to create microservices and web applications. Learning Spring Boot in 2023 is worth it because it offers numerous advantages for modern software development projects and a lot of work opportunities.

What are the key features that make Spring Boot stand out in 2023?

Spring Boot offers features like auto-configuration, rapid development, and a wide range of built-in tools for microservices, web applications, and more. These features enhance developer productivity and code quality.

What are some real-world applications of Spring Boot in 2023?

Spring Boot is used in a wide range of applications, from web development and microservices to API creation and backend systems. Companies such as Netflix, Alibaba, LinkedIn, Uber and Groupon use Spring Boot.

Install Digma for free: Here

Identifying Code Concurrency Issues with Continuous Feedback (CF)

LeeLussh — Tue, 14 Nov 2023 10:47:44 +0000

Hello folks! My name is Asaf Chen and I’m a senior Software Engineer here at Digma. I wanted to share a short tale on how our team used our own Continuous Feedback tool to identify a code concurrency issue. Even as a developer of Digma, I was seriously overwhelmed by the performance gains. Beyond Digma and its specific capabilities, I think this story can be meaningful to any backend developer who is having similar issues in trying to optimize a complex system.

Let’s start with the obvious. As you probably know, concurrency issues emerge when multiple threads access shared resources concurrently, often leading to unexpected behavior. If you’ve been doing this for a while, then you probably also know first-hand how it becomes super challenging to identify such issues as they emerge throughout the dev cycle. Such challenges will then continue to haunt the application if it lacks visibility into real-world performance. The absence of such visibility that most developers face today when building software in complex distributed systems makes it difficult to make informed design decisions or evaluate the consequences of code modifications.

This is where Continuous Feedback comes into play, our vision of Digma is to create a pipeline automation solution capable of detecting diverse issues throughout the development cycle in a continuous manner by providing contextual insights. But enough background! Let’s get into the specifics of what actually occurred.

The Tale:

Recently, we observed unexpected behavior and encountered performance issues in our backend services. In response, we decided to dogfood our own Continuous Feedback system in an attempt to identify the issue and pinpoint the root cause of this behavior.

Simply looking at the statistics was no help. There were multiple areas experiencing slowness, regardless of concurrency, and other areas that were blazing fast unless they were blocked due to another concurrent execution. We knew the data was there – in the OpenTelemetry observability were were collecting, but we also knew a lot of processing was needed to be able to RCA this to a specific piece of code responsible for the issue.

The benefit of Continuous Feedback is that it is, just as the name suggests – continuous. In practical terms that means developers don’t need to go fishing looking for such issues, if they exist they will be detected automatically, whether we know to look for them or not. All that remained was to actually see what Digma’s analysis of the code was telling us.

Indeed when we looked at the code, the issue was right there in the open. This insight saved us hours that would have otherwise been spent, identifying whether an issue actually exists, investigating it, searching, and attempting to unravel the intricacies of the problem. This entire investigation would have required a backlog item to be created prioritized, assigned and hopefully not pushed aside because of some urgent matters. Luckily using existing observability data, Digma was able to show a very specific analysis of the concurrency issue we were facing.

The Specific Problem Identified: Concurrency

The graph above consists of two axes: the y-axis represents the average duration of the span in seconds, while the x-axis represents concurrency. The duration remains relatively constant until we hit a concurrency level of about 35 executions in parallel – then the average duration begins to increase (shown by the blue dots).

The Root Cause

The analysis of the observability data went beyond identifying the issue, it was also able to pinpoint the root cause of this scaling problem.

In the graph, the root cause is represented by the orange line which we track in parallel to the overall execution time. It represents a query call triggered as a part of the request handing in this endpoint. As you can observe, both lines follow a similar pattern, it is specifically that query that is suffering the scaling issue that is then propagating onto the endpoint.

After identifying the root cause of the issue, we analyzed the problematic span and observed an inefficient query execution plan. We proceeded to refactor the query and added missing indexes, addressing the underlying problem. The scaling issue was resolved quickly as we were able to focus on the right specific issue.

Why developers need CF

I think this story highlights just how important data can be to developers. Observability data that is often thought to be relevant only for the DevOps, SREs, and IT folks can make a huge impact on developers developing scalable and maintainable systems.
If developers can’t see how their code performs in the real world, they can’t make informed design decisions and assess the impact of their changes. By closing the loop between observability and code, Digma opens the way for a new method of development.

Download Digma Continuous Feedback: Here

The Empathetic Developer

LeeLussh — Mon, 06 Nov 2023 14:31:46 +0000

“The craft of programming begins with empathy, not formatting or languages or tools or algorithms or data structures.” – Kent Beck.

This blog is part of our series “I’m Not a Great Developer,” where we discuss traits, skills, and habits that differentiate you as a developer and help you get maximum impact and create efficient software engineering teams.

This time, Markus discusses the importance of being an empathetic developer and how senior developers can leverage empathy for maximum impact. Markus Westergren is an experienced Senior Consultant/Staff Engineer with a demonstrated history of working in the information technology and services industry.

What is Empathy and Why is it important?

In today’s fast-paced and ever-evolving world of technology, being a great developer requires more than just technical skills. While mastering programming languages and staying updated with the latest frameworks are crucial, senior developers must also possess empathy. Empathy, often seen as a soft skill, can be the differentiating factor that propels a developer from good to great.

Source: Twitter

Empathy is the ability to understand and share the feelings of another person. It involves putting yourself in someone else’s shoes, considering their perspective, and acknowledging their emotions. Empathy fosters better communication and stronger relationships in a collaborative work environment. It enables teams to work more effectively together.

Senior developers possess a unique opportunity to leverage empathy for maximum impact in their roles. They can cultivate better relationships with their teams, stakeholders, and users, by developing and honing their empathy skills. It contributes to a more positive work environment and enables them to understand and meet the needs of their colleagues and users.

Empathy in Your Team

One way senior developers can leverage empathy is through effective communication. Being able to listen actively and empathetically, without judgment, can open up lines of communication and foster greater collaboration within the team. Understanding the perspectives, concerns, and objectives of others allows senior developers to find common ground and work towards shared goals. It will ultimately lead to better decision-making processes and overall project success.

Empathy also plays a crucial role in the mentorship and guidance of junior developers. Senior developers can provide support, guidance, and encouragement by empathizing with their struggles and frustrations. It will help junior developers grow and succeed and create a positive learning environment where everybody feels valued and supported.

In addition, empathy promotes diversity and inclusion within the development team. It allows senior developers to appreciate and understand the diverse backgrounds, experiences, and perspectives of their teams. This will, in turn, lead to more inclusive decision-making processes, where everyone’s ideas and concerns are considered and valued, ultimately creating effective software engineering.

Empathy in Client Relationships: Delivering Exceptional Solutions

Empathy enables senior developers to understand the end-users of their software or applications. By putting themselves in the shoes of the users, they can anticipate their needs and preferences, leading to more user-friendly and intuitive designs. Empathy-driven development helps create products that truly meet the users’ expectations, resulting in higher user satisfaction and loyalty.

Empathy Towards Yourself: Nurturing Self-Compassion and Self-Care

Empathy towards oneself involves recognizing, understanding, and responding compassionately to our emotions, thoughts, and experiences. It is about treating ourselves with the same understanding and support we would offer a friend or loved one. It means acknowledging our own pain, fears, and failures, and responding to them with kindness rather than self-judgment or criticism.

Conclusion: Prioritizing Empathy as a Fundamental Skill

Empathy towards oneself is a vital aspect of self-care and personal growth. By practicing empathy and self-compassion, we can nurture a healthier relationship with ourselves, leading to increased well-being and resilience. Remember, treating yourself with kindness and understanding is not a selfish act but an essential part of leading a fulfilling and balanced life.

Overall, the ability of senior developers to leverage empathy for maximum impact cannot be understated. It contributes to more effective communication, fosters stronger relationships, promotes diversity and inclusion, and ultimately leads to better outcomes for the development team and its end-users. Senior developers can elevate their work from good to great by prioritizing empathy as a fundamental skill.

One great way to develop your empathy skills is to work with a mentor. I have written an eBook that will help you get the most out of a mentorship. You can download it for free here: https://sendfox.com/lp/1xz4v5.

We at Digma would love to hear what you think are the key traits or skills for becoming a great developer. Connect with us here.

Punch for the optimization bucks, measuring performance impact: A Developer Diary

LeeLussh — Mon, 23 Oct 2023 14:18:04 +0000

In this short development diary, I’m going to share with you why and how I came up with the "Performance Impact Score”, what it is, why it is needed and how it was implemented and added to our Continuous Feedback (CF) platform.

Early Optimization is the Root of All Evil?

A few years ago I was working on an online service to support local businesses. The domain was QR codes, promotions, and mobile presence. We must have been doing something right, as the service gained momentum and I partnered with a large distributor that used my services in far-away places, supposedly sparking even more interest from other businesses.

Our product was meant to service a few local customers and the code was not designed for scale. As many startups and young products do, we made a conscious decision to focus on rapid, fast development and did not bother optimizing the code. I had in mind that premature optimization would waste too much time, delaying the service launch.

Reality was quick to catch up with us. Soon, customers began complaining. Pages were loading too slowly, operations were taking too long and even timing out. User experience was affected, and business was impacted. Struggling to match usage and demand, it seemed we discovered a deep truth about optimization: If you’re not early - you’re late. We’ve quickly moved from ‘premature optimization’ concerns to overdue optimization. We were in catchup mode.

Undaunted, we rolled up our sleeves and started making the changes we believed were necessary.

Optimizing the code where it counts the most

The thing is, after optimizing for two weeks I was not able to make an impactful change. We were very successful in refactoring, and in fact, made many code changes and improvements if you count the number of commits. It’s just that their aggregated effect did not do much to move the needle. In retrospect, I know I was optimizing the wrong parts of the code.

Eventually, when I did end up fixing something that really counted - a serious bottleneck in the service, it was almost by chance. I did not expect this specific method to account for so many of the performance issues we were facing. Looking at metrics alone it definitely wasn’t in any top ten or even top 50 lists. There were slower methods to optimize, critical sections causing delays, synchronous long operations, and other areas of the code that on the surface seemed like much better candidates to focus on.

I recalled this experience as we were thinking of the concept of “performance impact” as an added layer of information for Digma. After all, getting data about code performance and metrics is easy, but we were seeking ways to make optimization more guided and less random. In other words: analyzing the runtime data to aid developers in identifying those those pieces of code that affect the system’s ability to scale the most.

Measuring Performance Impact

It is easy to make the mistake of focusing on duration percentiles only. For example, the median, P95 or P99. However, looking at the performance data only can create a misleading prioritization. Areas of the code that are seldom triggered, or that affect very little else in the application might present themselves as major bottlenecks. Optimizing them, will in fact have very little actual effect.

To avoid falling into that trap, we decided to weigh the importance of each piece of code in terms of when it runs and how often it’s invoked, instead of just how long it takes it to run. We understand that the code that runs once, at the beginning of a process, might not be as impactful as the functions that are used on user interactions and API calls. We also know that I/O operations, rendering operations, and database queries may require special attention.

We found the best way to do this is by applying exponential smoothing to the duration of each span or activity segment. The formula looks something like this:

st=Tt+(1-)st-1

With st, the score after time t, Tt the duration (total runtime) of the span, and 01 a tuning parameter, with values close to 1 giving more importance to the new value over the accumulated score, and vice versa for values close to 0. s0 is just the span duration of the firs time we encounter it.

There are several nuances to the measured quantities.

Firstly, we debated how to measure time itself! Two principal paradigms arose. The first option would be to use real-time, as in seconds or milliseconds, etc. This way if a span is invoked again after one minute then its previous score would decay more than if it were invoked again after one second. The second option is to have time “tick” every trace, meaning every time a piece of code is invoked externally. This way the score is independent of the scale of endpoint usage.

We chose the latter. This is the better choice for us since we deploy the same algorithm for all of our clients. If we had chosen the former, we would have had to tune a vague formula parameter per service.

Another important decision was how to measure duration. We can treat a span as the total time between when it’s opened and when it’s closed, or we could subtract from that any time spent in its child spans (self duration). Each has its own implications, for example, using total duration would lean towards giving higher PIS to parent nodes.

After a process of trial and error, we decided on a hybrid approach. We use the exclusive duration as a default, and use the total duration for client spans, endpoint and consumer spans as they may hide some additional information.

Check out this graph to see how the PIS develops over time, using =0.95:

How measuring insights affected our own scaling

Recently, we noticed that one of our services is underperforming and set out to find the cause. The initial strategy of sorting by the Slowest 5% (P95) or Median duration, as expected, revealed results that were significant, but after fixing them did not resolve the overall slowness we’ve been experiencing.

For example, here are the top three slowest consumers looking at the P95 duration, as well as the top three slowest queries:

After optimizing these areas we saw very little improvement in the overall performance, resource consumption, and effect on the throughput of our consumers.

This was a chance to test the effectiveness of our new PIS. By matching usage with slowness, we wanted to pinpoint specific key areas that would be worth the effort of optimization. We took a look at the code assets again, this time sorting by our new ‘Performance Impact’ measurement. The results were quite clear in revealing a likely candidate.

Double clicking on that candidate revealed two clear sources for the problem, both seem to have suffered a performance degradation in a major release about three weeks ago. I am not including the entirety of the investigation effort but that very query also came up extremely high when sorting queries by performance impact. BINGO.

I was reminded of a recent Devoxx presentation by Mario Fusco and Francesco Nigro where they referred to the above-mentioned Donald Knuth quote about premature optimization and revealed there is a second part of that quote that is often ignored. Definitely, Knuth writes, focusing on 97% of inefficiencies would be premature optimization however Knuth proceeds to mention: “We should not pass up our opportunities in those critical 3%”

Indeed we were able to reveal those critical 3% and were able to get much more out of our optimization efforts.

Using Digma to identify your own application critical 3%
I’d love to hear if this algorithm also produces good results for you! If you already have Digma installed, then you're ready to go. If not, please head over to the JetBrains Marketplace to quickly download it. You can check out this video to get started. Digma is a Continuous Feedback tool. It constantly monitors your code at run time, to collect data on its behavior. In this case, it will collect data automatically using OpenTelemetry.

Once installed, all you have to do is go to the Assets tab in the Digma plugin, select the category you want to investigate (e.g. Endpoints or Database queries), and sort the entries by “Overall impact” or “Performance impact”.

Let me know your thoughts and results!

I'm Not a Great Programmer

LeeLussh — Mon, 11 Sep 2023 12:33:18 +0000

Hello, everyone! I recently read an article by [Addy Osmani], which got me wondering about effective software engineering. He argues that a good engineer is not necessarily an effective one. He outlines 10 traits of effective engineers. This got me thinking about the challenges modern engineers face making it difficult to produce clean, maintainable code rapidly in such envs.

As Kent Beck puts it, 'I'm not a great programmer; I'm just a good programmer with great habits.'

Are you truly an efficient developer? While skill mastery and technology expertise are vital, being a good developer doesn't automatically mean you're efficient.

So, what sets apart an efficient developer? You'll be surprised—it's your key traits and habits.

In every R&D team, there's that standout individual, the rockstar everyone seeks advice from. Typically, these programmers are humble and never label themselves as wizards or high performers and they usually walk bare feet in the office.

Ever wondered how these top developers distinguish themselves?

We've talked with some leading Engineers and compiled a list of the most essential traits and habits to guide you on your journey to becoming a more efficient developer. Let's dive in!

30 Key Traits and Habits for Software Engineers to be Effective

Strive to become a holistic, well-rounded developer. Master skills outside of your comfort zone, If your experience is in a static language, master a dynamic one, and experiment with paradigms from different platforms and frameworks.
Plan your shit, test your shit, and even before submitting a PR, conduct a self-review and refine your work to make it even cleaner. Be skeptical, especially of your own biases.
Choose simple over easy. The fastest path to building the feature can introduce complexity that will haunt the codebase for years to come. Don’t over-architect!
Practice Continuous Feedback during the Dev Cycle. Collect data about your code so you can identify issues before reaching prod, understand test results, and make the right design decisions.
Coding is like writing - you must be concise, clear, and eloquent. Good code is well-documented, great code explains itself.
Choose your abstractions. “There is nothing that can’t be solved by another layer of abstraction” but abstraction carries its own cost.
Enforce boundaries: You're expected to write code like a Renaissance sculptor but against totally unrealistic deadlines, It's up to you to enforce boundaries.
know how to communicate effectively with people. Be open-minded, self-aware, adaptive, and compassionate. Share your knowledge, offer help, and collaborate with your peers. Enjoy teamwork!
Be honest with yourself and management about the progress and challenges, avoid falling into an optimistic bias or portraying a non-realistic picture simply because you feel it would be appreciated.
Embrace criticism. CRs are your most important asset but it takes time and practice to learn how to use them as an effective tool.
Be language/framework/library fluid: The most crucial trait for long-term effectiveness is the willingness and ability to learn and apply new things quickly.
Think twice and do it once. Consider the design and existing code before changing things or adding anything new.
Take pride in your work, love what you do!
Empathize with your clients, fellow developers, PMs, etc. Understand that your needs won't always line up with theirs but you can still work together.
Think about the philosophy of what you’re doing and understand the context of your task fully, if not ask.
Get a second opinion If you are not sure about something.
Be user-centric, try to understand your users’ needs, and always develop with the UX in mind.
Be pragmatic and iterate towards goals. Keep a vision of what you want but understand that it could be a winding road to get there.
Don't let your ego get in the way of thinking about the needs of that business/project/etc, you are hired to work for a business/project/etc.
Don't burn out! Try making your 8-hour day more effective. before trying to compensate with overtime and working over the weekends.
Turn your problems into possibilities, and obstacles to opportunities. These obstacles often carry an embedded lesson or a disguised opportunity.
Break one big problem into multiple small problems that are easily solvable. It helps to understand where you gotta focus more.
Take as much responsibility as you can possibly handle the same with accountability AND NOT ONE BIT MORE.
Find the balance between challenge/growth and work /life.
Dig deeper and deeper over your career into the "why" of what you do, and don't be afraid to change based on the answers you find.
Seek feedback: Coding in isolation can cause you to overlook blind spots. Peers and users offer fresh perspectives and highlight areas for improvement.
See the big picture: Consider the time versus value trade-offs, Don't get caught on your small tasks sometimes, which makes it challenging to see the big picture.
Plan your day by reviewing the previous day's work and estimating the trajectory for the next day. Identify how your work contributes to creating value.
Don't fear failure and don't be scared of making mistakes. It can stop you from trying new things and growing as a developer.

Reality Check

In reality, this is what happens, code often ends up as something that can work but is highly unmaintainable, hastily put together as a POC, and then deployed into production without being cleaned up and documented. This is not good for you as a developer or for the business either, especially if it is or becomes a critical piece of infrastructure but remains unapproachable.

So, the question is, how do you deliver better code faster? We truly believe that harnessing Continuous Feedback throughout the dev cycle can help you become a more efficient developer. Knowing what your code is doing and when something goes wrong can help you proactively identify issues within the code before they break your code in production.

We’d love to hear what you think are the key traits for becoming a good developer with great habits:) Shoot me an email.

What Is the N+1 Query Problem and How to Detect It

LeeLussh — Wed, 23 Aug 2023 11:41:46 +0000

In this article, we’ll dive deep into the N + 1 query problem using a practical example, its effects on application performance, and how innovative solutions can help detect and mitigate the N + 1 query problem.

If you have used any ORM framework like Hibernate, you can attest to how easy it is to define data models in simple regular classes and map them to any relational database. Much of the convenience that we enjoy when working with Object Oriented Programming languages and relational databases has been made possible by ORM tools like Hibernate.

Although programming languages have different ORM tools, their general purpose is similar: They speed up development, keep your code DRY, improve security, and lessen the need for mastering raw SQL queries.

As a developer, however, you should also watch out for the shortcomings of any technology. The infamous N + 1 query problem is an anti-pattern that stems from the leaky abstraction that ORMs provide. Because ORMs make it extremely simple to access data without making queries, they also make it easy to access that data inefficiently. This problem is mainly associated with how ORM frameworks handle the lazy loading of related entries. You can find the details below.

What is The N+1 Query Problem?

To better understand the N + 1 query problem, we’ll first need to understand the concept of data fetching in ORM tools. By default, most ORM tools, such as Hibernate and Django, use lazy loading as the default data fetching behavior. This means they only fetch data explicitly requested from the database and delay any related data you have not requested.

Let’s look at an example. Suppose you are building a blog application with multiple blog posts, and every blog post is linked to its respective author through a one-to-many relationship. If your application fetches a list of blogs and then subsequently fetches the associated author for each blog using a separate query, this results in many roundtrips to the database.

// Fetching All Blogs
List<Blog> blogs = blogRepository.findAll();
// N+1 Queries: One Query for Blogs, N Queries for Authors
for (Blog blog : blogs) {
    Author author = blog.getAuthor(); // Triggers a separate query for each blog post's author
}

The tricky part is noticing that this is happening. In your code, you would seem only to be iterating over objects. Because ORMs provide an abstraction over SQL, they also make it very difficult to guess which object property access will result in a query. In this case, you are running one query to fetch the list of blog posts and then running multiple queries that fetch N number of authors corresponding to every blog post, hence the name N + 1 query problem.

The more blog posts and Authors in your database, the more severe the problem can be, impacting application performance and user experience. Here are some issues that can be caused by the N + 1 query problem:

Slow response times: The N + 1 query problem slows down data retrieval, which makes your application less responsive to user requests.
Limited scalability: As your application grows, the N + 1 query problem can limit your application’s ability to handle the growing user demands.
Increase Database load: The increased number of queries due to the N + 1 query problem strains your database.
Limited throughput: The N + 1 query problem reduces the number of transactions your database can handle per section.
Degrades user experience: With slow load times, users are likely to wait longer for pages to load, which is frustrating, to say the least.

Fixing N+1 Query Issues

Most ORMs also provide the means to avoid N+1 queries by controlling the lazy vs. eager loading of related entities. With Lazy load, the related entity is loaded as a proxy, only to be initialized when one of the entity properties is accessed in the code. On the other hand, Eager loading performs a SQL join when initializing the original entity so that no further queries are necessary.

Hibernate provides several ways to configure eager loading, either on the relationship mapping itself or per query:

1. Configuring the entity relationship as eager

This is the most aggressive of the three strategies as it fundamentally changes how the entity is loaded. Most ORM tools like Hibernate lazy load-related entities by default, resulting in multiple database queries. Configuring the relationship between related entities as eager instructs your ORM to fetch the main entity and its related entities in a single query.

@Entity
public class Post {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String title;
    private String content;
    @ManyToOne(fetch = FetchType.EAGER) // Eager loading
    @JoinColumn(name = "author_id")
    private Author author;
    // Getters and setters
}

Use this setting only if you know that ‌entity relationships and properties will almost always be accessed.

2. Setting batching preferences on the mapping

When dealing with entities that have complex relationships, this can be a good solution to the N + 1 query problem. Setting a batching preference allows you to batch multiple queries into one single query. In our earlier Post and Author example, this means that we can fetch all Posts and their respective Authors in a single query. If you are using Springboot, you can use the @BathSize annotation on lazy association.

@Entity
public class Author {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    @OneToMany(mappedBy = "author", fetch = FetchType.LAZY)
    @BatchSize(size = 10) // Batch loading strategy
    private List<Post> posts = new ArrayList<>();
    // Getters and setters
}

Instructing your ORM tool to batch multiple queries reduces the number of roundtrips to the database when fetching related entities, effectively solving the N + 1 query problem.

3. Eager loading on query level

You can also prevent N + 1 query problems by explicitly specifying queries that should be eagerly loaded alongside the main entity. This approach is useful when you know exactly which related entities you want to fetch, eliminating the need for subsequent querying.

public interface PostRepository extends JpaRepository<Post, Long> {
    @Query("SELECT p FROM Post p JOIN FETCH p.author")
    List<Post> findAllPostsWithAuthorsEagerly();
}

In cases where you only need to fetch related entities occasionally, and the relationships between your entities are fairly simple, then eager loading on a query level is an overkill. You can opt to use manual loading or ‌rely on the ORM’s default eager loading.

4. Manually load-related entities in the code

This approach gives you granular control when loading related entities from the database. ORM frameworks typically provide methods that allow you to load related entities. For instance, if your application has a Post entity related to Author, you can manually load related Authors using a method such as post.getAuthor(). You avoid running into the N + 1 query problem using this manual approach.

@Service
public class PostService {
    @Autowired
    private PostRepository postRepository;
    public Post getPostWithAuthor(Long postId) {
        Post post = postRepository.findById(postId).orElse(null);
        if (post != null) {
            // Manually load the author for every blog post
            Hibernate.initialize(post.getAuthor());
        }
        return post;
    }
}

Understanding Continuous Feedback

Digma Continuous Feedback is a runtime linter that lets developers quickly identify risky code, potential errors, and bottlenecks in complex codebases. It uses OpenTelemetry behind the scenes to collect data such as traces, logs, and metrics when you run your code locally.

Once the data is collected, Digma looks for regressions, anomalies, code smells, or other patterns that can be useful for knowing about your code while in the development phase. This allows you to accelerate your development cycles and, at the same time, catch potential problems in your code.

How Continuous Feedback Can Help Detect The N+1 Query Problem

As your application grows, such query issues can become serious performance bottlenecks that significantly increase the database load and slow down application performance

. If you have a complex application performing hundreds of queries to the database, it can be difficult to spot them by simply reading through the code. However, with Digma, you can easily detect such queries even when working with complex codebases.

Problems such as repeated queries associated with N+1 Select statements are easy to detect in the runtime data. Specifically, in traces that Digma automatically collects using OpenTelemetry.

Here is what an N+1 Select query looks like in a trace:

Once Digma has collected and analyzed the data, it then highlights that the second query responsible for fetching user roles has a potential N + 1 query problem. Digma then generates an insightful alert next to the query source code/

Apart from that, you can also notice that Digma also highlights the impact on ‌response time, showing that the endpoint handling this query (e.g., GET /owner) is affected by the N+1 problem. While the duration of the query time of 1.1 ms for the 10 repeat DB calls seems small, this can quickly increase if your application makes more queries, taking a toll on your application’s performance.

Digma also goes a step further and provides insights at the endpoint level. This allows you to note the endpoint that is potentially affected by an N + 1 query problem, the severity of the impact, and the method causing the issue, as shown in the output below.

Armed with Digma insights above, at the query and endpoint level, you can easily find and fix code that’s causing N + 1 query problems.

Case Study: Reducing Execution Time for Specific APIs

Markus Westergren is an experienced Senior Consultant/Staff Engineer with a demonstrated history of working in the information technology and services industry. Markus is a Beta user of Digma and recently shared with us that they could detect such N+1 query issues in their code, which reduced execution time for specific APIs.

What coding issues did you encounter that led you to try Digma?

I recently joined a team that is developing a new product. There were performance issues with some use cases. My job was to find and fix them. I used manual analysis and a profiler to try and pinpoint hotspots in the code. Any changes I made had to be tested and measured to see if an issue was fixed.

How did Digma help you solve these issues?
With Digma, I get continuous feedback on the application’s performance. It will instantly show me where the biggest bottlenecks are, so I don’t have to search for them myself. I can now get direct feedback on how my latest fix performs compared with the previous version. It also found bottlenecks that we did not even know about. It takes the guesswork out of the picture. We save lots of time finding and fixing performance issues.

How did Digma help handle suspected N-plus-1 in SQL queries?

We are using Hibernate, and it makes it much easier to see what’s really going on.

We have already identified some cases where Hibernate produces N-plus-1 queries which are affecting the performance of the application.

We’ve made big improvements, and Digma has helped us identify some cases where N+1 queries may affect the application’s performance.

Besides the insights on the repeating database spans, Digma also provides key endpoint insights that allow us to detect and fix N + 1 queries related to specific endpoints, among other performance issues at their source.

Digma has certainly been a great addition to our development workflow, and we will continue leveraging it to optimize and improve our code and provide the best user experience.

Conclusion

The N + 1 query problem is a common problem when working with ORM frameworks such as Hibernate. Although different solutions, such as overriding lazy loading provided by ORM frameworks, can help avoid this problem, detecting such queries is crucial. Digma is a reliable tool that can save you the manual effort of finding such queries. With Digma in your development workflow, you can leverage continuous evidence-based feedback to optimize your code.

Happy Observing:)