Contentful's Fast Forward 2021 Day 2 Keynote

24 min watch time

Slides

The cover slide for the opening keynote for day 2 of Fast Forward 2021. It has a blue patterned background, with the title "opening keynote", the subtitle "day 2" and the names "Salma Alam-Naylor (she/her)" and "Stefan Judis (he/him)". The Contentful logo is in the bottom left, and Salma and Stefan's headshots are on the right of the text.
View on Speaker Deck

Recording


Abstract

Join Salma Alam-Naylor and Stefan Judis on a journey through time where they explore how content management and software development has evolved.

The need for flexible content started with native mobile apps ten years ago, but the solution became so much more. Let's find out how Contentful's idea of API-first content unlocked speed, flexibility, developer happiness and most importantly — innovation on the web.


Transcript

Salma

So it is 2021 we are coming to you live from Berlin in 2021 and web development today is an extremely powerful ecosystem of tools frameworks and services that means I, personally, get to build really cool stuff all day, every day and put stuff live and update it whenever I want.

And we at Contentful are part of that ecosystem. But it wasn't always like this. So Stefan, how did we get here?

Stefan

That is a good question! So for Contentful everything started with a single question. And the question was, "Why is there no content management system for mobile applications?" And I did my homework, and I did a little bit of research, and I browsed internet and web archive and I found this Hacker News entry. And this user entry is from June 3rd 2011, and what you basically see there is a person that is called "sashthebash", who turns out to be Contentful's co-founder Sascha Konietzke and he was kind of testing the waters if there is a market for a JSON-based API-first CMS.

And what he was building at the time was storageroomapp.com — which still redirects today to Contentful, because at the time there was no flexible content management solution available. So Salma, 10 years ago what were you doing?

Salma

Funny story! There's still a website live that I released in 2010, and at the time I was building websites for my musician friends in a piece of software called iWeb which was an image-based website creator that used to ship with older iMacs. And even then, in 2010, I had to develop a solution to the content management problem. My clients wanted to be able to update their website without me and getting a developer involved. So what you see on this screenshot in that purple area in the latest news is actually an iframe taking content from a text file that I taught my clients how to upload via FTP and I'm sure they broke it a lot of times. So this was 2010 — an example of a small website that was trying to solve the problem of content management. But 10 years ago this problem also existed at scale in large product companies.

Stefan

So 10 years ago, websites and products were built entirely in-house and Salma and I — we have a big love for front-end development — but at the time there was no serious front-end development yet. And if there was, front-end and back-end teams were divided. And the pain point of this time was that everyone was forced to reinvent the wheel all the time. I cannot tell you how many times I had to build a login form, a search form or a content management solution in one way or another. It was repetition, repetition, repetition. And all that led to the sad reality that development was hard, expensive, and slow.

Salma

But around the time I was developing my own content management solutions with iframe text files, things were starting to change. In 2010, specialist front end developers were starting to build the beginnings of front-end frameworks as we know them today. In tandem the development of angularjs and backbone.js were starting to make front end development more serious. And it's really interesting that the first releases of these two frameworks were just a week apart.

Fast forward to 2013, and whilst angularjs and backbone.js aren't really in use anymore, React came to the scene, and was released to the public. And if you're a front-end developer you've most probably heard of React, and you've maybe used it to build stuff — so it stood the test of time.

So 10 years ago we can see with angular and backbone and react, front-end development really started to evolve. And content requirements changed, as we saw from Sascha's post on hacker news. And what's more, at the same time — which we'll get into later — cloud computing arrived on the scene.

Stefan

So with storage room, Sascha was looking for a solution to build mobile apps faster, and he wanted to do that with the ease of maintenance of websites, and at the time but basically, well, that was just the beginning. Because today we know that content needs to go anywhere. And it goes from watches, fridges, cars smart somethings, to also different use cases. Because when you just build a website today there is a high chance that you maybe want to reuse the content for a different project or different app. The core challenge was integrating content in dynamic applications that are ready for change and iteration. And in today's world you better be fast. So what does fast actually mean?

Salma

Fast means fast development, fast to build. How fast can you get your product to market? How fast can you iterate on your products and improve them? How fast can you react to change in the world and what your needs users need? A typical example is when Covid came. And how fast can you pursue new opportunities to keep your products ahead of the competition?

Faster also means fast and cutting edge products. You need to deliver speedy performance and a fast and responsive user experience on the web, because Google tells us and ranks by the faster your site is, the more people are going to stick around. And finally, making things fast to develop and fast to use is not actually possible without innovation. And you actually need to be able to innovate fast as well.

Stefan

Today builders and technology companies are changing the game. And we do have a few other examples of that. So Ty Magnin from UiPath told us that since they're using Contentful, they're able to ship and develop their software stacks faster, but also they're resulting in way better and faster products because this leads to a better user experience. And as Salma told us, Google pretty much ranks speed as a rating factor.

Salma

Claudia Kim, vice president and global brand director of Shiseido Professional says that since using Contentful, as a business today they are more connected. They work faster, and everything they do can be updated instantly.

Stefan

Candace Green O'Leary, director of marketing at Rangle says that Contentful allows them to build pages in hours rather than days.

Salma

So what makes these businesses fast? It's a combination of how they manage their content, and the technology they use to manage it. So Stefan, what were the problems that these businesses were facing with their content that was slowing them down before they discovered the power of Contentful?

Stefan

So before using a content system like Contentful, the problem is that your content is not ready to be reused in different use cases on several devices. And this is why we at Contentful bet 100% on the API-first approach. Sascha was looking for a solution to ship content to mobile applications but basically this is unlocking content to go anywhere. And if you use an old school or legacy content management system and HTML is in your content — well good luck with that one or porting that into a different platform.

We bet on RESTful and GraphQP APIs, but as a side effect we also discovered that structured and scalable content are the core too. So in a past in a previous life I was using HTML-based "what you see is what you get" editors, and they just gave me a pretty pretty hard time. This is why we 100% bet on JSON, and for example, our Rich Text JSON editing experience. But also we figured that probably the use cases are not around pages and posts all the time. So what you can do in Contentful is you can set up posts and pages, but also you can set up events, authors, recipes — you name it. You define the content structures and content metal models and are in charge.

Salma

You can then fetch and manage your content using our open source tooling. We provide libraries in a variety of different programming languages to help you build front ends with our APIs even faster still. We also provide data migration tooling and content management tooling on the command line (and as a developer I especially love that) but sometimes it's not only about fetching your content to display it. Sometimes you need to do more. And for that reason we provide an open source app framework, with its own design system, Forma 36, which allows you to build your own integrations inside Contentful to help you manage your own specific content and business needs. We'll talk about that in a little bit more detail later. And next up after us you've also got an AMA later on with the app framework team.

Stefan

So 10 years ago I had two choices when I was dealing with content. Either I was, I had to use a pre-built old-school content management system that messed with my content, or I was forced to build and run my own. But nowadays you need a way more than a content management system.

Salma

You need a content management platform. And that's what we want to do for you at Contentful. As Paulo said yesterday, a platform enables business specific workflows. A platform lets you easily add new capabilities, and a platform brings teams and systems together as we saw in the case studies before.

So now we've talked about untangling your content in order to go faster, let's take a look at how the developments in technology over the last 10 years have helped us as front-end developers to go even faster still.

Stefan

So in my previous life, what I had to deal with is server setups, hosting and database things. And I just like to build beautiful UIs and do cool things. Then when I was dealing with customers and clients and friends and family to build things for the web, I had to find a content management solution which I had to set up, maintain, and learn in the first place. And then if I had bigger customers, I had to find a solution to scale that up in case the traffic um rose roses rose? So I had to scale that up and then — true story — I was several times at airports going somewhere and I had customers and clients giving me a phone call telling me "Hey Stefan! We're down! Because I copy and pasted a random snippet from the internet into my content management system!" This is what I was dealing with 10 years ago as a front-end developer and it was just time to break free and go faster.

Salma

And so we come to 2015 with the dawn of the Jamstack, and the Jamstack started to emerge as a front-end architectural approach in response to a lot of these problems that Stefan was experiencing, personally. So what was the jam stack in 2015?

The Jamstack comprised JavaScript, APIs and markup — hence the name JAM. And the main principles were that you would use client-side javascript connect them, to services and AOUs decoupled from the monolithic CMSs which Stefan hated so much, to get your data. All of this would be built into markup, static HTML, and served from CDNs around the globe. And as a front-end developer you would profit and move at the speed of light.

Mpdern Web Development on the Jamstack from O'Reilly and Netlify says this brought a proper software architecture to front-end workflows and empowered front-end developers like us to iterate much farther faster eehhh.

Stefan

And Salma and I — we've been there. So I built my first Jamstack site with Jekyll and GitHub pages and was it was a pretty decent experience. So we would love to hear from you so please drop it in chat, raise your hand if you use this exact technology to build your first Jamstack sites, but also please provide us some URLS, we would love to see some retro looking Jamstack sites from 2015.

This was mine! JavaScript and the Jamstack was perfect for creating personal projects and small blog sites that front-end developers could build on their own without the overheads of back-end systems and databases and server scaling and all that jazz that I really didn't want to pay attention to. But since then the ecosystem changed quite dramatically. Today we have over 300 static site generators in use. They range from Next.js to Gatsby to Nuxt to 11ty, and there's a vibrant and thriving community around the world. around Jamstack today.

Salma

And we can see this in the results from the Jamstack 2021 community survey. We see that the Jamstack now is not just personal blog sites and small projects anymore. The adoption is far wider. If we look at the top five types of websites that are built on the jam stack they now include e-commerce, B2B software and consumer software. That's pretty big stuff just for JavaScript, APIs and markup, right? Because things started to change again. Today Jamstack is more than just static site generators. because as the needs of the developers became more complex, the Jamstack had to innovate again. So how has the Jamstack evolved? How was it possible that industries like e-commerce started to adopt the Jamstack?

Stefan

So it all started with cloud computing. When that kicked off when I started web development, I was using my first CDNs to distribute content all globally — but that was mainly static content. And that all changed with the evolution of serverless functions. Today any developer can build and develop their own APIs with a serverless functions and as you see it's literally just six lines of code for me to enhance and enrich my website and the products that I'm building, and I don't need a full back-end hosted application to do so.

And what we see now is that there are modern hosting providers that are tying together frameworks and provides serverless functions and serverless experiences right out of the box. Fast and cheap development is now possible because I can develop things without having to, without the need to know lots of back-end solutions. There's a very low barrier of entry and we don't have services to maintain. And the beauty of this entire architecture is that this is scaling up if I'm getting a hacker news hit or if I write a very popular app.

Small front-end teams today can take large projects with little or no operations and back-end support, and this is where we at Contentful come into play. If you need a content management solution, set up your content types, set up your content model and get it into your products.

Salma

And so now with the arrival of cloud computing and serverless functions, Jamstack is way more than just JavaScript, APIs and static HTML. And so to reflect that it needed a name change. So at some point between 2015 and now it changed from capital JAMstack to just Jamstack to reflect that shift.

So we went from JavaScript, APIs and markup to pre-rendering, serverless functions, software as a service, git integration, automated releases, preview URLs, infrastructure, CDNs at the edge — and probably so much more because of all the innovation in just a few years. But let me tell you what really excites me about the Jamstack as a front end developer today.

So we now have four types of rendering available. So back 10 years ago we started at server-side rendering — building the HTML every time at every request. Now this is still available on the Jamstack now and is great for things such as personalization in e-commerce. So right at the beginning of the Jamstack it introduced static site generation where everything was bundled up and served from a CDN at build time, static, doesn't change, great. But now there's some fancy stuff going on.

We've got incremental static regeneration which generates static HTML but your data is revalidated at intervals, which then is regenerated in the background using serverless functions, and still being served statically. We also have distributed persistent rendering. Say for example you have a huge website with thousands and thousands of pages which is going to make your build process take hours and hours and hours. With DPR you can choose what to render at build time — and if you don't render a page at build time, when somebody visits your site you will get that page generated at request time, and it will be cached at the edge for future requests. So you're building up this static site as you go.

So we've moved away from building only static pages with static data on the Jamstack to a truly flexible model, where you can choose when your page is rendered depending on the type of data you're serving to your visitors and how up-to-date it needs to be — and I love it!

Stefan

I couldn't agree more, because I love this new fancy revalidation stuff putting things on the CDNs and we at Contentful — we also love the Jamstack. So as an example we use our own product as much as possible and of course one obvious example here is contentful.com.

So what you see here is a typical Jamstack setup, Contentful.com runs on Contentful, Gatsby, we integrate with segmentio, and we deploy everything to Netlify. But while this is a classical marketing website, content can go in various places, and we took the opportunity the last summer to build something like an internal people directory. You could call it an internal Facebook Metabook, Metaverse or whatever, whatever is the the thing right now. So we built this with Contentful, Next.js, we integrated with Okta, and with Vercel. And I hear you. You might say, Stefan you built you built an internal company Facebook, what's the deal here, right? The deal is that we did that in two weeks. We were just able to develop, sit down and roll with it.

Thanks to the innovators and the innovation that Salma mentioned, the amount of work that is possible by a single developer is now astronomical.

Salma

It's all about speed and how fast you can go. So we started with JSON CMS for mobile apps in 2011, and the journey that web development took us on as developers coupled with all that good innovation means that content was unlocked with new technology. Speed was unlocked with new technology. More innovation was unlocked with new technology, and especially skills were unlocked with new technology. Never in my wildest dreams in 2011 would I have thought I would be releasing all this stuff with serverless functions and CDNs at the edge and blah blah blah, micro services and I had no idea how powerful I could be.

Stefan

And Salma is an excellent example here because it's just beautiful to be a developer today. She is YOLO-deploying new projects every day and we reach the state where one developer can literally — and that is a big statement — but one developer can literally change the world. But you won't change the world by building everything yourself. So let me ask you the question — would you make your own bricks to build a new house? Probably not. Or you probably also don't want to build your own CMS — I've been there — don't go there! Or you don't want to own and build your own payment gateway, or your own analytics tools.

There are now software as a service vendors that specialise on doing one thing and they do that one thing very very well. And these vendors go from authorisation to payment to databases and — yes of course — to content management. Because you have to consider that when you're building your sites or your products the developers, Salma and I, or the developers in your teams should be focusing on building your core product — and not on setting up or maintaining or scaling, for example a content management system.

Trust the experts, because these companies, like we at Contentful, we probably — we're focusing on that, and if you want to build that on your own, that will take a long time and you will hit a lot of problems on the way.

Salma

Over 10 years!

Stefan

Over 10 years! So when we consider all these software as a service vendors, how do you connect your content with these technologies?

Salma

And for this as I mentioned before, we love the Contentful app framework. And the app framework is low code tools for developers to build apps for content creation and orchestration. Because you know that content is at the centre of every company and their products that they're building. Content communicates with your customers, content is your brand, your message, your offering and your value. But it is surrounded by way more.

The app framework allows you to integrate with your ecommerce solutions, your analytics platforms, your warehousing tools and much more to keep your content at the centre where it belongs.

Stefan

So we at Contentful are heavily invested in providing you apps built on the app framework to integrate with other services and service providers. If you are interested to see what we already provide out of the box you can browse our marketplace and probably find a ready-to-use integration already, but the app framework is also about building your own custom solutions. So for example you can extend the UIs with sidebar apps, with full page apps — you can edit and change the entire editing experience. And if you have the need for content automation, content workflows, you can set up backend apps, too. With the app framework the sky is the limit and we can't wait to see how you innovate and what you build.

Salma

So what we've seen is that the bottlenecks that came with old school traditional software development, like me and Stefan hated, and building iframes with text files is a thing of the past. And by adopting a platform agnostic JSON-based and structured approach to managing your content, and coupling that with the innovative technology on the Jamstack — in an ecosystem of software as a service, and when you are a builder who can focus on building core products and not reinventing the wheel, you can go faster and faster and faster and innovate even more.

And if all of this has been possible as a result of the changes in web development over the last 10 years, who knows what will happen and what will be possible for us as developers in 10 years from now.

Stefan

I cannot even imagine what will be possible in the next 10 years but let's stick to the present for one moment. So if you're curious to see and to learn what's happening at Contentful, what are the new features, what are Salma and I doing and where's the Contentful community, you can head over to contentful.com/developers. It's always up to date, so you can go over there and if you want to have a chat with us too, after Fast Forward — not in the next eight hours! You can go to contentful.com/slack — it is an open Slack community, we hang out there a lot we answer questions and we would also love to learn what you are building and how life in general is.

And with this, we made it through the opening thank you everybody for listening and we see you during the day!