10 Advantages of Elm: Moving to Functional Programming in the Frontend

Elm as a functional language for front-end development that is well known in small circles of experienced web-developers. Its’ syntax is similar to Haskell, but less complex and designed specifically for building web-based user interfaces. Elm has some definite advantages in comparison with React.js. Nonetheless, it’s not very popular within the front-end community. To find out why that is, we talked with DSR’s web-development team.

Using Elm benefits not only the end user, but also the front-end developer. The former gets faster page loading speeds without errors in the majority of cases. The latter — comprehensive compilator warnings, increased compilation speed, and clear instructions on how to move to the new package version. These reasons are why Elm might become a popular tool amongst front-end teams.

Evan Czaplicki, the creator of Elm, doesn’t actively promote the programming language. Being an exceptionally talented developer, he clearly understands how to continue enhancing and developing Elm. His main goal is to make it the most reliable programming language for building web apps. In fact, Elm promotion is basically non-existent, with very few people allocating resources to advertise it. For example, React.js is heavily promoted by Facebook. The social network giant vigorously supports it by organizing conferences, meetups, and conducting other activities to put the framework in the community of front-end developers. Technically, Elm is on par with React.js, even excelling in some ways. Elm’s biggest problem is that very few people are aware of it.

Elm’s Key Advantages

1. Easy to learn.

If you are looking to learn Elm, there are tons of guides, tips, FAQ, books and a really friendly developers’ community. Kevin Yank, the legendary web developer, releases podcasts on Elm regularly. There are loads of studying materials are available for free.

2. Project support is easier for the entire life cycle.

Compared to other frameworks, Elm makes project support (the lion’s share of the app life cycle) significantly easier with the help of compilator’s warnings. These warnings don’t allow changes which your app won’t be able to compile. Hence, overall project cost can be greatly reduced.

3. JavaScript interoperability via ports.

When you start developing web apps (and packages) using Elm, you’ll become increasingly eager to avoid the hectic world of JavaScript wherever you can. However, it’s not always a good idea to rewrite preexisting JS solutions in Elm. Sometimes, it’s not even possible.

Elm has a great tool to integrate necessary JavaScript code, namely, ports. Not every task can be completed with the help of ports, but Elm boasts other interoperability tools as well.

4. No runtime exceptions.

There’s no way an app written in Elm will throw an error which breaks the UI. Front-end developers greatly appreciate this feature.

5. Maintainability & Enforced Semantic Versioning.

If the code doesn’t compile, it will not run. This is a built-in safety feature. Additionally, ff something has been changed in a package that the project depends on, the creator of this dependency is forced to update the version number. You’ll also receive a warning about incompatibilities with your project. Elm is always on guard, protecting your production workflow.

6. Big companies use Elm.

The front-end team at IBM writes apps in Elm and has shared some quite positive feedback. “Elm is really bullet proof, it’s not [false] advertisement”, and we’re quoting IBM here directly. It’s worth mentioning Japanese online retail giant Rakuten (the company also owns Viber messenger). More companies that use Elm are listed here.

7. Performance.

Elm Virtual DOM is more lightweight than that of React.js. Bundle size is most always significantly smaller. Hence rendering the first elements on any page will be faster on any device and in any browser.

Elm- RealWorld App Asset Size Graph

Vast ecosystem of open source packages.

Elm’s free to use code is the result of millions of hours front-end developers’ work. You can use these packages on your project absolutely free of charge. The aforementioned enforced semantic versioning guarantees that third party code won’t break anything in your web app.

8. Progressive web apps.

Developing PWA with Elm is a breeze. Check out this example with open source code.

9. Server-side rendering.

Though it’s not supported by Elm officially, experienced front-end developers have found easy workarounds. Examples can be seen here, here, and here.

10. Any Front-End Developer Can Start Using Elm in a Matter of Days

Should you put off your usual web development tools and move to the
“bulletproof” world of Elm, immediately? No way. But, you should at least
consider this elegant and powerful functional programming language for
front-end development. Read some guides, see some relevant examples, and try
some basic staff using Elm. Only then, once you’ve accumulated your own
experience on real projects, can you decide for yourself. Shifting to Elm
itself will be painless, even for the beginners.

The majority of front-end developers know how Redux works. Interestingly, this JavaScript library was built upon the Elm architecture. That’s just another example of the emerging trend of so-called “JavaScript fatigue.” Nowadays, more and more developers are turning to alternative solutions, trying to avoid pure JS. Since Elm is the “father” of Redux and requires immutability, a declarative programming approach, and has its’ own Virtual Dom implementation, the language will be quite familiar to the front-end developers who prefer the React ecosystem.

Let’s see some examples of code in Elm, highlighting its’ elegance, readability, and simplicity.

Function chaining

Unlike JavaScript, where you have to wrap every function, Elm offers a special pipe-operator. It makes a chain of functions more readable for the developer. This is one of Elm’s key features as a functional programming language.

This picture shows Function Chaining in Elm

Function composition

Another example of Elm’s elegance for front-end development is the function composition. The function composition allows developers to work with complex scenarios involving monades.

This picture shows Function Composition in Elm

App written in Elm

A simple counter that can be increased or decreased as an example of button code.

Any app in Elm consists of modules (just like in JavaScript). Every module contains three parts.

  1. Model. App state.
  2. Update. A way of updating the state.
  3. View. A way to render the state into HTML.
This picture shows an app written in elm

Line 20 in the above code uses a  type alias, that model will store only Int. At the lines 23-25 you can see function init, which is used to initialize the app with a predefined value.

At the line 51 we use the view function to generate HTML. View always takes a model in Elm, giving a front-end developer the ability to operate on the state of the application.

You can see that at the line 54 we call a button function. An array of attributes serves as its’ first parameter, including the event handler, onClick. The second parameter is an array of child elements.  In the example above, we use the function text, which generates a text node. onClick suggests the  performance of an action, in this case, decreasing the counter value. The  text function returns a string with the necessary data.

The App starts running with default value of the counter. Then it runs in the following infinite cycle:

  1. App waits for user input
  2. Sends the message to update
  3. Produces new model
  4. Calls view functionto generate new HTML code
  5. Renders new HTML code in the browser
  6. Repeat

That’s the essence of Elm architecture.

Try to play around with the app code here. For example, you can add a Reset variant to the Msg type.


Elm as a functional language might become your favorite tool for creating web apps, especially when you take into consideration all of its’ advantages and peculiarities. Functional programming is slowly but steadily is gaining momentum among web developers, so don’t miss the opportunity to improve your skill set and make yourself more competitive on the web-development market by adopting functional programming style, tools, and techniques.

Thoughts After CES 2019

CES 2019 at a Glance

Every year we make our way to CES (Consumer Electronics Show) in Las Vegas for the annual consumer electronics exhibition. Imagine over 4,500 vendors presenting new ideas and technological developments spread across an entire week — it really does give a whole new meaning to the city of lights. CES presents a great opportunity to meet like-minded individuals in similar fields, or different, helping catch new ideas, contacts, and ideas – it’s wonderful here.

The history of CES began over 52 years ago with organizers showing more progress each and every year. With the main theme being innovation and information technology, the width of coverage is vast:

  • Robotics,
  • Artificial Intelligence,
  • Three-dimensional Printing,
  • Design,
  • Drones,
  • Sport Technologies,
  • Smart Home,
  • Family & Lifestyle,
  • Virtual Reality (VR),
  • Games,
  • Unmanned Vehicles,
  • Music,
  • Entertainment & Content,
  • Cryptocurrency,
  • Internet of Things (IoT),
  • and Machine Intelligence.


All About IoT

The beginning of the year confirmed that IoT is coming to the mass market.  Focus has shifted from smartphones to other smart devices — and manufactures are taking notice.  Improved air quality sensors, door positions, windows, just to provide a few quick examples.  There are even smart window systems being developed that can inform the home when a window is opened wider than an indicated gap, for example.

Consumers can now choose between a wide variety of smart devices and systems, putting real pressure on manufactures and companies to advance smart home ecosystems. But the problem doesn’t just end there. Consumers need a way to connect many different smart devices to a single system – easy management.  This is where Zigbee and other wireless technologies flex their strength; gateways with multiantenna and customization service suggestions come to the rescue.

Hi Computer, Talk to Me

Voice automation control becomes more the norm than the rarity.  It falls into many devices and almost everyone has them now. People want to have a voice assistant in their home, in the office, and in the car, like Jarvis from Iron Man. Project recipes from the Internet to the kitchen door by voice request?  Yes, please!  Yet, even Alexa from Amazon or Google-assistant do not always suit as a compromising option.  Artificial intelligence is poised to grow wiser and communicate with people better and faster.  Companies that once winced at the idea of software in their products are now flocking to CES.  For example, Procter and Gamble – L’Oreal, are developing mirrors that can look at your face to determine if your skin needs support or treatment.  Maybe just a care cream?  Cameras take pictures of the users face and follow changes of the face in real time.  Maybe they’ll even notice skin cancer in due time.

It is interesting that companies that are seemingly far from “software” come into the sphere of technology.  These companies expand the development zone to such wide branches like automation for pets, children, sleep, and beauty.  There are even smart leashes and collars!  People even get interested in buying devices that can distribute pleasant smells throughout their homes.  And what if you could connect a device that could command three-dimensional TV? Cars? Batteries? Spotify on your steering wheel?  The ideas and possibilities are endless.

Robotics help businesses change their models.  It is especially gratifying that companies competing in the past are starting to cooperate.  To denote such activity, the new term ‘coopetition’ has appeared.  ‘Coopetition’ should bring even greater breakthroughs in overall development.  Teamwork gives rise to new achievements.  SDKs help bring the product to market.  Quick starts are real.

Meet & Talk

DSR had a lot of productive meetings with existing and prospective clients and it was the most successful CES to date. DSR was also a proud  sponsor of the Zigbee Alliance Social – an invitation only event that was a great opportunity to bring all of the members together in one location and celebrate Zigbee successes from 2018. During this event, Zigbee Alliance announced several of the new developments and expansions of the standard and also unveil the location of the next member meeting. The atmosphere for the event was very warm and inviting and perfect for conversations and celebration.

In Closing

Here are seven key CES 2019 takeaways that caught our attention:

  • IoT is finally an emerging mass market (and the data it gathers has lots of financial implications)
  • Amazon and Google are in “hand-to-hand combat” driving voice technology into the Smart Home and beyond
  • 5G, NB-IOT and Cat-M1 are expanding battery-powered WAN connectivity in amazing ways
  • Drones—from airborne to underwater to John Deere—are becoming platforms
  • Robotics are creating business change
  • Artificial Intelligence is getting smarter
  • “Coopetition” is happening in lots of places

IoT is moving capabilities out of smart phones and into different smart things. People want their homes, cars and offices to have a voice like Jarvis (see the Ironman movie franchise). And not everyone wants Amazon Alexa or Google Assistant as the go-between. Battery-powered WAN connectivity in a variety of speeds is making the cloud easier by “losing the gateway.” Drones and robotics platforms are giving new capabilities to businesses and consumers. Artificial Intelligence (“AI”) is changing the way products and services interact with humans. And if Apple and Samsung are teaming up, is it time to evaluate how “coopetition” might help your 2019 business goals?

Open Source Yeoman generator for AngularJS Is Released by DSR

DSR understands that open source community is what pushes the modern IT world forward. DSR is well known for ZBOSS, ZigBee® open source stack certified by the ZigBee® Alliance. Moreover, DSR continuously contributes bug fixes for issues found during development with various modern development platforms and technologies.

DSR understands the value of sharing tools, standards and best practices that we use internally. So recently DSR team released a Yeoman generator for AngularJS. It has some useful optional features, like JWT support, basic components, tools for responsive UI and some others, and, of course, good documentation. The source code is available here:


This is only the beginning. Soon we’re going to release a Yeoman generator for Node.js, several advanced AngularJS UI components and many other fancy things. Stay in touch and sign up for our newsletter to get the latest updates from DSR or check out our blog.

Developing SPA with Angular Material

Fast, convenient, tricky. These are the first three words that come to mind if someone asks how it feels to develop with Angular Material. The project’s documentation states the following right on the first page: “For developers using AngularJS, Angular Material is both a UI Component framework and a reference implementation of Google’s Material Design Specification. This project provides a set of reusable, well-tested, and accessible UI components based on Material Design.” Let’s take a close look at whether it is 100% true based on our extensive experience of developing SPAs with Angular Material here at DSR Corporation.


Well, let’s drop all these subjective metrics and talk features:

  • Angular Material is a flex-based framework which provides an impressive set of tools to manipulate the layout. What does it give us? We can drop a huge amount of CSS purposed to position our DOM elements the way we want. Position inside a block is set with well-documented directives right in our HTML, which makes it quite easy to read.
  • Built-in nice animated dialogs.
  • Built-in services and directives to work with font-icons and SVG pictures with ability to switch between different icon sets and modify the icon style quick and painless.
  • Built-in toasts.
  • Mobile-friendly date picker.
  • Basic support of swipe actions.
  • Resource-friendly list that reuses DOM elements to render long scrollable lists in order to improve performance.
  • Built-in tooltips.


As its name suggests, Angular Material implements Google’s Material Design Specification. So if you want to follow Google’s guidelines you’ll find that many things work right out of the box as expected. Just keep in mind that this is one of many ways to implement it. Get ready to be flexible in your design and to alter it in favor of keeping your code clean. With great power comes great responsibility. With many built-in features, directives, services, animations, and CSS’ rules comes a hard-to-modify predefined behavior. We are not saying it’s impossible to change the way things work in Angular Material, but it would take another dirty hack to do it.

After all, convenience is a very subjective thing so here are some key features that should make your life easier:

  • Adjustable autofocus for dialogs and navigation bars
  • Beautifully animated buttons
  • Custom designed checkboxes
  • Custom designed selects
  • Built-in chips
  • Built-in complex menus and navigation bars
  • Animated input containers with support of ngMessages for error displaying and built-in text’s length counter
  • Custom designed radio buttons
  • Built-in sliders
  • Built-in switches
  • Animated tabs with custom actions on select and deselect


Here comes a fly in the ointment. Since Angular Material is pretty young, it has all expected “puberty” problems. At the moment of writing this article it has 1545 open issues and 90 pending pull requests. That’s for a good reason: as long as it works fairly good under Chrome, it starts showing teeth under Firefox and constantly fails here and there under Safari, especially mobile Safari. If your target platform is Mac OS, you still can keep your code more or less readable, but cascade of hacks can bring your app to its knees in case you must make it work under OS X. Not to say that it’s not going to work in the end, but you will have to sacrifice some built-in features or spend hours making custom overrides, which kind of undermines the whole idea behind using Angular Material.

To sum up all of the above we can say that Angular Material is a promising powerful tool that can help you a lot and drastically improve your performance. Just keep in mind its current limitations and issues in order to not build an unmaintainable monster.

If you would like to learn more, have a project in mind, or want to share some comments, please connect with us at contact@dsr-company.com.

Hybrid Mobile Apps in the Real World

Nowadays most people have heard about hybrid mobile app frameworks and their advantages. There are so many of them and each promises everything you dreamed about for a cross-platform mobile applications development. The idea is nice and simple: hosting a web application inside of the user’s smartphone or tablet with the ability to have a single codebase, involve web developers, reduce costs, decrease time-to-market, and so on. However, we can see that most of the mobile applications are still native and platform specific. Why is that? Experienced developers (especially those who had a really hard time working with early hybrid applications) may notice that the real life cross-platform mobile app development process is far from perfect to make it a standard. DSR Corporation team has rich experience in PhoneGap application development and knows all (or almost all) pros and cons of this technology. In this blog we aim to summarize our experience and share the risks that should be considered when using a hybrid mobile app frameworks.

“Like Native” Still Doesn’t Feel Native

After your hybrid application is ready and deployed I bet the first complaint you will get is the performance. The modern day user has zero tolerance for even a slight delay, especially if he or she is expecting to be entertained. Just try to scroll a list in a native iOS application and then in a hybrid one: you will probably not say the hybrid has delays but it feels different and users notice that.

Additionally, if you want to use the same codebase for all platforms, then your application will look the same on all platforms. Sometimes it is good and desirable. Even if it is not, your application will still work fine. But as you may know the UX/UI guidelines are different for each platform and each user base has specific expectations on how apps work on their respective platforms. For example, an iOS user expects a “Back” button everywhere, where Android users may not find the search if you implement it using the iOS style. So when you are implementing the same UI, you are making a compromise or spending extra effort to make it different.

You Can’t Get Away from Debug

If it works on one platform, it does not mean it will work on another. Each hybrid app has its native part and framework development teams work hard to make them work the same way on all platforms so you could relax and concentrate on HTML, CSS, and Javascript. However, even if the framework you picked is “perfect,” each platform is assumed to have its own browser. Moreover, if you extended the native part, for example, by writing your own PhoneGap plugin, you will have to carefully port it to each platform. The situation gets more complicated when dealing with low cost or old devices: each one of them can have its own surprises. In this case you may need to research the Crosswalk pluggable webview (https://crosswalk-project.org/) to make it easier to maintain your app.

As a result, this is actually a normal case for multi-platform development when “write once, run everywhere” turns into “write once, debug everywhere.”

Platform-specific Nuances

In a perfect world a web developer can develop a cross platform mobile app without learning anything else. Meanwhile, using a hybrid framework, please make sure the team is armed with at least the following knowledge:

  • Environment configuration. At the very beginning, you can rely on a cloud build service. But sooner or later, even if you work on something simple, you will need to debug your application to make sure there will be no surprises the day before delivery.
  • Native support. It would be nice to rely on an experienced mobile application developer on your team. And it will be 100% necessary if your hybrid framework does not provide something you need.
  • Offline mode. Make sure you are developing a mobile application, not a mobile website. It will be nice if it works offline or at least provides a clear message that an Internet connection is required.
  • Guidelines. The users will very much appreciate if you meet their expectations. Everyone likes something he or she is used to and that feels natural with how they use their device.
  • Interact with others. Make sure you know and interact with typical platform applications that are used every day. Building good neighbor relationships is a good habit.
  • Deployment and approval. It can be a real pain for those who are doing it for the first time. You may need to read vendor requirements carefully even before you start the development: some rules can change your plans.

Keep it Simple

Please don’t expect too much from the hybrids. If you need something of flawless quality or great performance or exquisite look and feel – hybrid is probably not a good choice. Note that hybrid apps are fragile: the more complex architecture you have, the more effort you need to maintain it, especially if this is about interaction of HTML/Javascript part and the native part.

It’s Alive!

Considering the fact that you are still able to use native tools and controls you may think about combining web controls with native ones. Be careful not to create a Frankenstein: the application complexity can rise so significantly that it will become a nightmare to debug and maintain. First, the native control you used will need to be considered on other platforms (there is no guarantee that it will work the same way). Second, the integration part (between HTML/JS and native) is the “richest” source of bugs: the more complex the design is, the more “fun” you will have. Third, thinking about using native controls is a good signal that you need a native application. Consider your options and make the right choice for your app.

The Apple Dependency

Another risk that you may need to consider is a high dependency on the App Store Review Guidelines. The App Store is dominating the mobile apps market, so Apple can and does dictate its rules. The Review Guidelines change quite often and, although unlikely, it’s possible that hybrid apps can get banned from the App Store at some point in the future.

Now when you are aware of the risks you may wonder if there are any reasons for you to use hybrid applications. There are many of them!

Low Cost and Quick Time to Market

If you have a limited budget and need a mobile application, using a hybrid framework may be a solution. Easier UI development will give you a cost advantage even if you are planning iOS as your only platform. Make sure to keep it simple and that your single codebase can be easily ported to other platforms without significant changes. At the same time, reducing your effort can save you precious time, so you can deploy early and have the app ready before your competitors.

Startups and Explore

If you are planning to develop a serious application that requires a lot of effort for UX/UI you may consider prototyping it first. It will allow you to have better understanding of all application usage aspects and resolve problems early. Certainly, your prototype can be a quickly developed hybrid application you can use to get early adopter feedback and demo the concept.

Web Development Forces

If you or your team are good web developers, then you can use your experience in the mobile apps as well. Choose a hybrid mobile app UI framework you like the most and do the main implementation using your favorite tools. In most cases you will not need to learn a new programming language. At the same time, you will be able to develop for additional platforms improving your web development experience.

Better Than a Website

If you are thinking about developing a mobile website instead of a mobile app, then you should consider the serious advantages the mobile apps have:

  • Sales and distribution. Everyone knows about platform specific application stores that help users find what they want and allow developers to sell and distribute their apps with ease.
  • Usability. Mobile apps are optimized for use on mobile devices and users expect at least the same level of usability. It would be difficult to compete with a mobile application having only a browser application.
  • Works offline. Your users can work with the app even if the Internet connection is lost.
  • Using device capabilities. In contrast to websites, mobile apps can utilize a full set of device capabilities.
  • Popularity. Today it seems like a good habit to create a mobile app to meet user expectations.

Although we at DSR prefer to build native mobile apps because of their performance, seamless user interface, and best user experience, we have rich experience building cross-platform mobile apps as well. The latter can give you a serious advantage, but only if the related risks are considered. This is not a silver bullet, but it can be a powerful weapon on your side, if your project meets the parameters described above.

If you would like to learn more, have a project in mind, or want to share some comments, please connect with us at contact@dsr-company.com.

Why You Should Consider Node.JS as a Backend Option for Your Project


In the early 2000s, when the web was small, servers were slow and client machines were even slower, developers faced the C10K problem. The problem was about concurrently handling 10,000 client connections on a single server machine. As a solution, multi-process and multi-threaded architectures (a new process or thread per each request) became very popular in mainstream software platforms for web development.

But the web continued to grow (and it still does), C10K goal became implementable on most software platforms and frameworks and the community stated the next goal – C10M problem. As you might have guessed, it’s about dealing with 10,000,000 concurrent client connections, which is a tremendous load.

The C10M problem is still relevant now and developers need new solutions to reach much higher load requirements. Most modern web apps include RESTful backend along with web and mobile apps that consume backend API. This increases load that the backend server should be able to hold.

Async I/O based platforms were created to help developers reach the goal. In this post we’ll talk specifically about Node.js as our preferred platform for high load systems development.


Node.js was initially created in 2009 by Ryan Dahl and other developers working at Joyent company (main contributor of Node.js). The idea was to use extremely fast Google V8 JavaScript engine and implement system libraries that provide common APIs which are absent in browser environments (as browsers provide sandboxes for JS code actually), like file manipulation, HTTP client/server libraries, and so on.

Because of async nature of JS (which is executed in a single thread and does not support multithreading at all), all of Node.js system libraries provide evented and asynchronous API for I/O operations, like reading a file or sending an HTTP request.

So Node.js itself might be described as an asynchronous event-driven platform. Code written by developers is executed in a single thread and, speaking of web backend development, at each moment of time only single client request is being processed, while all others are idle. However, due to the async nature of Node.js, all calls that are potentially blocking, like execution of SQL queries, have event-based API and lead to switching from current request processing to next awaiting operation (all of this is handled by the event loop).



Let’s look at “classical,” thread-per-request based solutions, like Java servlet containers (Tomcat, Jetty, etc.) or Apache web server. By default, the whole thread is blocked on I/O operations here. Thus, maximum load that can be handled by a single web server instance is bounded by the maximum amount of threads that the server can handle.

Apart of the fact that creation of a new thread is relatively expensive, threads have quite a heavy footprint themselves. For example, each Java thread requires 1024KB of memory for its stack in 64-bit JVM, so 10K threads require 10Gb of RAM just for the thread stack.

So building highroad systems with such software platforms is still doable, but it’ll require many more server instances to handle the same load.


At DSR we have implemented several projects with Node.js-based backends and have been very pleased with the scalability and performance of the platform.

The strength of Node.js is the async, non-blocking I/O nature. Modern RESTful backends do a lot of I/O operations mostly, without involving heavy computations, and Node.js shines here. While reaching C10K goal requires certain effort from the developers on multi-threaded platforms, it’s just the worst performance level in case of Node.js.

Our experience confirms that Node.js is a stable and developer-friendly platform. Since Node.js 4.0, there are LTS releases now, which are stable and supported for a long period of time. As for developers, we find built-in platform tools, like npm, very handy, and, as for the code, promises cooked with generators are just simply awesome.

Of course, there are some negative points, like small amount of production-ready 3rd party libraries/frameworks. But the platform is rather young and Node.js ecosystem is rapidly growing and maturing. Growth of npm package count also indicates this well enough (see the chart below).


We’re actively participating in the Node.js platform community and are looking forward to building more great, high load systems using it.

Java Enterprise Development – the Technological Journey

At DSR, our expertise with Java Enterprise technologies, Java application servers, and servlets containers is often called upon by a wide array of software development projects. Our trials and tribulations in software development are many, but today we have adopted the Spring Application Framework as the DSR standard for enterprise level applications.

Let me explain why.

In the Beginning, there was Glassfish v 2.0 with SOA and ESB

In 2008, DSR was asked by the digital media industry to create a distributed solution that allowed users to work simultaneously with video editing software tools like Final Cut Pro, and a digital media archive that housed a vast amount of content.

To develop the solution, we started with Glassfish v2.0 having Service-Oriented Architecture (SOA) using the Enterprise Service Bus (ESB), and Business Process Execution Language (BPEL). DSR released several product versions and successfully supported consumers through 2012.

From an engineering point of view, we were satisfied with the technology stack but found that it was too complex of a configuration when using huge XML documents.

From a project management point of view, I believe we could have chosen better after reviewing the cost/efficiency ratio. In hindsight we realized project objectives could have been met with less engineering effort if a less complex stack would have been chosen.

Just a Few Years Ago, There was Spring, GWT, and Tomcat

In 2011, DSR was engaged to create a web-based service with stock exchange logic in the background. Taking into account our earlier learning experience with XML documents, we looked for a powerful, less complicated Java stack that allowed us to build a modern and scalable web-application.

Several server-centric technologies were tried, including, JSF (Java Server Faces) that is provided as par of Java Enterprise Application Server. However, we soon realized our approach didn’t meet the project needs for a good user experience and scalability. We quickly uncovered a client-centric technology and determined the GWT (Google Web Toolkit) showed the most promise in our tests.

For the back-end, we had to fit the integration with a relational database (MySQL or Oracle) and provide a solid infrastructure to manage the solution. After extensive research, we chose the Spring Framework in conjunction with Hibernate, and Tomcat as a servlet container.

From both an engineering and a project management standpoint, we were satisfied with the technology stack and found Spring Framework to be an integration solution that embeds the best parts of Java Enterprise libraries in tandem with a high degree of flexibility to add additional components.

Today, Evolution to Spring and Jetty

In 2012, DSR participated in developing an aircraft engineering configuration software used by workgroups. The engagement had a huge domain model (from a device down to a network package), concurrent versioning functionality with branches, dynamic ACL and rich client side UI to create and manage an Aircraft Engineering configuration.

Initially Glassfish v3 with EJB 3 was chosen for the project. Eclipse Modeling Framework was selected to deal with the domain model, while Eclipse Rich Client Platform provided a client side application. We created a custom JPA persistent provider implementation allowing for a persistent EMF based model through Hibernate. We also used a continuous integration approach based on Jenkins server.

For integration testing, we selected Arquillian technology and after six months of active development, we faced a speed issue in which our integration tests simply took too much time to execute. With a team of 10 engineers, we had several hundred integration tests with 4-hour run cycles that completely blocked our continuous integration approach. In short, our continuous integration server tested the project slower than it was developed.

While investigating solutions (including embedded Glassfish) we uncovered no viable answer. We found the issue could be solved by migrating with Spring while employing a standard Sprint testing approach. Fortunately, EJB 3 is very similar to Spring (actually EJB 3 shows a clear influence by Spring) and we only spent about 2 single-engineer work weeks to port the solution to Spring and its test approach.

Glassfish v3.0 was also replaced with Jetty since we didn’t need a Java EE server to run our server application despite us still using Java EE components. After migration, we continued to develop the solution for almost 2 years, and after successful acceptance procedures, passed the results to the customer.

To conclude, I’d say that with several years of experience using Java Enterprise technologies we have proven that the Spring Framework is a very good choice in engagements where using Java EE platform is not a strict requirement. With Spring, we have satisfied all engineering and project needs faced thus far. Despite Java Enterprise Edition being a good standardization for most popular platforms, (Glassfish and JBOSS application servers used & tested) we found Spring allowed us to provide best in class results.

Spring for a Java Enterprise level solution has become our recommendation of choice, although we remain open to support our partner’s needs and use a Java EE platform where Spring cannot be.