Server Side Web Frameworks, The Last Stand

I’m a fan of client / server architecture. I believe that…

  • the front end should be limited to the presentation tier
  • the back end should be limited to the logic / data tiers
  • the presentation tier should be separate from the logic / data tiers
  • the presentation tier should integrate with the logic / data tiers

I believe that the front end, the presentation tier, should be executed on the client and that the back end, the logic / data tier, should be executed on the server.


Client / Server / Server

However, it is possible to separate the front end from the back with server side web frameworks. Let’s call it a client / server / server architecture.

A few years ago, when I was a consultant, I created a client / server / server architecture for a client. It included both a front end and a back end. The front end included a web application. The back end included enterprise services. At first, the web application included both the business logic and the data access. However, I was not happy with it. First, I decided to move the business logic and the data access from the web application to an enterprise application with REST services.


* The application server was JBoss Enterprise Application Platform (link).

This architecture allowed the development of the front end and the back end to proceed at different paces. The web application no longer had to be redeployed if there were changes to the business logic and / or data access. It allowed development on the presentation tier and the business logic / data access tier to proceed independently and concurrently.

Finally, I decided to move the business logic from the enterprise application to an enterprise services bus (ESB).


* The ESB was JBoss SOA Platform (link).

This architecture allowed the business logic to be reused by different enterprise services. The business logic was moved to a workflow with jBPM (link). Neither the web application nor the enterprise services had direct access to the workflow. It allowed the enterprise services (data access) to be decorated with business logic. For example, to transform data for persistence or to persist data and start a workflow from within the same transaction.

However, not all data access required business logic (e.g. AJAX). This architecture allowed the ESB to proxy or decorate enterprise services. The devil is in the details.


This architecture is effective. At the time, I considered it elegant. Now, I think it’s inefficient. It’s not clean. It’s not perfect. That’s the nature of technology though. It’s never perfect. Not for long, anyway.

Web Frameworks as Service Frameworks

The current generation of server side web frameworks can be used to implement REST services. As such, server side web frameworks might live on in the form of service frameworks as an alternative to Java EE and JAX-RS.

Side Bar

Why didn’t Spring Framework implement the JAX-RS API? I suspect that Spring Framework suffers from chronic not invented here syndrome (CRONIHS). Like most of us, they were infected by J2EE. However, while most of us were cured by Java EE, Spring Framework looked to VMware for a cure. When VMware could not find a cure, they referred Spring Framework to Pivotal. I hope Pivotal can find a cure for Spring Framework.

I kid. I read a great article the other day on the architecture of BirdWatch. It relied on Play Framework for the back end, and it relied on AngularJS for the front end. It’s a great read (link).

Of course, using a web framework to implement REST services is like using a jackhammer to remove gum off the bottom of your shoe. That being said, I have nothing but respect for Play Framework (and Akka).

Server Side Rendering of Client Side Web Frameworks

What if the rendering of web applications that use client side web frameworks could be performed server side? I’ve been looking at PhantomJS (headless browser – WebKit / link), and I think it has a lot of potential. Perhaps it can be used to support the best of both worlds: the performance of server side web frameworks and the innovation of client side web frameworks. We can have our cake and eat it too.


It can be used for search engine optimization (SEO), yes. However, perhaps it can be used for performance too. PhantomJS may be able to render the HTML faster on the server than the browser on the client. It depends on the infrastructure and the client(s).

I like this architecture because a) it does not require a separate web application for SEO and b) the web application could be reused in a hybrid application running on a mobile phone or tablet since it is created with HTML and JavaScript. Why maintain two code bases for the front end if you can maintain one?

I think there could be value in a PhantomJS Apache HTTP Server module. Perhaps it could be used toggle PhantomJS rendering. If the request is received from a mobile browser then render the HTML with PhantomJS. If the request is received from a desktop browser, then render the HTML on the client. If, in the future, clients can render the HTML faster than servers then disable PhatomJS rendering.

It’s an idea.

I came across two useful articles when I was looking into this:

SEO and JavaScript with PhantomJS server-side rendering (link)
SEO for single page apps (via Backbone.js) (link)

Recommended Reading

Andy Block, Red Hat consultant extraordinaire, published the first post in a series on SwitchYard. He is ruthless in his pursuit of knowledge, and he is relentless in his attack on problems. If I were building a team, I would want him on it. It’s unfortunate, for him, that he is a Buffalo Bills / Sabres fan.

Setting the Stage for a SwitchYard Implementation (link)

, ,

About Shane K Johnson

Technical Marketing Manager, Red Hat Inc.

View all posts by Shane K Johnson

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: