What you need to know about the new web architecture.

The traditional 3-tier architecture is dead, or at least its dying quickly. In a traditional 3-tier web architecture the tiers were defined as:

  1. Client: HTML, CSS and JavaScript
  2. Server: A server-side framework in Java, Python, Ruby, PHP, Node.js/JavaScript, etc.
  3. Database: A relational database including stored procedures inside the database

Each tier had a specific job to do:
Client: render the UI
Server: business logic (controller) plus generate updates to the UI (view) based on queries run against the database (model)
Database: data access and storage

So what’s changing? Literally, everything. Every layer of the stack is undergoing a massive change that necessitates a change to the architecture.

Client to UI/UX

TL;DR: The client-layer has evolved from static HTML to advanced, thick clients composed of JavaScript. These new JavaScript apps require a UI/UX API to provide a portion of their functionality. Further, mobile platforms often share the same UI/UX API.

The web client has evolved from HTML, CSS, and JavaScript to JavaScript, CSS, and HTML (where order indicates the importance of the code in delivering a high-quality user experience).

JavaScript heavy clients have become the norm and are table stakes for today’s modern web apps. The emergence of JavaScript in thick web clients (aka Single Page Applications, or SPAs) has given rise to a larger number of advanced UI JavaScript developers who must deliver increasingly advanced functionality in their apps. As a result, modern apps demand more from UI/UX developers and this has driven the need for UI/UX engineers to have control of their own server-side API.

Node.js has emerged as the go-to solution for UI/UX server-side API development, although other scripting languages such as Python and Ruby remain popular choices. Essentially, a Node.js API (or equivalent) is a thin API layer that represents the Model portion of the older, monolithic server-side frameworks.

Further, mobile development for iOS and Android require a UI/UX API. Consolidating this new API requirement within the UI/UX team allows all customer facing application development to move at a faster pace.

The last big driver that necessitates the creation of a UI/UX API is the fact that the UI/UX API calls a multitude of other internal APIs (for various platform services or data services) and/or external APIs. The UI/UX API tier helps to consolidate these various API calls into a single API endpoint that can be called from JavaScript, Objective C/Swift, or Java

Server to Services

TL;DR: The older server-side MVC monoliths have been broken apart into specialized functions. The Model layer has been pushed down into Data Services, The View layer has been pushed up into the UI/UX team, and the Controller is now an entire Services API layer that provides common functionality that is used by multiple apps.

The traditional server-tier has been broken apart into specialized functions. Traditional server-side frameworks consisted of an MVC architecture (Model, View, Controller). These older applications were monolithic code bases that did everything from querying the data layer, running business logic to rendering UI components.

As discussed above, the View portion of server-side MVC has been taken over by the new UI/UX API server.

The traditional MVC server-side frameworks have given way to a more specialized business logic layer, which consists of APIs capable of handling various service-oriented functions. The new Services APIs consist of common Platform Services plus reusable app Services APIs.

The Model layer, or server-side data access layer, has been pushed into a new layer known as data services. Data Services is the newly evolved data team. We’ll discuss the data layer more below.

While it may appear that the server tier has been reduced in scope, the reality is that the Services API layer is the core infrastructure team. Neither the UI/UX layer nor the Data Services layer would be able to develop functionality as quickly as they do without the platform and shared services delivered via the Services API tier.

Database to Data Services

TL;DR: Data storage and query is undergoing a revolution.

Much as the client layer has undergone an explosion of capability, the data layer now consists of a myriad of technologies.

Live was easy for the data team when relational databases were the only option. RDBMS’ provide a fully integrated data environment, complete with the SQL query language, an integrated query engine, stored procedures, logical abstractions and physical storage.

However, the modern data layer consists of a multitude of specialized data components that often separate the query language, the query engine, logical abstractions and physical storage.

Let’s use Cassandra as a quick example. In Cassandra, data engineers write queries using CQL. However, to actually run CQL the data engineer must embed the CQL in Java, Python or another supported language. So, now the data engineer requires an execution environment for their query code and they must give access to the query layer to the Services team and the UI/UX team. The obvious solution is for the Data Services team is to run their own Data Services API layer, which is exactly what has happened. Contrast this with an RDBMS where all a stored procedure is embedded inside the database and the API is the stored proc’s function signature.

Summary

The traditional 3-tier architecture of client, server and database are being replaced by new tiers that more closely align with modern applications:
– UI/UX
– Services
– Data Services.

The UI/UX layer now contains a full stack of its own including rich, thick clients written in JavaScript plus it’s own server-side API.

The Services layer is now more specialized as the view layer has been pushed to UI/UX and the model layer has been pushed to Data Services. This enables the Services layer to focus on what it does best, which is write advanced business logic and provide platform services that are common across multiple apps.

Data Services, which was previously confined to relational databases, now runs multiple data storage technologies, just one of which is a relational database. Data Services now runs its own API layer as well.

These changes align well with modern application development and help accelerate development cycles. UI/UX can deliver client functionality faster by leveraging the core infrastructure provided by the Services team and owns it’s own server-side API to quickly integrate the data provided by the Data Services team.

Debug a Play Framework 2.0 application with Eclipse

Introduction

Debugging a Play Framework 2.0 application with Eclipse is exceptionally easy to setup. Importantly, using the debugger is integral to developing high quality, complex applications as it provides an easy way to step into your code.

YouTube Version

I have created a YouTube video that shows the steps below. You can watch the YouTube video at:

How to attach the Eclipse debugger to a Play Framework 2.0 application (YouTube)

Note: Change the playback quality to 720p with a large window for the best display.

Configure Play

Note: Prototyper is the name of a project that I use for prototyping code. Replace Prototyper with the name of the project that you want to debug.

Open a command prompt (Linux) or PowerShell (Windows), then enter the following
commands:

cd Prototyper
play clean compile
play debug run

Configure Eclipse

  • Open Eclipse.
  • Select the project (ex. Prototyper) in Navigator in the left pane.
  • Select the Run menu, click Debug Configurations…
  • In the Debug Configurations dialog box, double-click on Remote Java Application in the left pane.
  • In the right pane, a new remote Java application configuration will be created for you. Change the Port to 9999.
  • Click Apply.
  • Click Debug.
  • Add a breakpoint in your Java code by pressing Ctrl + Shift + B.
  • Open a web browser to http://localhost:9000 and navigate to the page where the breakpoint will be activated.

Install express for node.js on Windows 7

Getting express working on Windows 7 did not work exactly as shown in the vast majority of tutorials/blogs that I found.

While simple, it requires an additional step or two.

Before we start, the following are the current versions of node and npm that I’m using on Windows 7:

node.exe -v
v0.6.10

npm -v
1.1.0-3

Open PowerShell, then type:

npm install express

Unfortunately, this installs express in:

C:\Users\Akbar\node_modules

If you try to start the node.js server with require(‘express’), node will be unable to find express.

To correct for this issue, do the following:

Open Windows Explorer to (replace Akbar with your user name): C:\Users\Akbar

Copy the node_modules folder.

Open the folder that contains your node app, such as: C:\my_node_app

Paste the node_modules folder.

That’s it. run the node server and everything should work fine.

node.exe .\app.js

A consistent pattern for CSS element positioning

I spend a lot of time switching between different languages and each has a slightly different pattern for element positioning. This often creates the need to pointlessly look up the rotation pattern for each language, which is no doubt a waste of time. To overcome this, I find that using the default pattern for a language consistently is key.

For example, CSS has a different pattern then XAML. However, by reusing CSS’ default pattern it makes our code easier to quickly scan and eliminates needless Google searches (sorry Google).

In CSS, the generic pattern is:

  1. top
  2. right
  3. bottom
  4. left

For example, if I set the padding on an element, then I can control the padding for each of the 4 items above as:

padding: 1px 2px 3px 4px;

That is:

  1. top = 1px
  2. right = 2px
  3. bottom = 3px
  4. left = 4px

So, when define the margin edge offset for positioned boxes, it is beneficial to follow this same pattern.

For example, if we have a positioned box such as <div class=”my_class”>, then we’ll follow CSS’ default pattern as follows:

<div class=”my_class>

Then in CSS:

.my_class {
    position: absolute;
    top: 0;
    right: 0;
    left: 0;
    bottom: 0;
}

As can be seen above, we specified the 4 margin edge offsets in the same order that CSS uses by default.

The end goal is to improve readability and to maintain consistency in how and where we specify our CSS. In a large web application, this consistency makes it easy to maintain our CSS by ensuring that we can quickly find a property without having to read every line in detail.