DEV Community: Mario David

Simplicity & Focus Through Server-Driven Web UI Development

Mario David — Fri, 19 Aug 2022 16:48:13 +0000

Being a full-stack developer is a complex undertaking these days. As you might remember, it hasn't always been like this. There are multiple reasons for this evolution. One example is ever-growing responsibilities (think of DevSecOps). Another is specialised tooling for different aspects of the stack getting more and more complicated.

In particular, the UI aspects have increased in complexity over the years. There are various factors motivating it. One of the most important ones is the rise of single-page application frameworks (SPAs). A JavaScript frontend that uses API calls to display data or perform some action requires to build HTTP APIs for all UI-related interactions. For many types of back-office applications those APIs represent accidental complexity.

Jmix, being a full-stack business application framework, offers the server-side development approach with the help of Vaadin. Let's see how it works and why removing the dividing line between frontend and backend helps in a lot of scenarios.

What is server-driven web UI development with Jmix & Vaadin?

Server-driven web UI development generally means that the UI and the server side are closely working together to perform some business functionality. In this architecture, the UI and the backend of a business domain have a high cohesion as they provide a particular business feature together.

Let’s compare this to the SPA approach, where the frontend and the backend have a clear and strong dividing line through an explicit API. The coupling is much lower in this scenario as the two parts only communicate through an explicit contract.

Generally speaking, having low coupling is considered beneficial between independent components. But are the UI and backend actually independent from one another, or do they actually form a single logical component? If this is the case, having a high cohesion is actually desirable, as this is the nature of a single component.

In case of back-office UIs, the frontend and backend functionality are closely aligned. Therefore, the cost of introducing low coupling between the UI and the server side is very high. It brings no additional value but causes harm in terms of efficiency and unnecessary decoupling.

With the server-driven UI the frontend and backend code is often written in the same programming language.

For web applications, this has previously partly been possible for an application that used server-rendered HTML. In the Java world, solutions like JSP or Thymeleaf were using this approach to create the user interface with the help of Java. There are domain-specific languages / APIs, but the language was mostly the same. Still, developers had to learn the basics of the web with HTML & CSS.

With the rise of JavaScript and SPAs in particular, where more and more logic went to the web browser, using the same language was becoming less popular. Yet powerful frameworks emerged that make server-side driven web UIs possible, like Phoenix Liveview, Blazor for C#, or Vaadin in the Java ecosystem.

Conceptually they all follow the same principle: the application developer writes UI logic in their preferred backend languages like Elixir, C#, or Java. The framework performs some translation to make this available in the browser. This way, the developer does not have to think about the frontend and backend as separate components only due to technological restrictions.

How Vaadin works

Vaadin (Vaadin Flow to be more precise) is a set of web components and a Java API. An application developer writes the UI layout arrangement in Java. Vaadin uses this information to create the corresponding UI components in the browser.

When the user interacts with the components (like clicking a button), it creates a call-back to the server that triggers the corresponding Java method declared as an event listener.

The framework takes care of the interaction between the browser and the server, so no explicit API is needed to connect your UI to the backend.

It also keeps track of each user session and the state on the server to perform the corresponding dispatch of the method invocations.

In a strong frontend-backend separation the client code normally performs dedicated API calls via JavaScript to trigger an action on the server-side. As the majority of interactions reside on the client, very few manual API calls are performed. Vaadin, on the other side, transfers the majority of UI interactions to the server.

Let’s look at an interaction example. Jmix Petclinic example contains a calendar view for the visits for a particular month:

There are two buttons to change the month to display. When clicking the button, the following Java code is executed and the UI in the browser is refreshed with the visit data of the previous month:

@UiController("petclinic_Visit.browse")
@Route(value = "visits")
public class VisitBrowse extends StandardLookup<Visit> {
    //...
    @Subscribe("navigatorPrevious")
    protected void onNavigatorPreviousClick(Button.ClickEvent event) {
        calendarNavigators
                .forMode(
                        CalendarScreenAdjustment.of(calendar, calendarNavigator, calendarTitle),
                        datatypeFormatter,
                        calendarMode.getValue()
                )
                .navigate(PREVIOUS, calendarNavigator.getValue());
        loadEvents();
    }
}

The interaction performed by Vaadin is the following:

The JavaScript part of Vaadin (Vaadin Client) handles the button click on the browser and delegates the request to the backend part of the Vaadin component (Vaadin Server). This will lookup the context and the current user session. Afterwards Vaadin dispatches the click event to the Java UI code on the server-side.

The UI code will update the calendar component and refresh the data. This happens by interacting through the Vaadin Java API to update some Vaadin components. The Vaadin Server component will pick up the components to update and transfer the new component state to the Vaadin Client in the browser. This will mirror the requested updates in the browser so that the user can finally see the previous month data.

What Jmix adds to the table

Jmix is a Rapid Application Development framework for building data-centric business applications. One of its cornerstones is Vaadin as a UI rendering engine. Jmix enables declarative creation of the UI layout in XML, which is less verbose than programmatic building of UI in Java, as is done with pure Vaadin. The XML layout can be edited manually or in the visual designer. Jmix Studio is a tool based on IntelliJ IDEA. It provides the described functionality.

Jmix also provides features specifically targeted at enterprise applications, such as large collections of data-aware UI components extending the Vaadin library. One example is a sophisticated filter component allowing end users to construct arbitrary filtering conditions.

Besides, it comes with a set of modules providing optional features: from data access control and audit to reporting and business process management. Many Jmix modules include a user interface, which seamlessly integrates into the resulting full-stack application. And this inherited UI can be easily customised in the application, thanks to Vaadin's server-side programming model and extendable Jmix UI layouts written in XML.

Benefits of server-driven UI development

This approach has a couple of advantages compared to the frontend-backend separation, but it is also only beneficial under particular circumstances.

Reduced complexity

First of all, it removes cognitive load, as the overall solution is simpler from a developer's point of view. No need to think about two ecosystems to program in lets the developer focus more on the value-add of the application you want to produce. Java developers can leverage their existing knowledge for topics like debugging, dependency management, static code analysis tooling, testing approaches, etc.

Abstraction, on the other hand, is always a double-edged sword. It is good as long as there is no need to look under the covers. Therefore, in some scenarios, it is absolutely crucial to have access to the JavaScript ecosystem in its entirety. This is not so easy when using Vaadin compared to a dedicated JavaScript SPA in place.

One additional technical benefit is that there is little code duplication. In Jmix / Vaadin you use the same domain models for your business logic as for your UI. Removing duplication significantly drives down complexity. Validation logic is kept in one place and does not have to be mirrored in the UI code and the backend API code.

Security

From a security point of view, Vaadin’s architecture also has some benefits. It never exposes its internals to the browser and instead only sends to the web browser the exact data that is required to update the UI. This is an inherently more secure development approach compared to the situation where it is up to the developers to transfer the right data for a particular UI interaction. This can lead to too much data exposed to JavaScript by API endpoints.

Full-stack teams

When working in cross-functional teams with a strict frontend-backend separation, it often leads to the situation that the team itself divides on this line, as the different areas need dedicated expertise. Here the architecture drives the sub-team boundaries as commonly known by Conway's Law. In this case, it is an unfortunate development that leads to developers having a harder time thinking about the whole end-to-end business process as they are only responsible for one part.

Full-stack developers can clearly see the implications of modelling something in the data model and what problems/benefits it might bring to the UI parts. Vaadin promotes this model implicitly, as it reduces the entry barrier for backend developers to do frontend-related work.

This also brings another interesting benefit to the table. When having small teams, Single Language Development enables them to still bring the whole application to life. It does not require dedicated frontend developers in the teams.

On the other hand, for a lot of frontend developers, this approach of developing the UI with backend technologies is quite uncommon. Therefore, based on the existing team structure, it can either be a benefit or a drawback.

Limits of Vaadin’s UI approach

The architectural Vaadin approach is not a silver bullet. The fact that every UI session is represented on the server puts a certain memory burden on the backend. This is fine for most business applications, where the number of concurrent users is tens of thousands, not millions. But an application with tens of millions of concurrent users working with UI would require a tremendous amount of memory.

When it comes to Jmix and the focus on business applications, this limitation is not a real problem. But there are applications that have a public customer-facing part in addition to the back office where this huge number of concurrent users could come from. In this case, a hybrid approach with a REST API for the particular use-cases of the public frontend combined with an additional SPA mitigates this limitation.

Salesforce through the Lens of a Java Dev - Part 1

Mario David — Wed, 03 Aug 2022 05:28:00 +0000

This blog post series is about the learnings that I had during working in the domain of Salesforce Development. I will try to put Salesforce into a broader context and compare it to the previous experience - in particular Jmix or CUBA-Platform as it has previously been called.

Lately, I had the chance of learning about the Salesforce technology. The same interest that brought me to Jmix in the first place - the interest in higher-level abstractions - was also the reason I wanted to dig deep into Salesforce.

In this blog post, I want to explain what I learned about a platform that is in some sense on a much higher level, in some sense a high level similar to Jmix. I will also put this into a general context of some different approaches to software development.

In the upcoming blog posts about this topic, I will dig deeper into technical details about specifics in the development/administration of a Salesforce application.

Let's start with a necessary introduction about what the "Concept Salesforce" is and how it sets the scene for technical details.

One remark here is that although this blog post is about this particular software vendor, the majority of statements are also applicable to other similar vendors. Additional disclaimer: I am exposed to the Salesforce platform for about half a year. Therefore, those opinions are probably not 100% accurate and some conclusions might also be heavily influenced by that (little) amount of time & understanding I have about this platform.

That being out of the way - let's get started...

What is this Salesforce

Salesforce (SF) is a lot, this is why it is quite hard to crystallise. So instead of finding the one describing sentence, I will give you a couple of examples:

SF is a Customer Relationship Management System
SF is a Software as a Service Offering
SF is a Platform to build programs on top of
SF is the MS Access of the Web
SF is a lot more

To unfold these statements, let's first go into a little exploration of the history of Salesforce as a company and a technology.

A Brief History on Salesforce

SF started as a CRM system, that is offered for about 20 years in the cloud. It was one of the very first SaaS offerings in the world and it pretty much coined that term.

Salesforce was an invention from a couple of Ex-Oracle employees that wanted to build a competitor to the omnipresent CRM out there back then: Sibel.

SF was revolutionary back then, with this idea of having software not installed and maintained in the enterprise but instead just "consumed" via the web. The payment model has always been (what now is pretty common in SaaS offerings): x $ / User / Month.

For a long time there was a very famous Logo and Marketing Campaign from SF that claimed "no-software", referring to the above-mentioned situation of not having to install & maintain software anymore. Of cfourse, it was still very much software - just not what regular people would associate with the term "software" back then (for the most part).

SF successfully operated in the domain with this multi-tenancy application that was offering CRM in the cloud.

A couple of years of experience in SaaS, a couple of thousand employees and a couple of billion dollars revenue later, SF broadened their offering to a wider range of use cases. SF transitioned towards a platform that was able to offer software for more (related) domains.

Eventually, after this platform (technically) matured enough in terms of runtime quality and abstractions - the platform was opened up for more and more external developers/builders to extend the capabilities of their usage of SF.

Salesforce Today

Fast forward to 2020 - this platform is still a CRM (as well as other software), but the ratio of CRM to Platform has dramatically changed. It has become a complete Platform for "building" more or less general purpose applications.

Besides the enterprises' capabilities to build applications in this runtime, they can also leverage a huge marketplace of off-the-shelf software that are SF applications, but from third-party vendors. This Marketplace goes from simple CRM improvement tools to a complete line of business offerings for domains unrelated to CRM.

The company has grown to a massive size of 30k Employees with a revenue of 10 billion dollars per year.

If you want to read more about the history of SF, there is quite a good book looking into that in much more detail: Behind Cloud.

SF - Conceptually from 10'000 Feet

Let's shift gears here a little bit from this folklore-style history description to the software platform itself. To understand the SF platform from a software developer's perspective, let's step back a little from our understanding of how software is normally created in a "classical" agile software development process.

There are a couple of concepts that are relevant when we want to understand the way how software is built on the SF platform.

Concept 1: Software Development without Code

The headline should actually be "Software Development without Code (and with Code)" - but the other one is a little more controversial and catchy.

What does that even mean: Development without Code? Isn't Development == Code? Is there any difference between those two words?

In fact there is (or at least in the SF world they try to emphasise that to get through their point). Developing or creating software or "creating something that a user can use to achieve a task" is a much broader concept. When thinking about it, I can see various examples that can be categorised into that bucket, but still do not require a person to write source-code (or write even anything at all).

Let's go through a couple of those examples:

Define a calculation with inputs in MS Excel
Create automation of a workflow via Mac OS X Automator application
Configure a webshop via Shopify with PayPal integration
Adjust the validation behavior of your SAP ERP system
Creating a JIRA + Slack integration through Zapier

All of those things are in the area of software development, while they don't require the ability to express intends of how a computer should execute a task at hand via "writing special instructions in a source code file".

Salesforce has embraced this area very heavily. There are various offerings in the SF platform itself that range from "defining the field layout and arrangement of a UI screen" to "process automation that executes by certain environment triggers".

In the SF ecosystem, they market it more as "source code is optional". And in fact this is true to a pretty high degree. They stretched this concept to its logical conclusion so that it is possible to build non-trivial applications & workflows without ever considering yourself as a programmer/developer.

But "optional" also means that source code is possible.

If we put the general distinction between code and non-code in an application created by custom software development into an advanced Venn diagram, the ratio between code and non-code parts would look like this:

Code vs. No-code Ratio in a General Solution

The numbers represent the parts of a solution that are either achieved by configuration or by creating source code. 1-4 can then be described as:

creating a solution only by configuration
creating a solution normally by configuration, code variant is possible
creating a solution normally by code, sometimes configuration is possible
creating a solution only by code

Let's compare that to the domain of applications created in the SF ecosystem.

Code vs. No-code Ratio in a Salesforce Solution

We see a couple of differences there. In general, the size of distinct areas is smaller - in particular the section (4) is much smaller compared to the former picture. THis is not so much because it is not possible to express the same amount in source code compared to a general slution.

But it is because the area (2) + (3) in relativity are much bigger. This means the amount of stuff that can be done by non-code abilities is overall bigger.

There are still parts that are better suited (3) or exclusive (4) to be done by code. But the ratio between (3) + (4) compared to (1) + (2) is much more balanced compare to general solution.

With that observation let's go to the second concept that is worth pointing out:

Concept 2: Democratization of Software Development

Writing source code is a skill that not everyone has. Although it can (and should) probably be brought to a much bigger audience of the overall world population, it will stay comparably low.

That being said, as Software is eating the world, there will, for some foreseeable time, be much more demand for people who are able to create software. But as Software is eating the world, but services is eating software there will be a broader need in skills outside of classical software development.

With offering all those higher-level abstractions and tools for creating software by SF, they basically include all those people into software development, that would otherwise be excluded because they are not willing or able to write source code.

If you e.g. think about the number of business people that are able to work with Excel, define calculated cells via formulas, shape some form of UI through Excel, etc., people of this kind are empowered by Salesforce to participate in the creation of software solutions.

This is a very fundamental underpinning of a lot of efforts done by SF. And although this term "Democratization of Software Development" sounds almost like SF is trying to perform a service to the world, most likely there is also a very strong business reason behind it: one of the main audiences of this SaaS offering from Salesforce is exactly these tech-savvy business people, that previously in their job worked heavily with MS Excel et al.

Speed vs. Flexibility

When it comes to leveraging higher-level abstractions, it boils down to the trade-off between Speed and Flexibility. Back in my very first blog post I drew a diagram that points out this trade-off. Let's take a look at a new variant of that and put Salesforce into the picture:

The diagram shows a pyramid where the vertical area is referring to the speed of development and the horizontal part describes how much flexibility the technology allows a software developer to have.

What can be seen in the diagram is that the lower down the stack the more flexible (potentially) a solution can be.

Something like the Servlet API (referring to a fairly "low level" abstraction in the Java Ecosystem) allows creating a very broad range of applications. A business application, a twitter clone, a brand website, an API backend for a newspaper app, so basically everything these days. But even this low-level abstraction has limitations: it at least requires HTTP as the communication channel, and it also enforces a client-server architecture.

Then there are certain higher-level abstractions, and Jmix is one of them. It already narrows down the main use-cases very much to:

business applications with a client-server architecture

It cuts scope (heavily) and in return gives speed because of default choices and out-of-the-box use-case specific solutions. In Jmix's case this would be something like Access Management, Audit functionality, Reporting, BPM, etc. Do you want to write a business application? - go for it. Do you want to build a Twitter clone? - don't even try with Jmix.

Then you have on the very top of the pyramid something like JIRA. It is a pre-built software that has a very specific business use-case: Ticket Management & Collaboration. This piece of software is probably for the most part not even considered as a software development environment anymore.

But if you think about the configurability and the way you can either configure your desired workflows or even add plugins via code to it, there is still some flexibility in it.

But here (once again), you should neither try to create a twitter clone nor a general-purpose business application. But if you need a solution in the collaboration space with some flexibility, just roll with it.

Where does Salesforce fit now into this picture? Most likely it is somewhere in this wide range between the JIRA example and a Jmix application.

It really depends on how the SF platform is used. The plain usage of the Sales / Services CRM functionality with little adjustments is more on the higher end, where creating a LoB application with custom objects, workflows and a lot of APEX and JavaScript code is more on the lower end of the range.

Digging into this particular topic will be the content of the next blog post, where we will take a closer look at the technical details of SF. Furthermore, I will try to explain the technical differences between a Salesforce application, the Jmix equivalent and a more general Java stack.

Summary

To summarise this conceptual overview blog post: Salesforce started as a CRM SaaS application for businesses and turned into an application development platform where the CRM module is just one example of its usage.

Salesforce it treating configuration as a first-class citizen and makes coding optional for a lot of cases. In the (short term) speed vs. flexibility, it lives in another category than a Jmix application and even more compared to a more general Java application.

It is different from traditional software development in various ways, but there are also a lot of similarities. What the differences and similarities are, we will unfold in the next blog post.