Skip to content

rest.server.md

Latest commit

 

History

History
117 lines (86 loc) · 3.33 KB

rest.server.md

File metadata and controls

117 lines (86 loc) · 3.33 KB

Overview

  1. Candidate libs for light & modern REST server
  2. Selection criteria
  3. Best options for 2023

Criteria

  1. See criteria for selecting libs

Additional Criteria

  1. Container friendly
    1. Light on memory
    2. Library, not a framework
    3. Graal & native-image friendly
  2. Dependency injection friendly
  3. Simple routing
  4. Filters/Middleware
  5. Simple parameter mapping
  6. No scala (memory hungry, tomorrow's abandonware)
  7. Minimal runtime magic (reflection)
  8. Non-blocking IO (eg. netty based)
  9. No Reactor/RxJava (memory hungry, complex, infectious)
    1. Mono and Flux take over all your function signatures
    2. JDBC is still blocking so there's no value in contaminating your API
    3. Project loom obsoletes reactive programming
  10. HTTP/2 support
  11. OpenTelemetry friendly

Candidate libs

Jetty

  1. Best fit
  2. Optional Servlet 5.x support

Undertow

  • TODO

Spark

  1. Con: smaller community than jetty

Jersey

  • TODO

Blade

  1. Pro: minimal dependencies

Rejected

Quarkus

  1. Framework, not a library
    1. If it doesn't do exactly what you want, you are out of luck (same for most frameworks)
    2. You are locked into what they can provide (same for most frameworks)
  2. CDI for injection (cannot replace with Guice nor spring-context)
  3. vertx based (see below)
  4. Tightly coupled to popular frameworks
    1. They manually build "adapters" (only) to popular frameworks
  5. Reactive programming (see above)
  6. Eclipse micro profile for metrics
  7. Coroutines support isn't core

RestEasy

  1. Abandonware (last updated 2018)

Restlet

  1. Abandonware (last updatd 2014)

Spring Web

  1. Overly complex
  2. Heavy on reflection
  3. Abandonware (They are pushing webflux instead)
  4. Lots of magic
    1. Following stack traces is hard
    2. Reasoning about control flow is hard
  5. Heavy memory footprint

Spring WebFlux

  1. Reactive programming (see above)
  2. Heavy on reflection
  3. Most of the same problems as Spring Web
  4. Not graal & native-image friendly
    1. lots of warning & error messages

TomEE

  1. Too heavy
  2. Overhead for supporting too many abandoned/legacy technologies

Vertx

  1. Vertx doesn't help with non-blocking code
    1. They tell YOU not to write blocking code
    2. If you have to do the work, you don't need vertx
  2. Callback hell
    1. Not even lambda friendly
    2. asynchronous is undesirable, because it doesn't compose, isn't traceable via source, ...
  3. Immature EventBus
    1. SerDe performance overhead in both directions
    2. Loss of type safety at the EventBus (no refactoring, performance overhead)
    3. no bus retry
    4. no bus persistence
    5. no bus guarantees
  4. Non-blocking "lie" breaks at the SQL layer since JDBC is a blocking API
  5. No composition (verticles are not composable)
  6. Debugging is hard
    1. Non-trivial flows require following things thru the bus