In this article, I cover ten relatively recent software architecture trends that focus mostly on business oriented frontend development. The first trend actually applies not only to frontend development but also to the development of backend software too.
In the rest of this article, I am going to be identifying a lot of open source software which is what the application developer is working with. The trend is that, in the upper environments (such as integration, user acceptance testing, or production), you go with the enterprise upsell variant instead. Typically, the upsell technology can be available in the vendor’s own separate cloud or as an addon in the most popular public cloud vendor’s respective marketplace offerings. Why not use the enterprise version in the lower environments too? Would that not be better in terms of dev/prod parity? Many enterprise upsell offerings are not yet designed for lower environments, especially if they are cloud native. Deving on the enterprise version increases the risk of vendor lock-in as the developers inadvertently start using their proprietary extensions. Vendors that have done well in offering enterprise friendly versions of frontend focused open source frameworks include Kong, Vercel, and Apollo.
With the ubiquity of smartphones, many companies have chosen a mobile first strategy for application development. There are two major platforms, Android and iOS. For a long time, that meant staffing up on two fairly different skill sets for native mobile app development. It is rare to find a developer who has deep knowledge of both Swift (for iOS) and Kotlin (for Android). Recent advancements in cross platform frameworks, such as react native (the new architecture with the fabric renderer and JSI) and flutter, have made cross platform development a viable alternative for many companies that offer business apps that are not designed to be immersive games. With cross platform development, you need to have only one skill set which is similar to web application development. For the most part, you have only one code base for mobile which means developing each feature just once (not including web). You still have to build separately for each platform and go through Google’s and Apple’s workflows to publish to their respective app stores. In general, cross platform development entails much lower staffing and training costs.
Products tend to increase in size over time in order to increase market share by offering more features and capabilities for more value. If your company develops a mobile app, a wep based SPA (single page application), or both, then you end up with a large number of people working on the same monolithic frontend applications. This can result in high ceremony releases which increase operation and maintenance costs, undermine confidence, and decrease feature velocity. A growing trend is to refactor the monolithic frontend applications into MFEs (or micro frontends) with several reusable components that are maintained by separate smaller teams and released separately yet appear to be part of one big application. In the early days of MFEs, iframes and server side includes were the most notable ways of accomplishing this. More recently, companies are adopting an approach known as module federation from a technology known as webpack. This is for web SPAs but a similar technology called repack does the same thing for react native apps. Another approach is to use a web browser technology known as web components or custom HTML elements. Both react and angular support web components. If you want to create web components that do not depend on yet work well within react or angular, then consider using stencil which is a compiler for building web components from high-level code. MFEs promote component level ownership with team autonomy which tries to minimize coupling yet also tries to minimize duplicity. Those two goals conflict with each other and current trends don’t really address that directly. Pay attention to the level of granularity with these components. The story of MFEs has not been completely written yet.
With web SPAs and mobile apps, the frontend runs on the user’s hardware and makes API calls to the backend where typically the data resides. Those calls need to be hardened in order for the data to be secured against inappropriate or unauthorized access. This is the trend for authn (authentication) and authz (authorization). With authn, the requester is properly identified then checked if that user has sufficient privileges to make this request with authz. The oauth2 standard defines the mechanisms for how to do that and OIDC defines a protocol where all of the different apps use the same SSO (single sign on) app to collect the credentials or other MFA (multi factor authentication) mechanisms used to authn the user. The oauth2 standard is over a decade old but the implementation details have a lot of impact on frontend development to this day.
API calls from the Internet eventually get routed to a specialized service known as a gateway which validates each request based on the accompanying authentication token. Most cloud vendors provide their own offering for this or you can use the open source kong API gateway. Other related OSS of note are keycloak and supertokens. An API gateway can also address other cross cutting concerns such as logging, monitoring, and rate limiting.
Modern frontend development leverages lots of open source components that are freely available in various public registries and repositories. Companies tend to host their own private repositories that mirror the public OSS repositories but also run code scanning tools that look for security vulnerabilities. Most companies use JFrog Artifactory with Xray for this purpose. You need a package manager to download all of the components that your project depends on, and include almost everything in the artifact that eventually gets uploaded to an app store or downloaded to a web browser. For web SPAs and react native mobile apps, the most popular package managers are npm, npx, and yarn. These tools also get used to automate other developer tasks such as code quality and format checkers, test automation, versioning, and building docker images.
If you are using micro frontends, federated GQL, or BfFs, then you might be interested in adopting a monorepo approach. In contrast, a normal repo is maintained by a single team and holds the code for building a single deployable artifact (more or less). With micro frontends, you have multiple separately deployable artifacts maintained by different teams with different release schedules but run in the same web SPA. That makes these components tightly coupled which means that often changes to one prompts similar changes to the others. With a BfF, the backend service is tightly coupled with the frontend app. All of the cross team dependencies can cause a lot of developer pain that is somewhat mitigated by a monorepo which holds all of the code for tightly coupled yet separately deployable artifacts from different teams. The build pipeline for the monorepo makes sure that all impacted systems are tested before any changes get deployed to production. For frontend development focused monorepos, the two most popular tools are nx and lerna. Bazel is a monorepo tool that is more focused on backend development but it is very extensible and recent extensions accommodate the needs of frontend teams.
Which brings me to the next architecture trend which includes, but is not limited to, frontend architectures. You may have heard of it as CI/CD because continuous integration is easier to accomplish than continuous deployment. Though not exactly new, I mention this trend here because there is not much value to monorepos without CI/CD. I will skip past the wide variety of online marketecture devoted to this subject and just stick with the nuts-and-bolts specifics of the developer experience itself. In addition to the code that runs when the service runs, developers must also write code that tests it. This can be in the form of unit tests (where the XHR calls are mocked) and integration tests (that build and deploy the app with the changes in it then procedurally emulates a user testing that app). For web SPAs, the unit tests typically use jasmine, jest, or mocha and integration tests typically use selenium or cypress. The react native stack provides its own testing frameworks for unit testing (jest) and integration testing (test renderer). Every time a commit is pushed to a feature branch, this test automation gets run. If the tests fail, then the feature branch cannot be merged to the main branch. The unit tests run first because they are quicker. The integration tests get run only once all the unit tests have passed. When a feature branch gets merged to the main branch, then a new production intended release gets built and deployed. There are variations of this workflow which may optionally run more extensive test suites such as load tests or deploy to various other upper environments too. In the old days, the mechanism for doing all of this was included as a pipeline configuration that gets run by an open source tool called Jenkins. Many developer shops are migrating from Jenkins to GitHub Actions as the primary means of enforcing CI/CD.
From cross platform to GQL federation to micro frontends, these ten trends tell the story of what modern business focused frontend development is currently struggling with. There is a proliferation of everything and the logistics issues that come with this kind of abundance can be overwhelming. The role of the architect is to manage, or at least obscure, the unintended complexity that comes with the territory. These trends document popular attempts to mitigate these issues circa 2023.