Reference no: EM132757528

We have been tasked with replacing a series of 25 year old mainframe applications with web applications. There are 4 applications in the series and we are trying to come up with a stack that will work on all 4.

Now these applications are big. Not huge, but big. Based on the work that our sister company did to replace similar pieces of their systems, the small one is expected to come in at about 150k lines of rest service code and about 80k of UI code. For the big one, a million of service code and 200k of UI code isn't out of the question. The small application, so far we have about 150 different views, The big one has about 500 we know about.

Now I understand that line numbers are a bad metric to use, but at the moment, its the best i got, so lets just go with that.

So in the world I typically work in, this is one medium size application and three large ones. The next issue we have. Across the board, all systems. No user action is to take more than one second. Meaning, if you come into an application, the app has to be loaded and ready to login within one second. If you click on a search button, the response has to be displayed within one second. We have people that use the mainframe systems that process paperwork and in order for them to hit their daily quota, they have to average a start to finish processing time of 15 seconds for each case. The green screens they use right now just barely hit that mark.

Dont get me going on eliminating the paper. State and Federal law requires it.

So we already know that we have to build the app in such a way that a user can use it without touching the mouse. No way are they going to hit their quotas if they have to be mousing all over the place. Thats not such a big deal, we can define hot keys to do that. But the big issue is the speed.

The typical internal framework is JSF. The standard is RichFaces, but many years of horrible performance out of Rich has finally convinced them to move to Prime. We would be about the 2nd or 3rd to use Prime. But since our performance requirements are the highest they have ever encountered, they asked my team to evaluate different frameworks. For internal applications, the current acceptable response time is between 5 and 7 seconds. Pretty typical in an enterprise, usually pretty easy target to hit with JSF.

So we spent the past 5 weeks evaluating various options and by leaps and bounds the highest performing framework was GWT. In our benchmarks it blew Vaadin and JSF/Prime completely out of the ball park. Also, aside from JSF, its pretty much the only thing we could find designed to handle applications of this size with surprising ease. (Struts and SpringMVC are strictly forbidden in our enterprise)

Then the problems started. Our Enterprise group said no, we can't use it. They acknowledge the fact that there is very little chance of JSF pulling off our performance requirements and the only practical way of hitting our goal is a thick browser front end, but, instead of GWT, they want us to use Angularjs. For the purpose of this post, lets not get into why they said no, lets just stick to the fact the answer was no.

So, the past 2 days, I started digging into Angular. So far, I'm not impressed. It looks ok for very small applications (compared to what I normally deal with) but I can't find anything anywhere that shows an experience in trying to build an application of the size that I need to build. The closest I found was a guy talking about his "Enterprise" application he built with Angular that was about 9k lines. He said it was a bitch to pull off, mostly from inexperience, but once he found the tool Lineman, it became tolerable and he was able to pull it off. In the applications I need to build, 9k lines won't cover the logic I need to build into my search UI (so far we have identified about a dozen different ways to search for various data, and counting). To say nothing about actually doing anything with the results.

So I called up two of our really, really good developers and asked their opinion. After we got past the initial "Your out of your mind, that's what GWT was built for" phase of the conversation, it was settled that to try to pull off apps of this size as single page javascript apps, like you can in GWT very easily, would be complete suicide. Angular just simply wasn't designed to go that big, it was designed for tiny stuff. Mobile apps, small web apps, etc. Nothing of this scale. The idea is we have to break the app into smaller modules. But, this brings the problem of how to transfer application state from one module to the other. This problem has been tackled at this company before with very poor results. But, they had an idea.

Since we can't switch out our Websphere servers for Node.js, Their suggestion was to try a hybrid approach. The idea is to a JEE6 Conversation bean. Then a JSF file for each module of the application. That JSF would be linked to the conversation bean. This way, each module can run Angular to handle the MC side and the V side can be basic HTML with Twitter Bootstrap to make it pretty. When the user switches from one module to another, the JS application state is posted to the conversation bean. The conversation bean then redirects you to the new JSF module page, then the JSF can grab the object that represents the current application state from the conversation and pass that to Angular, loads it and they are off to the races. Then of course Angular would talk to the REST services directly. We are using the slow ass JEE stack as little as possible, but still able to sorta easily move app state from one module to another.

The stack sounds ok to me. We have the ability to break the app into modules, if the module gets too big, we can break them into sub modules, use the conversation to move the state from module to module, and we can use Angular.

My problem with this stack is 2 fold. One, thats a lot of plumbing. Lots of things to go horribly wrong. Two, I can't find anyone that has tried something like this.

Questions: What is the practical size limit of an application based on Angular that does not have the benefit of Node.js sitting behind it?

I have been told by my UI programmers that when an application gets to the point of about 10k HTML elements within a single page JS module, the performance starts to degrade. When you hit about 25k elements, the performance drops off a cliff, and about 40k elements the app usually doesn't load. Are these numbers consistent with medium to large applications that you have written? For comparison sake, lets say Stack Exchange is a medium sized application, Google Drive is large.

Does a design pattern exist for this scenario. Meaning does a pattern exist where you can break a large JS based front end app apart into modules that can be handled easier by the JS frameworks by using JSF or some other system to transfer the application state from one module to another. The failed attempt made in the past was to post the app state object to a web service and that service store it in an application scoped EJB to be retrieved by the next module. That technique failed miserably when the app came under any kind of meaningful load.

Are there any other frameworks out there to consider that can give us the performance, scalability, flexibility, and ease of developing large applications like this that doesn't have Google in its name?

BTW, I was told about Angular Modules about 15 minutes before I walked out the door today. All I really know about it is its name. If you think it could help me, please let me know.