In House Frontend Architects

• ^{0.00 - intro}
• ^{0:00:37 - Why is having an in-house frontend architect good for brands and retailers}
• ^{0:01:13 - Purpose and History of API}
• ^{0:03:14 - Technical experience in frontend}
• ^{0:04:00 - Why prefer In-House frontend architects?"}
• ^{0:05:23 - How are teams enabled to move quicker?}
  
• ^{frontend, javascript, programming, developer, coding, html, css, webdevelopment, ux/ui, frontenddeveloper, frontendmentor, frontendconf, frontenddesign, frontendux, frontendjs, frontendcss, frontendhtml}
  

Hi, my name is Karl. I'm one of the co-founders of Good Frontend, and today we're gonna be
talking about the importance of front end architects. So you are an advocate for, frontend
architecture.

Absolutely.

Why do you think it's a good idea for Brands and Retailers to have a frontend architect in-house

In my experience, having implemented a few projects using headless commerce, using
composable commerce, the projects that do best are projects where you have a frontend architect looking after the project. If you think about headless commerce, composable commerce, microservices, frontend architects really are in the best place to guide the team to know what they are doing. Firstly, APIs really are designed to serve other developers, mainly frontend developers. So historically we did everything in the backend. For example, we have this technology called Spring and uh, we had something called MVC, the Model View Controller. And the idea was of that was to separate the Model, the View, and the Vontroller and developers would create this Model that comes from the database. The Controller would then manipulate this data and then present it to the View. Of course, there were a lot more different versions of this before MVC came about, but MVC was a big deal when it came out.

And that was great for frontend developers because that meant that we could own the View, the presentation layer, which is presented to the customer. Over time, however, as frontend matured, we realized that we needed more control, we needed more control over the performance of the application. We needed more control over the search engine optimization. We needed more control to how dynamic and animated pages are. We wanted to do Single Page Applications. We wanted to take over, the website routing and so on. And so the conversation began and someone came up with an idea of, why don't we just provide you an API and we can do whatever you want. Okay. We just give you the data and you can do whatever you want. And there APIs were born that was designed to serve frontend developers so that they can have more flexibility to be able to do the things that they want. And so when we think about things like Headless commerce, Composable commerce, APIs, these are all designed to cater for those developers who care more about the View, the presentation layer to consume those APIs. So when it comes to projects, they're the best place to do those types of projects.

So you're saying it's a lot to do with their, technical experience in, in the frontend?
Yeah, absolutely. Absolutely. When it comes to those types of projects, headless commerce,
composable commerce, there's not much experience required from the SaaS perspective
because the idea of SaaS is to eliminate the custom code, eliminate the person that sits behind that code and turn into a product. So the expertise required for, for that side of things is no longer required. Right. The SaaS product now does that expertise. And so the only person really here that is most important, if you like, is the one consuming those products and creating that experience that is to the customers.

But why in-house, why not just bring in a consultant to do their job? That's a good question. Just before we were planning to do this podcast, I was thinking, should we add this word in-house or should we just make it as a generic for an architect? How important they are in the role? But I would say that preferably every organization should aspire to have a frontend architect in-house. I know that they can often be quite rare to find, but that should be an
aspiration for every brand. And I say that because this role is growing, this space is growing, and you want to be able to retain that knowledge in-house ideally. And you want someone advocating for your brand. Of course, there are consultants that can help brands and retailers like ourselves, right? We're fronted architects. We can help them, we can help drive the roadmap, we can help them with best practices, technical oversight, and all the things that are important. But when it comes to what is the minimum technical team that you want to keep in-house, I do think that front end architect should be one of them just because of the scope of work that needs to have a level of governance, if you like.

I see. how do they enable teams to move quicker?

Frontend architects, I would say that they have three primary roles when it comes to their job
description. Firstly, as I already mentioned, is technical oversight. So they enable teams to move quicker because the oversight is there. For example, they should be the ones responsible for component reusability and brand consistency. So when you think about the components in the website, often people think, why, why does this look so different from that page to another spacing is not there. I think that's because of lack of attention to frontend architecture. And that is one of the things that frontend architects should be doing. They oversight the non-functional requirements like Lighthouse reports from Google Lighthouse, we now kindly Google has produced this metrics that allows us to do our jobs a lot easier because it automatically does an audit to your website so that they should be responsible for that.

And, but also they are responsible for API integration approaches. So they allow teams to move quicker. Cause they provide this overarching oversight of how things should be done. If you think about, again, the scope of work that needs to be done in, in projects such as headless and composable, there is a lot of things that needs to be thought about, but a lot of that ultimately needs to be integrated and serve to the customer as a single customer experience that is fully integrated. And for you to have a website that feels like it's together, you really need to have that level of technical oversight. It's a full-time job. I don't think many people realize that it's a full-time job and many projects fail because they don't have a person performing that role.

The other thing that I would say about this matter in terms of how they allow teams to move
quicker is that frontend architects, they ought to be the bridge between the technical teams and the product designers. The UI/UX teams, again, frontend role is quite vast. You have front end developers who are quite brand oriented. You have frontend developers who are quite technically minded. You have frontend developers who are, uh, pretty good at uh, uh, marketing and so on, you know, but frontend architects idea is that they have an overarching understanding of all these concerns. And so it enables them to be in the bridge for different parts of the organization, the technical side of the organization, and the non-technical side of the organization. And finally, it's also about having someone who can be a soundboard for technology adoption. Frontend is a very fast moving place.

We have frameworks every six months. It's the running joke that we have. You know, we, we
always have new frameworks, we have React, but on top of React, we have a bunch of
frameworks. Like NextJS, we've got Astro, we've got Remix, and just when we think things are booming. Create React App gets sunsetted, Remix gets bought out. NextJS gets funding. And so everything changes every six months. You need someone to be able to really understand how to predict the future, so to speak, based on existing patterns that are already happening. And being able to do that will allow you to adopt technology at the right time without wasting time. And so when it comes to teams, a lot of them get stuck because one, they either adopt, adopt technology too late or the other on the other end of the extreme is they adopt technology too early.

There is no, uh, formal wisdom in terms of choosing when to do certain things and those
technology adoption decisions because there is no frontend architect, happens at a much lower level and can often be detrimental when it's the wrong choice. You know, you, you know the classic example, right? Many people do nowadays, micro frontend architecture and then they think it's this, you know, the business. Such a great idea. Yeah. Let's bring microservices to the frontend. By the way, I, I am, uh, an advocate of micro frontend in a way. We have used it in multiple projects, but I'm just saying this because many people fail when they head up this architecture, right? Because they, um, take on this architecture and, and then they read a bunch, a bunch of blogs and they think they can do it, and then they put on Webpack Module Federation. And then all of a sudden it's not working and no one in the team can solve it.

And so you, you go live and you see people selling solutions to this specific problem. So what I would say is that if you had a frontend architect in projects like those, those problems will not happen. I, I'm working on a project right now where we're using micro frontend and it's perfectly fine. You know, we've, we've come up with a, a wonderful strategy of understanding what is composed at runtime and what is composed on built time. And it's quite performant. We are able to scale teams, you know, in their thirties, forties, and so on. And we are able to produce work a lot faster. And again, that is just down to proper thinking and planning and architecture of how the systems are built, especially on the frontend, which is in a composable project, is probably 75% of the effort required to make things happen.