Insights From an Expert: Exploring the State of Spring, OpenAPI, GraphQL, and th...

Exploring the State of Spring, OpenAPI, GraphQL, and the Future of Java Development

We had the opportunity to speak with Michael Coté, a Senior Member of Technical Staff at VMware, to discuss a range of topics related to the Spring developer community. Our conversation covered the State of Spring report for 2022, the significance of Spring for developers, its strengths in certain use cases, as well as its limitations. Additionally, we discussed the rising popularity of OpenAPI and GraphQL, common challenges and frustrations faced by Java developers, and the potential impact of Project Loom. Finally, we touched on the future of Spring and what developers can expect to see in 2023.

devmio: Thank you for answering our questions about the Spring developer community and the State of Spring report. According to the data, 2022 was a big year for modern architecture growth. In particular, what saw an increase here?

Michael Coté: In this past year, I’ve talked with more companies than ever that are finally setting clear goals to move to the public cloud. Sometimes, they seem dangerously optimistic, but I feel like most organizations are finally ready to move, across governments and commercial companies, big and small. And while "moving to cloud'' doesn't, at all, mean only moving to Kubernetes, the fast rise in Kubernetes usage is another sign of this re-platforming trend: Kubernetes use in Spring environments went up another 8 points in 2022 to 62%, and this is after a 13% increase from 2020 to 2021.

For a lot of organizations, this means finally looking at huge portfolios of Java applications to migrate and modernize. That’s a window for developers to start using new services and frameworks. In addition to just general upkeep and architectural hygiene, I think this growing acceptance of cloud drives developers to start using modern architectural styles more. In general, this is great because a recent survey found that 76% of executives say legacy applications are holding back their ability to change how their organization functions.

There are also echoes of the increased attention to cloud cost management. For example, on the large end (10,000 or more employees) you see a high desire to reduce costs, and almost half of the respondents (47%) see reducing costs as a benefit of native compilation. As we’ve been seeing recently, the pay-as-you-go model of the public cloud can expose developers to costs they previously didn’t think anything about. Developers who’re moving to the public cloud need to start thinking about cost as one of the top considerations: the architectural choices they make are going to determine how expensive, or how cheap, it is to run their applications.

devmio: What makes Spring such an important tool for developers, and in which use cases does it excel?

Michael Coté: Well, the useless answer is "pretty much all of them." (There's some discussion in a question below of cases where Spring may not be the best fit.) To be less cute though, Spring is important because of its maturity, its breadth of capabilities and community, and its design philosophy. Spring has been around for a long time, 20 years depending on how you count it.

I'm old enough to remember a time before Spring. When we started using Spring it was amazing: there was all this scaffolding and toil we no longer had to do. It was like instead of designing a framework to be only sophisticated and powerful, someone designed a framework to be usable and even joyful. That's reflected in the design philosophy that's persisted in Spring from the start. And when you look at how it approaches working with Kubernetes you see that. Tying into the life-cycle of running your Spring Boot application in Kubernetes just works and is built in.

That's just one part of what makes Spring important, though. Spring has always been good at applying this design philosophy to as many parts of the developer's stack as possible from security, to API management, and so on. Spring is a great simplifier. This means it integrates with countless other frameworks and services, meaning that it'll likely work with what you have and need. The community that takes care of Spring has also demonstrated a long-term commitment to it. It's not a fly-by-night (or even fly-by-decade!) community of cool. That stability is incredibly important for developers, especially those that are writing the software that we all use in our everyday lives. And if you'll pardon some commercial talk, Spring has also benefited from the companies that have sponsored it over the years, funding development and innovation. All of that means the community around Spring is pretty rock solid and kind.

I'm old enough to remember a time before Spring. When we started using Spring it was amazing: there was all this scaffolding and toil we no longer had to do.

devmio: OpenAPI and GraphQL also saw some growth in 2022. Why are they growing in usage and when are they used?

Michael Coté: OpenAPI and GraphQL provide a way for developers to declare server APIs that in turn make it possible to build tooling for request processing, data validation, for generating documentation, and for testing, all of which reduces what an application needs to do and speeds development.

GraphQL provides an alternative to REST with a more data-centric architecture that also provides flexibility and gives clients extra control to obtain data at the level of granularity they need for a particular use case. This flexibility is built into the protocol, and into server implementations. The same is also possible with REST and HTTP but it requires much more effort.

For a more detailed account and insight into one decision to adopt GraphQL and the experience of providing a REST API for many years, see Why GitHub is Using GraphQL and link to the blog post announcing the decision.

devmio: Are there any downsides to Spring? Are there any instances where it is not recommended?

Michael Coté: I think there are the same downsides as any framework that you add to a core language: there's something new to learn and it adds more to your code and architecture. For example, if you have a smaller application that doesn't need the benefits of Spring then, you know, you'd just be adding extra complexity. Every programming language and set of frameworks has tasks it works best and not so best at.

That said, I think most of the applications out there don't really fit these criteria. And, indeed, most of the applications out there that we use every day are part of a portfolio of applications that need to work together. Think about the apps you use for buying gifts for your kid's birthday, paying your bills, updating government documents and licenses, and so forth. These applications all fit within a larger ecosystem of applications that often need to work together. And that's an area where Spring helps out a great deal as well: making sure that the community of apps all "think" the same, or close enough to the same, that they can work together.

Spring is a great simplifier. This means it integrates with countless other frameworks and services, meaning that it'll likely work with what you have and need.

devmio: What are the most common pain points and current frustration that you see reflected in the report? What are Java developers currently struggling with?

Michael Coté: We see two main challenges for the Spring community these days. First, the survey has, for the past couple of years, identified that the complexity of the Spring portfolio is a challenge. Spring’s breadth is both a blessing and a curse in this respect. Spring can handle an unmatched number of workloads: web, messaging, batch, APIs, cloud, etc. However, that leaves developers to take on navigating a large portfolio of projects. The Spring Team has taken on a couple of initiatives this year as a way to address this challenge for developers.

The first is the move of our reference documentation to an OSS project called Antora. We expect this migration to improve navigability, searchability, and SEO. This will enable users to get to the right documentation faster than ever before.

The second is the launch of Spring Academy. The success of Spring goes back to the days at Interface21 and SpringSource and the training that the team provided to developers. Spring Academy provides online training for Spring developers by the Spring experts. This platform will bring the Spring engineers, those who actually write the frameworks, to create training courses for our community.

The second main challenge for the Spring community these days is the rate of change. Change has always been a constant within our industry. However, within the enterprise development space, users had the ability to bring in those changes on an as-needed basis. When new capabilities provided enough of a benefit to warrant an upgrade or a CVE came out that forced the issue, upgrades happened. However, today, the rate of change is accelerating to a point where this reactive approach is no longer a best practice. Java releases a new version every 6 months. Hibernate releases every 6 months or less. Spring Boot and most of the portfolio releases every 6 months. Add to that, baselines are becoming more aggressive. Jakarta EE 11 (due out early next year) will have Java 21 as a baseline, a version of Java that hasn’t even been released yet. Enterprises will need to enable upgrades to be the norm, not the exception or risk being so far behind when they need to that it’s a major development effort to do so. This is through tooling both via the upgrade process itself (via projects like Moderne’s OpenRewrite and VMware’s Spring Boot Migrator) and through automation in deployment/rollback capabilities.

devmio: Where does Project Loom come into play here? Are developers looking forward to it and what will it introduce?

Michael Coté: Project Loom, virtual threads on the JVM, provides a lightweight threading model within the JVM. Offering a different magnitude of scale for traditional, imperative programming, Project Loom’s virtual threads are positioned to enable existing applications (with minimal changes) to unlock a level of scalability that wasn’t previously possible.

Project Loom is a technology that has been a long time coming. Hinted in 2017, it has been in development for at least 5 years now. The community could not be more excited about it. Project Loom was tied as the most popular with GraalVM in the survey when asked what technologies developers plan on using. It also was identified as the technology in our list that had the most positive opinion of any technology on our list in the survey.

For Spring users, Project Loom opens up the possibility of scaling well beyond what a traditional JVM threading model could support. This enables traditional servlet-based Spring MVC style applications to scale much further than previously possible. We expect to enable Spring developers to take advantage of Project Loom as it becomes available.

Every programming language and set of frameworks has tasks it works best and not so best at.

devmio: Why do developers tend to resist upgrading Spring and their current environments? Is this ill-advised?

Michael Coté: For the most part, I think developers would prefer to upgrade as much as possible. I know I would! But desire isn't what guides good development choices, especially in larger organizations. The answers about Spring Boot upgrading feel representative of upgrading your stack in general.

While I think most developers would prefer to upgrade, they have to prioritize what they're doing each release cycle. As the survey shows, user-facing changes are usually prioritized over upgrading components, especially if everything is working fine. And if you look at developers' plans, 70% are planning on upgrading within the next year, and 88% within the next two years. Plans fall through sometimes, sure, but that's a very high amount. Most of the organizations I talk with prize stability and, if you'll pardon the phrase "it-just-works-ability," which I think you're seeing here.

If you throw in that ever-growing re-platforming to cloud and Kubernetes that I've been seeing, you also need to minimize how many changes you're making at all layers of the stack. If there's a reason to upgrade your components to make migration possible, then, of course, you need to do that. But as most respondents answered in the proxy question about Spring Boot, things are either working fine and/or there are higher priorities to address.

Now, as I pointed out above, this pragmatic attitude needs to be recalibrated. People need to start thinking about when the "it-just-works-ability" of the past turns into complacency that will lead to tech debt. This is where the pragmatism of the Spring community can be a guide. I think you can rely on the overall community to help with that recalibration. I realize I'm contradicting myself a bit here. But here's what I'd say: with the rate of change that's going on in the stack now, the parts of your application below the UI (or API end-point - you get the idea) are a vital new feature as well. There's a new type of "just works" out there and we'll see more development there. That means that you need to think about fitting those new features into your stacks. And, indeed, you see that in the high numbers of people planning to upgrade over the next two years.

devmio: Finally, where do you see Spring headed in the coming year? Do you have any predictions for the State of Spring 2023?

Michael Coté: In 2022, the Spring team released a round of major releases that were intended to serve as the foundation for developers for the next decade. It included an upgrade to the JDK that puts enterprises on solid ground for the 6-month release cadence of the JDK. It included the migration to the Jakarta EE namespace that enabled developers to take advantage of new features in future releases of the Jakarta EE platform including the first release of the Jakarta EE platform with new features in 5 years[1] coming out early next year. The ability to utilize resources more efficiently as well as tackle new architectures via native compilation via GraalVM and the ability to monitor it all with observability upgrades rounded out that foundation.

However, it was only the first step in the journey for developers as we look forward to this new decade. Looking ahead the team expects to build on that foundation, enabling users to utilize new architectures and tools. For example, the barriers to Java being a practical option for serverless workloads are being addressed (by GraalVM’s native compilation added last year and CRaC support in the future) allowing Java applications to be a first-class option for those workloads. The use of test containers at development time will make the local development experience even closer to production. Project Loom looks to be a key focus for the ability to scale existing applications beyond traditional boundaries for Spring developers.

As for predictions into 2023, we expect to continue to see similar trends around interest in Spring Boot 3, Spring Framework 6, and the minor versions that come out continuing that journey previously discussed. We expect to see continued adoption of APIs via microservices as the primary workload for Spring applications as other architectures like serverless APIs are explored.

[1] Java EE 8. Jakarta EE 9.1 did add JDK 11 support but no new actual features.