44. Pioneers. with Michael Lukaszczyk, CEO and Co-Founder at GraphCMS

Piotr Karwatka: Hello everyone! In the Pioneers. series we explore the mindset and technologies required to shape the future of the web and e-commerce. 

In Today’s episode we’re going to talk about why GraphQL is the next big thing. I’m super excited to talk with Michael Lukaszczyk, CEO and co-founder of GraphCMS, one of the first GraphQL based Content Management Systems.

Piotr Karwatka: Michael, I’m super glad to have you in our podcast!

Michael Lukaszczyk: Thanks, It’s nice to be here ;)

[00:00:59]Piotr Karwatka:  Do you feel like a pioneer ?

[00:01:03] Michael Lukaszczyk: [00:01:03] Sometimes, some days I do, some days I would call myself and our team rather innovators and pioneers working on something that, that already existed. 

[00:01:19] Piotr Karwatka: [00:01:19] Awesome. I definitely  see you guys as pioneers in this space. Actually Graph CMS was the first GraphQL CMS I heard of. How did you come up with the idea for the product?

[00:01:33] Michael Lukaszczyk: [00:01:33] I'm sure it was actually some time ago. It was early 2016. I remember it was a Friday. I was just about to go to bed and before going to sleep, I was checking my Twitter feed and scrolling around and then I found one tweet by Chris Collier from CSS Tricks. I guess you probably know him or at least CSS Tricks. And the post was called “What is a headless CMS”. Okay. And I didn't know what a headless CMS was at that time. So it was, I was intrigued because he's always writing good content and it was really short blog posts.

[00:02:16 ] It was like a two pager explaining what a headless Content Management System is and why it's useful and why it's useful now. And so I got intrigued by the idea and I'm happy to recap or what it is for the audience.

[00:02:33] Piotr Karwatka: [00:02:33] If you can go along with the explanation that will be awesome.

[00:02:36] Michael Lukaszczyk: [00:02:36] Yeah. So basically Content Management Systems are around for quite a while. They first appeared in the nineties. And those were the era of the so-called Web Content Management Systems. Most people know the WordPress, Drupal or Joomla types. Those are web CMSs. And what they would give you at the end of the day is a website, a presentation for the content that you manage within the system.

[00:03:04] So you have a backup. You define your content by either I'm selling shoes online or having beyond the administering platform, a desktop user interface to onboard the content. And then at the end of the day, they give you a website that you can use to present the content. A headless content management system is similar in the first steps off the process by defining your content, giving you a user interface to onboard the content, but then it's not giving you a website. At the end of the day, it's giving you an interface, a technical interface and API application programming interface to integrate all of your content into any platform of choice.

[00:03:45] So it's the right choice. If you don't want to display your content only on the web, but also on mobile, maybe voice applications, smart TV, smart watches, any platform out there. And in fact it is also the most popular choice by now, or one of the most popular choice by now for the web, also because it gives you complete front end freedom.

[00:04:07] So you're not tied to prehistoric templating engines implemented in PHP so that you have to learn PHP in order to write a WordPress template, you can use React. You can use Vue spelled to any framework out there. Just to get back to the one question, how we came about. So I was reading the blog post and I loved the idea and I fell in love with the problem. Especially since in my former company, a company did something similar, doing a digital asset management system transferring it to sort of a headless way for one customer. And I loved the idea and I was thinking, how can we improve quickly? How can we get to market quickly with an idea with improvement?

[00:04:50] And by that time Graph QL was released. For a couple of months and to Daniel, who's my co-founder and our CTO. We were working already with graph QL on some projects. And for us, it was really just adding one by one improving the concept of a headless CMS by adding the capabilities of graph QL to it. So we could even improve the developer experience with it. 

[00:05:17] Piotr Karwatka: [00:05:17] Gotcha. So actually it is linked with the next question I had. The question was: wasn't Graph QL actually the core of the product from the very beginning or it started with just headless and maybe some Rest API? 

[00:05:34] Michael Lukaszczyk: [00:05:34] Graph QL was always at core.

[00:05:37]So we are really a Graph QL native content management system. You surface the content of , but also you can manipulate all of your projects with Graph QL with our management API. So you can create projects, manipulate your content model, using a graphical API, et cetera. Everything is graphical over.

[00:05:56] Piotr Karwatka: [00:05:56] Did you have some hard times back then in 2016, convincing people about it? Because I say, remember. It wasn't that popular headless and, and even less Graph QL. So I guess you needed to educate the market., 

[00:06:15] Michael Lukaszczyk: [00:06:15] Ultimately we needed to educate the market a bit, but thankfully there was a big wave of Graph QL doctors coming up and all of them kind of educated the market with us.

[00:06:26]So of course it was kind of a two track. Not only the market needed education for our graph, but also for the topic of a headless CMS, it was still very early for that concept. But back then, but yeah, we had to convince some people. But not users, actually, the people we have to convince more were angel investors, VCs.

[00:06:51] They thought, Hmm, can this be the next big thing in API? Will it really be adopted? And it turned out it will be. 

[00:07:02] Piotr Karwatka: [00:07:02] Awesome. Do you think  is just another format or is more like changing the paradigm or of how the apps are being built?

[00:07:10] Michael Lukaszczyk: [00:07:10] I think it's changing the paradigm quite drastically using Graph QL. To summarize in my words comes down to two things. The first thing is increased performance and data fetching because the data fetching is much smarter. So you don't over fetch. You have fewer round trips than developing with less so increased performance as the result here which is great. But a more important thing is actually the increased developer experience of working with Graph QL in a post to Rest API.

[00:07:47] So the API, the communication, the typical API communication protocol of the last 20 years you get increased developer experience because you have a type API, all of a sudden, and you have a fixed schema working on. And which means that you can query any data. A variation from this schema that you like within the boundaries of the schema.

[00:08:11] So if a front-end developer has some requirements on some fields from the backend that he or she needs to, to implement a feature. They don't need to talk to the backend team anymore. Can you adjust this rest endpoint for me so that I get the field here? No, the flow of control changes from, from backend to front.

[00:08:31] And if you have this one API endpoint, you can get all the data variations you need out of it, which is just a brilliant developer experience. So that's great. And, and on top of that, Graph QL allows new concepts arising in the API space. So it's not just about this, this early data fetching cases or writing cases with GraphQL on mutations, you would see new concepts around APIs.

[00:09:00] Or concepts that are finally taking off that have been around for a while, but finally taking off because of graphs, cure things like API Federation. So you have multiple API APIs and you want to bring them together to one API to combine and integrate multiple services into one end 0.1 API.

[00:09:19] So you can handle authentication, authorization and security on one end point, instead of having those isolated API APIs. Yep. Yeah, 

[00:09:29] Piotr Karwatka: [00:09:29] it makes perfect sense. So can you give us some examples about the key use cases people are using graph CMS for? 

[00:09:39] Michael Lukaszczyk: [00:09:39] Happy to. So initially we thought when, when you're building a CMS, okay, people will build websites with it.

[00:09:47] Typical marketing websites and agency portfolio websites, the typical websites you would see around that people will build, but we built our core and the API is so flexible that we see an interesting pattern coming up for our users. Replacing conventional databases with graph CMS. So instead of using things like Postgres or Mongo DB, they use graph CMS for the application development because they have use cases around content and they need more of a highly optimized database for content because they have things like they need things like localization digital asset management, content, staging, publishing, workflows, all of this that you wouldn't get from a conventional database.

[00:10:34] But they get it from grass CMS. And luckily we have built our API layer, so flexible. So it's not just only editorial content that can be. By a courier, not everything can be written just as an inter insert statement in a conventional database. So that's the most exciting use case for us where people don't build just marketing websites or portfolio websites but they're built real web applications of structured content and have all of them.

[00:11:02] Content assets would be in graph CMS, and this can be things like products and catalogs. This can be things like movies and series and video streaming platforms, all sorts of content that is not marketing. 

[00:11:16] Piotr Karwatka: [00:11:16] So it can, it can be used as a kind of backend, let's say you are doing the mobile application or PWA application. So graph CMS can be used as a back end service?

[00:11:24] Michael Lukaszczyk: Exactly. 

] Piotr Karwatka: Do you structure it? 

[00:11:28] Michael Lukaszczyk: [00:11:28] Exactly exactly. And our backend infrastructure is implemented so that we really expect also a lot of right data, not just serving via global CDN. We can also take a lot of rights. 

[00:11:43] Piotr Karwatka: [00:11:43] Yeah, that was my second question, actually, to this point, because I guess that if you are not like a typical CMS, but rather a database kind of. You need to take care about all the performance challenges because potentially the users are putting like millions of records into a Graph CMS. 

[00:12:08] Michael Lukaszczyk: [00:12:08] There they are, and there have been quite some scaling challenges for us. Give you one example. So in the early days, our backend stack, we started with a note based implementation cause we came from the JavaScript ecosystem, but then the platform grew and grew.

[00:12:26] And we had some scaling issues that we kind of could mitigate with Debow with the DevOps layer, like having Kubernetes and then doing some smart request routing and traffic routing with with an Istio service mesh that helped to mitigate this, but never helped to solve the the scaling issues.

[00:12:48] At core. I mean, it was, it was nice to have those issues. It was growing pains. So we decided. Over the course, we have rebuilt the platform three times actually, because yeah, kinda in a sense of we were pioneering, we were one of the first companies to figure out how you would scale a multitenant graphical backend system.

[00:13:11] So with the last iteration on our backend implementation, and I'm sure it was the last, it was also the last. For a long time for us, that we migrated from, from Node over to go to really to really maintain the scale and scalability in the application layer. And it's performing so much faster than before.

[00:13:34] It's one of the fastest Greco engines out there. And compared to our previous stack that is now our legacy stack it runs in some cases 50 to a hundred times faster than before. 

[00:13:49] Piotr Karwatka: [00:13:49] Well, that's, that's really impressive. What, what else makes a graph CMS? Special. I mean, which features are you most proud of? 

[00:13:57] Michael Lukaszczyk: [00:13:57] There's actually quite a bunch of features that we're proud of. At first, I'd already mentioned this really all of the API capabilities and how you can use the API is what it gives you, how you can fetch your localized content, for example, how you can use content staging, for example. So it's a really powerful API that gives you a lot of capabilities like filtering pagination, all you would expect and it's beautifully designed. So the API is one of our core. Components that we were proud of. And of course the usability of our user interface, the content management interface, it's nicely designed to lightweight and performance UI.

[00:14:41] And yeah, we are happy about the outcome of our product. What we are building on right now is something really good. We're very excited about it, and we're ready to ship this feature within a couple of weeks. I mentioned the concept of API Federation already when you asked me about the benefits of graph QL, and we are taking this concept of API for duration into the world of content.

[00:15:09] So what we want to allow within the graph CMS is that you federated. All of your different services that you integrate all of your services within the graph, CMS content API, which means that let's say you have some product content. So then some visual stories around content in graph CMS. But you have product information in other systems could be a product information management or PIM system, or maybe some CRM or some Salesforce. And you want to get data in, in the context of your product from graph CMS out of your PIM. So you can do this with the content Federation feature by extending the graph CMS content API with API additions that would fetch information from other systems so that you now have on your.

[00:15:59] Storefront or on your website, the product, you can also display how much of this product is still available because this information is mainly in the PIM system or maybe inside Salesforce. And it's really about combining and unifying content and content sources. This will be the next step for us. We see there still a lot of potential and a lot to do on this side.

[00:16:21]And this is what we're exploring and excited to roll out in a couple of. 

[00:16:25] Piotr Karwatka: [00:16:25]That sounds pretty exciting. So after this feature is released, as a user, will I be able to manage the whole user experience from graphs? Because I can combine the product feeds with the marketing information and, and stock information and all the other necessary parts.

[00:16:44] Michael Lukaszczyk: [00:16:44] Exactly. You're unifying your content in one system, and then you can also leverage everything on top of that you have from Graph. Seamaster the localization, the content staging the, the permissions. Yup. Of course, because you want to secure the data that's coming from the external source, so that you don't have to build your own authorization authentication in front of the API APIs.

[00:17:12] Piotr Karwatka: [00:17:12] Gotcha. That's also worth mentioning the last part that you need to have all those basic features to push the boundaries and, and  CMS have it all like internationalization as a versioning, everything. So I really recommend you guys, the listeners, to maybe test it out, the trial version.

[00:17:36] Okay. Perfect. Maybe let's switch a little bit to the company and the team. How many people are now in the graph CMS team? 

[00:17:46] Michael Lukaszczyk: [00:17:46] It's 27 people, 

[00:17:48] Piotr Karwatka: [00:17:48] 27. Nice. Are they mostly engineers? 

[00:17:52] Michael Lukaszczyk: [00:17:52] It's a split, half and half. So half of the company roughly is engineering and product. And the other half is the commercial team.

[00:18:02] Piotr Karwatka: [00:18:02]  It started about four years ago? 

[00:18:04] Michael Lukaszczyk: [00:18:04] Yeah. 

[00:18:06] Piotr Karwatka: [00:18:06] Can you, can you tell us more about the early days?

[00:18:08] Michael Lukaszczyk: [00:18:08] Sure. It was hard of course, months and years of lots and lots of work and little sleep, but it was exciting. It was, the early days were especially exciting with non-union where we had to.

[00:18:25] A little one room office close to our house close to the places we lived. And we were working from morning until the night trying to build the first prototype which, which is extremely important to get to this milestone, the first usable, usable version or your minimum viable product, because with this, you can pitch already.

[00:18:48] Yeah. Product, you can let users test it. And of course you can pitch it to investors and really prove, okay, you can build what you're what you're pitching them. So it was, it was a fun time also. And of course we’re both  engineers. I also studied computer science and coded for quite some time.

[00:19:12]And we had to learn the commercial side step by step. I was always interested in the growth side and marketing also. So I took the role of the CEO and Daniel was a better coder than me. So he took the role of the CTO. And sold, went, and of course we were in the early days we were visiting the startup events.

[00:19:34]One very important event for us was the startup weekend on decent, decent, this where we are initially located. And it is there, there are quite some events of this type around where you meet for a whole weekend. You pitch an idea and then you gather a team and you build basically a company virtually in 48 hours.

[00:19:58] And then you pitch at the end of the weekend. Well, we were nothing at this event. We pitched a similar story to Griffith. But the slightly different, but people in the audience and the jury wouldn't understand, it's a B2B story. It's nothing, it's a hard story to pitch a chose. Like, I don't know, lion's den or shark tank.

[00:20:18]You have to explain a lot of context. So I think one of the teams, the team, one that offered the vegan cookie or wanted to market the vegan cookie. But anyway this event was important for us because we met our first business angel there. And half a year later, we pinged him and Hey we're bringing out the product.

[00:20:40] Do you want to look at it? And he did. And he wanted to invest. Brought in some more people from his network. And then at the end, also, those people were bringing our first institutional institutional investor. So the startup events are crucial in the early days, building your network and getting to know the right people.

(...)

‍