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.
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 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:
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)