However, no matter which specific frontend technology is chosen, enterprise projects do have more sophisticated frontends than in the past. This comes with new challenges of how to organize the daily development work. Typically the work cycles of the frontend and the backend will vary slightly. Some developers will typically see themselves more on the backend and others more on the frontend side. Even if the team solely consists of full-stack developers, some de-facto roles are likely to emerge over time.
Depending on the used technology it therefore makes sense to separate the frontend into a single project. As said before, as soon as some part of the software is shipped individually or has different life cycles than the rest, it makes sense to create a dedicated project module.
If the frontend technology can be deployed without any backend dependencies other than the HTTP usage, organizing the project is pretty straightforward. The project can be built and deployed on a web server individually and will use one or several backends from the client side. This project then only consists of static resources, such as HTML, JavaScript, or CSS files, which are transferred to the client and executed there. There will be no tight technical dependencies to the used backends, besides the HTTP API.
This aspect clearly has to be communicated well upfront during development, as well as documented on the backend side. Typically, the backend defines HTTP resources that serve required content in JSON format, which can optionally be filtered by query parameters if necessary. The reason behind the JSON format being popular is that JavaScript client code can use the response directly as JavaScript objects without any other transformation required.
If the frontend will be deployed together with the backend as a single artifact the project structure requires more coordination. The artifact contains both layers of technology and compiles and packages both at build time. During development this combination isn't necessarily helpful if the cycles of developing the frontend vary from the backend side. A programmer currently focusing on the frontend side probably doesn't want to build the backend part each and every time. The same is true with the backend technology waiting for potentially slow JavaScript compilation and packaging.
In these cases, it makes sense to split the project into several modules that can be built individually. What has proven itself well is to package the frontend module as an individual module and to introduce it as a dependency of the backend module, which then will package it altogether. By doing this, the frontend module clearly can be built individually, whereas a backend developer can rebuild the backend part as well by using their latest version of the frontend. Therefore, build times are reduced on both sides.
To realize this feature, the Servlet API can deliver static resources that are packed not only in the archive, but also in contained JAR files. Resources that reside under META-INF/resources of a JAR file that is contained in the WAR file, are delivered by the Servlet container, as well. The frontend project contains all its required frontend technology, framework and tools, and builds a separate JAR file.
This enables developers to separate the frontend from the backend project to adapt to different life cycles.
The rest of this book will focus on the backend technology and business use cases that are accessible via machine to machine communication such as web services.