What’s the FEaaS all about?

If you want some reading material on this topic. We also wrote a helpful blog on this topic https://goodfrontend.dev/stories/buil...

0:00 - intro

00:01:07 - what are the benefits of a Frontend-as-a-Service?

00:02:16 - name some of the challenges of using Frontend-as-a-Service?

00:04:26 - how is this [FEaaS] different to what GFED is offering?

00:06:23 - What type of organization would suit a Frontend-as-a-Service solution?

You're watching "The Good Front-End Show," a podcast that gives you a weekly dose of inspiration and insights from GFAD's technology leaders and engineers. Join us as we explore ideas that enable technologists, marketers, and organizations to create successful commerce storefronts. Let's begin.

Welcome back to "The Good Front-End Podcast." I'm Karl, your host, and I'm here today with Kane, and we're going to be talking about "Front-End as a Service." "Front-End as a Service" is a subset of Software as a Service (SaaS). If you think of SaaS for different types of products like search CMS or commerce, it's a software that lives online, and you effectively rent it.

So, the idea of "Front-End as a Service" can sometimes mean front-end developers offering a service. But more commonly, "Front-End as a Service" is when an organization creates a front-end product that is then used to solve front-end application problems. That might include UI components, front-end hosting, API orchestration, and integrations.

What are the benefits of "Front-End as a Service"?

I think the key benefits when you use "Front-End as a Service" are time and cost. Time because that organization offering you "Front-End as a Service" has already developed this application, and if this organization is quite mature, they would have iterated over this product. So, it would save you a lot of time developing something. The other one is cost. It can be quite cheap when you use our "Front-End as a Service" out of the box. So, time and cost go hand in hand together when you are using "Front-End as a Service," provided, of course, that you stick to how they've decided to integrate the different APIs, you stick to the same hosting solution, and you stick to the components that they provide where they spend time on.

Can you name some of the challenges of using "Front-End as a Service"?

For the most part, "Front-End as a Service" can be beneficial, but depending on the context, it can be a barrier, actually. Because if you want to do heavy customization, it might mean that it takes you longer to do something or you have to work around the product to be able to get the type of integration that you want. The other challenge, of course, is that because it's a cloud service, it's an ongoing cost. So, if organizations are happy to have a front-end application and pay ongoing costs for that, similar to their SaaS APIs, then that's okay. But that can be a challenge because, for the most part, most organizations don't really pay an ongoing cost to maintain their front end. The other challenge, I guess, that I can see is it can be a sort of vendor lock-in. What I mean by that is, depending on what this "Front-End as a Service" does, more often than not, the front end can be the place where a lot of the business logic is integrated. And that's typical for headless commerce and composable commerce solutions. So, if you integrate a lot of your business logic into that application, then it will be hard for an organization to scale out of that should they need to. And scalability is a big deal when it comes to front-end applications, and it could be a problem in the future.

How is this different from what GFED is offering?

I think the question really is, is that "Front-End as a Service" a service or is it a product? GFED offers a service solution. We offer, similarly to "Front-End as a Service," we offer a "Team as a Service." It's similar in a way because, as an organization, we have what we refer to as accelerators. So, we have pre-integrations with existing APIs that are quite common, whether that's a commerce API, content management system, or search APIs. We have the architecture set in place already. The difference is that we do not charge an ongoing subscription. We charge for the team effort to further customize that accelerator. And then, after the ownership of that application is to the client. Whereas "Front-End as a Service," you're effectively borrowing a product and then building on top of it. So, that's the key difference. We offer a service. It's almost like we are builders of a house, but we give that house to the owner once we're done building it. Whereas "Front-End as a Service" is like renting a house. A client comes in and borrows some office space, perhaps in the building of that company that offers "Front-End as a Service." So, the philosophy is quite different. One is more renting or borrowing, which is "Front-End as a Service," whereas GFAD, when you take Chief and "Team as a Service," you're borrowing our team to develop your software, but the software belongs to you.

What type of organization would suit a "Front-End as a Service" solution?

What I would say is organizations that probably don't require a lot of customization. There is a certain level of enterprise that if you reach it, I would definitely say don't use that solution. So, probably lower mid is a good idea where "Front-End as a Service" can bring the most value just because you can save a lot of time and cost since everything is pre-integrated and pre-built. So, yeah, I would probably choose a "Front-End as a Service" if what needs to be done is lower mid enterprise, if you like. But larger enterprises or maybe mid-enterprises that want to own their integrations and they want to own their differentiation a bit more tightly, I wouldn't recommend it, especially if you're working, for example, with GFAD because we will offer you an accelerator anyway. So, I don't really see the value in that, to be honest.

Thank you.