Introducing Baratine 1.0 – introducing the first fully reactive programming framework!
Baratine features include:
- Automatice batching
- Child services
- Session services
- Worker services
- Templates and views
- Flow control support
- Jackson JSON support
- Zero dependencies
- Kraken, an embedded, fully reactive database
Top 3 reasons to use Baratine!
Reactive Programming - Asynchronous request processing can improve response times and lower resource consumption. Combining this with the ability to operate continuously on data solves many of the issues that plague multi-threaded and multi-tier programming.
No database or concurrency bottlenecks – Most applications can operate with their data in-memory and persist state when needed. Baratine makes this possible as well as transparent to the developer as requests no longer need to touch a bottleneck database for every read & update.
Agile development - One of the biggest hurdles for releasing into production is the unintended consequiences (i.e. resource consumption & dependencies) of a new service. However, if the service is a standalone .jar communicating with your app via REST or WebSocket, you can release new features to production with no potential impact to current application performance.
White Paper Preview
Abstract: Asynchronous and non-blocking execution is a highly coveted attribute of high volume web services. Server side web services strive to make contractual agreements upon interface based APIs to other services, assuming their environments to be highly-available, recoverable, & loosely-coupled. However these attributes are often in direct disagreement with an APIs implementation given: (1) the underlying multi-threaded libraries an API must rely upon and (2) the outside data source whose assets must be operated upon before an API can complete. This hindrance often results in contractual agreements across services tying down & blocking the multithreaded resources of a given architecture. This bottleneck is only half solved by frameworks where asynchronous request processing is paired with either NoSQL or SQL databases whose data access must block an incoming thread in order to make durable mutations on an asset. Techniques such as caching & sharding in-memory data structures alleviate the bottleneck for modifications on data at the cost of added complexity; exposing a view of the data that cannot be atomically mutated, results in complex and eventually consistent architectures.
Why is Baratine a game changer?
Reactive processing meets reactive data.
Working with data is the critical path of every application. Baratine guarantees only a single service owning thread will mutate a service's data. This unique threading & data model does three things:
- Allows data to be operated on continuously
- Eliminates database bottlenecks
- Eliminates multi-threaded concurrency concerns
Baratine's internals guarantee every service to be highly available, recoverable, and operate within an isolated thread context.
Clean & understandable asynchronous REST services are the perfect fit for Baratine's model. Services are fast, as in millions of operations per second per instance fast, clients can be in any programming language, and applications operate entirely in-memory.
However, Baratine is much more than just a simple async REST framework. What has been described by SOA for years and recently rebranded as Microservices is for the first time achievable with Baratine in a 5 MB .jar. Baratine is designed for high performance, scalability, security, and stability – something that Java EE and Spring cannot deliver.
Baratine eliminates the hassles created by multithreaded environments including writing lines of complex concurrency code, debugging database bottlenecks and ensuring applications meet the best known industry standards.
Check out the following examples of how Baratine can immediately help your infrastructure:
Smart Cache – Integrating a Baratine service with a JDBC or JPA driver to replace multi-threaded & concurrency problematic caches
Websocket chat microservice – capable of 20 million messages/second/instance
Single page auction microservice – API/interface based auction capable of millions/messages/second, embeddable
Resin 4.0 Tip – Max thread count
Every application is different in terms of threads used for answering requests. Resin ships with a default thread max count of 256, which is appropriate for many applications, but may be limiting how fast your application is running.
If you suspect this setting is impeding performance, first turn on finer logging. Then increase the max thread count in your Resin configuration file as follows:
While this isn’t guaranteed to resolve every performance issue, having more workers answering requests in your application can significantly increase the overall performance. Who knows, you may find the actual bottleneck in your application (a database or cache perhaps?
The next release will be Resin version 4.0.49 and is scheduled for September. Contact us at firstname.lastname@example.org if you’d like to receive an automated alert for this release.
You'll notice he details a plethora of stacks one must combine in order to truly have a MicroService. We recommend using Baratine plus the likes of Docker, a build tool, and a security framework to get a leg up on the competition and outpace your rivals!
Copyright (c) 1998-2016 Caucho Technology, Inc. All rights reserved.
Caucho®, resin®, quercus® and baratineTM are registered trademarks of Caucho Technology, Inc.