Rise of The Content Mesh: Webcast with Contentful and Gatsby

– [Linda] Hi everyone. Thanks for joining our webinar today. Rise of the Content Mesh: Webcast with Contentful and Gatsby. I just wanted to take
a minute to welcome you and also to let you know
a couple of announcements. Everyone will be on
mute during the webinar, but if you have questions please enter them in the question window. We will have a few panelists available to answer those questions
throughout the webinar as well as we'll set
aside some time at the end for Q and A. So feel free to put all your
questions in that window. Also, the webinar will be recorded so if you miss a portion of the webinar or you want to watch
or listen to it later, the recording will be
sent to all registrants and posted on Twitter later today. So with that, I'm going
to introduce our speakers. My name is Linda Watkins. I'm Director of Marketing at Gatsby. I am passionate about web
technologies and cloud. I formerly worked at
Pantheon as well as AWS. I also play the flute. I worked at a flute
factory and I perform flute with the Bay Area Rainbow Symphony. So we're also joined by Shy Ruparel. And Shy is a Python developer by heart with a passion for long board games, good jokes, and the
staying power to wish you a great day on Twitter every single day. And if you've ever seen
Shy's Twitter handle and the images that he's
posted, they are a lot of fun. Next we have Sam Bhagwat,
who is Co-founder and Head of Enterprise at Gatsby. Sam is a core contributor
and co-founder of Gatsby. Sam writes and speaks on topics like modern website development, React, GraphiQL and open source software. So with that, I'm actually
going to turn it over to Sam for his portion of the presentation. And Sam, you want to
unmute yourself as well. – [Sam] Hey there! Really excited to be talking today. The topic that we're
gonna be talking about is what it's like to build websites and how that's changed over
the last five to 10 years. We're gonna start from more of a business oriented perspective and then shift over into more
of a technical perspective. Fundamentally, like,
fundamentally as web developers, as website developers,
developing for the web is hard. And it's hard because
with millions of websites on the internet, developers have to create compelling experiences
to engage audiences, because to bounce all the user has to do is just type in a few things
into their address bar and navigate away from your site. And so what that means,
like, and what is that, people are trying to grab attention. We have the rise of brands like Harry's, Dollar Shave Club, Bonobos, Stitchfix. These brands are disrupting
traditional industries. So perhaps you have
clients who are these kinds of new brands who are
trying to gain attention or e-commerce content and
trying to get attention. Perhaps your clients are,
or the company you work for, is in one of these
industries and they're trying to stay relevant in today's age and show that they're
keeping up with the times. What this all means is that the returns to having an incredible
web presence are rising. Sites that are maybe a little
bit better or differentiated in some way from the
competition often can draw a disproportionate share of
users, visitors and revenue. And so with that world that we live in, where people are trying
to distinguish themselves as unique, as better, there are these returns to
investing in a digital presence. And what that says
overall about the internet is that the internet has matured because it used to be
that it was really hard, you know, 10, 15, 20 years
ago just to get content on the internet and then
establish, like, a web presence at all and that was going back,
you know, down memory lane or back a bit in history that
was how the CMS was born. But today it's everyone
is publishing content and the challenge is to be in a world or, you know, work for an organization or have clients who are in a place where their content is in a
lot of different places and they need to tie it all together. (coughs)
Excuse me. They need to tie it all together. So, you know, just to take
another thing in that vein, you know, publishing on the
web when the CMS was born in the early 2000s was very difficult. So the CMS emerged as a single application that could store content, build
sites and deliver to users. And what that looked like
is that the CMS would handle a lot of these key feature areas, whether that was analytics,
search, payment, preview, it would be your UI Lay braids
or our development in it. It would handle page creation,
forms, all that stuff. And so here over on the left, you see this kind of diagram
representing a traditional CMS, and you know, whether that's, you know, WordPress or that it's Drupal, whether that's a more enterprise CMS like Adobe Experience Manager or Sitecore. The world that you live
in when you're developing in these environments is
that these environments do everything for you by default. But often what's happened recently is that each of these services
and each of these components have become their own services. They've become their own
best to breed things. We don't really want to use WordPress. We don't really wanna
develop in WordPress anymore. We don't really wanna use Drupal. You like it. We wanna develop and react, we wanna develop and view, we want to develop in
a modern UI language. We don't necessarily wanna
use the out-of-the-box, you know, forms or search, maybe we want to use Algolia for search and Auth0 for auth and
Segment for analytics because these services
have kind of emerged as, you know, better. They've been able to handle
these use cases really well and now we need to, like,
somehow take their content from where it lives and plug
in these best to breed services and use, you know, use a
great modern UI library so that the development
environment is better, right? The traditional full-stack
CMS does everything, but does not a lot of that well and we wanna move to a world, you know, especially when we're working
for clients or for a company that wants to distinguish themselves and stand out on the web, we don't want just a generic website. We want something that stands out. And DOS to breed, best
to breed, excuse me, high quality websites
demand DOS to breed tooling 'cause if you can't develop
and iterate quickly, you can't make a really great
website that stands out. So we've been chatting with
a lot of folks recently and we keep hearing similar stories, you know, again and again. A team that's running an e-commerce site's moving away from this Drupal model, that they're starting to store
their products in Contentful, their reviews in Bazaarvoice, which is this sort of review site for user-generated content, and then storing their
user information in AuthO. Okay, so question. I think I'm gonna turn this over to Linda. – [Linda] Yeah, and
actually I realized I listed the wrong question there, so, but I will show you the right question. Right now we wanna know
what is the most important to you in a website framework? So if you had to choose one, would you choose easy for
content creators to use, easy for developers like leveraging the most modern web technologies, or for performance, a
fast, optimized site? So go ahead and put your answer in here and I will wait 'til we have
a good number of responses and then we'll close the poll. We'll give you just a couple more seconds. Alright, so I'm gonna close the poll now. We are, people are getting
their last minute votes in. Okay, great, and share results. So it looks like a lot
of people are opting for performance, 46%. 39% easy for developers to use, and we probably don't have
a ton of content creators on this webinar because 14%
say for content creators. Okay, thank you. Go ahead, Sam. – [Sam] Okay, so… Great, thanks Linda. I think it's interesting,
like, it's interesting that we kind of had this split. We kind of had this split
with a lot of folks… A lot of folks took a lot of time to answer the question, right? It's tough to think
about these trade-offs. It's tough to think about
who's kind of the person that you wanna optimize for
when you're building a website because ultimately, you
know, there are these, like, three stakeholders: content
creators, developers and users that we're… When we put together a site architecture, we're trying to optimize for all of them but often only end up
optimizing for one or two. Moreover, this is even more relevant because in each of these areas
we're seeing rapid innovation that helps this person have
a better and easier workflow. So content creators,
we see how this CMS is, like Contentful, we see specific CMSs like e-commerce CMSs, tailored
CMSs, and exalsify it. With developers, we see
that we see developers wanting to use modern frameworks
like React, Angular Vue, in order to be able to
iterate quickly and have a modern website development
component-based experience. Ultimately, and this is, you know, something that we were
talking about before, a modern website experience
requires modern tooling. And what that means is
that if you're building a digital experience that stands
out above the competition, which is something your
clients are gonna care, your clients and your company
obviously care a lot about, it requires this modern tooling. So it's fascinating to
see that React and Angular have just dominated as a proportion of the JavaScript ecosystem because of all these
advances that we've seen: component-based UIs, the virtual DOM. And what this means is
that we have a stable place to build on the future. That's a, you know, that's
a head and shoulders advance above previous, you know, whether that's WordPress
templates or Drupal UI kits and kind of previous CMS-based
development environments. It's interesting to see that some of the award-winning websites from, for example, the Webbys, are being built on
modern frameworks, right? Which rather than, you know, rather than CMS development experiences. And what this is all coming
back to is that in many ways, the enterprise CMS, that full-stack model that they integrated CMSs, is 10 plus years out of date. And it's all these advances
in the JavaScript ecosystem are simply creating a
pressure differential where the development experience is better in the modern JavaScript
ecosystem without issues like having to maintain local
app servers and databases, being able to use a Headless Cloud CMS, not having to handle bundling project organization on your own, having these transpiling
tools, so on and so forth. We can go, you know,
really in depth in it, Bbt there's really just
been a flood of advances in the modern JavaScript ecosystem that creates a better
development environment. And so that's the second area, right? So Headless CMSs, you know,
benefiting content creators. Modern development tools and frameworks benefiting developers. And then advances in website performance benefiting, excuse me,
benefiting site visitors. So performance has always been important, but it's becoming increasingly important. And it's becoming increasingly important because of the rise… So there's a couple of factors, but one of the big ones is the
rise of smartphone traffic. So between 2014, looking
at this graph a little bit, looking between 2014 and
2017, mobile traffic rose from 20% of overall traffic to 50%, right? And you can think about the
performance characteristics of a user on a smartphone. Maybe they're over a slow
connection, you know, who knows where they are. Maybe it's a 3G, you know, maybe they get really bad connection even inside their own home, maybe they're on the go,
maybe they're in a tunnel, maybe they're on a bridge, who knows. And then devices that may not be your top of the line iPhone,
you know, slow Android devices. They take awhile to evaluate JavaScript. So suddenly the rise
of smartphone traffic, mobile performance
becomes a key aspect of… It becomes a key aspect of
of your site performance. So I'm gonna turn this back over to Linda to talk about this, to ask a poll question. – [Linda] Thanks! And again I had listed the
wrong poll question before so apologies for that, but the right question is showing now. So about how many seconds will you wait for a page to load before bouncing? I know that I appreciate a
fast load time, of course. So just trying to get a
sense of how long you'll wait before getting frustrated and moving on. So we have several votes coming in. We'll give you a couple
more seconds to vote. Once we get to 60% of the viewers voting, we will close the poll. We are at 50% now, so couple more votes and then we'll show the results. Okay, great. I'm going to close the poll. Okay, so a lot of people will
wait a couple of seconds, some even three to five. Those are very patient
people in our modern age. And, but, you know,
showing a lot of people, you know, bouncing on a website if it takes more than a
second or two to load. Alright, thanks Sam. – [Sam] Thanks, Linda. Yeah, I think this poll stated
something really crucial which is that our visitors
aren't any more patient than we are, right? If we're gonna, if 97%
of us are gonna bounce when a site takes over
five seconds to load, we need to make sure that our sites load in definitely less than five seconds. If almost half of us are gonna bounce if a site doesn't take, if a site takes more than
three seconds to load, then, you know, we need to, we need to make sure that our site loads in less than three seconds. Studies have shown that every
100 milliseconds of latency costs 1% of sales, or in percent of visitors
if you're, you know, building a content site. A lot of times, clients will be, you know, pouring tens of thousands
or hundreds of thousands of dollars into in AdWords and driving folks to
the sites that we build. And when those sites are slow,
it hurts the bottom line. And we can deliver value by showing that "Hey, we can build a fast site." The challenge, of course, is well how does the site become fast? Sites actually become slower
unless you do anything proactively to make it fast and it can be difficult
to pitch performance and to get performance
baked into the budget because ultimately performance
takes time to implement inside traditional website
development paradigms and it's easy to mess up. A website becomes slow by default unless we purposely,
carefully make it fast. So those are all kind
of the three challenges of building a modern website, right? It's creating experiences that are good for content creators, it's creating development experiences that are good for developers, and it's creating a performance that's good for site visitors, right? And so ultimately to create
modern website experiences we need to do all three of these things. Gatsby is a tool that lets
you do all these three things. And we call this the content mesh, bringing best to breed tools together with modern performance together with a great development environment and wrapping it all
together into a new stack like the content mesh. So just to walk through a
little bit how this works with Gatsy, like, you know, with Gatsby you got
performance out of the box, you can bring content from
anywhere from any CMS or CMSs and you can use modern development tools. We build your UI in React. So kind of how that works is that Gatsby's a website compiler
and it takes your code and your UI components in React, together with your content, whatever sources you're
bringing that from, and it compiles it into a set
of files that you can then put on a CDN which will
be globally available. You won't have to deal with app service and databases to serve your files, to serve your site. Your site will live on the edge on a CDN and it will deliver, like,
lightning fast performance. So here's another kinda piece of that which is that you can, you know, we talked about this, but you can really source from any CMS or any combination of CMSs. So maybe you've got a blog in WordPress and you've got e-commerce in Shopify. Maybe you got Contentful, but then you also have
it another internal team working off of a Google Sheet together. You can bring all those
content sources together into your website through
Gatsby's plug-in system with, like, built-in integrations. You don't have to write the
code pulling the data in. That happens, you know, out of the box. So that's, you know, that's why it's great for content creators. Gatsby lets you pull your
content from where it lives and lets your content creators use tools, the tools that they're most useful, comfortable and familiar with. At the same time, Gatsby's
great for development team because Gatsby offers
more in development tools. You got out of the box React, you get modern sort of
bundling, code-splitting, transpiring with WebPack and Babel. It all comes out of the box. You get a CLI, you know,
dev server, hot reloading like a nice, a nice
development environment. And then it's really
to add these, you know, additional pieces of
the ecosystem that make development and teams bigger, whether that's linting,
formatting, component curation, component libraries, third
party components in React, inspecting your components. Gatsby gives you that experience. And finally Gatsby offers
performance out of the box. So you like to see that
there are two different ways that, like, you get performance. You can get delivery optimization, which is what you get when you use a CDN, you move torwards files and away from app service and databases. So Gatsby gives you
that because your site, it lives on the edge close to users, it doesn't have to wait on any DB call to, you know, to be delivered and the CDN is… CDNs are great and CDNs optimize delivery, but then what's being delivered? The payload is also optimized. So Gatsby does code-splitting,
it does pre-fetching, so if you're clicking on
a link inside your site that is often cached and
it has often been cached by the browser in the background,
so it's instantaneous. It inlines critical JS & CSS which means that you don't have
to wait for a blocking call for your page to load. And then there's advanced
image loading techniques which basically show you a
preview of the image right away when the page loads and then
when the image comes back then the full image will come in. That helps your user feel like, "Hey, this is loading super fast "and I see what this is." And then, like, you know,
when the last bit comes in it's, you know, it's complete. But it feels like money right away. People have said that Gatsby
sites are disgustingly fast. You know, they've used
various other adjectives which I won't repeat, but they're often quite
surprised by how incredibly fast Gatsby sites are. So with that, I'll turn it over.
– [Linda] Great. Great, thanks so much, Sam. I'm going to past the
controls over to Shy now. We've heard Sam talk
about the content mesh, kind of overall trends we see
with website development now as well as more description of Gatsby and how it fits into
that overall landscape. And now we're gonna hear
from Shy about Contentful and how Contentful and
Gatsby work together. – [Shy] Thanks, Linda. And thanks to Sam and Kyle as well for all three of you
and Gatsby for hosting me in this webinar. I'm really excited as well. If y'all have any questions, don't hesitate to throw
them in the question section of the webinar and
otherwise let's get started. So I'm Shy. I'm a developer evangelist at Contentful and I'm really here to talk to
you about content management. And Linda has a question lined up for me. What I really wanna know is of all of you in the audience, who here has used a CMS, like
a content management system? We can wait for just a couple seconds. – [Linda] We'll give people a few minutes. This is an easy question.
(giggles) – [Shy] Cool. – [Linda] So I assume this means if you currently use a CMS
or have used one in the past. – [Shy] Yup. Alright, that's about 20 seconds, so… Let's see.
– [Linda] Alright. We have 60% voted, so I'll
go ahead and close the poll and share the results real quick. – [Shy] Yup, that's about what I expected. Almost everyone, almost
everybody has used it. Now my following question is who here liked using a content management system? (Linda laughs) – [Linda] So another
easy yes or no question. (coughs) – [Shy] These were my favorite questions when I got quizzes in school, were the easy ones, so… (Linda laughs) – [Linda] Yeah, people have
to think about this one a little bit more. Oh, now we're getting some good votes in. – [Shy] Cool. – [Linda] Okay, we're at 60%, 70%, so I'll go ahead and close this poll. Little bit mixed!
– [Shy] Yeah, so we've almost- Yeah, we've got a strong
preference towards no, which is a bit of a flip from last time and kind of what I expected. And I think there's a
strong reason why, you know, content management systems
get kind of a bad rep, right? And that's partially because they slow software
development down, you know, they make it harder to get things done, it makes it harder to roll stuff out, it's slow and painful for developers, it's rigid and inflexible for editors, you know, it kind of traps
things in these silos. And typically when I talk about
content management systems and I hear about content
management systems, what I'm hearing about is tools that are in this page-centric
way of doing things. You are going into your
WordPress or your Drupal and you're building a page
and an editor specs out a page and that data is kind of designed
to be seen on the internet and you can't take it anywhere else. You're hosting these giant monolythic apps that have all sorts of things
you have to keep an eye on and, yeah, maybe you could
pay someone to manage this stuff for you, but it
is a giant solution that, you know, could be vulnerable to issues or security updates or whatever. And also, you know, you
have to really learn how the CMS wants you to do things. You are dependent on how the
content management system is built and how the content
management system allows you to engage with it. For example, you know, you
might have to learn PHP and it's specific, like, you
know, interactions of PHP to add functionality into WordPress that, you know, might not exist
which can be a bummer. And I think these are
three like totally valid and totally major problems, but I don't think they're
actually the worst thing with most traditional
content management systems. I think the worst offender of all of them is actually WYSIWYG. And if you think about it, WYSIWYG is amazing for editors. Editors can go into these things, they can, you know, to
figure out how it looks, but when developers see that, what we're really doing is
we're interpreting HTML. And we're really kind of
merging the content and the look in these WYSIWYG editors. If you dig into the HTML
of a WYSIWYG editor, you see there's all sorts
of crazy CSS going on there, there's all sorts of
additional spans and divs and unnecessary HTML elements
that get thrown in there and it's just kind of a mess. And when you, you know,
really kind of make it so content and look are the same thing, you really force yourself with that HTML to only allow it to be
used by a web browser; you can't take that to your cell phones, you can't use it on your smart fridges. You're really just breaking portability. So just to kind of summarize that, WYSIWYG has a couple disadvantages. It's too flexible, it mixes those content and look paradigms, it's really easy to screw
up for your editors, and you want HTML as the input which, I think, as the developer is really rough to work with. And, you know, you might
hear this and think, "You know what, I'm
gonna just build my own "content management system "that fixes these problems for me." But really, you know, I
don't think most people think that building the, you
know, a brand new application that you have to maintain is the solution to all of the problems. And most of, like, you
know, who has the time to maintain and keep
things like that running? And that's I think
largely where Contentful kind of comes in. So we have a different
attitude to managing content. We like to think of ourselves more as a content infrastructure, so we're here to empower
and enable developers. So rather than hosting
a monolythic application that your editors are
kind of familiar with, we give you your content
through just a standard API, we don't render it, we pass it on to you so you can build your website
however well you damn please because let's be honest, you're, you know, there's
a reason that developers are out there, and that's
because they're great at making things and creating things and you should be able to
render the content as you need. So when I'm talking about Contentful, really what I'm talking about is this idea of structured
content that we pass on to you that your developers can know and expect and then build around, providing an editing experience that your non-technical
folks need to be successful because they're never gonna be able to successfully edit markdown, and I don't think it's
realistic to expect, you know, a person that doesn't
have developer experience to learn it or to hire
them with the expectation that they already have markdown skills. And also, you know, it's much faster to split the content management piece away from the rest of your application and really, you know,
make it so you have all the functionality, all
the ability to build whatever functionality you
need to into your applications. So Contentful has four major
kind of APIs that we provide: our delivery API, our preview API, our management API, and our images API. And I can talk a little bit
more about those later on, but really I kinda wanna
show you a practical example of what I mean with Contentful and kind of what it's like to use it. So for me to give you an example website, I need to take a small tangent. So full disclosure about me, I'm really into long board
games like Linda mentioned earlier in the talk. Along with that bald
gentleman on the left, I helped organize a group in New York that plays this game
called Twilight Imperium. It's a really long board
game, it takes about 14 hours, and we have a group of people
in New York of about 30 people that are interested in
playing at least once a month. So we're usually running
about four or five of these games every month. December's gonna be really exciting for us 'cause we're gonna tally all the scores and the top six are gonna have, like, kind of a showdown match to figure out who the best person at this
board game is in New York, and I am currently in the top six so hopefully I make it to the finals, but it's a little hit or miss right now depending on the December game. So I went ahead and I just a dumb website to kind of help us organize the games. You can go to TI4.NYC. It's, you know, pretty simple. It has some information about our group. It has the logs of some of our games. It has some contact stuff
so you can reach out to us and then just some information
about how to get involved. And this is a pretty cool site, right? But full disclosure, I'm
not a front-end developer. I did use, you know, a
port of the HTML5 UP! team, a starter that was converted into Gatsby. And the stack of this website, you know, is a Gatsby website. It's deployed on Netlify and the content is provided by Contentful. So let's dig into that About page. We've got a bunch of kind of,
I think, pretty common things for a website. You know, there's a title up top, there's a feature image, there's some text with some links in them, and there's also a slug which,
you know, kind of helps you hit that route. So in Contentful, when I
was creating this page, what I did was I defined
something called a content model. Now content model is kind
of similar to a database in that, you know, it has defined values. So, as a developer, you can
go in and say, you know, "I expect any content
model of a type component "to have these things: "a title, a slug, an image, some copy." And then, you know, the order
it shows up in the website. And then an editor, so in
this case Sean, my bald friend who unfortunately is not a programmer, is able to go in and he's
able to create this page. He's able to fill this out, you know, set the image, upload it, doesn't matter what size image he uploads because Contentful can do the conversion and make sure that the
images that we're providing are appropriate and scaled appropriately. And he's able to type things
out in an editing interface that you can, you know,
hover over something, click the link button, type
in the link, and it will work. So that's kind of the data. Now, when I request that data, Contentful is gonna return it
to me through our JSON API. So this is standard get
request that we make to our content delivery API that returns to JSON object
that is just the data that means to a developer to
find them a content model, Sean is the editor has filled out, and now the application has ingested. So this is just the CA:
the content delivery API that we're using here. Now we're in Gatsby. I'm gonna go ahead and configure the Gatsby source Contentful
plug-in in the Gatsby app. Gatsby's gonna take that JSON, it's gonna hit the Contentful APIs, and take all of that information and convert it into the
GraphiQL implementation that Gatsby uses. It is something a little different from the Contentful GraphQL implementation that we're currently in beta, but it is a plug-in
available that, you know, helps bridge that gap between
Contentful and Gatsby. So now that Gatsby has that data, I can pull it up in GraphiQL. From GraphiQL, I can write my queries and figure out, you know, how
do I get access to that data. I can take those queries and I can, you know,
plug them into Gatsby, take that data, and pass it
over to my rendering function and now that I have that data, I can render the page,
I can build the site, and then for this case I'm gonna go ahead and also throw it up on Netlify. I'm gonna provide Netlify
with my, you know, appropriate API keys and set
up some webhooks on Contentful which will then trigger any
time we hit a publish event and that will deploy our website for us. So I'm gonna go ahead and show you a quick
practical example of this. On Netlify, I've hooked up the code base, I've configured everything. And so in this project, I'm gonna go ahead and I'm gonna change one of the images. So Sean is gonna go in, change it from a fleet to a flagship, hit publish, Netlify is
gonna pick up that change through the Contentful webhooks, and it's gonna cause a rebuild. That rebuild is gonna
take just a little bit and then when we go back to
the Twilight Imperium website and we refresh the page, that image should have updated. So the site is live now, Netlify is all finished and
we refresh and we're done. And there's our new image. And that's great! You know, connecting the content model and the data up to Gatsby
was fairly seamless. In terms of stack, what
this is really looking like is Sean is, you know, hitting
the content infrastructure making the pages that he needs, changing the pages as he needs to. I'm building the Gatsby site, you know, I'm typing my code into GitHub, that's, you know, going- both of those things are
going up to the build server so if any of those things change, it retriggers the build server on Netlify, and then Netlify when it's done will, you know, deploy it out to its CDN. So it is, you know, living on the edge. And so that way when a user
wants to get that site, they, you know, always get
the most up-to-date version as fast and as performant as they can. And more abstractly, what
that really looks like is editors hitting the
content infrastructure and developers working
with the source control in parallel successfully on that site which I think is really exciting. And so that code is all up in GitHub if you're interested in
kind of digging into it. And there's a lot of Contentful starters for Gatsby specifically that are out there that are also really great as well. I think there's really great documentation on kind of both the Gatsby
sites and the Contentful sites that you can dig into. So I really kind of want to
actually take a quick second to talk a little bit more about the experience
of developing software and the experience of using that software. So we're kind of on this same
page about how, you know, we can handle content using Contentful, but most developers and
editors do need to engage with that content infrastructure. And I think we can do a lot
of stuff to make it better. And I think something to keep
in mind as we create websites and create projects that
people are working with is that the way that editors
and developers evolve and update applications is
totally different, right? So traditionally, an editor
is going to draft something probably in Google Docs or Word. That document is gonna go to someone that gets a copy reviewed and edits and that's, you know, completely before that even gets to the website, maybe it needs to get to legal, they're gonna go ahead and want
to put it up on the website and they're gonna wanna see it and they're gonna wanna preview it and then once all of those
things are kinda cleared, then it hits production. Whereas a developer's experience is gonna be pretty different but, you know, it's gonna
use some of those same words. So a developer's gonna spin
up a copy of the source code on their local machine, they're gonna build a feature or fix a bug or do whatever they need all locally. When that's ready, and maybe
it'll go to a QA stage, a QA is gonna check it
and do what they need, it'll get pushed out to
staging where, you know, the entire organization can
preview it and check it, and then it'll get
pushed out to production. And we're using, you know, that
word preview in two places. There's both editorial
preview and developer preview, but they mean different things. They mean really different things here. For a developer, preview's
largely does this work? Whereas for an editor, it's,
you know, does this look right? And I think when you kind of
combine these two workflows, you really kind of push
yourself into the danger zone, you know, this area where, you know, editors don't quite understand
the software workflow and software engineers
don't necessarily manage to bring the content back up to the stack. And so I think that is
something to really keep in mind as you build solutions, is that the words might be the same, but the experiences are totally different. So let's talk about improving
the editor experience. And I think what you get out
of the box is really great, but with a little bit of work, we can really make the experience better. And when I'm talking about
improving the editor experience, I'm really talking about
improving Sean's experience. I want Sean, my non-technical
friend and co-organizer, to really be able to use the
content management solution and be successful. So an example of this is that
Sean wants a custom field type and I don't think that's
an isolated feeling. So with our board game, you know, we have a lot of information
that we try to track: who is at the table,
there are six players, how many points did they score, and what faction were they? And unfortunately, for whatever reason, Contentful and our
product team has decided that building a dedicated
Twilight Imperium tracker that gets rolled out to all
of the Contentful customers is probably not the best use
of our engineering resources which I have strong feelings about, so in fact I just went
ahead and built my own. And yeah, so I built my own
using our UI-extensions feature. So this looks kind of like a natural thing that fits into our standard web app and it's using our UI-extensions framework which is really great. It's an NSK that we provide everyone. It's a feature that enables you
to upload HTML to Contentful which then gets rendered into
an iframe on our website. So let's dig into this
extension really quickly. So what this is is actually just a wrapper for our JSON field. So we have a few standard
fields, you know, a text field, a number
field, a reference field, and we also have a JSON field. So if I turn this UI-extension off, really what it is is
just standard JSON data and me as a developer, I
totally get how this works, I feel completely
comfortable editing this, but this isn't necessarily something that Sean is comfortable in doing. If we pull this data up in GraphiQL and I have Contentful pass it through, it comes out as standard object which we can work with and
is, I think, pretty familiar, you know, from a standard
thing that we can use. So the way our UI-extensions
work is, you know, at the end of the day, it kinda
looks something like this: an HTML file that stores, you know, the styling and the form of
what things should look like and then the JavaScript that,
you know, manages the logic, and then a configuration file which, you know, defines what
the names are and the IDs and also what fields that the UI-extension will interface with and work with. So the config file for
this is pretty simple. It's just a, you know,
an outline of what it is and saying that it works
with our object field. The form is also a pretty standard form. It's using some of our
classes in Contentful to kind of hook into the Contentful STK. It asks for a name for each
player, a score for each player, and then, you know,
what faction were they. And then down in the script section, there's a thing that grabs all that data, a function that grabs that data when any changes are made and then sets the field
over on Contentful. And then there's, you know,
a simple get data function which is kind of does a four
loop with all the information. Now that we've created that UI-extension, we can push it up to Contentful. We can go into Contentful and
we can create a JSON field and set the appearance
to our new UI-extension, and that's it. So Sean is able to now
hit create a game, log in, and edit JSON data with
this kind of curated, guided experience that he
really needs to be successful, which I think is really great. And then Gatsby is able to take that data and also, you know, do what it needs to do to render it out to the site. So now there's a game log up on our site which you can dig into and you can see, you know, if I'm full of shit and I'm actually good
at the game or I'm not, so…
(chuckles) So Sean is really happy
because he can spend more time doing other stuff and he
doesn't need to, you know, worry has he taken the site down, which is a I think really cool way that, you know, the two
of us are able to… I'm able to create an experience for him that enables and empowers
him to be successful. So that code is also all up on GitHub and there's also some other
UI-extensions that you can use. It's not necessarily just for forms, you can interface will all
sorts of third-party vendors like Shopify to do search for items or all sorts of other things. There's a great extension
that one of my coworkers built that is just, you know, a
trigger to build a build button on Netlify. Their editors wanted to do preview and preview in static sites can sometimes be a little complicated so they just added a
button for their editors to just hit build and then, you know, a minute and a half later they're able to go take a
look at the preview site and, you know, confirm what
things are looking like. And that really means that
what this feature does is it lets Contentful be
friends with other vendors which I think is really cool. There's all sorts of prebuilt
extensions in our marketplace that you can check out as well. And so I don't think I'm gonna talk about developer experience today, I think I'm running a little over time, but there's all sorts of additional stuff that you can do to really
improve the developer experience using these systems as well and that's pretty much it. I think I'm out of time, so I'm gonna hand it back to Linda. And if you're interested,
all of these slides are up on my GitHub at Shy slash talks, so… – [Linda] Great, thanks Shy. And we are getting some
questions coming in that Sam and Kyle are getting to as well, so keep your questions coming. I'm just gonna take a few minutes to go over a few case study examples, then we'll have a demo of a new product that Gatsby is launching
called Gatsby Preview, and then we'll have a little bit of time for more questions as well. So I wanted to give you
two examples of great sites that are Contentful and Gatsby sites. The first one is Flamingo. It is body care for women. It's a product by Harry's
and it's at shopflamingo.com. This is what the website looks like. Really beautiful imagery,
a great flow to it, a nice kind of image
resolution and everything. So this is an e-commerce site having products for women. And they, when they were
looking to build this site, this is a totally new site, they were preparing for
a big product launch. They knew they were
going to have to handle lots of traffic spikes 'cause they were preparing a big PR push and they didn't want any room for failure. Like obviously, you
don't want your best day to become your worst day. If you have a product or
a website that goes viral and lots of hits, you don't
want your site to go down. So they wanted to make sure
they built it with performance in mind right from the beginning. They're working on a tight timeline which can be typical for
doing a product launch. They knew most of the website
visitors would be on mobile because of their experience
with Harry's' website, and they needed
performance out of the box, so, you know, they didn't
want to spend a lot of time kind of fine-tuning the performance; they needed development tools that would give that
performance right away. And in fact, Tim Brown, who
is a senior software engineer at Harry's said that, "We wanted to focus on
performance at the beginning "of the project because that's easier "than trying to make a built
website perform later." So, you know, he's had
plenty of experience working with websites, building websites, and he knew he needed to
get the performance right from the start on this one. So as a result, they launched
this site last month. It was very successful, they were able to get a lot
of PR attention around it, lots of website traffic the
first week that they launched. They said it's five times as fast compared to the other Harry's
websites that they have as well as their competitors'. And it is mobile-optimized. They were able to get
performance out of the box with Gatsby, and also it's
very important for them to have their content creators
able to update content on a regular basis, so that's why they went
with Contentful as well: it made it a lot better
and easier experience for the content creators. So with Contentful and Gatsby, they were very happy with this new site. And Johnny, who is an
engineering manager at Harry's who worked on this project also, said, "As an e-commerce site, performance, "meaning search engineering
optimization and conversion, "is super important and Gatsby
takes care of this for us." And one more quote from them: "We were able to allow newer teammates to be part of on-call
for the launch because "Gatsby made is so easy to maintain." So Tim was mentioning this point around having their website hosted
on the edge or on the CDN. He didn't have to worry
about traffic spikes because he knew the CDN would handle it, and this is kind of speaking
to that paradigm shift that Sam had mentioned
earlier on in the webinar about a new modern way to build websites hosted on the edge really can give you peace of mind, especially if you have
a lot of traffic spikes for your website. So the second case study
example I wanted to share is Youfit Health Clubs. They're at Youfit.com and
they have a lot of online, sorry, not online, but retail locations. This is their website. They use their website
mainly for lead conversions. So they want people to join the gym and to sign up for a free trial. They also get a lot of views
on their specific region pages so you can go in, find a
club, put in your zip code, for example, and find the health club that's nearest to your location. So when they started looking
at doing a site rebuild, their old site was very slow,
they had a 60% bounce rate, and they knew they were losing customers because the biggest way
for them to get customers was through their website, but yet an underperforming website was meaning they were losing
customers and revenue. Also it was a really poor
experience on mobile devices and mobile device traffic
is just increasing and becoming even more important today. So doing their site rebuild
with Contentful and Gatsby, they were able to increase
their lead conversion by 60% so just a huge improvement
in lead conversion, right? Right away, just by
doing the site rebuild. They had a over 20%
increase in organic traffic. A lot of that was due to
having their region pages, the pages that were specific
to a gym in a specific area, those were more optimized and then Google was able to, you know, search and make that
organic search a lot easier. They also increased
their accessibility score which also improved their
Google search ranking, and their page is a lot
more mobile optimized. So Zach, whose the director
of digital marketing at Youfit said, "The website went from being a burden "to a strategic tool
we use to capture leads "and generate RIO." So when he came on board with Youfit, he recognized right away that they needed an improvement to their website, and then was able to get that improvement with Contentful and Gatsby. Okay, so to get started
with Gatsby or Contentful, just go to gastbyjs.org or Contentful you can
go to contentful.com. They both work very well together, but that's where to get started. Like I mentioned at the
beginning of the webinar, the webinar has been recorded and the slides and the recording will be available later today. I will send a link to those
to all the registrants by the end of day today. So thank you for joining us today. Thanks to the speakers, Sam and Shy, and for Kyle in the background helping to answer some of the questions. Like I mentioned before, in about a week we will also
have a follow-up blog post where we will get to any questions that we weren't able
to during the webinar. So thanks so much everyone for joining, and hopefully we will see
you at our next webinar.

One thought on “Rise of The Content Mesh: Webcast with Contentful and Gatsby

  1. Great webcast! Combining the power of Gatsby, Contentful and Netlify is really delivering outstanding results!

Leave a Reply

Your email address will not be published. Required fields are marked *