JavaScript, JavaScript, JS all the way!

 

jrogelstad's picture

As many of you know we have been working hard on our next generation Mobile Web client platform that will enable xTuple users to use the application through a browser on both desktop and mobile devices. What you may not know is that this is the first business management system written that uses JavaScript in all layers including the database, the data service and at the application layer. You may be asking yourself a couple questions: First, "Are you crazy?" and second "Why is this a good thing?"

To answer the first question, no, we are not crazy. JavaScript is the direction the world is moving in and the reason is simple: It is the language of the web because it was designed for the web. No other language is more portable than JavaScript because all operating systems support browsers out of the box and all browsers support JavaScript. Because of the strategic importance of browser capabilities enormous energy has been poured into optimizing, enhancing and extending JavaScript so that first class applications may be written for a browser using JavaScript that are both robust and fast. A side effect of this optimization is that it has become a powerful and high performance language even for non-browser based applications like data services. It's no wonder then that JavaScript is far and away the most popular language on GitHub today.

This is a good thing because these performance improvements coupled with new framework technologies like Enyo, NodeJS and PLV8 are allowing us to build a browser based client with performance that meets or exceeds our compiled C++ based client. Another even more obvious benefit is that it has allowed us to build a new client architecture that works on any device, mobile or desktop.

It is also a good thing because it offers huge advantages to developers. One of the biggest is that our development team is not required to learn multiple languages and, because JavaScript is ubiquitous, most developers already have some exposure to it. If you know how to write JavaScript you can write code for any layer of our new stack. This greatly reduces the learning curve for new developers and makes our development staff much more flexible. Developers can concentrate on the business problems that need to be solved instead of spending endless hours learning the technical nuances of a new language. It also means we will be able to quickly offer more high powered functionality faster and with higher quality than traditional technology stacks that are a mixed bag of languages and technologies that often don't play well together. The other huge benefit for developers is that because in this paradigm we can write one client that works everywhere, we spend dramatically less energy than competitors who are writing compiled applications for every mobile platform. We write code once, and it works everywhere. While it has taken us a long time to get our first module out (CRM), I fully expect subsequent modules to become available at an increasingly accelerated pace.

Here's a short over view of the technologies in our new stack:

Enyo and Backbone

Enyo is a framework for building HTML5 applications that work on all devices, but ironically the way it works it allows us to do this without writing any HTML. Our Enyo application structure is built as an object model hierarchy so that components are reusable which is essential for an enterprise application. In layman's terms what this means is we've created a set of building blocks that we can quickly mix and match to create new modules and applications with unprecedented speed. We call our framework of user interface objects enyo-x. You can see an example of an object like our ComboBox widget here. What I find particularly exciting about an example like that is it is only 149 lines of code! Less code for us will mean a higher quality and more powerful application for you!

Backbone is a model system written in JavaScript. While Enyo lets us define the presentation bits you see and touch, Backbone provides a layer where we handle the business logic behind the scenes like "The amount attribute must be a number" or "When the status changes to 'Completed' the complete date should be set to today's date." Again, we have created our own version of backbone called backbone-x to handle our specific design requirements and the beginnings of a library of core models to support Postbooks. Contact is a good example of one of these business objects. One very interesting thing to note about the Contact definition is how little there is to it! This is because a lot of definition including privilege and data structure is derived reflectively from the ORM system described below.

NodeJS

V8 is Google's JavaScript engine that is used to power its Chrome browser, however because of its power and portability it is being used for a lot more than browsers these days. NodeJS is a platform for building network applications using JavaScript. It is specifically designed for the modern cloud environment. We use it as the basis for our web service that both serves our application and handles requests for data. It is difficult to get very far in a conversation about NodeJS that doesn't get into highly technical subjects like "Non-blocking I/O" and "Web Sockets", but the important thing to note here is NodeJS has caught on like wildfire in the developer community and it is one of those areas of open source where the momentum is so powerful its capabilities have quickly eclipsed more traditional proprietary technologies.

PLV8

PLV8 is an integration of JavaScript into the PostgreSQL database that allows us to write database functions using JavaScript. We have leveraged this technology to build an embedded Object Relational Map (ORM) system for PostgreSQL. This effectively allows PostgreSQL to "speak the language" of JavaScript which is JavaScript Object Notation (JSON). The ORM maps themselves are in JSON. You can see examples in our code base here and you can see examples of javascript doing the processing here.

Conclusion

These descriptions are very superficial introductions to our new JavaScript based architecture. I hope to write many more blogs describing each of them in more depth in the future. In the mean time, I hope you are excited as we are about the future of xTuple with this new stack. We will begin supporting live customers in December, just in time for Christmas. If you are interested in using our new Mobile Web client please contact our sales team and let us know!

 
jgunderson's picture
Offline
Joined: 05/11/2011
Good overview

John, just the overview and diagram I was looking for tie it all together!
Thanks!

 
petergutman's picture
Offline
Joined: 04/26/2011
Are you still using PLpg/SQL

Are you still using PLpg/SQL for your business logic?

 
jrogelstad's picture
Offline
Joined: 12/10/2008
Yes and no. One of the

Yes and no. One of the important goals of this initiative is that the web client be completely interoperable with the existing GUI client. Another important goal is that we not add major new dependencies to the GUI client, at least on this first pass, or destabilize it by gutting and completely rebuilding it from the inside out. It is very, very important to us that the GUI client remain solid and reliable because thousands of people depend on it for mission critical business operations. The GUI client itself will have no reliance on PLV8 in 4.0, and continues to use the existing plpgsql business logic it always has.

What we have done and will continue to do for some time is wrap and expose some of the more complex plpgsql functions with JavaScript equivilents so that both clients will share exactly the same business logic in certain critical places. Examples would be things like Post Invoice, Calculate Taxes and Run MRP. Here's an example of 3 Contact functions wrapped this way:

https://github.com/xtuple/database/blob/master/client/source/xm/javascri...

That said, the architecture of the new client is dramatically different. Much of the logic that the Qt client offloads to the database is handled by the Backbone model layer in the new stack. I estimate that when the whole application is completely ported the two clients will share about 20% of the existing plpgsql functions. At that point we may evaluate the prospect of re-writing the plpgsql functions in JavaScript, but that's a ways down the road.

 
tcollins's picture
Offline
Joined: 07/29/2010
I have to admit... this

I have to admit... this overview looks fantastic!

 
ularmas's picture
Offline
Joined: 01/15/2013
are we moving away from QT++?

are we moving away from QT++? I hear Openbravo also uses enyo.

 
jrogelstad's picture
Offline
Joined: 12/10/2008
We are continuing to maintain

We are continuing to maintain the Qt Desktop client. Version 4.1beta of that client will likely be released today which upgrades to Qt version 4.8.