Full Transcript
[Music] Welcome to the Solspace Podcast. Thanks for listening.
Mitchell: All right, everybody. Welcome back to the Solspace Podcast. We were on hiatus for a little bit of time. Doing a lot of client work and taking care of some projects, but we're getting this going again because there's a lot of technology conversations that I think we need to have as a community and certainly within my own company.
We need to sort out some things. Today's episode is going to be in the vein of headless. So the question I want to ask, and I'm asking our lead developer on the product side of Solspace Gustavs. Gustavs, check my spelling of my pronunciation on your last name. Was I correct?
Gustavs: Yeah, that's great.
Mitchell: Okay. That's a relief. And Ivars Baris as well. These are by champion Latvian developers and managers and coders. Ivars is now the director of operations at Solspace, a recent promotion that I'm really excited about. And one of the things we're doing is we're getting everything in alignment.
With how we tackle technology and how we help our clients create reliable websites and reduce friction on those websites. So today's topic, I'm gonna be grilling Gustav's on headless in. The specific question I want to talk about was prompted by a launch that we did last week where we launched a new Maili search implementation on the the site of a longtime client of ours.
Here comes the guide. And melee search is like Algolia. It's this search appliance that you can add onto a website. It's run on a separate server. You access it by way of an API. You build up some kind of JavaScript I implementation on the front end to access that search API. And you build the index by pushing.
Data to the API from your cms. And I'm calling this headless, and I'm gonna be corrected by Gustav. I'm calling it headless because there is a JavaScript that's accessing a separate service by way of a J S O N formatted API. And it's drawing and building the page from that API's results in, in real time.
So, You can cache portions of the page, but the core part of the search functionality is dynamic by way of this, what I'm calling a headless connection with this separate API. So my big question for Gustav's is, first of all, how can we define headless properly? And second of all, with that definition I, is it possible for clients like ours to gradually move their websites into a headless state?
And would they even want to, like, is there a benefit? So Gustav, if I can throw it to you and I can ask you, can you talk to me about how you define what a headless website is?
Gustavs: Yes. So a headless website is a site that doesn't have a backend layer. It's just the front end layer with the HTML and JavaScript running, and all the information and everything is being fetched from outside services.
And this is where the headless CMS comes in. It's a service which runs the server that hosts the CMS for you where you can go and edit whatever stuff you want. And then it exposes API endpoints where you can get the data from that server. So it doesn't matter where you access the data from, it's always gonna be able to supply it to anything that is contacted.
So it's separated. The CMS is separated from whatever medium you use for the front end, be it via web application mobile application or whatever have you. I guess that's it.
Mitchell: Okay. What, what are the other requirements for you to consider it like a, a bonafide, headless system? Does it have to use, say, a GraphQL? You know, as the sort of the standard data exchange layer, the kind of the language that the server speaks to the front end webpage.
Gustavs: Well, it doesn't matter what the transport of data is, it's as long as it is possible to fetch data in any way. So it doesn't really matter.
Mitchell: Does it have to be one service or can it be more than one service that the presentation later is calling out to, to get data? Well, it can be a number of services, but usually it's just a single service, which does one thing.
So maybe you have several services from where you get the data and you combine all of them in your front end layer. What are some examples?
Gustavs: The search you mentioned, that's that's one service. Then for instance, Contentful, that's another service that's the headless CMS part where you can have your translators and content managers and everybody work in a single environment where they know everything inside and out.
And then you can distribute this content that they enter to any other part of your. Ecosystem. Okay. Like some front ends, landing pages.
Mitchell: Okay. Landing pages, e-commerce, whatever. So in the context of e-commerce, if I mean, is it, is it conceivable that you could have, say a client who's managing their inventory and fulfillment and transactions in, say, Shopify, but use a separate CMS for.
The content marketing side of their e-commerce website, business. Have you ever heard of such a thing like this?
Gustavs: Yes. It's actually how it's usually done, I think. Okay. You have your, it separates the concerns. You have people who are let's say responsible for entering data about your products. And managing inventory. And then you have people who are responsible for managing content and marketing related stuff on your site. So you want to have them have their own tools instead of getting everyone the same.
Mitchell: Same system. Okay. Where does the transaction take place on such a site? I mean, if you can think of some examples that you've, that you've dealt with or worked on, you know, you, you're pulling in the inventory you're pulling in the SKUs, product descriptions, images of products that are gonna be purchased. And then you have a customer on that e-commerce website who's loaded their cart with stuff they want, you know, whatever it may be, t-shirts or pipe fittings or whatever the case is.
We see lots of different kinds of clients using this idea. Where, where does the transaction take place? Do they, do they do it on the primary site still with API calls to Shopify? Or do they bounce off to Shopify to complete the transaction?
Gustavs: Well, it depends on the setup, but if we're talking about Shopify, I'm, I don't really have much experience with Shopify per se, but I would think that Shopify has API endpoints exposed where you can send the selection the user makes to create an order, and then to, there's another service Shopify gives you where you can create a payment. And then handle the shipping and everything.
Mitchell: Okay. So you, you at Solspace, you lead the effort to build an aversion and feature and, and maintain our freeform plugin for Craft CMS as, as well as the other products. So that's really the most widely used and adopted of our products. So this question of forms on a headless website. Can you explain to me a little bit about what you know, if, if there are components of headless are the forms possibly a component that can be part of the headless model and how does that work?
Gustavs: Yes, actually that's pretty common. It's usually when you create a single page application, which doesn't have a backend server running, there is no means for you to validate the forms. To store the information that's being entered in, in, into them or send them to any other CRM integrations that you might have. So there are a plethora of services out there, which give you the ability to create a form and to embed it into your site without effort. Just a single line of JavaScript and the form shows up in your site, and then whenever anybody fills it out, On the server that provides the form, it handles the validation, the storing of the data, whatever integrations you might have. So nothing really happens on your server, it's just being displayed on your page. That's a great example of using a headless service.
Mitchell: Okay. But is there, is there a model where the developers, who the developers are owning the presentation layer? So they're, they're owning the page. And that would include, is there a model where that would include them owning the presentation of the form?
So actually coding the HTML and JavaScript to create where the form fields live, how they're styled like owning control of that. If you just have a JavaScript snippet that drops a form into your webpage, the developers have less control over presentation look and feel and so forth. Is there a headless model for that type of form handling?
Gustavs: Well, it depends on the service that provides forms. I have not seen external services that provide the ability to submit forms via API. They usually only provide ways of embedding forms, which means that's an iframe, and the form rendering itself happens on their servers, and it shows up as a block inside your Page, but usually you have quite an extensive amount of tools for you that let you style the form according to your needs.
Mitchell: Okay. But it, but it is possible to make a service that would be able to let you build your own form and just handle the submission via API endpoints. What would be the downsides of that kind of a system? I mean, you have. First of all, you need to have some model of like a, a token, like a Craft token where Yes, you, you validate that the form that's being submitted is one that you recognize that you own instead of spam coming from somewhere. Like how do you handle that? Or can you?
Gustavs: Well, you can do it again via API endpoints. You would, first of all, you would ask the service for a form. It would generate some data for you, like the CS RF tokens, some honey pot catching mechanisms and whatever else you have, and then you would have to incorporate them inside your form when you make it.
But there are several downsides to this approach. For instance, you would need to handle all the validation as well, like when the user clicks submit. You have to post all the data to the API endpoint, then get back a payload that might or might not contain errors. And if it has errors, then you have to display them.
It's it's a lot of work. So embedding forms is usually way easier because the service is the one responsible for there not being any bugs for it being as simple as possible. Because usually creating forms. Takes a lot of time, and that costs a lot of money to have developers work on something that others might have created and worked on for years.
Mitchell: Okay, so this is, there's a reason this model doesn't really exist at a practical level. It's too expensive and not worthwhile. Yes. Okay. Yes. All right. So, you know, the topic I wanted to get into, we've touched on already, which is once we've. We got your definition of a headless architecture and what it means.
I'm wondering if we can gradually move clients over to a headless architecture. See, one, one of the challenges that headless addresses is that until up until its fairly recent adoption within the web developer community, clients were on monolithic. Websites. So they would have a primary CMS who, who was responsible for generating html out of a templating system, polling content from a database and sending that HTML to the browser or sending it through a caching layer that would then send it to a browser.
And when you have this big monolithic system, there's a lot of friction. There's a lot of difficulty in making changes. Or upgrades to that system. You get tied in, it gets all tangled up and it's kind of a mess. One of the nice advantages of a headless approach is that so many things are decoupled from one another.
You're more free. So if the front end is expecting a certain type, maybe it's GraphQL or some, some sort of a format of the content, it gets to where it doesn't care where the content's coming from as long as it's the same format. So you can migrate from you know, from one system to another, say, Migrate from Contentful to Craft or Craft to Contentful or, or so forth. But what I'm wondering is, can we do it gradually? Can we gradually transition a site from the non headless state to the headless state over the course of a few years, spread the client's risk out, spread the cost out. Maybe you could talk to me a little bit about what you, what you see as the upside downside on that.
Gustavs: Yes, it's certainly possible. And first of all, I would start with using external services like Algolia or Mail Search as implementing a search service brings the biggest benefit right from the get-go.
Ivars: Actually, on my client's end, I would say that I don't have any client who hasn't started that process.
Mitchell: Really?
Ivars: Yeah, because I. Why didn't you tell me? You know that's, that's how we got to this, this topic already, right? Yeah. Because what we noticed usually with, with clients is that, as Gusto said previously, there are usually in companies, in clients, companies responsibility groups. Maybe one group is responsible for the careers page, another one is responsible for.
Press releases or events or something like that. And eventually clients start to use specialized tools for those D types of things. And then eventually they want to show all of those information data sets on the homepage. They want to pull in from one service, from another service, from the third service data show, all of them dynamically on the homepage. And then you are forced to basically, Start to build your small, headless front end. It just happens that it's hosted usually with our Craft website. But I would say that that's basically the first step that you start to use external services. You don't actually pull them in within the Craft. You start to pull the men directly in the front end.
Another approach would be, The configurators for shops that we've been building out to build out something so dynamic we have to use to react or j or Ujs on front end, and to use them. You are basically forced to use APIs to retrieve data, which means that we cannot, we cannot even continue to build out monolithic applications in that specific section of the page, we have to connect with our custom built out APIs within Craft. So that's also another example where you actually have started gradually to move to headless space.
Mitchell: Yeah. Configurators. Yep. That's right. What else?
Gustavs: Marketing pages, that's definitely something if you have a marketing team and they have to rAPIdly churn out. Pages specifically meant for some marketing campaigns, and usually they don't have the tools for doing that. So for instance, if they would use Contentful, they could create a separate section in their site, which gathers the data from Contentful and displays these pages where the marketing team can rAPIdly work on them.
Mitchell: You know, this is the fundamental problem I remember seeing from, from years ago. I've been at this more than, more than 20 some odd years, and the roadblocks that teams would experience that were somewhat created by the underlying technology like the, the underlying cms. That would prevent the different teams at a large organization from moving in parallel.
They would all have to be backed up in sort of in, in series and they'd have to go interns to get their content up on the site or get attention from the web development team or, or agency, outside agency, or whatever the case may be. So this is one of the things that I'm most excited about, is it loosens up this, this block, this, this friction that our clients see.
And there's more opportunities for parallel work for the different teams that are trying to support different aspects of a given business. Yeah. So this marketing sort of landing page idea is a good idea. But this headless model is akin to what you're talking about. So, The web development team owns the presentation layer and they reach out to a separate API and they kind of don't care which API it is as long as they can control the presentation to stay on brand and, and that sort of thing.
What other considerations do they have to think about with regard to these marketing pages? Like aren't there tracking and analytics considerations, or is that not, not that big of a deal.
Gustavs: Well, that's actually a huge deal for marketing teams, right? They have to track all kinds of things, so usually that requires the development team to jump in and work with them. But maybe there are services which provide like some sort of configuration for the marketing team so they don't, don't have to. Have the development team help them out every time? I'm not really sure.
Mitchell: How do they handle, you know, if these teams have multiple systems that they're managing content in, there are approval layers that have to take place, even if they are capable of working in parallel.
And this may be a question that's not quite on topic or. Something you, you two might not want to answer, but I'm wondering about the workflow side of things. Like some companies have to have a, like a chief editor approving how, how the content was written, you know, is again, is it on brand? Is it within the voice? Are there workflow tools inside something like Contentful or some of these other sort of cloud based headless CMS systems that support that problem? Can you guys speak to that at all?
Gustavs: Yes, Contentful has all of this built in where they can set up users and the flow for the publishing process in general. So you have content editors, content like, okay, people who look at the content and make sure everything's fine, approve it, and then at the end there might be a CEO or somebody super high up. Doing the final approval before it's being published. So when you write the APIs on the presentation layer, you would fetch only the the entries that have been published instead of ones in draft or whatever other statuses.
Mitchell: Okay. That makes sense. That's a good answer.
Ivars: For example, if you have also in parallel also events page like CMS for events and press releases and those types of things. I know that some of our clients are using tools like Content Link. That's really the content staging and those types of functionalities that Gusto described just now, which is also in Contentful. But yeah, there are some tools that allows you to collaborate in terms of content and then spread out in, into these different types of specialized tools. The same kind of approved content.
Mitchell: Okay. I, what do you know, with regard to Contentful and sanity, IO and Craft, of course, can be run as a headless system. Maybe Gustav's, can you speak a little bit about these other systems, these other tools and even the companies like how do they compare to one another? What, what are, which ones are on the top of your list?
Gustavs: I can talk about Craft. CMS and Contentful, cuz I have experienced those. They differ mainly in that Contentful has been specifically created as a headless cms. Where it doesn't have any presentation layer, you just use it as a service. You can create your account, you create your users, you create your content models, and then you have your content editors come in create the content and then publish it. And then you have a website or a mobile application which pulls in the data via APIs and displays it.
Whereas Craft, it has the capability of being a headless cms. But first and foremost, it is a monolith. So you have to have a server, and it is going to have a front, front end layer, a presentation layer, but you can opt out of using it and to make the headless part work. You have to do additional work. It doesn't come out of the box. You have to configure all of that. Mm-hmm. For it to work that way.
Mitchell: Okay. But it's cheaper. It's cheaper than Contentful.
Gustavs: Yes.
Mitchell: Okay. Because Contentful is a service and it has a service pricing model where you have to pay either annually or monthly, and it's pretty expensive, especially the. The more content you have, of course, the more expensive it gets. Okay? This was something that we liked about Mailly search compared to Algolia, by the way, is that you can, you can, or you currently, you must create your own Mailly search server somewhere and maintain it. But the upside is that cost is far more predictable. Then what we know right now of Algolia. The other thing I wanted to mention was at the Brooklyn do All conference for Craft, they announced that they're pretty far along on Craft cloud, like in they're second generation concept of what Craft cloud would be.
So it should open up things a bit more. More broadly for using Craft as a headless system. It's, I don't, I don't know very much about it yet, but just to mention that it's useful. Another question, and this may be the last one that we have time to answer. One of the things we need to do, to do with the, here comes the guide website was to have a mini project before the big melee search project in the mini project.
Was to update the website's sort of JavaScript base as a whole to get it to be more moderate and current and capable of handling what we were gonna do with the Mailly search implementation. So we used view JS for that Meilisearch implementation, but we had to have a preliminary step to get it there.
If I'm going to start talking to clients about moving them gradually moving their websites gradually into the headless space. Then what should we be thinking about as far as what changes, what sort of preparatory changes do we need to make to the front end code so that it's ready to make the gradual move to a headless model? Gustavs, any thoughts on that?
Gustavs: Yes. Well, it's well, it's possible to use whatever the client already has and provide the logic. Of fetching all the data from services and displaying it on the page. It's very cumbersome and slow and expensive if you use the bon js approach. Whereas if you use a modern react reactive framework such as react dress or new dress or well there or whatever, then it gives you the possibility to work.
Faster and the outcome is more reliable, first of all, and it looks way better and works faster, and everything's, everything's just better.
Mitchell: So when you say faster, do you mean that the rendering and the browser is faster, or do you mean the team implementing changes on the site is faster.
Gustavs: Well, it depends on the theme, right? If they have everything in place, like some sort of bootstrapped project already, which they can reuse across all their new client projects, then it's way faster than just writing some from scratch. Mm-hmm. But what I mean is it's faster. In loading times, it's faster when the user just interacts in the page just looks overall better and modern.
You would notice the difference between a vanilla JS project and a view JS project instantly.
Mitchell: Oh, okay. Well, you touched on our next podcast topic, which is what you're working on, what you're calling a bootstrap react js. Framework for, for use across certainly the Solspace team. And maybe some other people will adopt it too, for deploying headless sites. So we'll get into that in the next episode. For now, I think we're on time. I wanna thank you both for, for answering my dumb questions. This is, this was good and this educated me quite a bit. Ivars, Gustavs, thank you very much.
Ivars: Yeah, of course.
Gustavs: Thank you.
[Music] You've been listening to the Solspace Podcast.