Last Tuesday I gave a talk at DevNation 2016 on building Reactive Applications with Node.js and Red Hat JBoss Data Grid. The slides for it will be uploaded to the DevNation site shortly, but for those who want to play around with the application demoed in the talk, you can find the code and instructions in this repository.

The Red Hat Developers blog posted a review of the talk in this address: http://developers.redhat.com/blog/2016/06/29/devnation-live-blog-building-reactive-applications-with-node-js-and-red-hat-jboss-data-grid/

Please find below review as written by Rob Terzi:

DevNation Live Blog: Building Reactive Applications with Node.js and Red Hat JBoss Data Grid

Posted by Rob Terzi on June 29, 2016

At DevNation, Red Hat’s Galder Zamarreño gave a talk with a live demo, Building reactive applications with Node.js and Red Hat JBoss Data Grid. The demo consisted of building an event-based three tier web application using JBoss Data Grid (JDG) as the data layer, an event manager running on Node.js, and a web client. Recently, support for Node.js clients was added to JDG, opening up the performance of a horizontally scalable in-memory data grid, to reactive web and mobile applications.

JDG is capable of processing and storing real-time streams of data, while maintaining very fast response times. It does this by using the memory available from a dynamically scalable grid of machines. Galder described JDG as a four-in-one package capable of being:

• a distributed cache.
• a high performance NoSQL primary data store.
• an event-driven data store, particularly for real time event processing.
• a big data and Internet of Things (IoT) data store.

The three-tiered web app in the demo consisted of:

• A web client written in Elm, which is a functional language that compiles to JavaScript.  It is statically typed, which the presenter feels leads to well architected code. Elm competes with platforms such as React and Angular. Any of those other platforms could be used, but Galder chose Elm for the live demo, particularly given the useful error messages the compiler generates as a virtue of using a statically typed language.
• An event manager running on Node.js using Express.js.
• JBoss Data Grid as the data store.  Three nodes were used, running on the same laptop. Each element was guaranteed to be stored in two nodes, providing redundancy for fail over.

Node.js based applications have become very popular. Many use JavaScript on all three tiers, including NoSQL data stores. However, most of those data stores can’t match the scalability and response times of JDG. Traditionally, developers have needed to use Java to take advantage of JBoss Data Grid. The new fully asynchronous Node.js interface to JBoss Data Grid should enable developers to build some truly interesting next-generation reactive applications.

You can download JBoss Data Grid from developers.redhat.com. If you’d like to get involved, join the open source community at infinispan.org.

DevNation 2016: Galder Zamarreño on “Building reactive applications with Node.js and Red Hat JBoss Data Grid”

Earlier this month I did an interview with the DevNation 2016 organizers to talk about my talk on forthcoming talk on building reactive applications with Node.js and JBoss Data Grid, the Infinispan version for which Red Hat provides professional support, certified integration, patches...etc.

The talk will be happen next Tuesday, 28th June at 3:30pm PDT, so if you're in DevNation and want to find out more about Infinispan and our new Node.js Javascript client, make sure you join us then!

-------------------------------------------------------------------------------------------------------------------------

Originally posted in: http://developers.redhat.com/blog/2016/06/09/devnation-2016-galder-zamarreno-on-building-reactive-applications-with-node-js-and-red-hat-jboss-data-grid

Building reactive applications with Node.js and Red Hat JBoss Data Grid

JBoss Data Grid is a distributed in-memory key/value data store from Red Hat, which can be used for caching, temporary and permanent storage. Although Java developers were its primary audience initially, the team has been expanding its appeal to C++, C# and even Javascript developers.

The latest JBoss Data Grid release includes a fully asynchronous Node.js client for interacting with JBoss Data Grid servers and my talk at DevNation is focused on how Javascript developers can make the most of the client to cache or store their data.

The talk has been designed around a web application that promotes JBoss Data Grid talks in forthcoming conferences, user groups… etc. The application will contain a Node.js component whose job will be to interact with the backend JBoss Data Grid servers to store and retrieve data, as well as receiving events when new information has been added to the backend. Through the live coding of this application, the audience will get an understanding of how to interact with the newly released Node.js JBoss Data Grid client, and after the talk they’ll have access to the code to be able to try it themselves.

Tuesday
3:30 p.m. to 4:30 p.m.
Room 133

About the presenter:

This will be my first time speaking at DevNation and I’m really excited about it because it brings together speaks and attendees not only from the Java/JVM space, but from other important developer communities such as Javascript.

Although I started as a Java developer, over the past decade I’ve become more and more interested in other programming languages, in particular functional programming languages such as Scala and Javascript, which I’ve been able to apply directly at my job.

These days I’m hugely interested by the purely functional ones such as Haskell, Elm or Purescript because the lack of mutability makes their solutions both elegant and easier to reason about. I’m also keeping a close eye as well on the Erlang ecosystem, e.g. Elixir, because I feel that the predictable latency offered by the Erlang VM is something that it’s not so easy to achieve in Java Virtual Machine.

I think learning other programming languages is one of the best things a developer can do, because it opens your mind to different points of view, different ways to solve problems, and widens the solution space.

Node.js Javascript Client 0.3.0 out with improved stability and API docs

Earlier today Infinispan Javascript client version 0.3.0 was released whose primary focus has been stabilising and tightening existing functionality, deprecating some older methods, and documentation:

• Multiple fixes around remote execution, remote listeners and iteration.
• Improved failover handling logic to correctly deal with socket error and remote disconnect situations.
• Removed getVersioned, getBulk and getBulkKeys methods since these are deprecated in favour of getWithMetadata and getAll. The examples in the README file have been updated.
• Added API documentation for Javascript client. Online API docs for Javascript client can be found here.

If you're a Javascript user and want to store data remotely in Infinispan Server instances, please give the client a go and tell us what you think of it via our forum, via our issue tracker or via IRC on the #infinispan channel on Freenode.

Cheers,

Galder

HotRod C++ Native Client 8 Series

The Infinispan Team started the development of the new HotRod C++ Client (version 8) with two main goals in mind: update and refresh the code and reduce the feature gap between the C++ client and its Java big brother.

The work is still in progress, but since we're close to the 8.0.0.Final release, I would like to describe, in this and in the following posts, what's changed as of today.

Although there are a lot of changes and improvements in the code (protocol updates, segments topology, configurable balancing strategy... you can have a detailed view of the activities stream browsing to the Jira issues), I would like to focus on the following three big changes:

• C++11 Standard
• Remote Execution
• Queries

C++11 Standard

Activities grouped under this title are motivated by the change in the development approach of the new features. Until version 7 we have followed the approach of keeping the baseline compiler requirements quite low to ensure a broad client portability, even to platforms with old compilers/libraries, but when we started development for the 8 series we felt that this principle would excessively complicate the implementation of new features.

With this in mind, we have fully embraced the new C++11 language feature (such as lambda function in the asynchronous interface method, or variadic templates) and pushed for extensive use of standard library container classes in lieu of our custom ones.

We know that in this way we may have limited use of the client to more recent platforms (bye bye RHEL 6) but fortunately the source is open and we have a very good build procedure based on cmake that can easily generates builder for the most used pair <compiler model, compiler version>.

The work on C++11 language adoption is still in progress and the goal on this front is to update the code wherever it results in improved readability (i.e. the auto keyword is a simple but powerful way to reduce code verbosity).

Because in this cycle we have added a few new features that required the introduction of some library dependencies and automatic code generation, the build process has become more complex, but we're doing our best to keep it manageable. We want to ensure that our packaging structure is what users expect on all of our platforms with respect to libraries, headers and documentation.

I will be glad to hear from any of you about any thoughts and suggestions, especially on the portability issues.

In the next post I will show an example of the new Remote Script Execution features.

Cheers