Building a Sustainable Codebase with FP

Rate this content
Bookmark

As software engineers we are always trying to be more productive, to deliver better code, and to have faster development feedback. In this talk, we'll explore how functional programming, tests and hexagonal architecture can perform great together in order to support a maintainable codebase for hundreds of engineers and services. Diving deeper on how we can leverage hexagonal architecture with dependency rejection in order to decouple decisions from effects, resulting in a code that is easier to reason, compose and test. The codebase is not the only one that takes advantages from that, but also the developers. It helps everyone feel more comfortable and engaged about maintaining good practices.

20 min
20 Jun, 2022

Video Summary and Transcription

Today's Talk focuses on building sustainable architecture through functional programming, tests, and hexagonal architecture. It emphasizes the importance of maximizing functional programming and immutability to improve code quality and maintainability. The Talk also highlights the significance of tests for accuracy and speed, and discusses the benefits of hexagonal architecture in separating business logic from technical concerns. The concept of isolation and encapsulation in functional programming is explored, along with the advantages of using pure functions. Overall, the Talk provides insights into designing and implementing a sustainable and efficient codebase.

1. Introduction to Sustainable Architecture

Short description:

Today I'm here to talk about how you can build a sustainable architecture. The main topics are functional programming, tests, and hexagonal architecture. Functional programming is about pure functions, but we also need to deal with impure functions and side effects. We need to carefully structure our database to not mess with it.

Hi, folks. Today I'm here to talk about how you can build a sustainable architecture. First, I'm going to present myself. My name is Karolina Pascal Campos. I'm from Brazil. I'm a software engineer that works at Briza. And here you can follow me on my social networks. And I love books, coffee and running. So let's go to the presentation now.

So the main topics that I'm going to talk about today are functional programming, tests and hexagonal architecture. So let's start with functional programming. We know that functional programming is about pure functions, right? So given its inputs, we are always going to return the same output and we're not going to have side effects. So when we talk about side effects, it could be like saving to a database and an email, so anything like that. But it's important to have in mind that we will also need to deal with improved functions because we know that in order to have like a useful code base, we need to have improved functions. So our programs need to have input and output. We want to be able to interact with it. And those interactions always happen in perfunctions. So after we write your database, for example, we're going to change its state. So when we are going to read from the database, after saving to it, the result is going to be different. And how are we going to handle that? So we need to talk about side effects. When we are like functional programmings, we love to talk about the pure things. But we also need to talk about the effects. And that's a really important topic to be discussed, how to deal with them. So we need to be really careful about the impure functions because they change states. So if I run something today, tomorrow the results can be different. So this is the hard part to manage, but we need to manage that. So that's the reason we need to carefully structure our database to not mess with it. So here's an example. Imagine that you have an impure function inside a pure run. So you no longer have a pure function.

2. Maximizing Functional Programming

Short description:

We need to separate what we built. Our goal is to maximize functional programming and minimize impure functions. If a function could be pure and is not, we are doing it wrong. Let's try to refactor this.

This is why we need to be careful about structuring our code. We want to maximize the pure functions we have. So we cannot call an impure function inside a pure run because we have just lost it. So we need to separate what we built. We need the effects from the pure functions. The effects can infect everything. And our goal here is to maximize our functional programming and to minimize and isolate the impure functions, the imperative code. So what we need to have in mind always is that if a function could be pure and is not, we are doing it wrong. So let's try to refactor this.

3. Functional Programming and Immutability

Short description:

Another powerful thing about functional programming is immutability versus mutability. Immutability allows us to observe the state of an object at a certain point in time, while mutability loses the notion of time and blends state and identity. Pure functions and immutability make functions easier to reason and debug, as the output is always the same and changes are represented by new objects. By focusing on data, calculations, and functions, rather than classes and boilerplate code, we can write more clear and efficient code. Tests are important for a sustainable codebase, as they provide confidence and serve as documentation.

Another powerful thing about functional programming is when we talk about immutability versus mutability. Let's start with the image that we have on the left. We have a book with many pages. This book is the identity. When you want to change something in the draw, you just turn the page and draw a new thing in the end. So the act of turning pages represents the state of the draw during time. So if you stop on a page, you can observe the state in a certain point of time.

But if we look now to the right, we have a mutable example where the book is only one page. So if you want to make a change, we need to erase stuff and redraw things. So we have just lost the notion of time here. And state and identity are now blended. So when we talk about immutability here, we have the animation. You know all the steps your draw has been through to get to the end. You know the whole story.

So when talking about pure functions plus immutability, we are going to have functions that are easy to reason and easier to debug. This is what we want. Because with pure functions, you know that given an input, the output is always the same. So it's really easy to reason about it. And also with immutability, you always have new pages when you change something. So you don't need to go deep in the code to understand which function is mutating the page. So we want to be mindful about the things we want, that's pure functions and immutability when developing, so we can seek them. Because this combo is going to give developers a lot of power and speed. Nice.

So when programming is functional, we want to focus on data, calculations, functions and not classes, interfaces and boilerplate code. So the intent of our code is clear, and you can try new things faster. So what we want here is to be as functional as we can to be able to move faster and with confidence. Now let's talk a little bit about tests, because if you want a sustainable codebase, we need tests. So tests are important because they give developers confidence to change or to extend or change our code. So when trying to understand for example a code we didn't write, we can check the test to understand what was expected from that code when it was written. So it's also like documentation.

4. Test Accuracy and Designing for Maintainability

Short description:

If we change code, we need to change tests because otherwise it would get stale. So what we want here is functions that are really granular, so as granular as it is, the more accuracy you can get. Also about speed. The faster we find a test failing, the sooner we can identify the problem and the smaller their impact will be. Here we use contract tests to guarantee the conversation between services is working. So with that, we can have accuracy, speed, and reliability. Now, I'm going to talk about how to design a record. What we want is high maintainability with low tech debt. We need them to be simple and easy to work on.

If we change code, we need to change tests because otherwise it would get stale, but they don't, because it's a live documentation. But how do we know and check if our program is doing what it's expected to do? How can we check the quality of this feedback? And here I'm not going to talk about 100% coverage.

So let's start with accuracy. If your tests fail, can you determine exactly which portion of the code has failed? How long do you take to know where it failed? So what we want here is functions that are really granular, so as granular as it is, the more accuracy you can get. So it's way faster if you have small functions with no dependencies from the outside world, so that remember pure functions.

Also about speed. The faster we find a test failing, the sooner we can identify the problem and the smaller their impact will be. So what we need here is tests that are simple to write and to maintain, and also that are fast to run. If we have a lot of complex code with a lot of dependencies from the outside world, it's going to take a lot for us to maintain these tests. And also we need tests that are reliable. We need to trust the outcome of our tests. If the outcome changes from one execution to another, if we don't change the code, the configs or the dependencies, why do we keep these kind of tests? Because we don't trust them, so it makes no sense to keep them.

Here we are usually talking about end-to-end tests. End-to-end tests are a problem because you don't walk anything, you really save stuff to the database. It's really common for them to fail for obscure reasons, like latency, garbage collection, asynchronous operation. So we need to think in a different way. Here we need to think a little bit larger. We know that unit tests cover the function levels, integration tests cover the flows, and we need to guarantee that the conversation between services is working. So usually we use end-to-end for that, but we can just think a little bit larger and test the conversation between two services at a time, for example. So here we use contract tests.

So every contract test is going to have a provider service and a consumer service, and for each communication between them, we need to define a clear interface called a contract. So now we have like automated tests that are sure that the data generated by the provider can be consumed by the consumer. And if we change anything, the contract is going to break. So it's important here to have in mind, this is not a one-to-one replacement with end-to-end tests, but most of the errors that end-to-end do catch, those tests can also catch them. So with that, we can have accuracy, speed, and reliability. And that's what we want.

So now, I'm going to talk about how to design a record. Because okay, we have the functional programming, we have the test, but how to design the code to leverage this? What we want is high maintainability with low tech debt, because we want the application that are used to give maintenance and have low tech debt. We need them to be simple and easy to work on. And this is hard because maintainability is a long term concept because in the beginning, it's really easy.

5. Hexagon Architecture and Separation of Concerns

Short description:

Your project has just started, and as it grows, maintainability becomes crucial. We initially tried using a simple hexagon architecture, separating the domain model, controller, and IO layers. The IO layer allows impure functions and data mutation, while the domain layer focuses on pure functions. The goal is to separate business logic from technical concerns and test in isolation using mocking and dependency injection. With hexagon architecture, we can isolate and control side effects in the IO layer.

Your project has just started, we have a few lines of code, three people working on it. So it's just a couple of dependencies. But as soon as your team and your code grows, things get harder. And the bug can result in a whole architecture refactoring. So that's the reason you need to think about maintainability since the beginning.

What we are going to say here. So the first attempt we had was try to use hexagon architecture. So here we have just a simple hexagon architecture. The domain model where we have the implementation of our domain. So here we're going to have the pure functions and the mutable data. That's why it's green. After that, we have like the second layer that there's where we have the controller that's responsible for connecting the ports with the adopters in the logic, the domain. So here is all about coordination. But here we already have some functions that are impure, right. And some mutable data. So it's not all of them, but some these whites, yellow. And in the third layer, here is where we have is called the IO or ports. And here we interact is external words. So here we're going to have called for other services, we're going to have calls to the database to third party APIs. So here it's okay to have impure function and data mutation we expect that in the IO layer.

So what we want to take second hexagon architecture is to be able to separate the business logic from the IO. So we want to structure the code in a way that we protect the domain from the technical stuff. So we can define what are the business rules, what are the educational rules and what's the infracode and how do you do it testing this architecture? So we want to test in isolation with mocking steps because we don't want to rely on external database or external APIs. We really want to mock and step things for that. We use dependency injection. Right? So these dependencies here are going to be passed as arguments. So when we run in production, we use the real database and for test, for example, we can use a hard coded file, but what was the first discovery with this architecture? So remember that in hexagon architecture, we have our functions in the boundaries, right? In the IO layer, the ones that generate side effects. So the HTTP request, the emails, the message, everything is there. So it's nice to realize that in this architecture, we can isolate and control the side effects in this layer. So we have the boundaries here, as we can see.

6. Understanding Isolation and Encapsulation

Short description:

Isolation is when all the info a function has from the outside world is passed through arguments. Encapsulation means that the object has a state and the outside world knows nothing about it unless it's made explicitly available to it through getters and setters. Isolated functions are really easy to test and given for free when using functional programming. The minimum expected from a good functional design is to have pure functions. Why is hexagonal architecture in FPP natural? One of the languages that helped to understand that is Haskell, because Haskell is a functional language that expects all functions to be pure.

So let's talk about this concept. What does isolation mean? So isolation is when all the info a function has from the outside world is passed through arguments. So we can come to the conclusion that every peer function is isolated. So a peer function is a subset of isolated functions. Not all isolated functions are pure, but all the peer runs are isolated. And isolation is the dual of encapsulation. So encapsulation means that the object has a state and the outside world knows nothing about it unless it's made explicitly available to it through getters and setters. So isolation means a function knows nothing about the external world unless it's inputted on it. So it's the dual, right. And isolated functions are really easy to test and given for free when using functional programming. But in object-oriented programming, they are a problem because of the encapsulation principle. So when developing with object-oriented code that's going to be tested, we need to find intersection between isolation and encapsulation. And that's really hard because it's way easier to work in a subset than an intersection, right? So it's hard to maintain the balance between isolation and encapsulation when dealing with object-oriented programming. But with functional programming, it's no problem at all. The minimum expected from a good functional design is to have pure functions. And they are a subset of isolated ones. So if you're doing pure, you are doing it isolated, and you get the easiness of the test for free. And we want to have as many pure functions as we can to get all of those benefits, because we know that if you have pure functions that cause an impure run, it would be impure also. So why is hexagonal architecture in FPP natural? So one of the languages that helped to understand that is Haskell, because Haskell is a functional language that expects all functions to be pure. And so when we are imputing Haskell, the compiler helps you in that function, checking if that function is pure or not. Because if you wrote an impure function and forgot to declare its type as IO, it's going to throw you an error. So in order to have as many pure functions as you can, you push the impure function to the boundaries. So the impure functions can call the chain of pure functions, but a pure function never can call an impure, otherwise you get a compiler error. So we are going to have a shell of impure codes. So this is a reminder of hexagonal architecture. So this is why Haskell is a language that helps you discover that because it expects all functions should be pure. And so good functional programming design can be an eSports and adopters. And this is a great discovery. But remember that at the beginning I said that we want to leverage functional programming to its maximum. And as I showed you, we still have controllers with imperative code and side effects.

7. Hexagonal Architecture and Dependency Rejection

Short description:

Why don't we want that? Let me show you an example. I have a functional call called block, and I'm passing a card, a database, and a producer. When I look at this call, I have no idea what the output is. It's harder to compose with imperative code. So let's try another approach. What about using hexagonal architecture with dependency rejection? Now when I call block, I only pass the card and I have a return object with facts data and facts message.

So why don't we want that? Here I'm going to show you an example. Imagine that I have this functional call that's called block. And I'm passing a card, a database, and a producer. So here, when I look at this functional call, I have no idea what's the output. It could be true. And if it's true, what does that mean? OK, let's enter the function trying to understand that. So as you can see, I have the card. I'm doing some logic on it. And then I'm calling the update in the database. And after that, I'm calling the producer card status changes here, right?

So here, I needed to enter the function to understand what it's doing. And I'm not returning anything here. So I have no idea what happens before I enter in the function. It's also harder to compose when I have imperative code. So here, imagine I'm calling block for 10 cards. Imagine that at the third card it failed. So now I have called the debate to update the producer to send messages, but only for three cards. So I cannot just rerun stuff because I would duplicate effects. How would I handle with this composition? So it's hard because I'm just doing the things on the fly. And what we have here is not the permit that we want. We have a permit that we have more integration than unit test because as you can see in my controller, I have those kinds of functions that are calling the debate, that are calling the producer. So this not what we want. Those functions are not pure. The tests are not that easy, and also the maniability is not going to be good. So let's try another approach for that.

What about if you use hexagonal architecture with dependency rejection? So what does that mean? That we enter the couple, the decisions, from the facts. We decouple the intent from the execution. So the same function, but now when I call block, I only pass the card. I'm not passing the database or the producer. And as you can see, I have a return. And my return is an object that has a key called the facts data, and it has its value and a key called the facts message, and it has its value.

8. Understanding Pure Functions

Short description:

I'm just calling the logic here that's a pure function. What do I want to do? What's my decision? I want to update the card and send a message. This function is pure, so I can test using unit tests. It's easy to reason about and compose.

So now I know what the function does. But sure, I can enter to better understand. And as you can see, I'm just calling the logic here that's a pure function, and I'm just creating. What do I want to do? What's my decision? And I want to update the card, and I have the data that I need for that. And also, I want to send a message. I have the data that I need for that, but I'm not doing anything. This function is pure. So I can test using unit test, for example. It is really to reason about. Also, it's going to be easy to compose, because before we were iterating and saving things to the database and producing messages. But now, I'm not doing that. I'm just creating an object.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up