GitLab Foundations, 2 Dec 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Pajamas Migrations. Why they're important

Description

https://docs.google.com/presentation/d/1_RZnMbgC60ysTO4cZkVfc7IXKOHLsezJlbeK1ucpZPA/edit#slide=id.g19fbf055713_0_10

A

So thank you for uh listening to me today. I've recorded this uh and uploaded it to YouTube so that you can watch this asynchronously. You can speed it up. You can skip over sections. You can repeat the bits that you've missed. You can do all of the things that that come with video, recording and leaning into it, saying great and obviously, if you have any questions, feel free to ask me so I'm going to talk about all pajamas migrations.

A

uh These are the okrs we've been setting for a while now and there's a definite feeling of migration fatigue. uh It's something I can totally empathize with I get it. uh I was an em verify very recently, and we also were given these migration KRS and I felt that frustration, but we leaned into these uh and we we did a few migrations and when we used more and more of gitlab UI and- and we quickly realized like how important these migrations are and what they can do for us.

A

So now that I am the EM for foundations. These migrations followed me, and my hope today is that I can show you all why they're important and and get you your EMS and your engineers as excited about these as I am and to understand the importance of so we've been doing these for a couple of years. uh We've made a lot of progress when I created this slide, we had migrated 1 813.

A

This is probably higher because it's currently pajamas migration day, but we're about 80 of of the way through um and, as we all know, that's the easy 80 we've got the difficult twenty percent to go and we're starting to look at the more difficult to migrate components.

A

Now- and this is why we're directing people to to drop down to the minute and why we're asking for one per engineer, because I want as many Engineers to look at this as possible so that they're familiar with gitlab UI they're familiar with these migrations before we dig in uh I, am mentioning gitlab UI a lot here. uh These migrations are technically pajamas migrations, they're, not the same thing. uh So pajamas is our design system that is maintained by a ux team.

A

There's a set of rules and guidelines about how we design, use and interact with GitHub, and the goal of these migrations is to make gitlab more pajamas compliant so to adhere to these rules and guidelines. What gitlab UI is, is it's a series of pajamas compliant components?

A

Also, there are two types of view: components that we have. uh There are view components and there are view components and the naming on this is horrendous, uh so view v, u e the JavaScript based and they are built-in view. This is what gitlab UI is and view components v. I e w they're Ruby based and they're built-in rails. These aren't our names. These are just what they're called and unfortunately they're very, very similarly named, but basically always reach for the view components.

A

Unless it doesn't make sense to convert an entire page into JavaScript, then we have view components the Ruby ones, and these are the helpers that are also pajamas compliant, so you can use them in your rails and Hamill views when migrating to JavaScript.

A

It doesn't make sense the slightly less useful they're, not as good as the view the JavaScript components, but you know they're a good alternative, so uh things you get for free when migrating to gitlab UI, you don't just get the usability and the visual improvements and all that sort of stuff like that grip, but in, in my opinion, they're they're, lovely side effects to the the real power of of gitlab, UI and componentization right.

A

So you get security built in for free. You get performance built in for free. You get a reliability, accessibility, usability and maintainability all built in for free, oh and efficiency as well. I forgot that one there we go. We got a lot built in for free yeah, all of these things when you use them components and over time all of these things get progressively better in gitlab UI and all of them improvements bubble out to your areas or the code base as well.

A

So if you're using gitlab UI to build your features, then your page will become more secure, performant, reliable, accessible, usable and maintainable over time.

A

Good example of this is with security, so in August last year we had a good number of security issues. um This is the the chart that of just opened front-end security issues.

A

uh You can see the issues start to increase around October November time, and then they start to drop off around March April, and this is because we shipped some security fixes to get lab UI and because we shipped until AP, UI everywhere in the code base that was using them, got these security fixes for free, which brought us all the way down to a much more manageable level, and we've we've stayed there since.

A

um So these were improvements that garage made like thank you for durage for doing these he's talking about Dom purify setup, it's improved sanitization, it's prevented the rendering of unsafe HTML and, as I said, because he made these in gitlab UI.

A

All of these uh fixes rolled out to a big chunk of the code base and because gitlab UI is in one central place, he doesn't have to seek out all the vulnerable areas of gitlab. You can just improve it in gitlab UI, knowing that that'll have the most impact on on the rest of the code base, because when you use get love, UI security comes for free, there's, also performance right. That's another important aspect of our front end. Something we've been making improvements to over time and gitlab. Ui helps with this in two ways.

A

So, firstly, bundle sizes for in development is the dependency Nightmare and and every dependency you include on the front end gets shipped to the user in their browser we have jQuery, bootstrap, dropper, select two and all sorts more and a lot of these do the same thing or very, very similar things.

A

You know drop downs, the ones we're trying to migrate at the minute they're a good example of these, so those dependencies that I listed earlier um dropper select two Etc they're, all just libraries we use for drop downs, and if we migrate everything that's used in these libraries over to gitlab UI, then we cut down all of our dependencies and the less dependencies we have the smaller the bundle size, the less code we send our users and the better.

A

The performance of gitlab generally, the other way that the gitlab UI improves performance is just with the performance of the components themselves and and some of the the tricks that gitlab UI utilize to render things a little bit faster. You you get these for free right. So if we we look at the LCP for the page using verify from April last year, you see they weren't correct LCP is the largest contentful pen.

A

This is what we were measuring at the time, and this is basically how long it takes to render the most important thing on the page, and you can see that the times here range all the way from 1.5 1.6 seconds up to over 10 seconds, which is not good, I. Think! That's really! That's really not good. We did improve this, and- and this is what the chart looks like now- uh it's a lot better.

A

We've gone from 10 seconds to 5 Seconds, which is still not good, but it's it's a hell of an improvement, but that's not really what I want to talk about the minute I want to specifically call out the verified job list. This went from taking three seconds to load all the way down to half a second a little over half a second but half a second right. It's about a 600 uh decrease in loading time.

A

We could do this because, as you may guess, uh we migrated this page from a handle view to to using View and using GitHub UI, um because with GitHub UI performance improvements come for, free I would look to security. You will look for performance. I mentioned accessibility, reliability, all the other LEDs. There are similar stories for all of these, but I think you get the point.

A

You get a lot for free with gitlab UI. It makes things a lot easier and makes things a lot quicker, because when you focus sorry, when you use gitlab UI, you can focus on the features and you can link gitlab UI. Do the rest. This is exactly what paint did when when he built the new jobs list page the one that had all the speed increases from last time, so he was tasked with adding fillers to the job list, so this page just used to be a list of jobs.

A

This is what it was when we took the first Benchmark, so there's actually more going on on the page now, and it renders a lot quicker and currently this list was in Howell, so we had two options: he could leave the list in Hamel. Add the filter hook them up somehow go from there or you could migrate. The entire thing to view take that that list rewrite in View and then have the the filter bar and the list using the same, the same data style essentially now my great interview is the better option.

A

It would yield a better result, it would become which I was complying and prepare user experience, and it would make it a lot easier to add, develop and fix things on on this page in the future. However, it would involve an entirely right, so he would need to create the components for the list. The items in the list and the elements within those items you'd then have to deal with fetching data paging it in that data. Updating that list.

A

You then have to solve all the problems that come along with this, with secure e, with accessibility with performance. You'd need to make sure he handled empty. States error, States loading, States you'd, have to ensure the CSS was written correctly and was pajamas compliant.

A

This doesn't all work and something that realistically, he wouldn't have been able to do within within the time that he needed to to be able to shift this filled about our own time. However, uh if you use gitlab UI, which he did, he didn't need to worry about as much of this. uh A lot of this stuff came for free, so he used GL table to render the list he took. This took care of the layout, the accessibility, all the various States all for free.

A

He just needs to plug in the Dare use, GL intersection, Observer to add infinite scrolling to the same table with just a few lines of code. You use GL, Sprint F to handle internationalization geolink for Save, secure, link, rendering and all sorts of other things there's more going on here. It's overly simplified, but you can see how nice this code is right.

A

um This this intersection Observer here from line 14 to 19, is everything he needed to to fetch more jobs and and keep the thing infinitely scrolling.

A

um The skeleton loader similar story- jobs table that's a separate component in itself, but within that there's a GL table component that just says here's what my data needs to look like do everything that the table needs to do and by taking this approach pink, will roll out the feature.

A

Refactor a neglected area of our code base and improve security, accessibility, reliability usability all of these things and and as we saw earlier, the the performance like it was so much better because you focused on the feature and you like your lab UI, take care of the rest.

A

So what's in it for me, why should I care about GitHub UI migrations, or what should you care about getting FBI migrations?

A

um Well, as I mentioned before, it's about all the things you get for free, you get security, usability, performance, efficiency, reliability, maintainability and accessibility, all built in all for free, uh you use get web UI. Your area of the code base is is much uh much better in all these aspects. I think I want people to start migrating more areas of our code base to use gitlab UI, not because we're telling them to, but because they see the benefits and they want to reap the rewards.

A

When we get to that point, then we will have no more migration or chaos. I, don't want to keep doing these forever. I don't want to keep telling people to do these I'm sure you don't want to keep getting these old chaos so the more we migrate, the less we need these or KR. Let's push on. uh Let's, let's get these drop downs done.

A

Let's get give each engineer an opportunity to interact with Git love UI and do one of these drop down migrations and let's use the feedback from these interactions to improve UI, and then we can use them improvements to make gitlab more usable performance, secure, accessible, reliable and everything else. Thank you for listening. There's some links here to some more and as I said, send any questions my way.