A front-end microservices development approach can enable greater capabilities, once the give-and-take relationship between front-end and back-end services is deciphered. It wasn't long ago that it looked as if the concept of front-end development might become obsolete. Server-side applications did the bulk of the work, and generating a webpage was just another back-end process. This made sense in an environment where a webpage was essentially a GUI for a monolithic server-based application.
In today's microservices-based environment, however, an application can consist of an orchestrated swarm of containers, and the internal/external boundary can become blurred, if not insignificant.
At the same time, there has been a trend toward moving dynamic elements of the UI to the client side, giving the front end greater importance and turning it into a set of services within the overall framework of the application.
New architecture requires new strategies
What does this mean for front-end development? And are front-end microservices a viable architecture strategy, or is it better to stick to monolithic architecture for major front-end components?
Fundamentally, the front end needs to communicate with the back-end services, and to do that, it needs to know how to find those services. This is usually a fairly simple task with a monolithic back-end application; it might only need a single URL.
In the case of a microservices architecture back end, however, the job of locating and communicating with a specific service is not so straightforward. An application creates and destroys individual container-based instances of a microservice as required. It isn't enough to simply locate the application and request a service. The front end must find an instance each time it needs a microservice, and that instance may not share the same address as its predecessors.
The front end and container orchestration
The solution to this problem is to use tools such as Kubernetes to orchestrate and manage containers and microservices. They typically provide stable proxy addresses, which can represent multiple instances of microservices. The front end requests a microservice by its proxy name, and the orchestration tool does the rest.
In some ways, the front end can continue to handle the back end as if it were still a monolithic app, with the orchestration tool managing services. At the same time, Kubernetes and similar tools provide a framework for managing microservices, but they don't work the same way as a monolithic application. You may need to do more to communicate with a microservice than you would using a monolithic application's API.
A front-end microservices approach?
What about the front end? If the back end is microservices-based, should you break down the front end into microservices as well?
The front end as a mosaic
Extending front-end capabilities
This is where platforms such as React and Polymer come in. These tools provide a flexible and sophisticated framework to support front-end microservices, enabling developers to design a front-end architecture that better reflects the back-end architecture.
It's a new game
The move toward microservices architecture ultimately makes the front-end developer's job easier, by integrating front-end development into the continuous delivery process and by creating a more transparent and manageable relationship between front-end components and their back-end counterparts. Ultimately, microservices architecture enables front-end developers to benefit from greater capabilities in executing front-end tasks and more flexible ways to do them.