Backend Development Stack

Backend Development Stack

What do we need

Required

1. HTTP server (client requests handling)
2. HTTP client (requests to 3rd party services like Github)
3. Database
4. Database driver
5. Data format for client-server interconnection
6. Serialization/Deserialization
7. Build and dependency management system

Optional

1. Dependency Injection
2. ORM (if data model will be relational)

Requirements

1. Relevance (chosen technologies must be used in real enterprise applications)
2. Less boilerplate
3. An ability for effective CPU utilizing
4. Simple usage
5. Team members experience with chosen technologies
6. Open-source + suitable licensing

Candidates

HTTP

1. Spring Boot over servlet container (classic)
   • Classic: RestControllers, thread and connection per request model. Threads are idle most of the time
   • Simple and time-tested
   • Many things integrated: DI, FasterXML Serialization/Deserialization
   • Spring Data
   • Boring
   • Not so fashionable at non-blocking technologies era
2. Spring Boot Webflux
   • Functional endpoints
   • Reactor Netty
   • All pros of previous one
   • Reactive
   • Non-blocking
   • At least 2 team members worked with that
   • Uses Reactor - popular and helpful implementation of Reactive Streams specefication
   • Spring Data supports R2DBC
   • Declarative
   • May be complex little-bit?
3. Vert.x
   • Interesting idea
   • Non-blocking
   • Reactive driver for SQL
   • Callbacks
   • None of the team members worked with that
   • Goes well with Kotlin coroutines. None of the team members has enough experience with Kotlin
   • Kotlin is not a standard in enterprise
4. Play framework with Akka Streams
   • Cool so much!
   • Lot of DB integrations
   • So much verbose and really painful in Java
   • Only one team developer knows Scala well
   • Extremely complex!
5. One-nio
   • Extremely fast
   • Own fast serialization
   • Too low-level for our project. Many things need to be written manually
6. Netty
   • In general same thing as one-nio
7. Reactor-Netty
   • Netty plus Reactor, that makes easier to use R2DBC
   • Anyway many things need to be written manually

Database

It looks like we'll use something relational because it's suitable for our domain.

1. PostgreSQL
   • Experience to work with
   • Actively used in enterprise
   • Lots of drivers exist
2. MySQL
   • ± Same

DB Driver

1. JDBC (classic)
   • Time-tested
   • Boring
   • Blocking
2. ADBA
   • Looks like it's stillborn spec
3. R2DBC
   • Reactive Streams
   • Non-blocking
   • r2dbc-pool
   • Stable
   • Supported in Spring Data
4. Vert.x Reactive
   • Goes well with Vert.x
   • Technical preview stage
5. Vert.x JDBC
   • Stable
   • JDBC =(

Data format

1. JSON
   • Let's just stop here. It's used everywhere. A de-facto standard in the frontend world
2. XML
3. Protobuf

Serialization/Deserialization

1. FasterXML Jackson
   • According to benchmarks - it's very fast for JSON
   • Spring default
2. GSON
   • Slower
3. Protobuf
   • Unnecessarily for us
4. HTTP framework preinstalled solution
   • One-nio has its fast serialization. Low-level so much

Build and dependency management system

1. Maven
   • Declarative
   • De-facto standard a few time ago
   • Spaghetti XML
2. Ant + Ivy
   • It's already the last century
3. Gradle
   • Declarative + imperative
   • Kotlin / Groovy
   • Useful
   • Becomes increasingly popular

Summary

We should choose

• Java 14 (Is gonna be released 17 March)
• Spring Boot Webflux over Reactor-Netty
  • Functional endpoints
• Lombok
• R2DBC
  • Spring Data
  • pool
• PostgreSQL
• JSON
• FasterXML Jackson
• Gradle

Because it's relevant, powerful, suited well to each other, declarative, laconic, team members worked with that. And it finally meets all our requirements.

Traditional Spring Boot - is the nearest competitor, but it's too boring.

Vert.x - is another interesting option, but none of the team members worked with that and some of its interesting features are in technical preview stage