serverless-java-frameworks-samples VS Spring Boot

In the previous 8 parts of our series about AWS Lambda SnapStart we measured the cold starts of Lambda function with Java 11 and 17 runtime first without without and with enabling of SnapStart and also applying various optimization techniques like priming when using SnapStart. You can refer to the cold start times measured with GraalVM Native Image. Current measurements reveal, that the fastest cold start times can be achieved with GraalVM Native Image followed by SnapStart with priming (in case you can apply such optimization for your use case, for example when you’re using DynamoDB as your database of choice), followed by SnapStart without any optimizations. Of course the slowest cold start times you will experience without using GraalVM Native Image and SnapStart. See the summarized measurements in my previous articles of this series or in one of my presentations like this one.

Now the measurements of cold start times (and overall API Gateway end-to-end latency) make complete sense and I assume that AWS made a fix to display the "Restore Duration" and thefore the entire cold start time correctly. Nethertheless these are still quite big cold start times (especially if you can't prime some invocations to reduce them), comparing to other Lambda runtimes like Node.js and Python. Obviously GraalVM Native Image shipped with Lambda Custom Runtime can provide much better results (see Results from GraalVM Native images running in custom runtime) but with different set of trade-offs. Of course in case of using SnapSart, the snapshot restore times can be improved in the future, so I hope that we can further reduce the cold start times with Java by several hundred additional milliseconds.

If we compare these metrics with AWS Lambda with plain Java (and AWS SDK for Java version 2) and Micronaut Framework with SnapStart enbled we'll notice that using the Micronaut Framework the average cold start with Quarkus is quite comparable with the first and better than the latter. If we compile our application with GraalVM Native Image and deploy our Lambda as Custom Runtime (which is beyond the scope if this article), we can further reduce the cold start to between 450 and 550ms, see the measurements for the comparable application.

- Usually manually wired and configured vs the spring boot "starter" pattern of having libraries that automatically do some of the manual setup work for you: https://github.com/spring-projects/spring-boot/blob/main/spr...

I wish more client library sets had the feature-matrix that the pulsar one does, because in practice most end up being the same: Java supports everything because it's either built in the same codebase or is the most used client and gets the most support, while the dotnet client codebase has many feature-requests or performance improvement issues, often leading to a "third-party client" being created.

https://github.com/spring-projects/spring-boot/pull/39754/co...

If you’re currently running with an earlier version of Spring Boot, I recommend that you upgrade to Spring Boot 2.7 before migrating to Spring Boot 3.0. It minimizes compatibility issues as much as possible.

Okay, we need to build the game? No problem, we will use Spring Boot and Swing!

It's weird that some people including you directly attack my competence. As a power user you should have plenty of experience getting something to work that is not properly document, does not work how the documentation promised it to, or has weird problems on top of it. Look at idiotic things like this:

https://github.com/spring-projects/spring-boot/issues/33044

Take any similar issue and you'll see a bunch of people who try to find a solution for them because they just aren't repeatable at all. The underlying issue is the auto configuration doing things you can't follow quite properly. It's like it wasn't mean to be understood. Issues like the one I linked above also show me that the spring dev crowd also doesn't understand the ecosystem anymore. The problem is complexity and automagic.

An interested reader can decide for themselves:

https://github.com/spring-projects/spring-boot/tree/main/spr...

Explicitly decoding URL query parameters occurs less often because many frameworks, including Spring Boot, handle decoding automatically.