 Hi, I'm Robin Ginn, executive director of the OpenJS Foundation here for another cool story about OpenJS and action I'm delighted to have Robin Glenn here from YNAP, which is like for me one of my favorite brands and retailers, so Super cool to have Robin here to talk more with us. So Robin tell us a little bit about yourself First thanks for having me on it's really exciting and it's always exciting to see a fan of our website I've been there a while so, you know, we were quite small and Maybe a bit niche and so when everyone when anyone says that they've heard of us. It's super exciting for me Oh, yeah, I think I changed clothes three times like what do I wear? Yes, I'm a principal developer at YNAP. I'm also a member of the Chrome advisory board I work within a team called the luxury division and we look after mr. Porter and net porting And yeah, I've been there for ten years, which is you know an ice age and technology, but I started My career as a designer and a flash developer And then I moved to net porting. I've worked in different departments different teams Wherever my curiosity takes me. I just end up going and that ranges from web standards performance engineering test automation observability scalability And the last six months I've been working in SRE and mainly with Kubernetes So in fact just before this call I was running a workshop with we've works around Kubernetes Very cool So I know technology is pretty important to net or port a can you explain why a big retailer and Why that is so important to the company and that in your team. Yes, so I mean I Wine up as a whole it is technology. So Interestingly enough, it was our 20th anniversary of ukes and net port a this year So if you think about the landscape, you know in 2000 people were just getting comfortable buying books online We just had the comm burst You know boo who had blown like 130 million in six months And we were trying to convince people to spend thousands and thousands on dresses So technology was about making them feel safe secure But but also exciting and now 20 years on, you know, people are much more demanding with what they want So we have to up our game to offer more to them to retain them So, you know technologies there is the backbone of the entire brand. That's cool I read a blog series that you did over the course of a couple years and it talked about sort of this Defining moment when you decided to shift your architecture. Do you want to just So, yeah, you know like talking to you and me being like, oh, I'm excited that you know the brand, you know When I when the company was young it was kind of niche underground I mean undergrounds available where but it wasn't like no, you know, if you knew you knew but Maybe it wasn't that mainstream because the You know the entry to barrier with expensive luxury clothing is quite high So we're quite niche. So what we started getting famous for is sales and when we do our clearance So what would happen is a sale will come around and we couldn't hold the traffic, right? So that there was the decision of do we You know, we were still on physical tin back then Do we get this extra hardware and then we have this point of redundancy for the rest of the year Or do we look at something else? So we looked at, you know cloud offerings And and we just made once more simple microservice of the sale listing page put on AWS to horizontally scale just to Distribute some of that load And then we managed to keep the site up Which is obviously really exciting But also we'd seen this kind of change in our mindset, you know with microservices of teams have an autonomy to release faster We've changed the way we do an automation testing and all of these things just freed us up a bit and that's started us on this microservice architecture And and that's taken us to where we are today Great So talk about a little bit where you are today in that sort of you've been there 10 years. How are you sort of? defining your architecture what? You know what solutions are you building? We'll talk a little bit more about some of those challenges so we As we were saying so the sale app was successful Then different teams that I get an autonomy and they were like, okay, we're gonna cut up the the website into into different domains So like okay Shopping parts or listing parts and you know separating things out and we followed In that journey would have separate domain specific teams to do different jobs And they would have complete autonomy of our applications and get deployed So we had a first pass of that And that was pretty successful. We learned a lot. There was also problems and and then we got an opportunity to To start again from scratch So they wanted to change the way that our logistics worked new factory new distribution centers new robotics So that included having like new API structure. So we took the opportunities a front-end team to say all right this Let's take what we learned in the first few attempts and and do it again So we did that for mr. Porte and that went live globally. So we did it in segments the countries That went global this year the outnet Who I don't work exactly inside But they are also using that infrastructure and architecture and code that we built us all brand diagnostic So they're already on it and now we're just in the process of migrating Netaporte onto it as well So then we'll have three, you know Large brands with over I think it's half a billion page views a month or losing this new infrastructure So at the moment, yeah, we're we are Implementing that portal to that and but we've got some technical things that we that we really want to look at going forward as well Which mainly wraps around Google's push towards the things called core web vitals Got it. So, you know So what were some of the factors that sort of drove your decisions on the technologies that you chose when you, you know Move to the new, you know, I know you moved from microservices and now you're you're evolving that further. So so what what we had Previously in the past which is you know, I think it's quite common and it works many businesses, but it weird hit this breaking point So we had a large Java spring MVC application You know what some people might call a monolith and that was separated into like two teams There was like the back-end team right in the Java and then there was the front-end team who were just around JavaScript client side and CSS HTML And and when we made these microservices we adopted node.js really because we wanted this kind of Fast iteration. So we had a bunch of client-side JavaScript developers who were learning more server-side JavaScript and Yeah, that's so that was You know really successful for us and we wanted to break that apart and follow what we wanted more than anything is Rapidness. So we wanted people to not do context switching. So if you're doing a front-end feature, you could also do it on the server So the main thing for us was around context switching and we had a huge pool of resource of JavaScript devs Yeah, so we wanted to keep that and we've looked at other projects in the blog post you reference we built a POC in go and we also built one in node.js and Although we got them similar in comparable throughput the the ultimate deciding factor was We didn't have that many go developers But we had a huge pool of of JavaScript developers We wanted to keep that that lack of context switching. So when you work in our ecosystem, we we use things like jest for our unit tests We use Cypress and Pappeteer for our functional tests our servers written in node.js we use JavaScript frameworks and We have things like autocannon, which is a benchmark in low testing written in JavaScript We use node clinic, which is a JavaScript tool for them. So we have like this closed ecosystem where Not closed, but we have this like if you need to switch between projects It's really straightforward and that's not to say that we haven't got other things. We have plenty things written in go And we've got some things in .net And C sharp sorry and but the idea was it was more important for us to be fast and iterating And if there was maybe a throughput loss The the expenditure and horizontally Expanding the service to take that load was the cost is lower than the engineering cost of hiring people in these different languages So we get switching is what we wanted to avoid We still evaluate technologies to see, you know What what works, but that's a big factor for us was iterating fast. Oh great It sounds like your team was pretty adaptable and moving to those Yeah Do you know like we as a small group of front-end devs work with some SRE and infrastructure and we Got Kubernetes deployed running and we're really happy with it But we've got these opportunity to give front-end devs the opportunity to learn how to do this infrastructure work So, you know, we have a pool of talent if you want to move around this Yeah, we we try and encourage that to just move around And see what you can adopt and what you're interested in. Yeah, that's very cool. I'm very rewarding for them. So that's cool I'm talk a little bit about your decision to use fastify and You're you know, and how that impacts your web performance So this is was for a specific project, which is called loco There's a blog on our medium called Solving a problem like routing. It's a series where we talk about the adoption of fastify and The main thing for us was So we have a bunch of presentation servers In Node.js and most of them use express and that that worked well for us there's there's a few now that are using next.js and we've been working with Versailles and Google about how to tune that With POC and with cynical supper, which is a svelte equivalent of Next yes, but this application loco is is like a proxy of how to orchestrate our microservices So if a certain route comes in it looks like this pattern You need to call this microservice and then it did a bunch of like business logic as well So the the main point was and my fear when when I started looking at it was this is a single point of failure It's a bottleneck that all the requests have to come through to decide what what HTML a customer gets back So performance was was absolutely key so we built a POC in Go and it had like super high throughput and concurrency We built one in Just know JS it was lower We built one in express and it was still lower than we were happier with so then we tried out fastify And you know we started using multiple cores and we felt like we could we can't compete with With go but we could we could get to a level of parity that we were happy with so Yeah, performance was was key I've also worked with Mateo from near-form multiple times and you know, he's a he's a performance genius and they're so Obsessed with performance We knew that that was the kind of right framework for us because we needed that that enthusiasm to keep it going and Yeah, those and you know working relationship with Mateo near-form They've come into our company a few times and some training When you were on to a winner as soon as we started looking through that That's great And it's it is good to see that project grow and and get better every day and probably with your implementation We're all everybody's learning as they go as well. Yes, we were you know We were adopters of like it uses the log of Pino, which is in there. We were already using that in all our applications anyway You know It's a great project. We don't have a Huge need to move some of the other applications. They don't have that level of throughput requirement So express works, you know fine for them, but with this The amount of throughput that we wanted this to do it was super important and important for us and As it's been an Approxies basically network bound. So that's where like all the latency is is calling these services, but when we were Doing our performance tests Check-in for bottlenecks, you know, the compute time of a request when you take out the network is like Under two milliseconds usually so it's super fast churning it through. So yeah, we're really happy That's great. Great to see those results. Cool. Very cool Sounds like you're working with a few other open JS foundation projects probably amp. Maybe did I hear that? so about my role on the Chrome advisory board is that I've been involved with amp and some of the other things since since the get-go and also I was traveling with some other Conferences we we haven't got a huge adoption of of amp yet We've looked at it in different senses. I think we there's some web open standards questions that we have as a development team around around amp I but I know that the editorial parts of the company are really interested in it But yeah, we're not huge adopter yet, but we have looked at it Oh good And I know they're building out an advisory team as well. So lots of opportunities to give input there. Yeah. Yeah Yeah, and definitely part of working different Google working groups. We we have daily dialogue with the the Google team and their dev rail team So I think there's been a couple of POCs. It's just hasn't been massively prioritized for us yet. Great So I know that you like said you've been there 10 years and so you kind of you have that luxury of having that sort of big picture I mean, it's hard to say you have a big picture, but you probably do given the history So what's sort of next on you know for your engineering road map? What's your so? I think like the big thing for us is performance as you know, most people say I think I Performance is traditionally been quite a hard sell. I don't think that the tool chain was good enough to begin with like Collecting performance data was a bit hit and miss the browsers weren't offering enough But yeah, the now the browsers have good implementations of performance metrics You can you can quite easily start to correlate. Okay You can bucket people off for good performance bad performance or whatever and then look at, you know On your KPIs for business conversion bounce rate these kind of things. So that's that's a huge thing for us as I'm sure it is for everyone but The a really interesting thing is if you know the core web vitals, which are first input to lay largest contentful paint Cumulative layout shift. So those now a measure not just performance, but good customer experience So is the website nice to use? And if you look at Google's search tools now They are starting to add the core web vitals does your website have core vitals and based off your users crux report so it doesn't Take a genius to start thinking well Google and now we're going to start Either badging good UX or they're going to start ranking based on good user experience So it's not just a case anymore of okay. These can affect your your business KPIs These could affect your business rankings or these could affect your natural search so for us that is a big that's a big question and Many people have been down the journey already, but you know Stopping to use rest As your API endpoints, you know, maybe building something a bit more flexible That's something that we're looking at another big thing that we're looking at is zero runtime frameworks I think it's an industry problem of JavaScript bloat in the browser like we've just shipped more and more JavaScript and in the luxury department we we don't have the problem that other companies do so much because About our barrier of entry is already high, right? We sell watches that are 200 000 pounds. So the adoption rate of New phones is high. So we have the luxury of having high compute phones good memory And generally I think it's 95 percent of our traffic is is 4g So we're lucky, but we still want to take our website on a bit of a You know, so cut some JavaScript loads. So we're looking at different zero runtime frameworks like Svelte To to to see in the future what what that might look like At the moment, you know, it's just pocs. We're still migrating and we've just got some ideas But we're also working on next.js with the versel team and with google Uh to help, you know, improve performance there, but that That I think for the next year is is probably what we will look at As well as more experimentation We've been writing some interesting stuff for kubernetes to to roll out applications at different experiments So your server side rendered a b testing through kubernetes. That's quite interesting Yeah, those are the big things I think for us, but a focus on Web vitals, I think is going to be big for everyone in the industry For the next year, I think Got it Okay, and I have one question. I always love to ask devs So when you go to work What's a good day at work for you? Um Not back to back meetings. That's the dream You're gonna if you get a day without meetings. That's uh, you know, that's the highlight um I like to I bounce off people's energy So I really like to see what other people are doing and just geek out, you know talk about it But I mean People in work get a bit distressed by this by me, but what I really like Because I've been working in sre they're like the last six months Is I I like when things go wrong, you know, uh when things break It's like the closest I feel like I come to a detective like you're looking for clues Trying to find the smoking gun of what what caused the issue so I think that Like that's where like the adrenaline and the excitement if something goes wrong. I I really enjoy that. I not too often, you know, I want the customers to have a good time, but When something goes wrong, it's quite exciting. That's very cool inspector robin, right? Yeah, that's all I like Well, we're just delighted to have you part of our community and like getting super excited To hear about all the cool things that you're building at netta portet and wine app and all those cool brands that you have so Really, thanks for joining us and we hope that you pop back in and share Everything that you know when they're learning along the way Of course and it absolute pleasure to be asked. It was really nice to be here and chat to you guys