How to approach legacy apps migration
Okay, you got that unpopular task – to get your hands dirty with pretty old, legacy apps and code that probably nobody wants to look at. And what now? You can cry, whine and blame your boss for that decision or start getting the job done without excuses and complaining. Whatever your choice is, that job needs to be done. And yes, it may not be the best thing ever in your life to work on but you can LEARN A LOT. As you must go through that, my advice is – to make it as easy as possible and just start working on that and try to learn every single step and maybe write some things down. I can share some tips and tricks you can implement to make that journey easier. Initial steps Even if you don’t really have to understand the business domain, try to gather as much information as possible about your legacy code and try to understand what is going on there. At least you will know why is it important to migrate to the latest tech stack and then you will hopefully do it with more willpower and more enthusiasm. It was at least in my case – I wanted to work on meaningful stuff. Besides that, try to use the current version of the app and try to visualize, or understand what and how can be built using the latest stack. It will help you with estimation and planning. Do your research The second thing is to research technologies used in that project and understand what they are used for even if you have never heard of them. That will give you an overview of how it works and the power of choice for implementing a modern solution for a new version of that application. The third thing is to analyze the package.json file and take care of what packages and versions are used in that project. It can be tricky if your project is a huge monolith created from smaller apps. In that situation, use some tools like Google Sheets and write down specific versions of each of those packages. Last but not least, make a plan for what and when you will work on and try to estimate how long would it take to migrate everything to the latest tech stack. This part can be tricky and pretty hard to estimate if you don’t work on the first step or if you don’t work on it properly. And don’t forget to request as detailed requirements as possible. If there is some documentation on that project from the developing stage, it would be nice if you can get it. If not, try to gather and write down every single detail about specific functionalities. Get your hands dirty Running an app locally Okay, now that you got enough research, you have a plan and you know what you are supposed to do, let’s start. The first thing to do is to run that app locally. Yes, it may seem easy but sometimes it may take a few days to run it locally. Why is that? Because if you have a large application with lots of dependencies and if you keep in mind that it is a legacy code, you should understand that probably some dependencies are pretty old, unusable, or even deprecated and there is no support for those libraries anymore. So that is why it may be tricky just to start your project locally. If you do not have those kinds of problems, you are lucky! If you have any problems with running it locally and are stuck there, try to ask for help. Ideally, some developer already ran it locally some time ago and has node_modules folder with specific versions of packages needed to run it. Try to research who that might be and contact him to send that whole folder to you. Then paste that folder into your local project and your app should run. If there is no such developer and no signs of making that app alive, hopefully, there is at least some server where you can see how the app is working and parallelly look into the code and try to understand piece by piece what is going on there. If there is no live version of that app, probably rebuilding is the option you should choose. Sometimes it is also the easiest option. Start working on migration Now that you ran your app locally or just went through a live version of it, you can start understanding what is going on in that code, how everything works, what are the requirements, and how your app should behave. If your app does not use the latest technologies you work with, obviously it needs a rebuild. If it does, you should take a closer look at the differences between the old version used in your legacy app and the version you want to use. Make detailed research about every single dependency. Once you do it properly, it will save you a lot of time during the migration process. How to migrate it When you’re done with your research, start migrating piece by piece. Separate your concerns into smaller chunks so you can track your progress and make your work easier. For example, do not try to migrate all the stores, all the styles, and all the functionalities at the same time. Separate your problems and make priorities. If the highest priority is a change in the design that the user can see, make it your first step. If additional functionalities are the highest priority, make them your first step. And be aware that you will get a HUGE amount of errors during this whole process. But again, solve them piece by piece, error by error. If you work on an application that has some pretty old or even deprecated libraries, I am sorry, but you’ll have to find a way to migrate it onto the latest version
What the heck is Astro?
Astro is, you would never believe, a new JavaScript framework. There are a whole bunch of JavaScript frameworks out there, so you might ask yourself – ‘Why would I even be interested in just one in a row?’ But, let’s see what Astro can offer. Astro is hot new stuff in the world of web development. It is an MPA (multi-page application) framework that loads apps with 0kb of JavaScript. Basically, it tries to offer an experience of using some modern framework like Next.js but with the performance of traditional MPAs. It gives you the opportunity to control when you will load your JavaScript code through islands architecture. But not just that! Astro offers you an opportunity to combine multiple frameworks inside one application. How interesting it can get! If we got your attention, let’s deep dive into it. How did it all start & Astro at the moment Astro was a result of a technical experiment where its core team tried to combine multiple frameworks inside one application. So, for example, they wanted to combine React and Vue components together. Guess what? They were successful. In the beginning, there were just 4 people in Astro’s core team but now there are 12 people already. A fun fact is that the initial commit was done in March 2021 and they already have more than 21000 stars on GitHub. For more information about source code and GitHub repo, visit withastro GitHub repo. Most of the features and improvements are done by Astro’s community. They have a pretty huge community that is always here to help. Also, bugs and errors are solved pretty quickly in general. At the moment, Astro aims to be a static site generator. Its aim is to let you build astronomically fast websites. In other words, its goal is to reduce loading time when a user visits your webpage and make it interactive as soon as possible. What may be interesting is that it uses JavaScript on the frontend part as well as on the backend part. That is one of the differences between Astro and other MPA frameworks. Let’s dive now into core design principles and core features. Core design principles and features Content focused Astro is mainly content-focused at the moment. What does that actually mean? It means that you should use Astro for content-rich websites such as blogs, simple e-commerce websites, or something like that. That is where Astro shines. Server-first Astro supports SSR (server-side rendering). It does everything it can on the server and serves you already generated content or at least generated parts of the content..astro files can fetch remote data at build time. It means that users will see your webpage quicker than fetching on the client. Fast by default Astro applications and websites are fast by default because they ship code without JavaScript by default unless you change it. It means that if you create, for example, React component with some event listeners glued to it, your component will be shipped without those event listeners and will not have any interaction with the user. Astro will actually turn your component into basic HTML and CSS unless you decide differently. And that is an awesome feature. You can have complete control over every single aspect of your application. Easy to use Probably the best thing about Astro is that you don’t even have to use Astro components. You can write the whole application using technologies that you already know. And that is the biggest Astro advantage. You can use whatever you are comfortable with and let Astro take care of your application under the hood. On the other hand, if you want to use Astro components, the syntax is pretty similar to modern frameworks. You write basic HTML with kebab-case attributes instead of camelCase which is used inside modern frameworks. HTML comments are valid inside Astro components. You are encouraged to use Typescript (if you want to learn what is Typescript, visit this link). You can type all the styles within the <style> tag and Astro will stick all the styles just to your component and prevent your styles from affecting some other component. Fully featured It has lots and lots of integrations that are ready to use. You can use almost all modern frameworks like React, Vue, and others. Before using them, you just need to add them to your application. It is as simple as this one-liner (in this example I want to add React to my application): npx astro add react Besides JavaScript frameworks, you can add modern CSS frameworks and libraries like Tailwind CSS, Sass, Less, or similar. For deploying services you can use almost every popular hosting service like Netlify, Vercel, AWS, Azure, or similar. Markdown is supported by default while there is also MDX support. It also dynamically creates static routes. It means that you name your new page in the pages folder and Astro will create that route for you. Astro islands (islands architecture) Islands architecture is a new term used to describe a different way of loading JavaScript on web pages than it used to be. The general idea of islands architecture is relatively simple. It renders HTML on the server and makes slots around highly dynamic regions. What does this actually mean? It means that your user will get a server-rendered page to his browser and there will be a dedicated place on the webpage reserved for loading your JavaScript code there. Those regions or slots are treated as self-contained widgets or, in other words, small, separated applications. Maybe it is easier to understand if you take a look at the picture below: How does Astro use it? Astro basically ships your code without JavaScript. So, if you make your super interactive React component, Astro will ship just HTML and CSS (in order to ship less code) and disable the whole interactivity unless you enable it. And that is where partial hydration comes into the story. Partial hydration Islands architecture and partial hydration