Full Stack Development with JHipster,

Chapter 1. Introduction to Modern Web Application Development

According to the Stack Overflow developer survey 2017 (https://insights.stackoverflow.com/survey/2017#developer-profile-specific-developer-types), full-stack web developer is the most popular developer title. The software industry defines a full-stack developer as someone who can work on different areas of an application stack. The term stack refers to different components and tools that make up an application.

In terms of web application development, the stack can be broadly classified into two areas—frontend and backendstack or client-side and server-side stack. Frontend generally refers to the part that is responsible for rendering the user interface, and backend refers to the part that is responsible for the business logic, database interactions, user authentication, server configuration, and so on. A full-stack Java web application developer is expected to work on both frontend and backend technologies, ranging from writing HTML/JavaScript for the user interface to writing Java class files for business logic and SQL queries for database operations as required.

With an ever-evolving software architecture landscape, the scope of technologies that a full-stack web developer is expected to work has increased tremendously. It is no longer enough that we can write HTML and JavaScript to build a user interface, we are expected to know client-side frameworks such as Angular, React, VueJS, and so on. It is also not enough that we are proficient in enterprise Java and SQL, we are expected to know server-side frameworks such as Spring, Hibernate, Play, and so on.

In this chapter, we will introduce the following topics:

Modern full-stack web development
Web architecture patterns
Choosing the right pattern

Modern full-stack web development

If we were to even begin discussing the life of a full-stack developer, it would be worthy of a whole book by itself – so let's leave that for another day.

Let's look at a user story about a full-stack Java web application and see what is involved.

Let's use an example of developing a user management module for a typical Java web application. Let's assume that you would be writing unit test cases for the all the code hence we won't detail them out here:

You would start by designing the architecture for the feature. You would decide on the plugins and frameworks to use, patterns to follow, and so on.
You will be modeling the domain model for the feature depending on the database technology used.
Then, you would create server-side code and database queries to persist and fetch data from the database.
Once the data is ready you would implement server-side code for any business logic.
Then, you would implement an API that can be used to provide data for the presentation over an HTTP connection.
You would write integration tests for the API.
Now, since the backend is ready, you would start writing frontend code in JavaScript or a similar technology.
You would write client-side services to fetch data from the backend API.
You would write client-side components to display the data on a web page.
You would build the page and style it as per the design provided.
You would write automated end to end tests for the web page.
It is not done yet. Once you have tested everything works locally you would create pull requests or check-in the code to the version control system used.
You would wait for the continuous integration process to verify everything, and fix anything that is broken.
Once everything is green and the code is accepted, typically you would start the deployment of this feature to a staging or acceptance environment, either on-premises or to a cloud provider. If it is the latter you would be expected to be familiar with the cloud technologies used as well. You would also be upgrading the database schema as necessary and writing migration scripts when required.
Once the feature is accepted you might be responsible for deploying it into the production environment in a similar way, and troubleshoot issues where necessary. In some teams, you might swap the steps with other team members so that you would be deploying a feature developed by your co-worker while s/he deploys yours.
You might also be responsible, along with your co-workers, to make sure the production environment is up and running including the database, virtual machines, and so on.

As you can see it is no easy task. The range of responsibilities spawns across making stylesheet updates on the client side to running database migration scripts on a virtual machine in the production cloud service. If you are not familiar enough, this would be a herculean task and you would soon be lost in the vast ocean of frameworks, technologies, and design patterns out there.

Full stack development is not for the faint-hearted. It takes a lot of time and effort in keeping yourself up to date with various technologies and patterns in multiple disciplines of software development. Following are some of the common problems you might face as a full-stack Java developer:

Client-side development is not just about writing plain HTML and JavaScript anymore. It is becoming as complex as server-side development with build tools, transpilers, frameworks, and patterns.
There is a new framework almost every week in the JavaScript world and if you are coming from a Java background it could be very overwhelming for you.
Container technologies such as Docker revolutionalized the software industry but they also introduced a lot of new stuff to learn and keep track of, such as orchestration tools, container management tools, and so on.
Cloud services are growing day by day. To stay on track you would have to familiarize yourself with their API and related orchestration tools.
Java server-side technologies have also undergone a major shift in recent times with the introduction of JVM languages such as Scala, Groovy, Kotlin, and so on, forcing you to keep yourself up to date with them. On the other side, server-side frameworks are becoming more feature rich and hence more complex.

The most important thing of all is the pain of making sure all of these work together well when required. It will need a lot of configuration, some glue code, and endless cups of coffee.

Note

Transpilers are source-to-source compilers. Whereas a traditional compiler compiles from source to binary, a transpiler compiles from one type of source code to another type of source code. TypeScript and CoffeeScript are excellent examples of this, both compile down to JavaScript.

It's very easy to get lost here and this is where technologies such as JHipster and Spring Boot step in to help. We will see the details in later chapters but in short, they help by providing the wiring between moving parts so that you only need to concentrate on writing business code. JHipster also helps by providing the abstractions to deploy and manage the application to various cloud providers.

Web architecture patterns

The full-stack landscape is further complicated by the different web architecture patterns commonly used these days. The widely used web application architecture patterns today can be broadly classified into two—monolithic architecture and microservice architecture, the latter being the new kid on the block.

Let's take a look at the following in detail:

Monolithic architecture
Microservice architecture

Monolithic web architecture

A monolithic architecture is the most used pattern for web applications due to its simplicity in development and deployment. Though the actual moving parts will differ from application to application, the general pattern remains the same. In general, a monolithic web application may do the following:

It can support different clients such as desktop/mobile browsers and native desktop/mobile applications
It can expose APIs for third-party consumption
It can integrate with other applications over REST/SOAP web services or message queues
It can handle HTTP requests, execute business logic, access a database, and can exchange data with other systems
It can run on web application containers such as Tomcat, JBoss, and so on
It can be scaled vertically by increasing the power of the machines it runs on or scaled horizontally by adding additional instances behind load balancers

Note

REST (Representational State Transfer) relies on a stateless, client-server, cacheable communications protocol. HTTP is the most commonly used protocol for REST. It is a lightweight architectural style in which RESTful HTTP communication is used to transfer data between a client and server or between two systems. SOAP (Simple Object Access Protocol) is a messaging protocol using HTTP and XML. It is widely used in SOAP web services to transfer data between two different systems.

An example of a typical monolithic web application architecture would be as follows:

Let's imagine an online hotel reservation system that takes reservation orders online from customers, verifies the room availability, verifies the payment option, makes the reservation, and notifies the hotel. The application consists of several layers and components including a client-side app, which builds a nice rich user interface, and several other backend components responsible for managing the reservations, verifying payment, notifying customers/hotels, and so on.

The application will be deployed as a single monolithic Web Application Archive (WAR) file that runs on a web application container such as Tomcat and will be scaled horizontally by adding multiple instances behind an Apache web server acting as a loadbalancer. Take a look at the following diagram:

The advantages of a monolithic web application architecture are as detailed here:

Simpler to develop as the technology stack is uniform throughout all layers.
Simpler to test as the entire application is bundled in a single package making it easier to run integration and end-to-end tests.
Simpler and faster to deploy, as you only have one package to worry about.
Simpler to scale as you can multiply the number of instances behind a load balancer to scale out.
Requires a smaller team to maintain the application.
Team members share more or less the same skill set.
The technical stack is simpler and most of the times easier to learn.
Initial development is faster hence making time to market faster.
Requires simpler infrastructure. Even a simple application container or JVM will be sufficient to run the application.

The disadvantages of a monolithic web application architecture are as detailed here:

Components are tightly coupled together resulting in unwanted side effects such as changes to one component causing a regression in another and so on.
Becomes complex and huge over time resulting in slow development turnaround. New features will take more time to develop and refactoring of existing features will be more difficult due to tight coupling.
The entire application needs to be redeployed for any changes.
Is less reliable due to tightly coupled modules. A small issue in a service might break the entire application.
Newer technology adoption is difficult as entire application needs to be migrated. Incremental migration is not possible most of the time. Hence many monolithic applications end up having an outdated technology stack.
Critical services cannot be scaled individually resulting in increased resource usage as the entire application will need to be scaled.
Huge monolith applications will have a higher start-up time and high resource usage in terms of CPU and memory.
Teams will be more interdependent and it will be challenging to scale the teams.

Microservice architecture

The microservice architecture has gained momentum in recent years, and is gaining popularity in web application development due to its modularity and scalability. Microservice architecture can offer almost all the features of a monolith that we saw in the earlier section. Additionally, it offers many more features and flexibility, and hence is often considered a superior choice for complex applications. Unlike the monolithic architecture, it's quite difficult to generalize the microservice architecture as it could vary heavily depending on the use case and implementation. But they do share some common traits and they are, in general, the following:

Microservice components are loosely coupled. Components can be developed, tested, deployed, and scaled independently without disrupting other components.
Components need not be developed using the same technology stack. This means a single component can choose its own technology stack and programming language.
They often utilize advanced features such as service discovery, circuit breaking, load balancing, and so on.
Microservice components are mostly lightweight and they do a specific functionality. For example, an authentication service will only care about authenticating a user into the system.
Often has an extensive monitoring and troubleshooting setup.

An example of a microservice web application architecture would be as follows:

Let's imagine a huge online e-commerce system where customers can go through categories of merchandise, maintain favorites, add items to a shopping cart, make and track orders, and so on. The system has inventory management, customer management, multiple payment modes, order management, and so on. The application consists of several modules and components including a UI gateway application, which builds a nice rich user interface and also handles user authentication and load balancing, and several other backend applications responsible for managing the inventory, verifying payment, and managing orders. It also has performance monitoring and automatic failover for services.

The application will be deployed as multiple executable WAR files in Docker containers hosted by a cloud provider. Take a look at the following diagram:

The advantages of a microservice web application architecture are as detailed here:

Loosely coupled components resulting in better isolation, easier to test and faster to startup.
Faster development turnaround and better time to market. New features can be built faster and existing features can be easily refactored.
Services can be deployed independently making the application more reliable and make patching easier.
Issues, such as a memory leak in one of the services, are isolated and hence will not bring down the entire application.
Technology adoption is easier, components can be independently upgraded in incremental migration making it possible to have a different stack for each component.
More complex and efficient scaling models can be established. Critical services can be scaled more effectively. Infrastructure is used more efficiently.
Individual components will start up faster making it possible to parallelize and improve overall start-up.
Teams will be less dependent on each other. Best suited for agile teams.

The disadvantages of a microservice web application architecture are as detailed here:

More complex in terms of the overall stack as different components might have different technology stacks forcing the team to invest more time in keeping up with them.
Difficult to perform end-to-end tests and integration tests as there are more moving parts in the stack.
The entire application is more complex to deploy as there are complexities with containers and virtualization involved.
Scaling is more efficient but setting upscaling is more complex as it would require advanced features such as service discovery, DNS routing, and so on.
Requires a larger team to maintain the application as there are more components and more technologies involved.
Team members share varying skill sets based on the component they work on, making replacements and knowledge sharing harder.
The technical stack is complex and most of the times harder to learn.
Initial development time will be higher making time to market slower.
Requires a complex infrastructure. Most often will require containers (Docker) and multiple JVM or app containers to run on.

Choosing the right pattern

When starting a new project, it is always difficult to choose an architecture pattern these days. There are so many factors to take into account and it is easy to get confused with all the hype around different patterns and technologies (see Hype Driven Development (https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22)). Following are some general guidelines on when to choose a monolithic web application architecture over a microservice architecture and vice versa.

When to choose a monolithic architecture

The following list can be used as a general guide when choosing a monolithic architecture. This is not a definitive list but gives an idea of when to go with a monolithic architecture over microservices:

When the applicationscope is small and well defined, and you are sure that the application will not grow tremendously in terms of features. For example, a blog, a simple online shopping website, a simple CRUD application, and so on.
When the team size is small, say less than eight people (it's not a hard limit but rather practical).
When the average skill set of the team is either novice or intermediate.
When time to market is critical.
When you do not want to spend too much on infrastructure, monitoring, and so on.
When your user base is rather small and you do not expect them to grow. For example, an enterprise app targeting a specific set of users.

In most practical use cases, a monolithic architecture would suffice. Read on to the next section to see when you should consider a microservice architecture over monolithic.

When to choose a microservice architecture

The following list can be used as a general guide when choosing a microservice architecture. This is not a definitive list but gives an idea of when to go with microservices architecture over a monolith. Please note that unlike choosing a monolithic architecture, the decision here is more complex and may involve cross consideration among many of the following points:

When the applicationscope is large and well defined and you are sure that the application will grow tremendously in terms of features. For example, an online e-commerce store, a social media service, a video streaming service with a large user base, an API provider, and so on.
When the team size is large, there must be enough members to effectively develop individual components independently.
When the average skill set of the team is good and team members are confident about advanced microservice patterns.
When time to market is not critical. The microservice architecture will take more time to get right up front.
When you are ready to spend more on infrastructure, monitoring, and so on, in order to improve the product quality.
When your user base is huge and you expect them to grow. For example, a social media application targeting users all over the world.

Though a monolithic architecture would suffice in most cases, investing up front in a microservice architecture will reap long-term benefits when the application grows huge.