BradleyCorp.com is a beautiful statement of contemporary web design. Two By Four did an amazing job in putting together the concept and design for this “website” – which is really more of a complex Single Page Application (SPA). And just how this website is stunning to look at, under the hood it really holds up to the same level of quality and cleanliness that stands out from the design.
From a dev stand point BradleyCorp.com was designed completely from scratch. Its complexity required us to look at the whole picture and really understand how all the different parts interact with each other before we could even began thinking about a solution. Taking a step back allows you to be creative sometimes and that’s what we did. We designed a whole new architecture for Bradley that checked off all the boxes on their list.
Bradley’s list was no small feat by any means. The most important aspect of the site for Bradley’s dev team was performance and scalability. For the marketing team it was the ability to edit content via a user friendly interface that did not require the help of a programmer. For other departments like their support team for example, lowering the number of calls and emails they get per day would go a long way. But whatever solution we came up with also had to communicate with other apps written in different languages. So as we searched for a platform or CMS that could check off all our boxes we realized that none did. We needed a more sophisticated solution to be able to offer the level of performance and scalability expected by Bradley while staying data agnostic. Again, we had to get creative.
The Architecture
BradleyCorp.com was a big and complicated site to build. The site is massive in content with over 16,000 unique (non-product) urls and thousands of SKUs. The site also has many moving parts that all need to work together efficiently. For example all files have to be stored, and pulled from, a different server than the one the CMS or the frontend run on. This Media Manager allows Bradley to maintain one set of files (images, PDFs, etc) to support their own website plus vendors, distributors and retailers that use the same files to showcase Bradley’s products.
BradleyCorp.com also feeds from multiple data sources. One of course is the CMS that holds the site’s content. But Bradley also has some applications written in Java that perform specific tasks such as helping a customer find where to buy Bradley’s products. Each of these apps is a new data source. The Where To Buy app for example, communicates with Bradley’s retailers database to help the user find the store nearest to them. There are about 6 different Bradley apps that perform different tasks ranging in complexity.
Taking all these nuances into consideration we designed Bradley’s architecture as an ecosystem of apps that work well together and are both data and language agnostic. This means that each app in the ecosystem can be written in a different programming language and store data however they want. For example, one app can use MongoDB to store its data while another app uses MySQL. In order to do this we agree on a standard way of communication within the ecosystem. Kind of like choosing a language that all the apps can speak and communicate in. Its a way for the apps to share information without having to share any of their logic.
Bradley’s ecosystem is broken down into 2 parts: The backend and the frontend. The backend handles all the data logic – pulling from the database. The frontend handles the user interface which is the only thing that users see. When a user takes an action in the frontend like searching for content, the frontend sends a request to the backend with the keyword used in the user’s search, the backend then performs the search and returns the results in JSON format. The frontend is responsible for analyzing the backend’s response and updating the user accordingly.
Going one step further, both the backend and frontend are complex in their own way. In the backend we have mentioned how the CMS and the Media Manager must be synced at all times. But in the frontend things really get interesting! The frontend is literally a network of small apps. There is 5 React apps that make up the whole frontend. What makes them a network is that they all share components and the same set of APIs to function. This lets us be incredibly flexible and scalable with our codebase. We can build a new app for the frontend extremely fast by leveraging any of the components already available. When new features are introduced they are automatically available for all apps. Apps also have a lot of flexibility by using the components “as is” or extending them to do something different. For example, Bradley has two different blogs, The Washfountain and Bim Revit, that load the same header as the main site but each loads a different footer.
Here is a visual breakdown of how the ecosystem looks like:
The Backend
WordPress powers the backend for the new bradleycorp.com site. But it is not your typical WordPress installation. Bradley’s backend is actually composed of three parts: The Content Management System (CMS), the Media Manager, and a group of standalone apps that handle specific business logic, like a tool to help users find the right size valve within Bradley’s thousands of SKUs.
When we first discussed the project with the Bradley team three things stood out from that conversation
- They needed a user friendly CMS so their marketing team could update or create content on the website with ease and without the need to reach out to a developer.
- All files (images, PDFs, etc) had to be stored in Bradley’s own Media Manager. So any CMS that we chose had to be able to sync with Bradley’s Media Manager.
- Any solution provided had to be compatible with a group of apps at the moment built in Java. So we had to be both data and language agnostic with our solution.
The Bradley team was also adamant about the fact that scalability, performance and security were not to be compromised in favor of any of the points previously mentioned. Like I said, this is not your typical WordPress installation!
So how does WordPress fall into place? When designing the right Architecture for Bradley we looked into many different CMSs including WordPress, Magento, Drupal and Magnolia (built in Java). WordPress stood out for a few reasons but most importantly because of their built-in REST API. Using WordPress’ REST API we were able to communicate with Bradley’s Media Manager and all of their apps via HTTP requests sending and receiving JSON data. WordPress acts as the backend’s admin interface, keeping the CMS, Media Manager and all other apps synced, but WordPress is not what loads the front end of the site. When you visit BradleyCorp.com you are actually loading a stand-alone React application that makes individual requests to the backend in order to load different pages. Requests made by the frontend app may go to the WordPress REST API or directly to one of the Bradley Apps.
The Frontend
BradleyCorp.com is Single Page Application (SPA) built in JavaScript using React – A library for building user interfaces built and used by Facebook. In order to provide the performance and scalability that Bradley’s team expects we had to think beyond the standard HTML pages that you would see in a typical website. This is why WordPress, or any CMS out of the box, could not be used as “The Solution” alone. In the typical WordPress installation when a user visits a page on a website the whole page is rendered by the server and then served to the browser. This means the larger the content the longer a page will take to load. That does not sound very efficient or scalable, does it?
In comes React! Using React we are able to take a modular approach on how we load our content. With React each piece of content is its own module and is responsible for its own state and data only, nothing else. For example, when you see a sidebar with widgets like “Most Recent Posts” or “Newsletter Sign Up Form”, each of those widgets is a module. The Newsletter Sign Up Form for example, is responsible for loading the form’s HTML and handling the form’s functionality. This allows you to include the module wherever you want, as many times as you want, but it also means that while the site is loading the server does not have to wait for the form to load so it can continue to load everything else. In a modular approach every module loads individually and quicker most of the time since most modules require very little HTML or data to function. This makes each request that a module makes to the server super quick since there is not too much logic for the server to handle at once.
Code Splitting
To take performance and scalability a step further we utilize code splitting in Bradley’s frontend app. Code splitting allows us to load only the parts of our codebase needed to run the modules being displayed at a given moment. Basically, we do not load the whole app at once, rather we load only the code that the current modules require. When new modules load we load new parts of our codebase needed to run the new module.
SPAs are packaged into one file that loads all at once. This makes the SPA super quick to any user’s input because everything that it requires to run is already loaded. This approach works great for small apps with a small codebase because the app loads pretty quick anyways. But as your app grows so does your codebase and that means that your app’s bundle needs to load a lot of code all at once to run properly. So you load everything, including all the code required for features that the user may never interact with. BradleyCorp.com is a massive application so it would take way too long to load the whole app at once so that the user can begin interacting with it. This is why code splitting is key to the performance that we see in the new site.
Flow
When people talk about scalability they often refer to handling large amounts of traffic and being able to grow the application (codebase) to an unlimited scale. But what exactly does it mean to be “able to grow the codebase”? Well it means that no matter what new feature you add to your application, or what changes you make to update old features, your code will not run into conflicts. In other words your changes will not cause the application to break.
Flow is a type checker for JavaScript. It analyzes data as it travels through your code and alerts you when it spots an issue. This makes it a great tool to scale code. Let’s face it, we are all human and we make mistakes or forget things. And when your application gets too big it is absolutely impossible to remember every nuance of the codebase when making changes. So flow keeps track of the nuances for you and lets you focus on the logic at hand.
SEO
For most clients nowadays SEO is a priority when it comes to their website and Bradley was no exception. But when you build a website in React, you are really building a Single Page Application which means that there is only ONE page for the whole site. So your pages do not have unique urls and for SEO that is a big issue. We fix this by using React Router.
React Router allows us to set unique urls for our different React components. So when the user goes to our /contact-us page we automatically load the contact us component instead of the home component. This way different urls load different content and do not end up in confusing errors for search engine bots.
But we still have one more issue to fix: different pages would have different <head> tags in the DOM. React Helmet allows us to fix that. With React Helmet we can update the <head> of our document dynamically. This lets us update not just the title of our document but also Google Analytics tracking code or events and more.
