Complex React Migration: New Solutions to Old Codebase Problems

Oh good afternoon everyone, of course not everyone, only those that are where it's actually afternoon for everyone else whatever time of day there is. Let me know if you've seen this before, right?

Imagine like you have your legacy code and it's not giving you all the speed you need, right? The world has changed, you can feel it in your styling, you can feel it in your build, you can smell it in the code. Then you find brand new technologies and your team is eager to adopt that. Everything's pretty amazing, you can do things you haven't been able to do before and yeah, except they are not super familiar to you. You let your teams decide what to use. At some point, the best technology wins, everybody's happy and now you at least can start delivering your features. Business is always doing it, you deliver, business wants new things, shinier things, and somewhere along the lines you have a little bit of discrepancy. Some technologies are different here and there, different ways of doing things have appeared, your team grows, features grow, and you start seeing discrepancies here and there, but at least you're delivering and things are evolving and growing. Fast forward 10 years and you have yourself a new legacy code.

My name is Jason Santos and this is how I used to dress to impress clients, I mean when you could actually meet them face to face and I worked at Rainbow. You probably know who we are and I'm here to talk to you a little bit about how some of the awesome things we did in partnership with ServingMonkey. But don't get the illusion that I have done all these things by myself, right? There's an awesome, awesome group of people that helped me a lot and like that did this most of the work actually, while just keeping you and taking the credit. And seriously, they're some of the most fantastic and smarter engineers I have ever worked with.

Well, but first let me tell you a little bit what this presentation is about. We're going to talk to you about what is ServingMonkey exactly, what's Rango exactly, and what are the problems we faced. We're going to talk to you a little bit about what type of solutions we came up with to solve those problems. And of course, I'm going to show you some of the code.

Okay, what exactly is this product we're modernizing? ServingMonkey has one of the first examples of software as a service in the market. It's a pioneer of Silicon Valley that helped shape that industry. It has about 1,200 employees and more than 17 million users. They have product lines that include market leader survey software and whatever type of market research, like quick polls, competitive analysis, customer feedback, you name it. They have a large footprint on enterprise companies around the world, and they have an impact that was massive during the 2020 pandemic. They empowered communication across companies, engagement, all that good stuff that we are forced now to do from our kitchens. Yeah, it's great to have great software to do that with.

Now, for the shameless plug, Work4Rainbow, right? We're pretty known in the software development scene. We were pioneers on the modern web and we have a very constant presence in summits like this. Our team excels at creating new products and helping companies modernize and become more digital. You probably know us. We've been sponsoring and presenting in many technology events ever since 2013, and we are a consultancy board in Toronto, Canada, but now we have presence in multiple countries. In the last quarter of 2020, Silver Monkey partnered with Wrangell in an effort to modernize some of their code bases into this brand new technological platform they were developing. The Silver Monkey team was facing a lot of challenges to bring all their feature teams into that brand new web platform, and the biggest challenge may be the sheer size of it, and they used the best technology that was available, and they were building that with some of the best and most mature DevOps practices that we have ever encountered. It looked like they were set up for success. On top of that, they had developed this awesome design system, like they're very cohesive and well-rounded, based on solid design principles, and implemented as a React component library with everything on it, on and the cherry on top. However, now that they needed to migrate, they had this big set of expectations of what that migration was going to do. And together, Rangel and Sarumaki devised some of the fine-tuning and some of the planning around how these goals were going to be achieved. It all started with the problem statement, right? How can we make sure this migration is successful and that we can reap all these benefits at the end? You start with the challenges, right? The sheer size of their products, the high sophistication of it, made it hard for us to really make sure everything was going to fall into place. Local complexity was the key element, right? It was really a matter of trying to figure out how each one of these highly sophisticated pieces was going to really come together as one platform. The solution was the domain library. Maturing a rolling out wrench that was SurveyMonkey's design system was a good strategy to help the feature teams become more productive and create a cohesive look and feel to the application. But it was just the start. Simplifying the feature code was possible only if some of the business and presentation logic on the features themselves were shared. When the same concepts were used in different places, domain-specific code will be in charge of that section. The concept is inspired in domain-driven design and helped shape a library that could concentrate everything related to one of the most important domains at SurveyMonkey, the question.

Now for the more concrete part, the execution. First, the process. We divided the team into two different squads, allowing the React developers to start delivering quickly, and in the meantime, have another group started creating the relationships and the alignment with the feature teams inside SurveyMonkey to help design APIs and integration points. The two tracks ran independently, spearheaded by different solution architects that kept in constant contact, one team, one goal, but with the ability to concentrate focus across the two dimensions.

On the design system side, we have been able to refine and validate most of the governance model that empowered the feature teams and the domain library team to continue to contribute to that design system and keep it cohesive. At the same time that by contacting the feature teams themselves, we were able to bridge some of the knowledge silos and create a common understanding of the structure and of the problems. The names were not super important, but they needed to be aligned. The important thing was with the abstractions in place, we can not only communicate more efficiently, but now we can reshape those same abstractions as a single team.

One pattern emerged as a good way of giving this whole integration system the flexibility it needed and ensure the separation of concerns that will allow all the teams to move forward with the domain library, the three-tiered architecture. Inspired by the capability pattern, it consisted in separating the domain library in three parts. The pure visual components of the domain, the question type-specific business logic, and the interface with the specific needs of features. Most of the mechanisms were implemented using React contexts and TypeScript and the goal was to make sure the feature teams could implement question-related user interfaces without deep knowledge about the particulars of each question type.

This is how we deployed the solution. Three different packages were delivered as internal NPM packages and one of them, the question internals, contained only the domain-specific visual components. Another library, the question definitions one, contained the business logic types and type cards specific to each of the 23-plus question types supported by the SurveyMonkey apps. The third one, question bundles, included the capability providers and the visualizations that were actually the mapping between those two. They were feature-specific facades that allowed the feature teams to inject custom behavior and custom visuals into the domain visualizations.

Okay, enough talk let's see some code. This is one of the smallest components, like it's super tiny but it can show you the pattern. It's one of the key things that we had to support here and one of the reasons why some of these components were very specific to the domain was the custom visualization of it, like it's the ability to theme it differently in run time. We achieved that by having this separate file alongside each component that could give it some specific styling but that would also change the way that styling worked based on the theme that was injected by the end user. This is a slightly different but yeah still very basic component. It's different from the design system version of the same component because of the ability for the end user to theme it. This is the rest of it. It's a basic input and it's also one of the first iterations. Visual components are tier 3 and this is tier 1. This is an example of a visualization. Visualizations are non-visual components despite their name. They were designed to be one of the easiest things to write because you have lots of those. Their structure is designed to really map the usage to the actual visual components and map the properties and if necessary hold some state.

It was also one of the hardest ones to name. You can see the rest of it here. The single text box question field is a visual component from tier three and you can see that the visualization maps some of the external properties that are the way the feature is going to call them to the internal ones in the visual component. The last bit is the visualization declaration that helps the overall engine to select which visualization is proper for each capability and question type.

So one of the most important aspects of the strategy was to make sure that the code that was going to be written many times was extremely easy to write. So, this is one capability provider. We tried to make sure that the end user didn't have to spend a lot of their time preparing the types and setting parameters and things like that. So for that we created a bunch of helpers like a lot of helpers that allowed someone to simply use this factory here with a list of visualizations and then TypeScript will infer the types for the external capability provider based on the visualizations that were selected. Now let's see some typical usage here. This is how you would use it on the application code. You would get the capability provider somewhere in your code and inside of it, amongst all your other visual components, you would have one single question controller. The single question controller would be replaced by the appropriate visualization depending on what the question at the runtime was configured around. For example in this case, you have a single text box that will render as a single text box and if you change to a comment box, it will change everything that can be changed based on the data that's inside the question type. The question type itself is on tier two and drives what can be changed by each one of these things.

The idea here is that this is an example of an evolutionary architecture, that's the main concept of this solution right. What's an evolutionary architecture? It's an architecture that can sustain changes and reconcile those changes without losing cohesion. It's the antidote for having to do that again in 10 years. Right, this migration is still ongoing, but we can see some very important results from the approach. The main one may be the response from the engineering teams. We received a lot of positive feedback, and some of the engineers really jumped into the opportunity to really understand what was going on there. So one of the things that we really tried to drive was to really create this collective ownership of the architecture, to really make sure that everyone could contribute to it and bring their problems so we could accommodate it. It's really important to have that flexibility, otherwise you end up solving problems but not the right problems. Okay now the only thing missing is the monkey bonds. How do you call a group of very young monkeys that are siblings and keep yelling a warning at you all the time? Monks! Well, thank you all. I hope you like the presentation. If you want to know more, join me for the Q&A. So it seems that for your question how old is the oldest code you have to maintain on your day to day, it seems that the winner is five years old with 38 percent, and the next one, the follow-up is less than three years. So in between three and five years maybe, I would say. What do you think about this? Yeah, that's pretty interesting because like five years in JavaScript, years, it's a lot of time. Like that means that you're probably dreading having to do certain things because they will probably be harder in certain parts of your code than they are in other parts of your code.

And you're missing opportunities. People are asking you to do things and you're like scratching your head. That's tough. And it's a big challenge, this, right? When you have this code that you depend on it to produce value for the business, you don't want to just spend time rebuilding it. But then at some point you will be forced to because there's other things that you want to do that depend on that code being more modern. Yeah, that's for sure. I can tell you for sure because in the past I used to work at a startup and we actually were one of the early adopters of React I would say, almost eight years now. And we started with Create Class. We have used mixins and everything, right? Like the sugar, and suddenly we had to move on to classes, to use classes, and also we had unit tests, and everything was a mess. And we also wanted to move to TypeScript as well. And it was, how can you do everything at once? And it was really, really hard. You either had to rewrite everything or, I don't know, do something like code modes and everything. And it was only three years old. So it's still like five years, it seems a lot as well. But I see that also 10 years, it's kind of growing and really hard to maintain after a while, especially for JavaScript, as you said.

Yeah, yeah. And that's the thing, right? If you try to approach it from a technology perspective, like you look at these brand new technologies and you want to use it, sometimes there's not the right call, right? You need to really think of the value you're adding to the overall value stream of the business. And what are these opportunities to do that, that are missing? Because that's how you get like your migration budget, so to say, right? Like you get there. We could just do that. That would be awesome for this product for our users. And that's where you get the conversation going for really modernizing the codebase.

Exactly. Speaking about questions, we have quite a lot of questions. I'll start with a one from Popling. Can scrolling be considered as first input? Be considered what? Can scrolling be considered as first input? You are the expert. I don't exactly get the question, but maybe maybe Popling, if you can add more to that as well, we'll come to it.

Let's pick another one from Tom HD. How did you arrive with the three tiers of architecture? Yeah, that's okay. We can get the scrolling afterwards. I think I got it, but the three tiers, we started with the simplest possible thing that could work. Let's build the visual components and people would use them any way they want. That's the first idea. Then we started thinking about the constraints that you should always do. Like if that happens, some things we'll be able to do and some things we won't. And what you wouldn't be able to do if everybody could consume just visual components everywhere. You wouldn't be able to standardize the way they approach gathering, getting the data from the back end of the GraphQL data and the shape of these data. Then how would they do validations, how will they do the transformations, all these things. There's a missed opportunity there. The question needs to always be, okay, what do you want to pay in terms of a tradeoff for the ability to centralize these things? Now you're going to build a little more complexity, but you're going to gain something. So we started having those conversations.

Okay, you folks said you wanted this, like that you wanted the features of these applications to be very easily expanded. So how can we reduce the cost for these developers? We might remove some something from them, but now we give them the ability to do something really fast. This is going to be like reducing their complexity and giving them a little less customization options. And at some point we started having problems. Like, okay, now in this situation here, as we started creating an inventory of all the things that needed to be done. At some point in the app, like, okay, these folks really need to customize this part here. So let's give them a mechanism now. But if you give them a mechanism, you're adding complexity again. And is that trade-off, okay. And then the conversation keeps going. And at the end, we found out that this complexity that was mounting inside the domain library needed to be divided.

Like, because it was different types of things that were born there. Like, okay, we have the visual components, but they should be devoid of business logic. Like, otherwise, it's kind of crazy. Depending on the scale, of course. Like, where does this business logic go? Does this business logic belonging react? Probably not. So, at this point, we started shaping this as a three-tier thing. Like, we have the integration part, we have the business logic isolated, and now we have the business-oriented visual components and organisms that people could use tied to these other things.

Okay. All right. Let's move, because we have so many questions. Let me pick up the other one. Can you also do the, in addition to what you said about the scrolling, as well? Like, let me read it again. I think he's asking if scrolling is an input that goes into the infrastructure. That depends, of course. The real boundary of this is the vertical domain, the bounded context that it belongs to. So, if you scroll inside a component, that is the responsibility of the library to provide as an organism, and this thing is kind of opaque to the outside. This component should deal with the scroll itself. But if the scroll is the responsibility of something that includes that, then the application should do that and the communication between the application and the library should have some semantic that is really representative of what that means. If it's something like, oh, you're in view now, show yourself. That's one message you want to send to the library instead of, oh, the user scrolled 10 pixels. That's the key. It makes sense.

Urbon is asking, Jason, do you have a Git repository with simple example and playable architecture? No, actually, no. I should probably put that up. I'm a really bad user of Git repositories, public Git repositories. I should do that more often. I think the oldest public code I wrote is already like two years old or something. In JavaScript years, that's forever. Yeah, nice one. Yeah, definitely.

I totally recommend you to just put it out there on GitHub so people out there can take a look, can play around. Maybe they'll have some tips and tricks here and there that they implement or move towards their own application or the whole structure of the company.

Another question from Chris Shim is how did you migrate the code of SurveyMonkey, feature by feature or more domain by domain? That depends. It started with domain because the thing that SurveyMonkey had was like very independent feature teams. They had a lot of local complexity as I said in their code because each one of these feature teams were super powered to really drive features and sophistication into their part of the product.

Now what you need to go there and understand that complexity and see what are these features so you don't rob end users of anything and make them cohesive in the centralized domain, a bounded context, like a group of business-oriented domain entities. Once you have that working right by your perspective and by the feature teams that have that domain as part of their features perspective as well, you can then onboard this feature team into this new structure, into using this library and start getting their input into evolving that. It can happen with multiple feature teams at once because they will run in parallel and they should probably migrate their own features because they are ultimately the ones that understand the best what that feature does and you can also start helping them to rebuild certain parts or build brand new features using that library because now it creates the opportunity for them to build stuff super fast because some of the complexities is removed from their plate and contains everything they would wish to contain.

Great. Yeah, that's that's a really good answer to be honest. The last question is by Arek. We have time for one more question. So, how to prevent enterprise applications from to be legacy after two years? If you have any best tips or tips and tricks how to do it? How to avoid being legacy after two years? Yeah, there's no silver bullet right? And it's it's one thing that is really important for us to understand is that as technologists we consider something legacy once it's not a shiny toy anymore, right? It's like we look at things, oh i can't believe you're still using class components, right? That's that's that's not really true. Code that's there, delivering great value to users is great code, right? You the focus is when you are missing opportunities to deliver great experience to users then you're starting to think okay can I justify rebuilding this or do we spend this time building something new right? If depending on the answer you might want to just every few months or like maybe just every day adding a little modern piece to your code.