Prioritizing Architecture Over Framework in Web Development

Hey, everyone. My name is Alexandre Rivet, and welcome to my talk about pricing the architecture over the framework in web development. A bit about me, I'm Canadian. I live in Quebec City, so I'm French. And I am a senior front-end developer at NextApp for nine years now. NextApp is a constant company, so I've seen many projects using different languages, libraries, tools, framework, you name it. Because of that, I had to learn ways to be efficient in my work without focusing too much on specific technologies. And one of the ways to achieve this is by focusing on the architecture. That's why it's my subject today.

From what I've seen in the multiple React projects I've worked on for my clients, a lot of people tend to only think about React and the brand new tools that just came out. However, if you only focus on technologies, you'll end up with the project hard to maintain. Well, maybe not for you, but maybe because you've designed it. But it will be for newcomers on the project. And that's basically my situation for many projects.

So, last year, I asked myself why we had so many difficulties working on STEM that we have not designed ourselves. I started searching online on why the real reason behind it, and I stumbled upon a presentation called How to Read Complex Code. It was a talk given by Filiane Hermann, who is from Amsterdam. I learned recently. She also wrote a book called The Programmer's Brain. And Filiane draws a link between the functioning of our memory and how to help us be better at programming.

To explain my point about the architecture, I'm going to borrow one of her exercises. I'm going to briefly show you symbols. Try to remember as many symbols as possible, enough to be able to draw them. It's going to go very fast. Are you ready? Three, two, one. That was very fast, right? Would you be able to reproduce the whole series? Probably not, and that's normal. People tend to remember about three symbols when I show them. When we see something, the information goes through our short-term memory. There is a very limited amount of information that it can retain at the same time. The latest study suggests that we can retain between two to six units of information at the same time in our short-term memory.

So, despite this, if I display a symbol again, it will be easier for it to remember that. That's because after seeing the information, our brain starts to interpret it. The interpretation is done by our working memory. It analyzes the information and decides what to do with it. If it takes too long, however, the information will be lost in the short-term memory for new information. When you are exhausted after a long day of work coding, most of the time that's because your working memory has been overloaded.

In French, we say that we are out of brain juice. An important thing to say is that the working memory doesn't depend only on the short-term memory. To prove that, we're going to do the same exercise but with a little twist. I'm going to show you a symbol. Try to remember as much as possible in the short amount of time. Ready? Three, two, one. If I ask you to write what you saw, it would be easier, right? That's because we recognize those symbols. They were letters.

That's because our long-term memory supports our working memory in analyzing what we've seen. We have trained our long-term memory all our lives to recognize these letters. The same principle can be applied in programming. If I say public void if else, use state props for react-specific. Those are all concepts that we have learned to recognize quickly because we've seen them many times, and we create long-term memory about them. So, we do not have to ask ourselves, what does it mean? We just know. It makes us read the code faster.

It is not enough to easily find our way around the code and quickly understand what is happening. Even if line by line, we had information to understand it, our short-term memory becomes insufficient. As I said, two to six elements maximum at a time. I'm not sure if it was in the book already, but this is an interesting point in relation to this metric. What are we able why are we able to understand words of more than six letters if our short-term memory is so limited?

We will do one last version of the same exercise. So, still the symbols, try to remember as much as you can. Ready? Three, two, one. Did you get what was written? When I get this talk in front of a crowd, I get the whole audience to say cats love cake at the same time. It's magic. Why was it so easy? Well, because it was the same number of letters at the same exercise, but now what did you manage to remember everything? The solution is quite simple.

Our brain is excellent at grouping or chunking information. Our brain can associate a set of letters, create a unique concept. When you see the letters CAT, you don't think about those three letters. They become one to the concept of a cat because you created long-term memory about those being the animal. Human brains are excellent at pattern matching. Creating association in our long-term memory greatly helps our working memory interpret the information fast.

In order to make great React applications that are easy to work on, we need ways to create useful long-term memories that could help our working memory. Now, how do we do that in React? I'm going to give you a couple of tips. The first one, use component. This is basically the most known trace of the four. It may sound obvious for some, but I've worked on projects where each page was a single component, a single file of two and a half thousand lines of code. So, even after working months into this file, I was still getting lost. So, creating components with names that represent what it really does. It's the same principle as giving names and variables to variables or functions.

And it's more useful to create long-term memory about component names than which line of code contains which time of code contains what you're looking for. The same tips, watch out for too many dependencies. Let's say you have a big application and you've created a lot of components, well, name and all. But you still have issue finding what you're looking for in the codebase. Why is that? One of the reasons I see in many projects is because of external dependency used in the component. Let's say, for example, you want to have a global state in your application. You can use the context API or Redux or Xtend, you name it. It's not important. Those tools allow you to access states in any component you want. In theory, this is a great feature that prevents problems.

In practice, it can be quite dangerous. When requiring a value, it becomes easy to simply add a new selector to the component and done, you have access to value. However, if you repeat this action over and over again, you might get something like this, where most of your component becomes dependent on your global state. They don't get props anymore. They just go to the information themselves. I need to be clear about something. This is not the fault of the library you're using. This is an architecture of law. Given you have an issue related to the global state, how can you tell which one is at fault? And if you're new to your project, good luck finding the issue by yourself.

You'll be here for a while. So, what can we change in our architecture to develop a long-term memory of our code and find issues faster? Well, before the coming of the hooks in React in the old days, there was a pattern developed by the community to separate the logic from the application logic, from the rendering logic. There were two names for it. The component versus container or the DOM component versus smart component. DOM component receives props and renders HTML. That's it. There are no external dependencies, except the props. Smart component are tasked to obtain information, handling state and give data to DOM component as props. They don't do much rendering except feeding information. Smart component are usually at the root of a concept tree. A piece that can be directly independent from the rest of the page, the rest of the app. And normally, by applying this pattern, you will get mostly DOM component in your application and a few smart component.

So, in your tree, you will get fewer dependencies to your global state management, so you will have fewer points of failure in your issue. It's become easier to create long-term memories of the global state as there are less components directly impacted by it. Receiving this information multiple times also create the memory, make the memory more durable. If you want to have long-term memory even more about this, you can even give name to smart component that makes it more obvious that they have this logic. For example, maybe you could use the add a suffix to the name of your components. The desorption is not important as long as it makes it clearer, more obvious.

Third tip for you is to make the APIs independent. In single-page application, one of the most frequent features that I see is the application needs to load content from an API, from a server. There are some libraries that offer you to handle everything that turns around the API call. An example of that is a project I worked on where we decided to use GraphQL because it was a brand-new shiny thing. REST was dead, long live GraphQL. So, we will do the request like so. We will create, we will define a query and use the use query from the library we're using to get the information and have loading state, error state, and so on. In my example here, I use Apollo, but it's not the only one offering this pattern. Relay, Redux Toolkit, and many others do too. That's just for the example. At one point, we found out that the GraphQL was slowing us down more than using a simple REST API for our use case. It wasn't a use case for us.

But, we were kind of stuck there, because our React components were dependent on GraphQL queries. As you can see in our component Pokemon sensors. What should have we done instead? Well, nowadays we tend to create clients who abstract our API works. This gives us more flexibility of how we communicate with the back end. So, for example, for this example, the Pokemon client with the function get Pokemon, and there's my query in it. But, in my component, I can do it the way I want. I could use the use hook to get the information with a suspense. If I want the same functionality as the use query from Apollo, for example, I could use React query from 10 stack, which only handles the management. It's nothing with the API. If I decide that I want to use this API called in a server component, I could simply just call the get Pokemon in the same component, in a React server component. I could also use it in a React native application, because my API is independent from the UI. There are a lot of pieces of code that can be extracted from React components, and this is the first one.

The second one I can give you, this is the last step for today, is the business logic. This logic corresponds to the all the business logic of your product, the kind of logic that you can discuss with a non-programmer. Someone who doesn't know React, well, it's the logic that turns around the business model of your product. For example, let's say you decide to make a shopping website where you have a cart, you can add items to your cart, and you can check out and buy everything. Well, the shopping cart will have logic associated to it. For example, you cannot have minus one item in your cart. That's just not possible. For each item, you can only have a positive quantity. When you open this website, the cart should be initially empty. If the quantity of items changes to zero, I might want to remove the item of the cart. All this logic can be implemented without the UI. This is pure business logic. When the logic could be exactly the same in a single page app, server-side rendering, in an express backend, in a React Native application, then it shouldn't be in a component or a hook. It should be extracted. So, also, by extracting it, you can name all this behavior, and you can even make automated testing easier. What would it look like as code in a component? You could create a simple JavaScript class representing your cart with all these methods that represent how you can manipulate the cart. In this example, you can update the item quantity, you can remove an item, you can count the total amount of items, and we even have a method to create an empty cart. Then, in your component, well, you will have all the UI logic, the state logic of the application.

So, we could create a local state, a state for a cart where the cart is initially empty. We use the method. In the rendering, if we want the total amount of items displayed, we have a method for that. Or, even, if we want to update the item quantity, we use our cart, and we just call the method update item quantity. By doing that, we just create a great separation of concern between UI and business logic. Components architecture, like so, are way simpler to understand, because they focus on what you are meant to do, render UI.

Doing so also helps the code being closer to the way non-programmers talk with you about the application. And, doing so, it creates a better long-term memory, because you don't need to convert what someone is saying to how the code is made. It's closer to the reality. They're closer together.

So, I've given you four tricks to help you be more efficient when developing a React application, so you can create better long-term memories that could help you navigate the code faster. But, if you remember, at the beginning of the talk, I said something about how hard architecturing applications can help your future teammates ramp up fast. Because, in the end, just like Martin Fowler said, any fool can write code that a computer can understand. Great programmers write code that humans can understand. Thank you. If you're interested in what I do, what I say, and want to learn more about the practice that I just told, here's some links about an article on the blog that I wrote. Thank you again.