Decisions

Decisions, decisions

Back End: Vert.x

Vert.x is a quite new, exciting project. It is an application platform, designed to make the best use of today's hardware. It uses not only the multicore/multithread capabilities of modern servers, but also the power of servers distributed over a network or even the internet. And, most important, the application programmer does not have to be concerned about multithreading, synchronization problems and deadlocks. We create just simple bare bone single threaded verticles or modules, and Vert.x does the rest to scale them to a multiprocessor- or even multiserver- environment.

Even better: We don't have to mess around with communication between separate independently running parts of an application. The Vert.x EventBus provides a fantastic easy way to send messages and data around, even between clients and servers running on different machines somewhere on the internet.

And, last but not least, Vert.x is multilingual. You can easily write Verticles in Java, Scala, Ruby, Groovy, CoffeeScript or Javascript, and all work neatly and friendly together.

Data store: MongoDB and Mysql/PostgreSQL

We have to use mysql/postgreSQL, because legacy elexis is built on it. But since sql databases are not well suited for the task of a distributed data store, the final goal ist, to migrate to NoSQL. After some evaluating, MongoDB proves best suited for our needs (with CouchDB running up).

Vert.x, however, offers a combined mysql/postgreSQL-Module, and a MongoDB-Persistor ready to use. Downloading, installing and running of such modules is as easy as:

 container.deployModule(<module-id>,<Callback>);

Communication to Front End

With Vert.x, the decision is easy: We use the Vert.x EventBus via Sockjs to communicate between server and client.

Front End

Since we want to support as many devices as possible, there is only one choice, if you don't have lots of developer power: Create a web based fronted. Most devices today feature a recent web browser and thus are able to run browser based software.

The language of choice for browser based software is JavaScript. There are many options to reduce the amount of work to create such an application.

Two obvious solutions are Google's GWT and Eclipse's RAP. Both let you write your code in Java, using your favorite IDE and Debugging tools, and convert it automagically into a browser-app. In this automation lies the drawback, though. At least in my opinion. Everything is hidden. You can't easily understand what happens, and you can't easily modify the output, and it's difficult to leave the predefined path of the toolkit. I gave both a try, but didn't really succeed. This ist definitely my own fault, since other people created great software with either GWT or RAP. But it's not working for me.

So I decided to learn JavaScript. And making this step, I learned, that it is much more tedious to program in Javascript than it is in Java. The coding-debugging-coding cycle becomes an adventure as it was in times of C/C++ (or I probably just didn't find the right tools for the job yet).

Fortunately there is help. I didn't have to code everything by myself. There are great JavaScript Libraries around.

General toolbox: jQuery

Many programs written in JavaScript, make use of jQuery. It ist cumbersome to program something like

 $("#myhtmlsomething').getVal()
 $(".somecssclass").putVal("anything")

without jQuery. Of course, it must be possible. But, since jQuery exists, why should I try to find out?

UI design: Twitter Bootstrap

Having said, that we want to support as many platforms as possible, we have to consider everything from phone to big screen. Well, it's quite tedious to create user interfaces for all possible sizes. Except if you use Twitter bootstrap for this task.

Single Page Application support

This is a collection of different tasks:

• We don't want to reload the whole page, when the user clicks something. Instead, we want a single window. The key for this task is Ajax.
• We want an easy transfer of server based objects into the client view and vice versa. The key concept here is Databinding.
• we want to separate design from application logic.
• we want to move load from the server to the client. Most clients today are powerful enough to do some data processing, while servers tend to be overloaded.

There are a number of libraries to achieve these tasks. After some looking around, I ended up with either AngularJS or KnockoutJS. Both seemed to provide the things I needed, so the decision was not easy, and somewhat arbitrary. Finally I chose KnockoutJS.

---

If you read until here, you are ready to setup your developing environment for Webelexis.