DOM manipulation over REST

Is it possible to change the way of thinking of web applications?

Marco Domenico Marino
Quick Code
4 min readNov 4, 2019

--

Photo by Марьян Блан on Unsplash

Intro

Many years ago the trend it was to realize standalone application software , after was started the run to the MVC server web application and today we are attending to the era of the single-page-application.

Is it possible to follow other ways? Or more easily, exists other ways?

We start with an assumption: today the network rate and the power of the servers infrastructure is more increased than 10–15 years ago and about 10 years ago was started the ideas to move all the code and the runtime processing from server to the client (birth of the SPA applications).

But today is still necessary for this approach?

I’m maturing an idea to change the approach of realization of the web applications.

Let’s go!

SPA and Monolithic applications

Today many application are structured like SPA or monolithic:

  • SPA: The SPA (single-page-application) are application realized in Javascript the are executed on the browser of the client and communicate with a REST API that supports the front-end and also manage the access to Database or to the external system
  • Monolithic: The monolithic applications are applications realized in a single big architecture that contains front-end, back-end and access to external systems. Many application of these type are realized in Java or C#

In these architectures, if we try to focus on where and when the DOM manipulation takes place, we can describe two scenarios:

  • Manipulation on the browser: in these scenarios the software executed on browser has all the pieces of the HTML to represent the page or has the logic to create a new piece of HTML. Over the HTTP communication between front-end and back-end transits only the business data.
  • Manipulation on the server: in these scenarios instead, the owner of the creation or the manipulation of the DOM is the application that is executed on the server. Over the HTTP communication between front-end and back-end transits the HTML pages or pieces of pages (that will be combined by Javascript library on the browser) that already contain inside the business data.

Many years ago the network connections were too slow, the CPUs of the desktops or laptops was too small and the power was only into the web servers: the server, that executed the monolithic application, had the thankless task to manipulate the DOM to prepare the HTML code of the web pages and serve the requests of the clients.

After the CPUs of desktop and laptops were fastly increased, but the network connection not was boosted up like CPUs: the trend was to reduce the packet exchanged on the network and move the logic on the client.

But today…

Is it possible for the future to follow new hybrid ways? And what are the benefits?

I’ll try to explain to you my idea.

DOR — DOM Over REST application

The DOR application (DOM Over REST application) will be a new type to think and design the web application.

The idea of the DOR application was born to permit the realization of web application based on component realized and managed on server-side, but assembled and viewed on client-side using a common framework.

These approaches will be so based on five main concepts:

  • Web application: the web application will be unique (a JAR or a WAR) and it will be executed server side. The application will provide the HTML pages to be viewed on the browser.
  • Web Component: the fundamental unit of the web development needs to be the component. The component, like many other existing frameworks, represents the minimal part of a web application and it will be composed by HTML for the structure of the view, CSS for the style and Java for the logic
  • Common Framework: the framework will have the ownership to organize the component on the browser and to manage the same component on the back-and. This framework will need to have a Javascript soul to be executed on the browser and a Java soul to be executed on the server.
  • Server-side: the ownership of the server side will be to provide a set of REST service, one for every Web Component and serve the request to present the portion of the page .
  • Client-side: the client will manage the invocation of the REST services exposes by the back-end.

In the next picture I have tried to represent how the DOR architecture needs to be realized:

DOR architecture and layers

To realize this architecture I have created a Java Spring Boot project and I’m trying to realize the Javascript and the Java framework

Now I have generated a simple page with two nested components to try to present the HTML and the CSS Style.

Conclusion

This idea is in an embryonic state: I’m thinking and working to realize the framework at the same time.

There are many topics that I have in mind to drill down, like:

  • Performance and benefit
  • Managing of POST requests
  • Managing of application state
  • Many others…

I’ll try to drill down one or more topics in the next stories, but every your advice is welcome…

Thank you for your time!

GitHub: an example of DOR application (repository)

--

--

Marco Domenico Marino
Quick Code

Software engineer and Architect @Accenture. Java is to JavaScript as Car is to Carpet…