Frontend Architecture Revolutions

Since the infancy of web development, front-end engineering never seemed as promising, and as crucial, as it is in the last few years. The lack of interest from software engineers and the underrated “professionality” of the developers who actually get their hand dirty by moving pixels, are creating a diverse world of design patches, immature frameworks and a lack of conventions that are very common in other fields of software.

Concerning the rapid growth of the web, something has to change. We demand better client applications, a more sophisticated-yet convenient UI/UX, scalable frameworks and beautiful layouts. All of those requirements cannot be arranged and developed without some kind of “glue” that will be able to concentrate all of those fields into a “one-stop-shop” that will define how we build and arrange our front-end. We call it front-end architecture.

Our decision to invest on front-end architecture at JFrog is in order to benefit from recent technologies, to better organize the different fields and be able to deliver fast (or almost liquid) UI updates.

What are we trying to achieve?

Technology

One of the first problems of front-end is the numerous amount of technologies that are available to undertake a simple task like building a web application. The picture isn’t getting much clearer if you talk about choosing the right technology and tools for building a large, rich-in-features front-end application.

What is the right decision? Newer, yet less mature tools, or well tested, yet soon-obsolete ones?
We found that the answer should be based on several critical parameters:

• what we are trying to achieve
• what we are willing to risk
• on what things we are ready to compromise

The average web app strives for complex layouts with great amounts of data, a good user experience in terms of usage-simplicity and latency. We seek to minimize the risk and use well- tested and mature technologies, and for this We are willing to eschew from the novelty of brand-new, yet half-baked technologies.

Code conventions

The flexible nature of front end frameworks and languages require that we suggest some code conventions that should help us to standardize the code, and create a basic interface between variety of styles and developers’ preferences. The benefit is trivial while the downside is that you have to teach and maintain the conventions among the developers and different teams.
We are inspired by the best practices of JS framework, and we use them with customized ESLint tool.

Scalability for new features

Nobody wants to build an entirely new architecture for the next two versions. We want to be able to build it once, and solid enough so it will maintain until the end of days. Some scalability aspects may be taken into consideration as expected feature growth, new layouts and complexity that will be added in each version iteration. Core aspects of every good front-end architecture like modular components, templating, routing, state manage, and global style theme should be implemented. Automatic task should be defined to support every day duties like builds, testing and other common tasks.

Rebuild all while keep selling

Nobody has the privilege to bring an entire business to a halt and go into maintenance mode for several months. We came up with architecture that can support all current features in addition to brand-new different-technology-and-style features.

Legacy, legacy, legacy

We have a live application that already includes a vast number of features, what should we do? should we migrate them into the new architecture and “contaminate” it? or perhaps rewrite them in cost of time and risk for the overall profitability of the new architecture project?

We have decided to “isolate” the old features from the new features so they can live happily together in one app. We have built the main app on top of the new architecture, but it’s support legacy features that live in an isolated wrapper component that is managed by our state manager and the router.

Every company has this legacy code that is somehow working and there is no need of immediate refactoring. Usually, on a daily basis, this legacy code does no harm, but this can be a thorn in our side when it comes to architecture redesign. Our goal is to treat the legacy with utmost respect but also to minimize the amount of legacy that will be merged into the new architecture.

Fence the risk

When we talk about refactoring and especially architectural rewriting, the most “dangerous” risk is the inability to finish what we have started. We might invest a huge amount of time in planning and implementing the new architecture, but we end up with a half-baked, rickety and fragile infrastructure.

It’s very important to know what you're doing, and by that I suggest that you plan your architecture well before you start to implement it. You’ve got solid knowledge on each type of technology you are using and preferably you did this kind of work before, even if it wasn't necessarily on the same scale.

All about people

Managers, timing and luck

As we saw along the way, there are three factors that are crucial for driving the architecture forward:
First, the managers have to acknowledge the extreme necessity of the new infrastructure. Hence to allocate the needed resources, time and engineers.

Second, when is it the right moment to build/rewrite the infrastructure? It depends on the business cycle and the amount of resources that’s available for the task.

Last but not least, the most unclean and non-scientific point is luck. You need it. There is a vast number of variables that you’re unable to control, or worse, predict, mainly on the human factor.

Convince the convinced

Somehow everybody is convinced about the necessity of change, the new infra or the recent technology that is needed to be involved, but yet, nobody is willing to pay for it- why?
Possible reasons can be a personal difficulty to breach the comfort zone or fear of the unknown, but maybe one’s personal interests disconcert his priorities, and are in need of resolution in order to proceed to the next step.

Upgrade professionality

I tend to think that technical success is all about people. We are not depending on a single piece of technology to solve all our problems, and there are many times in which we need to improvise, manipulate and reengineer in order to solve some technical challenges. The bottom line is that more power and trust should be granted to the minds behind the keyboard rather then keyboard itself.

Conclusion

Infrastructure rebuild is possible! Proper design should be done, and the right people should be engaged, the requirements have to be approved and supported by the managers, but despite it all, it is possible.

Once you have executed your first “infrastructure revolution”, the next one won’t necessarily be easier, but you’ll be more familiar with the relevant forces and with the proper condition, and with the knowledge of when and how you should implement new technologies, for every infrastructure and business differ from each other.