Under the Hood: Life as a Frontend Developer at O’Reilly
When I’m spending time with other developers—either at meetups or catching up with old friends—one of the first questions I ask is, “What stack are you working with?” Technology changes fast, so I’m always excited to learn what my colleagues are using. I’ll admit though, it’s just not as fun to hear about maintaining a legacy framework or application—another jQuery or Drupal application in the world—over something new and state-of-the-art! Sometimes, at that point in the conversation, I can’t help but put on my bragging hat and excitedly talk about what we work on at O’Reilly and how we structure our services from a frontend perspective.
If you’ve ever wondered how our e-learning site is structured under the hood, this article is for you.
React-Redux
If you haven’t guessed (or viewed our source), our frontend framework of choice is React-Redux. You’ve probably heard about this JavaScript-based, reusable UI library, but if you haven’t you should listen now. React makes your websites lightning fast and code easily reusable. Additionally, it leverages the ability to reuse components throughout your codebase. This keeps single page applications DRY while keeping development efficient.
The use case for React is straightforward: creating reusable components makes dissemination among teams simple; the end user experience is improved with superior rendering times; accessibility improvements are spread across the entire site; and as a developer, the tools and community behind React are nothing short of impressive.
We’ve been implementing React within our systems since 2015, and while there are still some services on our platform which use vanilla JS and pure HTML and CSS, the majority have been migrated into bite-sized React libraries. And, if you’re worried about testing—and you should be—all of our code written in React is deployed with 100% unit test coverage supported by Jest and Enzyme.
UI Library
At O’Reilly, we use a user interface component design system. Businesses such as AirBnb, Shopify, Pinterest, Uber, and many more have all adopted the methodology—and for good reason. Consistent component use across our platform helps users navigate and interact with our site, while providing a sense of predictability.
All of our frontend engineers look to our internal design system for the base components and layouts that make up our website. Uniform styles and reusable components eliminate the need to create responsive buttons by hand or look up hex codes.
Like many other companies, the origin of our internal system developed from a static style guide, and progressed into a system that can be easily imported. Designers are required to use the components of the system when mocking up new designs. This eliminates a large amount of ambiguity during the hand-off of designs between the developer and the designer, and makes the development process much simpler. For portions of our website that were built without our internal components, migrations to the new system are in place to adopt it.
We also have a dedicated frontend architecture team that continuously releases updates to our internal UI library. In the spirit of O’Reilly, they also welcome feedback, contribution, and feature requests from other teams. Our library is heavily documented and utilizes storybook instances which provide examples of deployed components for inspection. New releases are shared on a close to weekly basis, and are updated in streamlined microservice boilerplate.
Hey, speaking of microservices…
Easily Deployable Microservices
At O’Reilly, we strongly believe in the importance of decoupled microservices and the reliability/extensibility that gives our code base. As a new hire, one of the first things we worked on as a part of the RAMP team was deploying a simple “hello world” app with our pre-defined front- and back end boilerplate application. From start to finish, a new full-stack microservice could be deployed to QA in less than an hour, eliminating a lot of overhead in regards to webpack config, internal authentication, and continuous integration.
And, our frontend microservices come bundled with our in-house UI library, React/Redux, and webpack configuration ready to go!
As someone newer to engineering, this packaging has been a tremendous timesaver for me. In addition to all of the above, we have a back-end architecture team that supports, updates, and maintains our boilerplate application—much in the same way we have a frontend architecture team to support our UI library.
Interested in learning more about the benefits of microservice architecture? Be sure to sign up for Microservice Fundamentals hosted on October 16th or check out our Scaling Microservices Learning Path.
In short, working with microservices has made my quality of life as an engineer improve drastically. Our environment provides me the opportunity to really be able to focus on doing what I love—building things. In contrast, configuration and standardizations in the absence of microservices can become repetitive and time consuming. Not to mention- if cross team contribution is involved, the process of understanding how each application is structured becomes a pain point prior to contribution. I’m extremely excited and proud to be a part of a team that invests in new technology and empowers its employees to utilize it.
After learning more about the inner workings of our frontend development practices and codebase, what questions do you have for us? We’d love to hear if you have similar (or different!) environments, and what kinds of tools have been successful in your workplace!
