以下的筆記主要參照Baeldung這篇文章，後續會在針對如何用Quarkus建立第一個專案補充說明。

SpringBoot v.s. Quarkus

1. 概觀

這篇文章的關注點在於比較兩個廣為人知的Java框架—SpringBoot與Quarkus。看完文章，能更加瞭解兩者之間的相似、差異處以及各自的特殊性。另外也有一些測試來檢測效能並觀察表現。

2. SpringBoot

這個Java framework主要用於企業級應用程式。集成了所有Spring project，提供許多production-ready的整合，可協助開發者提高生產力。 減少了要配置的數量以及文件樣板。另外因為約定大於配置的方法，會根據runtime時classpath中的依賴 (dependencies)，自動註冊預設的配置。SpringBoot大幅減少了許多Java應用程式上市的時間。

3. Quarkus

Quarkus 是另外一個framework，其方法類似SpringBoot，但另外能在快速的啟動時間內，交付較小型的artifacts，有更好的資源利用度以及效率。 Quarkus 是以 cloud、serverless以及容器化環境所最佳化的框架。除此之外，Quarkus framework與Java其他框架的的整合性也很好。

4. 比較這兩者

如上所述，這兩個framework與其他的project跟framework的整合性都不錯，但其內部 implementation & architecture 並不相同。例如，SpringBoot提供兩種 web capabilities: blocking(Servlets) 以及 non-blocking(WebFlux)

Quarkus 當然也有提供這兩種行為，但它可以讓開發同時使用blocking跟non-blocking這兩種策略。另外 Quarkus 有將響應式的方法內嵌在本身的架構中。

因此這裡主要比較的是 Spring WebFlux 以及 Quarkus reactive capabilities 比較相似的情境 (non-blocking)。

另外，這兩個projects中比較顯著的功能是新建 native images (binary executables 以及 platform-specific executables)，所以也會比較這兩個projects的native images。

註: SpringBoot 2.7 版本的 native image support 仍在實驗階段，直到 VERSION 3 才正式支持 native image support，需要使用 GraalVM。 註: Native image 這裡指的是將Java程式碼建構成 standalone executable 可執行檔的技術。Executable 包含了 java classes, classes from its dependencies, runtime library class, 以及 jdk 的 native code。

4.1 ~ 4.3 測試參考原文

5. 結論

總結起來，SpringBoot的documentation資源會比Quarkus更加完整，Quarkus有很多協助改善生產力的功能，但文件與StackOverflow上面的討論仍比較少。

Quarkus在jvm以及native versions上的啟動時間都比SpringBoot還要快。另外Quarkus build native images的速度也比較快 (91秒，相較於SpringBoot要花113秒)。但 SpringBoot 的 JVM build 就比 Quarkus 快了非常多 (1.75 vs 5.24秒)。

• CPU USAGE
  • Quarkus表現在native image跟JVM上都稍佳，但差異不大，也可以說 Quarkus 跟 SpringBoot 這局平手
• MEMORY
  • 這兩個frameworks的JVM版本，相較於native image版本，都需要比較多Heap區的memory
  • 只看JVM version的話，Quarkus的memory consumption比SpringBoot的少了一點點 (super tiny difference)
  • 在 native images 版本，Spring native 的 collect memory 較為頻繁，memory footprint 較低

    memory footprint 指的是運行時間占用的內存比較少 collect memory 就是管理程式內存，釋放不需要的內存空間

  • RSS memory measurement上，Quarkus在兩種版本的表現都比Spring還要優秀一點

    RSS指的是處理程序的實際記憶體(常駐集)大小，即 resident set size

• RESPONSE TIME
  • 這邊使用 hyperfoil 來避免 coordinated omission 的問題
• Connecting the dots
  • native app 比較快，資源消耗比較低，適合serverless, short-living 的應用程式
  • JVM app 所需成本比較多，但穩定性跟吞吐量表現較好，適合robust, long-living 的應用程式

6. 結論

本來以為會有實作寫法的比較，但只有比較回應時間, 記憶體消耗跟cpu用量，實際程式碼以及使用的工具可以到這一個REPO查看。