Experiences with Quarkus. The Great, Good and meh?

Alright, as a developer who’s spent years knee-deep in Spring and Spring Boot, diving into a greenfield project with Quarkus has definitely been an interesting experience. It’s like stepping into a new neighbourhood; some things are immediately familiar, while others require a bit of a mental map adjustment.

Benefits and What I’ve Liked So Far

The most striking advantages, especially when thinking about cloud-native deployments and my daily workflow, revolve around performance and how quickly I can iterate:

• Blazing Fast Startup: Honestly, this is a real eye-opener. For services that need to spin up in a flash, like in dynamic cloud environments where instances come and go, Quarkus really shines. Even for local development, the difference is tangible. Seeing my application restart in less than a second when I’m messing with cloud deployment configurations is a massive boost to my productivity and feedback loop. While some might argue that the framework’s inherent startup time isn’t the main bottleneck compared to database setup or other boot processes, for a developer, that instant response feels great.
• Lean Memory Usage: It’s genuinely built to be lightweight. We’ve experienced, and I’ve heard similar stories, about applications consuming a lot of memory in container platforms, sometimes leading to restarts. Switching to this new framework has led to noticeable improvements in memory efficiency and overall stability in those environments, with applications no longer crashing or restarting frequently. My personal experience, corroborated by others, confirms it’s quite memory-efficient.
• Exceptional Developer Experience with Instant Feedback: This is where it truly feels different. The ability to change code and see the updates reflected almost immediately, without a full server restart, is fantastic. It’s a significant upgrade over the developer tools I was used to with Spring Boot. This ‘hot reloading’ feature, combined with automatic, continuous testing that runs relevant tests after every code tweak, makes the inner development loop incredibly smooth and enjoyable.
• Reduced Boilerplate Code: One of the pleasant surprises has been the reduction in lines of code. For example, configuring security and other aspects often involves just tweaking property files instead of writing extensive Java code, which used to be a common task in my Spring projects. Plus, for simple data-holding objects, it can automatically handle accessors, meaning less need for external libraries like Lombok I previously relied on. The way it manages data persistence, though different from what I’m used to, also contributes to less boilerplate.
• Simplified Testing: Setting up tests is much easier, particularly for integration tests. It offers out-of-the-box support for automatically spinning up necessary external services (like databases) in containers, which means less manual configuration for me through its devservices feature. This, combined with the faster startup times, makes running our automated tests considerably quicker.
• Native Executable Generation: It offers a much more straightforward path to building highly optimized, standalone executables that consume minimal resources. While Spring has also made strides here recently and now has a stable native image feature, this framework’s long-standing contributions to the underlying compilation technology make it feel very robust in this area. Quarkus (Red Hat) is a big contributor to GraalVM.

Drawbacks and Gotchas I’ve Encountered

It’s not all sunshine and rainbows, and some aspects have definitely required a mental shift or a bit more digging:

• Smaller Community and Ecosystem: This is perhaps the most noticeable drawback. Coming from Spring’s colossal global community, with its endless array of blog posts, tutorials, and Stack Overflow answers for every conceivable problem, the resources for Quarkus feel comparatively sparser. While the official documentation and guides are good, finding solutions for niche issues sometimes requires more effort. Some parts of the official “start coding” page were also found confusing or out-of-date.
• Different Data Access Approach: The approach to data persistence, which feels like a different pattern than the repository interfaces I was accustomed to in Spring, has been a significant adjustment. Quarkus often promotes the use of Panache, which follows the Active Record pattern.
  • For developers deeply familiar with Spring Data JPA, its ability to derive queries directly from method names (e.g., findByNameStartingWith(String name) or FindByNameAndAddressOrZipcode) is a significant convenience that reduces boilerplate code, and they find its absence a major point of contention.
  • Some express strong reservations about Panache, stating it’s “not good enough at all” or even “absolutely terrible”. A specific criticism is that Panache can lead developers to mix domain entities with underlying data access layer dependencies, which some consider a poor practice that shouldn’t exist. Developers used to Spring Data JPA’s automatic query generation might question the need to manually control SQL.
  • Conversely, those who like working directly with the underlying EntityManager and prefer to know “exactly what is being executed on the database” find Panache more aligned with their preference, as it aims to reduce boilerplate code. An example of its usage is MyEntity.find(“name = ?1”, “John”).list();. Both frameworks utilise Hibernate underneath for data persistence. Ultimately, the preference often boils down to individual intuition and familiarity with one data access style over the other.
• Learning Specifics: While the core concepts of dependency management and web application structure are quite similar to Spring, there are nuances in how certain things are done. For example, transaction management felt a bit different from the robust facilities I valued in Spring, as Spring has “more facilities” like @TransactionalEventListener which some find very useful. Similarly, for very custom security requirements or specific gateway patterns, Spring’s broader and more mature set of extensions often feels more comprehensive.
• Talent Pool: It’s a practical concern for team building. Given Spring’s dominant market share, finding developers already proficient in this new framework might be a tougher task.
• Perceived “Magic”: While the framework aims to reduce complexity, some of its automatic behaviours, like handling property accessors for public fields during compile/build time, can feel a bit like “magic” if you’re not aware of how it works under the hood. It’s different from Spring’s “magic,” but still something to get used to.

Overall, knowing Spring has definitely given me a head start, making the learning process “100% faster” in terms of understanding the fundamental principles. For new, cloud-native microservices, especially those destined for container orchestration platforms, it feels like a strong contender due to its performance and developer productivity. However, for projects that might need less common integrations or have a heavy reliance on a broader, more established ecosystem, Spring’s vastness remains a significant advantage.