Ep. #58, Bootstrapping Your API with Pierre Burgy of Strapi

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Pierre.

Pierre Burgy: Hey, Brian. Thanks a lot for welcoming me today.

Brian: I understand that Strapi is basically open source, but can you expound on the history of it and how we got to there?

Pierre: Yeah, sure. So the name Strapi comes from "Bootstrap Your API." At Strapi, everything is about API.

So Strapi is a headless CMS, but the main thing about Strapi is that Strapi is completely open source.

You can host it on your own servers and you can customize it according to your needs.

So we actually started Strapi in 2015. We were students and we worked as freelance developers on our side-time, and we did a lot of projects and a lot of websites using traditional CMSs.

But when we had to do a mobile application or a website using modern technologies, it was Angular at the time and React was just a brand new framework.

All of these technologies were not compatible with the traditional CMSs, so we were stuck because we couldn't find a great fit between these technologies.

We decided to create our own CMS, which was API-first.

We weren't talking about headless CMS at the time, but we just created it because we needed something like this.

At the end of 2015 we just said, "We're probably not the only one having this need," so we decided to publish it on GitHub.

We could have built a SaaS, but for us we've been using traditional CMSs for years and all of the CMSs we were using were open source.

It was just a no-brainer for us to both in the open source headless CMS, so that's why we decided to publish it on GitHub.

We started having some users and it was extremely exciting because we were six students, and at the end of university we decided to create a company behind the open source project and to switch to full-time on the project.

That was the real beginning of the story.

Brian: Excellent. So, you had mentioned about Angular and the whole ecosystem around JavaScript at that time, because I remember that time.

That's actually when I first started really doing JavaScript pretty seriously, as far as an engineer.

Before I used to be a copy-and-paster, and drop in jQuery snippets and stuff like that. I did work at a company that I worked on Angular full time, but I did not know what I was doing.

It was more copy and pasting from stack overflow and good projects that were out there, so I'm curious.

You'd mentioned that you started this when you were a student and you were looking to solve problems with getting projects up and running, how was the adoption at this point?

Did you see that once you open sourced it that people just started jumping to it? Or, how did you actually get people to know about Strapi?

Pierre: We started a few posts on Reddit to make the project a little bit more famous than it was.

We had feedback about the product, about the need. So it was extremely helpful to us, absolutely in that situation we have today, but still it was really important to get some feedback.

Then we started publishing tutorials and it really boosted our adoption. We really started at the beginning of 2017 to publish lots of tutorials and it's still our number one growth strategy.

We publish a lot of tutorials, for example How to Build a Blog with Strapi and Next.js, for example. We do a lot of tutorials with complementary technologies.

Brian: Yeah. It cannot be understated enough that introductory into new projects or new technologies , hands down, tutorials and actual explanation outside of just standard documentation is how I actually learn things.

If I can't find an example of how to get something accomplished in the way I want to get accomplished, I can sort of pick and piece stuff through the documentation.

But being able to see how to do something either the X-way or the Y-way or the Z-way, that's definitely super helpful.

I'm curious, what are different things that people use Strapi to build with today?

Pierre: It's extremely important to bring the developer to "What is this tool to the 'wow' moment."

The developer is pretty important to be able to see the value of the project very quickly.

So regarding projects which are made with Strapi we have some main use cases.

The first one is a corporate website, I also have a lot of editorial websites and lots of e-commerce websites. But we also have some mobile applications and projects, and even IoT.

For example, the MIT decided to create a connected object which is in the street, and in case of an earthquake the connected object is going to spread a message in the street.

This message comes from Strapi. So, we have lots of use cases and it's impressive how the headless approach brings new possibilities to projects.

Brian: The content that I like to write and that help other developers, it's really around "How many seconds does it take to get to actually using a product, or using this feature or using this library?"

If I can get someone unblocked or get myself unblocked if I get stuck again, like Google and find my blog post again, I want it to be the quickest as possible.

So, I tend to always build templates and starter projects to get myself unblocked rather quickly when I use the product again.

It sounds like Strapi is doing that pretty well, where you have those examples where I can just either clone or copy and paste, and then at least get myself with something usable as opposed to spending half a day working on something and trying to make it bend it to my will.

I'm super appreciative, I'm actually looking at the documentation now and some of the links as well. I'm super impressed to see a couple big names as well who are using Strapi.

We talked about the open source side, but I'm also curious around the actual product side and that transition and how that worked getting there, but also how it works today.

Pierre: Lots of companies are using Strapi.

Regarding the onboarding, we really tried to focus on this because the JAMstack brings a lot of advantages, but it also brings a lot of complexity if you compare it to something like Wordpress.

Because you have to build the whole thing, you have to build the front end and you have to connect to the CMS to configure the CMS, so it's a lot of work. Because Strapi is a benchmark, you also have to install node to configure your server or your computer.

So, we just tried to focus on the onboarding parts . This year we decided to publish some starters so that way you can get up and running with the front end and the Strapi project.

This is something we really tried to focus on. I'm sure it's something which is just going to be drastically improved in the next few years in the JAMstack ecosystem, because now you have lots of different components.

You have the front end, you have the hosting for the front end . You have maybe the e-commerce platform, you have the CMS.

I think all of those different components have different values, so I'm not always going to be complied in only one solution but the more integration there are between all of the solutions, the better it would be for our users.

Brian: Yes. So I'm curious, perhaps you have a biased opinion on this because you're running a company/project that's powering APIs and content management, but I'm curious about the outlook of that actual piece that you were talking about where we have the different components and they're all in different areas.

So in my mind I like having separation because then I can focus on the front end and do that really well at that time, and then focus on the back end and do that really well at that time.

I'm curious, the adoption for Strapi-- IBM is a big name, they've been around for years even before tech was tech.

But I'm curious if adoption conversations, are you having these positive conversations or are people still on the fence on using something like Strapi to actually power some of their content?

Pierre: They decide to choose Strapi most of the time because they want to build a mobile application, so it's not compatible with our traditional CMSs or because they want to use modern technology for their front end, typically, such as React or Vue.js.

When they have to make this choice there are a bunch of different options, but we really want to have something which is customizable, self-hosted and flexible.

That's why some of them decide to use Strapi. In general, I also think it's important to keep things separated.

I have to think it's our responsibility to make the usage from the front end easier. Just to give an example, we decided to develop a plugin for Gatsby.

As you probably know, Gatsby is based on the data source system, and to get that out from its specific source you have to develop a Gatsby source plugin. So that's what we decided to do with Gatsby, and it definitely helps our users to make a bridge between the front end in the CMS. This is also true for all of the potential complementary integrations, and I think integration is the new plugin.

In traditional CMSs you had lots of plugins, but I think most of the plugins now for headless CMSs would be about making integrations.

For example, if you want to manage your content in a headless CMS and you want to synchronize it in Algolia, you don't want to build your own synchronization software.

You want to install a plugin or enable an integration, and I think it's definitely the future of headless CMSs.

It's really about integrating your solution to as many software as possible, and this is something we really want to focus on at Strapi.

Because if you take a look at WordPress, for example, what made the success of WordPress is not WordPress itself.

But it's really the ecosystem of plugins that no one did, so we already have a plugin system in Strapi that we are going to drastically improve overall to anyone, the possibility to develop their own plugin, to share it on the marketplace and to download plugins forms other people.

I think that's a very good way to create bridges with solutions into the JAMstack ecosystem, and at the same time it keeps things separated. We don't intend to become a search engine, Algolia or Elastic will be better than us at this, for sure. But I think it's our own responsibility to create these integrations with all of this software.

Brian: It's very observing to see that you have a integration platform or ecosystem.

Gatsby has a plugin ecosystem, and then we have Algolia has them and Netlify just announced theirs as well.

They unveiled a bunch of new plugins for their ecosystem, so being able to integrate different pieces and have those bridges between things like Strapi or an Algolia, it's definitely helping and it's definitely helping further the adoption of this, like a separation of these concerns.

So I'm a fan of these integration platforms, and I'm curious of how the Strapi integrations, how they work or will work?

Are these just open source libraries on NPM that we just plug in, or is there a template? Is there an SDK that I should be looking out for?

Pierre: Most of the integrations are published on NPM and they are available on GitHub.

We maintain a few integrations, but our community developed lots of them.

So just to give an example for the most famous use case we have at the moment, headless CMS you can upload files.

Because Strapi is open source by default, the files are uploaded on the server, which is running Strapi.

But it doesn't cater really well, because you would definitely prefer to upload your assets and storage provider such as cloud services, S3.

So we did this integration system and currently we do maintain the integrations, we either S3 and cloud, but we have lots of contributions for the community on these plugins.

Also some people decided to publish plugins, for example, to upload on the Azure. That's just an example.

Brian: So I'm curious, when I think of headless CMSs, and the listeners are very-- They should be familiar with headless CMSs if you listen to most of the episodes of JAMstack radio, we've had Contentful on and a few others too, as well.

I'm curious of how you align and compete, compared to some of the other ones that are out there?

Contentful being the one that I have the most familiarity with, I know Sanity is a little more bells and whistles out of the box.

Sanity is more of your Webflow, where you have all the pieces directly in the UI and you're just using an SDK to then present that in React.

But then life with Contentful, it does have a little extra bells and whistles with their SDK, but also still similar where you spend most of your time on the UI.

So, with Strapi, how do you compare to that experience?

Pierre: The main difference is that only Strapi is completely open source, and that's a very big advantage because most of the big companies still want a CMS on their server, and that's mostly for privacy reasons . It's extremely important.

For example, IBM, Nasa-- All of these companies are using Strapi because they want us on their servers.

It's extremely important for them, and the thing on thing is really about the flexibility.

Strapi is completely customizable thanks to the plugin system, but you can also, for example, override any API endpoint.

You can update anything in the admin, so you are completely free and you are not locked in a specific system.

Also, the content structure in Strapi is extremely flexible, because if you are building, for example, a corporate website and you are building the home page and on the home page you have a tagline and then you have a list of testimonials, and then you have a description, and then a slider.

You can land with a very complex data structure, and this is something we really focused o n with Strapi.

For example, we introduced the concept of components into CMS, which means you can create a slider component and you will have the possibility to use these components across different content types.

We also introduced the dynamics and the concept, which means you can create a new page and actually define the structure on the fly, so when you create a page it doesn't necessarily censor another one.

But thanks to the dynamic codes, you can really create the content on the fly and it gives you lots of flexibility.

Brian: Excellent. I'm curious too, on that thought process of being open source. I think it is actually truly powerful too as well, having me being able to see what Strapi is all about by just looking at GitHub is really awesome.

I'm curious of how licensing works, and you do have a paid version which I believe is the hosted version, how does that also compare to the open sources? Is the paid version also the open source version?

Pierre: Strapi is completely free under the MIT license.

At the moment we don't have any business model, but we are going to introduce the first paid features this year through an enterprise edition.

This enterprise edition will be an extension of the community edition, and it will include enterprise features such as role-based access control or single sign on.

It is still a self hosted, so we won't host this version at the beginning.

That's why it is only our first business model, but in the next few years we would like to introduce a hosted veteran of Strapi to make the onboarding and the infrastructure management extremely easy for our users.

It's not a focus at the moment, we have lots of competitors doing this very well, but it's definitely something we plan to do in the future.

Brian: Excellent. It's good to know. For some reason I thought I saw there was a paid version, but maybe I was looking at another--

Pierre: Actually, we already have an enterprise page on our website.

Because we have lots of requests for all of these features, and we started selling it, even the easy first feature is still under development.

But it would be probably available in July or August of this year.

Brian: OK, excellent. Even putting a date on it too as well. Yeah.

So I guess I wasn't mistaken, but I'm curious between the community edition and the future enterprise edition, I'm certain you have employees or maybe you're still "strappy" at the moment.

But I'm curious of how much you get as far as open source contribution versus people who are funded by Strapi to work on it?

Pierre: We have more than 400 contributors who contributed from the beginning of the project, and I would say that in a way if we were these, we have between 25% and 50% of pull requests from our users.

To be honest, most of the code if you take the number of lines of code, it obviously must be from the code team.

But we have a lot of contribution, and this is something we really want to do more, so we just hired a product manager in July and his role will be to enable the pull requests from the community.

This is something we really want to embrace, and we also want to anticipate the design specs so anyone in the community can contribute on a very important feature.

That's something we really want to do more.

Brian: Excellent. This was pretty enlightening. I've been working on a project, I've been working on a couple of projects where I've not really addressed the idea of having an API or even a database, or powering the project or other things.

I tend to try to use the path of least contention when approaching the solvable problems, because I tend to not want to have something that's been longstanding and dependent on me updating it.

If I can get started with an API rather quickly, I'm a big fan.

If I can get started on an API rather quickly that I know 400 or 500 contributors, if there are that many people who have eyes on something I have way more confidence in that if I choose this solution, that at least it will continue to move forward even without me paying attention.

Which I love paying attention to open source and I love contributing back, but there's always some projects where they just sit on the sidelines for a bit.

Pierre: The project just reached 25,000 installs and GitHub.

Brian: Nice.

Pierre: So you're definitely not alone. The project is using production, it was still in beta until last month, we just released the stable version so you can use it with confidence.

It shouldn't cost you a lot, because you can host it just for free on Heroku, for example. Feel free to give it a try.

Brian: Excellent. Well, you're about to get 25,001 stars, because I'm about to hit the star button on the projects.

But with that being said I appreciate you coming on and chatting about Strapi, and talking about the open source story as well.

Is there anything else you want to add before we transition to picks?

Pierre: Just maybe with the JAMstack, I truly believe that's not only the CMS industry but the entire website creation industry is completely shifting to the JAMstack, and I think it's only the beginning of the journey.

There was still lots of complexity in stack now, but I'm sure it's going to be really improved in the next few years.

Brian: I'm right there with you. Super excited. With that being said, I'm going to transition us to picks.

These are jam picks, things that we're jamming on, per se. It could be a movie, food, technology, it could be a library you just used.

I'm going to go first, if you don't mind, and share my picks. My first pick is actually the Marshall Project.

In the US we've got some systematic issues, and if you're following the news at all in the last six months in the US, it's been crazy.

But I wanted to highlight a non-political-focused charitable organization basically is what I'm getting at, and it's called the Marshall Project.

They're focused around actually getting technology into prisons and actually teaching them for the better. You're able to walk away with skills.

They're non-partisan, non-political, they're just really focused on education. I'm a big fan of all those three things.

So I highly recommend, if you have some time, check out the MarshallProject .org and see if it's something that you want to help support as well.

Then my second pick, not as deep a pick, but it's going to be OneGraph.

Which is a platform for co-locating all your third party GraphQL APIs. We have Spotify, GitHub, etc.

You can put it all in one bucket and just authenticate in the OneGraph, and I've been using it to actually power one of my side projects which is Open Sauce, which I literally just mentioned last episode as well.

But it's actually been super useful because I just recently adopted a second API, which is Netlify's API as part of OneGraph. Actually, it's a third.

Twitch is another one that I've been using, so I'm actually starting to see the power of actually using something like one graph to be able to co-locate some of that data.

Data that I don't own-- I own the data because it's my accounts, but I don't want to spend the time putting together all this entire API and GraphQL endpoints to make sure all my data is in the right place for my application.

So, I'm a big fan. Also, episode 39 they were on, so take a listen to that as well. Pierre, do you have any picks?

Pierre: Yeah, actually we're with you. We believe in OneGraph.

I think they are doing a very good job at merging all of the different GraphQL APIs, and that's probably part of the future of JAMstack to be able to request the content from any one single end point.

Regarding the pick, I think the past few months have been really crazy. What is happening also in the US now is very impressive. I think we really have to learn from what happened in the past to build a better future.

Brian: I could not agree more. I would also just echo that too as well, if you are on Twitter and you happen to follow maybe only React developers or maybe only Angular developers, and maybe this analogy is not after very consistent.

But you should follow people who are less like you because that helps you grow, and I think things like Strapi is a good example of that.

Where we can take a solution of maybe a problem that has already been solved, but the fact that you're still solving the problem is just testament that tech is never finished.

We're never feature complete and the world is never feature complete.

So, I appreciate you saying that, and I appreciate you coming on and talking about Strapi and talking about the JAMstack. Best of luck with the project.

Listeners, keep spreading the jam.