What is Finagle and what are its top alternatives?
Top Alternatives to Finagle
- Finatra
At Twitter, Finagle provides the building blocks for most of the code written on the JVM. It has long-served as Twitter's extensible, protocol-agnostic, highly-scalable RPC framework. ...
- gRPC
gRPC is a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking... ...
- Akka
Akka is a toolkit and runtime for building highly concurrent, distributed, and resilient message-driven applications on the JVM. ...
- Spring Boot
Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run". We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need very little Spring configuration. ...
- Play
Play Framework makes it easy to build web applications with Java & Scala. Play is based on a lightweight, stateless, web-friendly architecture. Built on Akka, Play provides predictable and minimal resource consumption (CPU, memory, threads) for highly-scalable applications. ...
- Akka HTTP
The Akka HTTP modules implement a full server- and client-side HTTP stack on top of akka-actor and akka-stream. It’s not a web-framework but rather a more general toolkit for providing and consuming HTTP-based services. While interaction with a browser is of course also in scope it is not the primary focus of Akka HTTP. ...
- RxJS
RxJS is a library for reactive programming using Observables, to make it easier to compose asynchronous or callback-based code. This project is a rewrite of Reactive-Extensions/RxJS with better performance, better modularity, better debuggable call stacks, while staying mostly backwards compatible, with some breaking changes that reduce the API surface. ...
- Netty
Netty is a NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server. ...
Finagle alternatives & related posts
- Fast7
- Easy6
related Finatra posts
- Higth performance25
- The future of API14
- Easy setup12
- Polyglot4
- Contract-based4
related gRPC posts
I used GraphQL extensively at a previous employer a few years ago and really appreciated the data-driven schema etc alongside the many other benefits it provided. At that time, it seemed like it was set to replace RESTful APIs and many companies were adopting it.
However, as of late, it seems like interest has been waning for GraphQL as opposed to increasing as I had assumed it would. Am I missing something here? What is the current perspective regarding this technology?
Currently, I'm working with gRPC and was curious as to the state of everything now.
We need to interact from several different Web applications (remote) to a client-side application (.exe in .NET Framework, Windows.Console under our controlled environment). From the web applications, we need to send and receive data and invoke methods to client-side .exe on javascript events like users onclick. SignalR is one of the .Net alternatives to do that, but it adds overhead for what we need. Is it better to add SignalR at both client-side application and remote web application, or use gRPC as it sounds lightest and is multilingual?
SignalR or gRPC are always sending and receiving data on the client-side (from browser to .exe and back to browser). And web application is used for graphical visualization of data to the user. There is no need for local .exe to send or interact with remote web API. Which architecture or framework do you suggest to use in this case?
- Great concurrency model32
- Fast17
- Actor Library12
- Open source10
- Resilient7
- Message driven5
- Scalable5
- Mixing futures with Akka tell is difficult3
- Closing of futures2
- No type safety2
- Very difficult to refactor1
- Typed actors still not stable1
related Akka posts
To solve the problem of scheduling and executing arbitrary tasks in its distributed infrastructure, PagerDuty created an open-source tool called Scheduler. Scheduler is written in Scala and uses Cassandra for task persistence. It also adds Apache Kafka to handle task queuing and partitioning, with Akka to structure the library’s concurrency.
The service’s logic schedules a task by passing it to the Scheduler’s Scala API, which serializes the task metadata and enqueues it into Kafka. Scheduler then consumes the tasks, and posts them to Cassandra to prevent data loss.
I decided to use Akka instead of Kafka streams because I have personal relationships at @Lightbend.
Spring Boot
- Powerful and handy142
- Easy setup132
- Java125
- Spring90
- Fast85
- Extensible46
- Lots of "off the shelf" functionalities37
- Cloud Solid32
- Caches well26
- Many receipes around for obscure features24
- Productive24
- Integrations with most other Java frameworks23
- Modular23
- Spring ecosystem is great22
- Fast Performance With Microservices21
- Auto-configuration20
- Community18
- Easy setup, Community Support, Solid for ERP apps17
- One-stop shop15
- Cross-platform14
- Easy to parallelize14
- Powerful 3rd party libraries and frameworks13
- Easy setup, good for build erp systems, well documented13
- Easy setup, Git Integration12
- It's so easier to start a project on spring5
- Kotlin4
- Heavy weight23
- Annotation ceremony17
- Java13
- Many config files needed11
- Reactive5
- Excellent tools for cloud hosting, since 5.x4
related Spring Boot posts






















We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.
To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas
To build #Webapps we decided to use Angular 2 with RxJS
#Devops - GitHub , Travis CI , Terraform , Docker , Serverless
Is learning Spring and Spring Boot for web apps back-end development is still relevant in 2021? Feel free to share your views with comparison to Django/Node.js/ ExpressJS or other frameworks.
Please share some good beginner resources to start learning about spring/spring boot framework to build the web apps.
- Scala81
- Built on akka55
- Web-friendly architecture55
- Stateless50
- High-scalable47
- Fast46
- Open source40
- Java34
- High velocity27
- Fun24
- Lightweight9
- Non-blocking io8
- Developer friendly5
- Simple template engine5
- Scalability4
- Pure love3
- Resource efficient2
- Evolves fast, keep up with releases3
- Unnecessarily complicated1
related Play posts
Some may wonder why did we choose Grails ? Really good question :) We spent quite some time to evaluate what framework to go with and the battle was between Play Scala and Grails ( Groovy ). We have enough experience with both and, to be honest, I absolutely in love with Scala; however, the tipping point for us was the potential speed of development. Grails allows much faster development pace than Play , and as of right now this is the most important parameter. We might convert later though. Also, worth mentioning, by default Grails comes with Gradle as a build tool, so why change?
related Akka HTTP posts
- Easier async data chaining and combining5
- Steep learning curve, but offers predictable operations3
- Easier testing2
- Ability to build your own stream2
- Works great with any state management implementation2
- Lot of build-in operators1
- Simplifies state management1
- Observable subjects1
- Great for push based architecture1
- Documentation1
- Steep learning curve3
related RxJS posts
- High Performance9
- Easy to use4
- Just like it3
- Limited resources to learn from2