5 min read

If you start to think about building modern middleware there are a lot of decisions that you need to take from the first moment. Starting from the architecture if you feel that you need to go with microservices to be ready for containerization / clouds / horizontal scaling then you immediately wonder how to organize communication or manage transactions in such distributed environment or what kind of API expose (Restful / GraphQL / gRPC) and how to protect it. The next important decision is a technology stack to use which will allow you to focus maximally on the business domain and not on implementing repetitive elements required from modern platforms.

In TWG we like to build backends based on Java & Spring with Full Reactive Stack including:

• Web reactive – Spring WebFlux

(https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html)

• MongoDB reactive driver

(https://docs.spring.io/spring-data/mongodb/docs/current/reference/html/#mongo.reactive)

• Reactor

(https://projectreactor.io/)

called by many as “Java on steroids’“.

Additional in such distributed setup we are usually introducing:

• Distributed, correlated logs and tracing – Micrometer Tracing (former Spring-Sleuth)(https://micrometer.io/docs/tracing), combined with Zipkin (https://zipkin.io/)or Jaeger (https://www.jaegertracing.io/)
• Integration with many different logging systems: LOKI (https://github.com/grafana/loki), AWS Cloud Watch, ELK Stack (https://www.elastic.co/what-is/elk-stack)
•  Metrics exposure and monitoring (https://micrometer.io/, https://docs.spring.io/spring-metrics/docs/current/public/prometheus)
  • for basic statistics (uptime, start time, JVM statistics – memory, JVM statistics – GC)
  • for REST API (inbound / outbound HTTP requests)
  • for Spring data repositories (MongoDB) & mongoDB driver commands

Consumed by:

• • Prometheus (https://prometheus.io/) or
  • Victoria Metrics (https://victoriametrics.com/) or
  • Datadog (https://www.datadoghq.com/)
  • Grafana as visualization and analytics solution (https://grafana.com/)

• Sophisticated security (https://spring.io/projects/spring-security) supporting oAuth2 / OpenID Connect often combined with keycloak (https://www.keycloak.org/) as oAuth server (to not build by our own AAA and user management and use proven, easily extendable solution in java which is additional benefit as complete backend can be Done in a single language)
• Support for event driven systems (Spring AMQP and Spring for Apache Kafka – (https://spring.io/event-driven)
• Support for externalized configuration with Spring Cloud config (https://docs.spring.io/spring-cloud-config/docs/current/reference/html/) and different backends as configuration storage (git, vault etc)
• Support for GraphQL as yet another presentation layer (https://spring.io/projects/spring-graphql
• API Gateways, to expose solid API and hide internal distributed infrastructure, with standard gateways capabilities like: rate limiting, circuit breaker etc, based on spring components (https://spring.io/projects/spring-cloud-gateway) or kubernetes ingress controllers like Traefik (https://doc.traefik.io/traefik/)
• Automatic REST API documentation generation in OpenAPI Standard – Swagger Specification successor (https://www.openapis.org/, https://springdoc.org/)
• Easy containerization thanks intelligent spring-boot concept and big players involvements, providing hardened base images like Amazon Corretto (https://aws.amazon.com/corretto/)

Pros:

• Production-grade, scalable and reliable distributed platforms build in a very fast way
• Happy developers doing great things 🙂

Cons:

• Complicated ecosystem

Statement:

• Have you already practiced a similar approach?