Full Transcript
Mitchell: Welcome back. Welcome back to all friends of Solspace. This is the Solspace Podcast. This is a follow up episode in a conversation that I'm having with Gustavs Gutmanis and Ivars Bariss. I completely butchered your names, but I'm not gonna edit it out because why not? I mean, it took me, it took me years Ivars to call you “Eee-vars” instead of “Eye-vars", and people are still doing it. They can't seem to help themselves. But at any rate, Gustavs is our lead developer on the product side at Solspace. He's responsible for freeform and calendar and basically any plugin that we sell. Whether it's craft CMS or Gustavs, I'm sure regrettably ExpressionEngine at this stage for you. There's still a market there and it's still working. Actually, it's possibly gonna stage a comeback. So we're watching that carefully.
And Ivars is the director of Operations at Solspace, and we're talking about headless, and we're probably gonna be talking about headless for a while because we have seen a lot of activity on our existing clients.
And Solspace normally has clients for many years, in some cases more than a decade, and we're helping them to maintain websites, and really the effort is to make those websites over time more reliable every day and have less friction every day. That's what I care about. Those two things usually turn into money for our clients, and that's the principle reason they keep us around and find value in us.
So we're talking about headless, but today's topic is we're gonna talk about a new project that we're starting internally that I think is something that other people will be able to access. Hopefully, you know, as sort of a free tool we're seeing that clients of ours and incoming clients are, there's an argument to be made for transitioning their, transitioning their websites to a headless architecture and the argument is much easier to win with a new client if I can tell them that they can do it in phases, they can do it gradually. Anytime I have a client who's uncomfortable about the big push, the big timeline, the big budget to make a big change on the website I always put them at ease by saying, we always go in phases. We break a big problem into smaller pieces.
So an important part of converting a site to headless is that you can do it in chunks. You don't have to do it all at once. For example with Here Comes The Guide, we moved them to Meilisearch. That's just one part of the website. A critical business part of the website is now headless. It's using a separate search search API with separate indexes that we custom built. And it's pulling that in with Vue.js.
So Gustavs is gonna start working with other members of the team on creating a bootstrap, sort of a framework around ReactJS. And this will be sort of a standard that we adopt for the headless websites that we're gonna deploy. And in some cases, I'm imagining that we'll deploy this bootstrapped framework in advance of completely converting a website over to headless. We'll do that gradually, but after this framework is in place, I could be wrong. You could shoot me down on that. But Gustavs, can you tell me what your thoughts are so far on this idea?
Gustavs: Which part? Exactly?
Mitchell: The part about setting up this, you're gonna take ReactJS and you're gonna create this bootstrapped version of it that other people on the team can, can start with, can use as a starting point, kinda speed their development along, because the problems are gonna be standard across a lot of different kinds of client sites.
We shouldn't have to reinvent this every single time. So for the sake of speed and cost, we want to have sort of an underlying best practices type of a framework that you're gonna develop and be able to deploy that. Maybe you can tell us a little bit about you know, what are the components of it? How, how are you thinking about it in its different component parts?
Gustavs: Right. So the idea is to speed up the development process of any team that is willing to create a new project in React and start employing the headless services that are available. And the idea is to make a bootstrapped version of React, specifically built for our team with our guidelines, our code style and everything. And with several APIs in place. Interfaces, which let us connect to any of the headless CMSs that we are going to use. Like, for instance, connecting easily with Contentful or connecting easily with Craft CMS just to make our process of development faster.
Mitchell: When you set this up, is it and I'm gonna borrow the term monolithic. Can I use the framework that you have in mind? Can I use it gradually? Like, can I take one portion of a website, for example, this work that we did on Here Comes The Guide to move them to Meilisearch. Not every page on the website was affected by our Vue.JS changes. It was just some sections, some critical sections, but just, just a few. Could this be used, like is do you have to make this a wholesale conversion or can you use your, the framework you're gonna be developing in, in pieces and do it in phases?
Gustavs: It is possible to use it as a part of your existing page, but the main idea is to create an easy way to set up a front end layer for your headless data. So you can easily spin a new server up with the bootstrapped version and it's going to run your site. So it's going to be easy to create new pages and use whatever headless content that you have in those.
Mitchell: What's gonna be involved with let's, let's say we wanna deploy this for a new client and where we've managed to convince them that moving gradually from where they are to a more headless architecture is gonna create a lot of efficiency for them. But they don't necessarily want to go through the process or pay for. A redesign of their front end website. They want to use their existing design. How hard will it be for them to retain their existing look and feel but convert that to a React model. Like how, how does, how does react work in that regard and how are you gonna set it up so that say the navigation, the landing page of type view forms and so forth. How, how can that conversion be done? Is it gonna be difficult? What's involved there?
Gustavs: Well, it most likely you would set up a specific page, which would load this react framework, which would then take over the page. You can create when using React specifically, you can create portals which reuse existing parts of the page.
So you can use your React app to modify some headers or navigation or, or just the content in the middle or what have you. So it's easy to inject your React application inside any part of the existing page already. So for instance, if they would like to create generic, I mean not generic, but landing pages for their marketing content, they could create a single dedicated page that buyers up the React app that we make, and the app would then pull in the marketing content from whatever headless CMS they employ.
And display it on the page. So it would cost less, significantly less because there would be no need to redesign everything, create from scratch, rebuild it in react. You could just take over a single page and just inject the content that's being fetched from elsewhere, In that specific page.
Mitchell: That's awesome. What's the pathway? Let's just, let's imagine it's, you know, one of our client's craft websites and it's currently coded in twig. So the twig templating system in craft is owning it. Right. What does it, what does it feel like to convert from the, the sort of the, the structure that, that someone's used in a given twig template? You know, looping through the output of the database and so forth, converting that to make it. Turn it into React components that are fetching from an API. Is it a complete rewrite? Can you borrow some of those concepts? Like what is that like?
Gustavs: Well, you can start out by just re-writing the React front end and still use everything that you have in place so you can get all of your navigation, your entries, and everything that's already inside your craft page and displayed using React.
So that way you just do half of the job instead of moving everything to headless. And then afterwards, when you're ready, you could create the headless CMS or move out the craft part to a different server or move the react part to a different server and join them by using APIs instead.
Mitchell: Ivars, how, how quickly can we start deploying this idea to our client sites? I mean, I know Gustavs needs some time to build it, but do you see a need right now or do you see a need coming in the next year or so?
Ivars: That's kind of a thing that we mentioned in the previous episode, all those situations when we are already actually building in these kinds of headless approach type functionalities.
So for example, if we have this kind of boilerplate for React, I can just see that whenever there is a next time when we have to build the next shops configurator or anything like that, you can just start to use this kind of base. I would say that it's important that there is a need for that because sometimes a standard monolithic website just works. But eventually when you grow out of a standard website and you start to connect these bunch of services, then you will certainly have a need to to implement this.
Gustavs: Well, the biggest question is does the client need to scale? Because scaling becomes extremely hard with the monolithic approach. Once you start moving to, like, having different franchises in different countries when you have larger and larger sets of teams you definitely need to go headless if you're planning on scaling.
Mitchell: So what does scaling mean? What do you mean by that? Like, scaling for traffic or scaling for you. You mentioned you know, multiple countries, multiple language websites. What, what does scale mean?
Gustavs: So for instance if you use a headless CMS and you have a front end layer, which consumes that headless CMS's data and you are opening up in several different countries, scatter across the globe, for instance Europeans accessing your United States server would see really slow loading times. So you would like to create another server that's residing in Europe so that people get access to your site as fast as they can while still retaining this. You wouldn't wanna clone your whole monolithic server clone the database and keep the database clones in sync. You would instead just create another instance of the front end layer. You would probably use a cloud system for hosting it such as AWS or, or Digital Ocean or Google Services, whatever. You would spin up another instance that would then connect to the database of the headless CMS via API and FET data and display as fast as possible in their region. That's a nice way of scaling. It's just not possible with monolithic architecture.
Mitchell: Well, unless you're really aggressive with caching pages, caching full html. We often do that with CloudFlare and, and we will inject the dynamic components into the page as needed, but for the most part, we can cache the entire thing.
But that has another set of challenges that are really annoying for our clients. Once we solve the scale problem, and their site loads really fast because of caching, they're next annoyed about waiting for the cache to refresh. And sometimes it doesn't happen immediately. So they hit the button many, many times and it creates additional problems.
This is another reason I like the headless approach, is you're doing some decoupling that's really intelligent that way. So with this React.js, bootstrap, you're, you're gonna be developing. How is it gonna conflict with existing JavaScript libraries on an existing site? I mean, any given site that we work on, whether we inherited it from another agency who built it, or freelancer or, or internal team.
There's always a lot of JavaScript stuff, usually outside marketing services that get loaded in there. How do you manage the conflicts across those different libraries with your bootstrap? React.JS framework.
Gustavs: I've never run into any conflict in existing pages using existing JavaScript and implementing a React app on top of that, unless they are using some sort of React components, like parts of React, if they're using those, then there would be conflicts. The conflicts would be of React versions. You would probably be on a newer version than that of that site, and that's when conflicts begin. But even then, it's possible to load two sets of React libraries with different names so that you can use yours separately from the one that already exists. So there are means of bypassing that.
Mitchell: Why react? Why not view or, or something else?
Gustavs: It's a matter of preference. I think personally that view approaches the reactive framework from the wrong side. You write HTML templates first, and you use HTML templates too. Do loops and, and pull in data and it doesn't look as good as React because React uses JavaScript first to create HTML components. And in my mind that's, that's the correct approach.
Mitchell: So you walk me through an example of like your, your bootstrap is gonna have to have an accommodation for navigation. So what is that like? How many components is that? How will you set that up?
Gustavs: There's a library called Reactor Router, which lets you effortlessly create pages and they expose components which can be used as links, so you can easily link to other pages in your app. And what happens is when you click, click a link, the URL changes. The whole application renders the correct parts how you've set them up. But the page doesn't refresh. Actually, it's still on the same page. It's instant. Everything's beautiful.
And when you refresh, this is the cool part. When you refresh and you have the URL that's been changed it opens up the correct page. That's pretty cool. It's hard to explain. You have to see to believe it. It just hydrates everything to the place where you are at in the URL? So basically, the URL determines which components are being rendered in which parts, what, what does hydrate mean? Hydrate means that you load HTML and then JavaScript determines which parts to make active and which not to make active.
Mitchell: How does this fit, you know, this page load model that you're talking about, how does this fit in with Google Analytics? I mean, this is one challenge we're working on after this launch that we did with Here Comes The Guide. So they got this Meilisearch up and running. It's nanosecond fast compared to multiple second load times for filtered pages. It's so fast. Google's not keeping up. So we need to do another cycle where we send events to Google Analytics. Is there something that you're thinking about in these terms?
Gustavs: You have your Google events, analytics, JavaScript, and you write hooks and react, which send events to Google whenever you navigate somewhere. It's all depending on the setup that you have, the client, each client has their own way of doing events, right? So it's a matter of business logic.
Mitchell: Well, one of the goals for this bootstrap system that you're developing is that we, you know, a lot of our clients are fairly large enterprises and they have internal policies from their IT teams. That mandates that they revisit their technology choices on an interval, but usually it's three years, sometimes five. It happens faster if they have, you know, a new VP of marketing step in who's gonna reevaluate all the technology and platform choices. And one of the great things about this idea is we'll be able to quickly, and this is my question, how quickly spin up demos. No. So you're evaluating your craft CMS website, and you're asking questions about is it still the right platform? Well, we can quickly spin up demos on a, a version of your site, a few pages running on, say, Contentful or Sanity.io or some other system like that, or a, a, a headless version of Craftcloud or something like that. So how, how quickly do you think we'll be able to do that for a client who's interested in it? And, addressing that because really it's an existential question for us because the client is saying, we're ready to fire you. Because we're reevaluating the technology and that usually means we're gonna get rid of the technology. And that means you usually go away. I'd like to retain that client. I'd like to retain that relationship because we've built up so much trust and understanding and business logic, understanding and all that sort of stuff. So this is like a retention device, but how quickly can we use it?
Gustavs: Well, it's a matter of if everything goes as planned. Of course, then it should be a matter of days. Being able to spin up an instance of Contentful. Well, first of all, you have to register and create the content in Contentful to display it in our bootstrapped application, right? So you spend some time there and then you create the actual application, which is. Minutes, I guess. And then you pull in the content from the Contentful CMS and create some components and display it on page. If you have the site already there, then using React, then it should be basically no problem at all, using existing components and just presenting the new data that comes from elsewhere.
Mitchell: Ivars, how are you gonna use this?
Ivars: Well, on our end, one of the challenges is that we want to become more scalable and flexible within the operations team. And to really do it all developers have to understand the tool that we are using. So if we have such a standard base for these projects, then we can easily, quickly onboard any kind of developer or any amount of developers on a project. And they don't have to spend too much time to understand the project and set up. So that's one of the reasons on, on our end, why it's valuable. And also for clients, really it's valuable because that also introduces quality. We've tested out this kind of tool at that point with many, many clients. So you already know that it'll be solid and Sometimes client needs to do some kind of a rush, job rush project or something like that. And it also allows us to add a bunch of new developers on a project and they wouldn't be surprised what's under the hood.
Mitchell: Yeah, that's good. We sometimes will pitch in and help other agencies when they need overflow and, and they come in and help us if we were standardized, if we were even able to open source this and have this, you know, that's one of the questions you ask another agency, are you using so and so React bootstrap? Yeah we are. Ok. Then you scale, you're instantly faster and there's better understanding. This is a problem that we had this summer and it was, this would've been nice as an additional thing to help buy insurance on the timeline that we were facing. What else? Do you see any other benefits to this?
Gustavs: Well, it's more modern. Compared to monolithic approaches. And if it's standardized enough and people have been using it for quite a while, then I guess it's also way cheaper. Like you'd get the same quality and for more money, right? You basically, this would make it cheaper for a client.
Ivars: And also, I am I'm hoping that eventually we can grow it out with some additional standard features that are always necessary for clients. Those are usually form submissions. Also, your mentioned connection with CMS and E-commerce, if we have something like that and already tested and proven in a bunch of client projects. Then you know, you just know that you are going to have a really solid base.
Mitchell: What's the competitive landscape for this? I mean, this idea is a good idea. Surely it's been done.
Ivars: Well, I believe that any agency or company or even group of developers have their own type of boilerplates. It's kind of, as Gustavs has mentioned, a matter of preference as well.
Gustavs: It's nothing groundbreaking. It's, to be honest, it's just tailored for our needs, right?
Ivars: The other, I guess the, the unique part for our setup would be really this, API or CMS API level of interaction because you know, we are known as a company for working with CMS right now with Craft CMS, but also they're gradually moving to others as well. And that's our strong suit. That's, that's the thing that we know and we just want to make sure that our base is really able to consume any kind of headless CMS and also in a way how we want it to be consumed. Because one of the things that we always implement in our client projects is, for example, page builders, where in the CMS, we have these flexible blocks based page builders where you can easily create any kind of page with your set of components and we for sure have to implement in our boilerplate an assumption that that's how we will create our pages.
Gustavs: Also, with this kind of project, I wanna mention as well that we can create boilerplate templates for Craft CMS and for Contentful as well, where we already have blocks of content models ready to go. Like we could instantly create models for navigation, for pages, for different kinds of layouts. Stuff like that, it's also possible. So we would probably definitely go there.
Mitchell: The page builder idea is a sure thing that we're already seeing a lot of demand for.
Ivars: And you know, who can do it better than we might. We've been working with Craft CMS in our specific page builder setup for so long, So, I'm excited to see how that translates in the React world and in a standard solution that we can always offer to our clients.
Mitchell: That's gonna save a lot of money. It's gonna be easier to write proposals that hit a price point that's comfortable for the clients. I'm just, we need to find more efficiencies like this. I'm excited about this one.
Gustavs: Well, maybe famous last words though, and it comes with scalability as well, which is cool. Definitely.
Mitchell: And again, what kind of scale is it? Are you talking about scale like we were mentioning before about adding more team members to a project and scaling up the speed at which you can build? Or is it a different kind?
Gustavs: Well, it's, on all sides, right? You can increase the number of people developing the site. It can increase the number of people editing content. What do you have, or increase the amount of servers to meet the demand? If, for instance, you're running into issues of the page not loading because of too many requests, you could easily spin up new instances which alleviate this issue.
Mitchell: Well, let's wrap up. Any, any last comments before we conclude this episode?
Gustavs: Not for me.
