Back in 2019 (feels like I'm talking about the good ol' days but really was last year at the time of writing this...) I had the opportunity to work at Société Générale, a French multinational bank, as a Software Engineer. It really was a nice time working there and the team I joined was over the top. Talking of that team it was composed of roughly 30 people, mainly developers but also DevOps, Data Scientists, Supports, Product Owners, and UI/UX designers. We were in charge of maintaining and developing a set of internal applications, about a dozen, and as you may have already guessed by "Choosing Vue in a Big Company" I meant it in that team obviously, not company-wide.
Anyway, let's dive a bit deeper into the main topic so I can stop annoying you with too many side stories. Maintaining, developing, and making an application last through years involves a lot of things, one of them is about bringing it some sort of freshness from time to time. Indeed probably at first your client, whether it's one outside of the company or the team next door, just wanted a tool to store customer information, then, after the first release, they wanted a way to sort clients through folders and once that got implemented a way to be able to share those folders with specific people only, oh, and eventually they thought auditing who is accessing what might be helpful too! And so on, and so on, you got my point and probably can relate, that's part of what building a product is after all, nothing bad here although after years working on that product you may agree that the original data model is not that fitting anymore with the current needs, that this technology we thought cool at first is not scaling as expected, and so on. This happens for designers too, that skeuomorphic design has certainly not aged well, and those UX nonsense has accumulated in the dashboard. You named it, it's time for a whole application overhaul!
Overhauling!
Stay calm as we don't want to break anything here, revising an application is a long process but it will get you rolling for years until you need to revise it again. It usually brings a lot of excitement to the team, or at least to me, but there are a lot of pitfalls in doing so that I won't discuss here because that's not today's topic (and I also don't think I have enough experience with it yet~) Anyway, that's what my team was working on when I arrived at Société Générale: applications' UI had been completely reshaped and rethought from scratch by the design team and the dev team was thinking about how to refactor current code to fit the new UI.
One great thing about a full UI redesign is that most often it's an opportunity to throw away that old UI framework and bring in a fresh one. Our applications were built as monolithic Java applications making use of Rythm engine to render HTML. The fact that Rythm's documentation website does not support https might eager you at trying it out but honestly it wasn't that bad apart from being quite old-school and oddly supported by code editors. But anyway, Rythm's age was over as my team wanted to get rid of it along with that redesign, so came the question of "What to replace it with?" We knew that other teams at Société Générale were either using Angular or React so most likely one of those would fit our needs. Nonetheless, our tech leader was aware of other frameworks like Vue or Svelte so he wanted to challenge that a bit, gathering insights about all those frameworks from the team in order to make the right choice. That's where I shined, I think: among the team I was the only one with great experience with Vue and React, as well as some bites of Angular, so I decided on giving my team a presentation about those frameworks for them to make an informed choice...
Vue, React & Angular in a Nutshell
Vue is the clear winner! Just kidding~ Honestly, I like them all in their own way and really think that the one you need to choose only depends on what are your needs and tastes. Also if you're wondering why we aren't talking about Svelte anymore, well, sorry folks, but back then its ecosystem was not judged mature enough for building our applications UI on top of it.
Back to the three ones! I'm not going to give you the comprehensive review I gave my team back then as there are already plenty of great articles around about any particular aspect of those frameworks you may question. Also when searching about Vue, React, or Angular you will encounter a lot of articles saying that one is better than another or its contrary, proving to me my point that at the end of the day it's all really about needs and tastes, and that's what I explained to my team before addressing these two points:
- For the needs part of the choice, they were already well aware of theirs, as they knew our applications certainly better than me. I found it relevant to provide them anyway with some human resources related insights as it's something to consider when choosing a new technology. Currently here in France if you are looking for developers with experience on those frameworks you will easily find Angular developers, you won't struggle with React developers too much either but as for Vue ones, it's not the same story. Nevertheless, that's not a NO GO for Vue so far, indeed I think that any JavaScript developer can quickly get into Vue where Angular and React learning curves might be a bit more abrupt at first. Also, in my opinion, most tech leaders will agree on that they prefer someone who knows JavaScript well to get into one of those frameworks rather than someone who knows React well but doesn't know what magic a
querySelectorperforms; - As for the tastes part, I showed them code, really. I built the Angular sample application using each framework and walked them through, highlighting key differences like how each of them split concerns or how files are organized and such. The point of that was to give them some sort of a "look and feel" of what coding with each of those frameworks was like.
All of that achieved, obviously, a lot of discussion about this choice still went on, but one day at the pizza restaurant (yes, that's how it went~) we decided on giving Vue a go and they asked me to create a proof of concept by moving an application to the new UI using Vue to see how it goes. That's how I started to lead that transition.
All Hail to the Jamstack
One thing that these new frameworks allow us, and not only Vue, is to take a new approach to how we are building applications with the Jamstack. By building our new UI with Vue we did not want to throw away all the Java backend part which was integrating nicely a lot of securities and utilities to manage the data our applications were handling. What we wanted to do was to turn its monolithic part rendering Rythm templates into a standard REST API. For the most part of it, it was made pretty easy as Java was basically injecting objects into templates so instead of that we just had to serialize them in JSON before sending them to the new and separated Vue client, so whether or not that Vue proof of concept made it through at least the process of turning the Java backend into an API was not a waste of time.
Also, another benefit of the Jamstack is that you can easily fallback to a part of the application that has not been yet migrated. Let me rephrase, when you have a Jamstack based application deployed this is somewhat the process it goes through to give you content:
- First, it checks if there's a file matching your request, like one to
/about-uswill match/about-us/index.html; - Then, if there's no such file, it can fallback to SPA mode by catching any request not matching a file and sending it to
/spa.htmlfor example, this can be made with a simple.htaccessfile with Apache. You can probably relate as it works the very same way when you deploy a PHP application.
But then, how do you fallback to the old Java application? Well, you just have to tell your HTTP server where to fallback when no file is matched by the request (n°2), so when the client hit /user/john-doe you tell it to either send that request to the Java application or to serve /spa.html if that page has been moved to the new UI, and voilà, all of a sudden you are able to migrate each page of your applications to the new design one by one without breaking anything.
After I had migrated successfully the first few pages of the application I was in charge of, Vue had proven that it would fit our needs effectively and the new Jamstack approach really shined at making the migration process smooth. That was when other developers were assigned to migrating the whole set of applications we were in charge of to the new UI, and when my role in the team shifted a bit toward addressing developer experience and knowledge management.
Making that Choice Last
By migrating one application using Vue I also had to design the monorepo which will hold the migrated applications, involving a common code base with a lot of helpers related to our context and how we will query our new Java REST API. I really took care of crafting simple and useful code components so developers joining me in that project won't struggle with getting basic things done or reinventing the wheel each time. This obviously went along with writing an extensive documentation about each of those components as well as the design choices made while creating this monorepo. Indeed it's no secret that a non-documented component of mine would most likely not be used anymore or that a design choice would be poorly understood and lead to frustration if not after me leaving. So that was something really important for me to do well and that was really appreciated.
Also as I said earlier when we launched that migration project I was the only one among the team to have experience with those new frameworks, especially with Vue. And because Vue at the end of the day is all about regular HTML, CSS and JavaScript it was not that complicated for my teammates to learn its basics, get up and running. Nonetheless, as being the one experienced with it in the team I felt I was a huge plus for us as I was able to quickly answer my colleagues' questions about the framework, to help them with debugging things, or teach them some aspects of Vue when they were starting with it. With that time spent helping, and the strong documentation we discussed before, these allowed me to leave my team with a lot of knowledge about everything I've worked on and that they needed in order to keep that migration process going without me.
Following Up
We've discussed a lot and I hope everything made sense in that post and that you found it interesting even if it was mostly about me talking about my life. It's quite a big deal to make someone who's only here for 6 months in charge of leading the migration of your applications to a new technology and I can definitely not thank my team enough for giving me that opportunity back then. Earlier this year I was at the restaurant with them to see how all of that was going and to hear from them now that my contract at Société Générale was over. I got pleasantly surprised to see that everything was still going super well and that they even hired new developers to speed up their migration process, really warmed my heart to hear such great news from them!
Thanks for reading~