Git-based or API-driven CMS - Chris Macrae

hi there guys so I'm here today to talk about get back forces API driven CMS's and the purpose of this talk here really is to talk about the modern reality of content management and how these two different types of CMS's are playing into it and my goal here really isn't to evangelize either one it's to give you guys the information you need to basically choose the tool that fits the jobs that you're working on so before I get started in an introduction to myself my name is Chris McRae I'm head of developer relations at forest radio we are the leading get back CMS for Hugo and Jeckle sites and we let you edit build and deploy your blazingly fast super secure static sites so before we actually jump in to get back forces API driven I want to talk about old versus new and essentially what I'm talking about here is the traditional CMS versus the headless CMS that we're seeing now so these are things like WordPress Drupal crafts CMS and Kirby you guys are probably all familiar with CMS's like this and then we have these new headless CMS's which are things like Forestry nullify CMS contentful and get cockpit for example and the big difference between these two different CMS's is the traditional stack is that monolithic stack that you're used to where the CMS is hosted on a server front to back and that has a lot of problems with the reliability and performance and security and this headless stack that we're seeing now aims to solve a lot of those problems and it aims to do that by decoupling content management from production environments and what I mean by this is your content management is separate from your front end and your back end the CMS doesn't know about presentation at all and it solves a lot of the problems that comes along with performance reliability and security so I'm going to quickly go into a little bit of detail on that so the problem with their traditional stack number one is vendor locking and this really comes from that monolithic framework when your when your front end and your back end and your content management are all highly coupled together essentially what you're doing is giving content editors a CMS at the cost of developer freedom so when you install something like WordPress you're basically for putting yourself into a proprietary content model and front-end standards and what this means is the longer you use a tool like this the harder it actually gets to move away down the road if you decide that it's not good for your business performance another big problem with this vendor lock-in is it makes it really hard to repurpose your content from multiple front ends so what we're seeing these days is a lot of companies are starting off building you know a simple e-commerce web site or a static site and they realize a couple months later that they want to go into mobile or they want to go into different types of platforms and with a traditional CMS it actually makes it a very big challenge to do that so the next big thing is poor performance and this is really where the Achilles heel of these this monolithic CMS comes in and the reason for that is they're almost all exclusively dynamically rendered so when someone comes to your comes to your site to and requests a page the CMS has to actually dynamically generate the markup for every single request and that adds a lot of overhead when people are visiting pages so I'm gonna actually break this down for you just to you guys a little bit of content context so you know somebody comes to your site in the browser they hit they send a request off to a server that server is going to make a bunch of requests off to the CMS which then has to go make requests off to a database it takes the data from the database builds the template and sends the HTML and assets back to the browser and the big problem with that is all of that over it has to begin before the browser can even start downloading the page so what we're looking at here is this time to first byte when all of this is happening the browser sitting there waiting for the server to send this stuff back and so this example I'm showing here is actually from forestries website before we made the move to static it was initially actually part of our back-end infrastructure as part of our rails app and our time to first byte was actually over a second so every time somebody would hit a page you'd be sitting there waiting a whole second before it even start downloading and Google released a stat in 2016 saying that the average mobile visitor will actually leave your site if it takes more than 3 seconds to load so we were actually well over that so we identified that we wanted to fix that up so you'll see here our media was actually well over that 3 second mark and so is our JavaScript so what our initial approach would have been is what we were used to in this traditional stack well let's add some infrastructure in place to actually try and optimize performance so again we go over this we've got all of these requests happening step by step we're sending HTML and assets back and step one would be to add in a page cache and a database cache and essentially what we're doing here is when the server is making a request back to the CMS if you've got content that isn't changing you've got markup that is exactly the same for every user we cache that and what ends up happening there is there's no overhead the content goes straight to the browser and we don't have to wait that one second for the content to come down but what happens if we have dynamic content you have a user content like e-commerce recommendations for different products in that case we can't cache the HTML for the page because it's different for every visitor so we put a database cache in front of that and that way when the CMS requests makes requests off to the database we can actually cache their common requests and move straight on to rendering the markup and sending it down to the browser as fast as possible so the next big thing we run into is you add a CDN to this monolithic staff and the reason for that is if your server is hosted in North America and you've got someone in Australia requesting a page what you're gonna end up running into there is that distance is going to increase that time to first byte and it's going to increase the time it takes for images and assets to download so a CDN essentially distributes your cache content and assets all over the world so when someone requests a page in Australia they actually get the content from a server in Australia which makes that process a lot faster and in a simple setup you're only sending over your assets you can even make this setup even more complex where you're actually serving the the page page to the CDN as well and then you have to deal with a whole bunch of complex over overhead there and then the last thing we've been seeing in the last few years is we're also adding in api's into this stack so on the front end using javascript we're decorating HTML and pulling in dynamic content after the fact just to give the illusion of performance increase and this just adds another layer of complexity onto the stack but what the end result of all this is is our time to first byte is much much lower we've instead of having a second you've got you know hundreds of milliseconds so the users getting the HTML right away and they're seeing images come in a lot faster but when it comes down to brass tacks that's just a ridiculous amount of overhead and I know everyone in this room feels like there's got to be a simpler option so the next big thing with this stack is poor reliability and that comes in due to all of these moving parts making sure all of it is working all at once is a lot of overhead for a developer or a dev ops team and the next big thing and that is there's always a bottleneck I'm sure you're all familiar with the reddit hug of death you know you get your site up on the front page of Reddit you get your 15 minutes of fame you think it's great and then you know an onslaught of new visitors come to your site a part of your stack can't handle it and the whole thing goes down and so in that case you have to scale your stack and that gets complex so what I want to cover here is in regards to scaling this stack and keep keeping it all reliable all of the different moving parts you have to manage so looking at this you've got a page case or in your database case you have to manage cache and validation and resource management on your server you have to manage provisioning and monitoring and management on the CMS you're gonna have to do security updates and plug-in updates and all the management of that on the database you've got tuning and maintenance you've got migrations and replications and you've got backups and on the CDN you're gonna have to deal with cache and validation and versioning and all of these different things and it's just oh so so much for a dev team to manage and then you have the reddit hug of death and you realize that you know your single server can't handle all of this so then you've got to scale your stack and so what you end up doing is you double this or you triple this or you could Drupal it and now you have twice double triple or even quadruple the overhead with multiple servers running all of this infrastructure and it just becomes extremely hard to manage the DevOps team in this scenario have to make sure multiple servers are all in sync and all serving the exact same content and it's just a Horror Show so the next big thing is poor security and the big issue with these monolithic CMS is in this case is they need to be installed in a server and exposed to the Internet because they're your back-end they're your front-end and they're all serving all of your content so in a lot of these systems there's methods for hardening them making them more secure but when it comes down to it a single vulnerability and this monolithic stack could compromise your entire system this mean and what this essentially means is you're putting your trust in the provider of the CMS the developers of WordPress or the developers of craft to ensure that the CMS is secure and then you're taking on the overhead is a development developer to actually keep the CMS up to date with all of these security updates but even more importantly the security issue falls into this stack what I like to dub the plug-in economy so all of these traditional monolithic CMS's basically rely on an economy of plugins built by third-party devs to actually add all the additional functionality that you might need for your specific site and this by itself doesn't seem like a big problem it seems like a big bonus but when you consider this security issue where you're already relying on the provider of the CMS to keep things secure when you're adding in 1 2 5 10 maybe even 20 plugins built by 20 different developers all over the world you're now putting your trust in those developers to ensure that the code they're writing is secure and isn't adding any you know opportunities for breaches in your CMS or in your stack and when when it comes down to it you can't put your trust in these developers so you as a developer are taking the burden of all the responsibility for the security of the CMS and that's a big deal and to put this into context I actually have a funny story we were getting packed up ready to fly into New York City I made a phone call off to my bank provider about my American credit card asked him to make sure everything's good and I can use it in the States and they went actually it looks like there's some interesting statements here's some charges that what kind of fraudulent and they were like it looks like you may have been compromised and it the case had been Equifax had announced a cybersecurity incident affecting about a hundred and forty three million US consumers and because my credit card was an American credit card I actually had had been compromised and somebody in California spent about 800 bucks in a McDonald's over a couple weeks so I couldn't use my credit card over this whole trip so it just puts it into context how how important making your your websites are secure and making sure your whole stack is secure so the next big thing I want to talk about is cost and when it all comes down to it there's two factors with this monolithic stack you have technology costs so we were talking about your servers your databases using a CDN using bandwidth CPU cycles all of those things that developers are familiar with your upfront cost for that but then you're also playing development cost and resource costs with your team you're going to need to hire front-end engineers back-end engineers and even DevOps teams to manage all of this stack and that's all gonna cost you more money it's just to deal with all of this performance reliability and security issues and to put this into context WordPress VIP which is essentially a managed stack for enterprise installations of WordPress starts at five thousand dollars per month for up to five web sites on their cloud cloud hosting option or their help self hosted services start at 15k for per year so to put that into content context in a year you're basically paying the WordPress team $60,000 to deal with all of these performance security and reliability issues so when it comes down to it managing this complicated stack isn't easy you need deep knowledge of the browser of server management of databases caches caching and CD ends the CMS backup automation versioning and just so much more and what it all comes down to it none of us want to deal with that absolutely not so the real question is what do we do well you know we've been building websites for over 10 years can there really be a better way and as you guys all saw bud talks earlier there is a better way and that is the headless CMS and the Jam stack so you know what this is is the modern decoupled stack it is using CMS's that focus solely on managing your content and providing a really good experience for your content editors while empowering devs to use whatever front-end and back-end technologies they want and it's the jam stack it's this awesome new approach to building websites which is a lot faster a lot more scalable and just a lot more fun to be completely honest it's much more fun to build these jam stack sites so again the solution in this case is they get back CMS which is again like forestry or net Liffe ICMS and we have the API driven CMS which is contentful or get caught as an open-source option and essentially the difference between these two options are the get back CMS is a layer on top of git it's interacting directly with a git repo and everything that happens in the CMS is just you know an action taken as part of the git workflow or as the API driven CMS is you know a cloud hosted option which is basically just offsetting the the stack that you're used to seeing in the traditional monolithic stack and it's given developers a really nice rest like API to consume content with and the JM stack just to give a quick brief overview on that is a JavaScript API and pre-generated markup and the whole premise behind the jam stack is you pre generate markup with build tools and you decorate that markup with JavaScript that consumes from you know API is like stripe intercom discuss or any self created API that uses ternal II to that you can deploy to a CDN serve really fast and you know give the best possible experience you can to users so this is where I'm going to get into get back purses API driven and my goal here is to kind of give you guys a picture of what's the difference between the two of them so you guys can understand which tool is right for you so the first thing I want to talk about is storage this is one of the biggest differentiators between these two types of CMS's so getting started with the get back CMS the CMS lives in the cloud and it essentially connects and communicates with a git repository your contents living is text files and git so they're either marked down or HTML or a variety of different formats and your content model actually lives in these text files as what we call frontmatter so it's structured metadata and all of your content changes are happening in get as part of the git workflow so you're doing as people are adding things in the CMS you're seeing commits and get you're seeing branches and get you're seeing no requests happen so it's something that developers are really friendly and familiar with and developers are using build tools inside the get repo to basically create an API to build sites with that content that text content and gif whereas in the API based approach your CMS lives in the cloud and in in general its communicating with a database in the cloud that's just abstracted away from the developer and your content again is living in the database it's structured by the CMS and editors are using a cloud hosted interface to edit the content and developers are consuming that content using a rest like interface using a REST API so they're you know dealing with JSON responses like you're seeing there so the next big thing I want to talk about is cognitive load and this is another huge factor for treat between choosing between these two options depending on the size of the project you're working on one option may be better based on this and what I mean by cognitive load is how easy it is for individuals to learn about your new your new stack about the project you're working on so in the get back approach developers are really loving this and it's because a database of text files are really really human readable and easy to understand you know your mom who uses a Mac every day or a Windows PC every day is going to understand a set of files and folders and and can understand that very well it's very intuitive the next big thing that makes get really good is backups and versioning are you know built right in it's built into the get workflow so developers intuitively already know how to do that the next thing is a frontmatter is very very easy to manipulate seeing a bunch of key value pairs in a text file is really easy to understand and the best the big thing about git is content editors are actually using git without even knowing about it so they're using a CMS interface that they're totally used to it feels like WordPress but when developers are going and interfacing with the project they're seeing that developer workflow that they want and they need whereas in the API based approach larger organizations are using because in the API driven approach your rest like interface your STP is give you one single source of truth for your content so if you're building a large project with a website and mobile apps or any other kind of technology like that you're not having to use built tools to purpose that text content in a format you need for those sites you're using the exact same format however it requires a lot more overhead because you can't just pull down a repo and get started and so to put this into context in in the git based approach to start a project you basically just pull from get you download the dependencies for the build tool you start making changes and you build the site and when you're done you push you push your changes into get and you're done the site rebuilds itself whereas in the API based approach you're pulling down the project down from get you're downloading dependencies you have to authenticate with the API you have to pull in the content with the build tool and then work on it from there so there's a lot more overhead there so for no smaller projects it's kind of overkill the next big thing I want to talk about is intellectual property and this is a huge huge factor in regards to this old monolithic stack the reason developers chose to you know host a wordpress.org site or host a craft CMS or any CMS like that is because we want to own our content we don't want to hand our content over to other providers so using a solution like WordPress calm or Squarespace means you're kind of giving that ownership up in return for you know a little bit less overhead and in the get back to proach you're actually we're actually maintaining this you know all of your content changes are happening in get the whole workflows happening and get your you know all of your backups and the history of your entire content is in get and you own that repository a developer can pull that down and go back through the history whenever they want and what it means is you're never actually tired or poor holding to the CMS you choose you decide that the get back CMS you're using you don't like you you know pull it out you move on to another one you connect with you connect your gate repo and to start using that CMS where as in the API driven approach all of your content and your history is actually stored in the cloud by the CMS provider which means you're a little bit more tied to that CMS provider you still have that vendor lock-in that we saw in the monolithic stack what that means is switching will require DevOps migrations and you know all of those things that we want to avoid we don't want to deal with but you're in and you're doing that to basically get the benefit of having that single source of truth for your content so it's a trade-off that you need to you need to pay depending on what problem you're trying to solve so then the next big thing I want to talk about is solving the old Stax problem so again we have all these problems we talked about and you know how does this new stack solve all of these and again the first thing is decoupling the content management system front-end code and back-end code really solves the vendor lock-in problem given that your content is is separate from your front-end and back-end the markup and code that you use is completely up to the event developer and the back-end services you use you know the server-side processes and database actions you use are completely up to you so to give you guys some context for this in this new stack you've got a build tool and generally you know it's either talking to content and git or it's talking to third-party api's it's pulling that content in it's processing it and it's turning it into static HTML image assets j/s CSS all that kind of stuff and you're deploying it up to a CDN where it can get served you know lightning fast the browser and then using javascript you're talking to AP is in the cloud and so in the get back to proach all you're really adding into this is the CMS which communicates with that content and git so when an editor makes a change in get it gets reflected in the git repository as a commit or when a developer pushes a change up to get it's getting reflected back in the CMS automatically and then the content is again read in by that build tool converted into the static assets and deployed up to the CDN whereas with the API driven approach you know the contents getting it edited in the API driven CMS hosted up in the cloud the content is reflected in an API that developers interact with so you know you're authenticating with that and the build tool is pulling it in and creating the assets that way and then again dynamic functionality like comments and user authentication is all handled by API services so this is where I think this stack really really shines so going back to that going back to the old stack at the plugin economy you're installing a whole bunch of plugins to get all this functionality you want but we've been seeing this API economy emerge in the you know the last five or ten years where you're using services like stripe or intercom or SendGrid to handle complex stuff like payment and customer support and email handling and why this is really great is your trusting major companies to handle all of this complex infrastructure instead of you know waking up at 3:00 a.m. because your proprietary payment system failed and you're having to like sling some code to get it fixed you just submit a support ticket go back to bed so it makes it makes life easier for us so the next big thing is great performance and this is through simple hosting so really this is this is a no-brainer in that old stack we have so much going on you have all this infrastructure we have to manage we have to scale it and in the new stack all we have is a CDN and third party API is it's a no-brainer this is where we're you know getting rid of all of this logic and so this simple you know stack where you have a CDN sending HTML and assets to a browser and any and the browser talking to AP is through j/s is giving that us this performance increase that we had all that infrastructure for pretty much for free and you know that's just a huge win for us it means we can get back to doing what we love best and we can get back to you know solving real problems instead of trying to solve all of these complex infrastructure problems and so the next big thing I want to talk about is reliability and this is due to the distributed infrastructure that we're seeing here so in this stack as compared to the old one you know you have a build environment either your CMS is handling it or you're using a you know a tool like natla Phi which is handling your builds for you and this is completely separate from the rest of your stack and you can scale it as you need it if you're finding builds are taking too long you you know you throw more resources specifically at that problem and then at that bottleneck the next stage of this is you know the CDN and the browser this is completely separate from your build process so in its handling serving your site to your users so this is basically self handling the CDN scales itself you don't have to deal with any you know reliability or infrastructure problems here and then the last part is the third party API so the internal API is you're using to you know add dynamic functionality to your site so if you're finding these are a bottleneck you just have to actually either scale these discrete services or go out to the providers that are using like stripe or discuss and complain to lend to them and let them handle it so it makes managing the stack a lot easier and the last thing I want to talk about is superior security and again this is a no-brainer in this stack and this is because you have a secure CMS because the CMS is decoupled from your front end and back end give security concerns you can put the CMS behind a firewall because all it needs to do is talk to your get repo whereas in the old stack you would have to deal with hardening the CMS so you know security of the CMS becomes a no-brainer you have bulletproof front ends because it's completely static and you have no database or plugins or dynamic server software open to code injections or hacks it's completely bulletproof there's there's really nothing here that can get compromised and your back-end or being handled via these this API ikonn so here you have you know trusted companies that you're relying on them to build security or you have these you know smaller services that you're you can focus on the security of them alone in the communication between the browser and those api's so it makes the you know the cognitive overhead of managing security much simpler and the the other big thing is the distributed infrastructure actually makes security much much easier and what I'm what I'm referring to here is we're looking at like a gift based stack for example your security ends up becoming you know handling these these touch points where each you know service in your stack is communicating with each other where the CMS is communicating with your build environment or where the build environment is communicating with third-party api's or the browser is communicating with api's that's where you're trying to secure things and if one of these gets compromised it doesn't compromise the rest of the stack necessarily and it's the same in the API based approach you've really only got these four touch points and you're securing these kind of separately so let's talk about the pros of these two stacks so in the get back your pros are there's no vendor lock-in because it's your contents all in a git repo and you're using CMS's that are communicating with that repo you can kind of you know pull out the CMS and replace it at any time if you didn't if you don't like pros you can go to forestry and that kind of thing and it also means you have no lock into your front-end you can just you know if you decide to use Hugo and decide Hugo isn't meeting your needs you rip it out and replace it with Gatsby it it makes life a lot easier the next big benefit is devs and editors using the same workflow so because the CMS is talking directly with git if you're trying to if you're trying to train your team to understand what's going on in both scenarios you actually have only one process to train here you're getting automated backups and versioning it's a no brainer you don't have to deal with it you just you know deal with your git history and you've got simple setup going back to that you know of pulling down the repo installing the dependencies in getting to work whereas in the API driven approach we've got easy-to-use content with multiple front ends or then again what this means is because you have a single source of truth you're dealing with an API developers only have to learn how to use how to interact with the content once and they use the same process across multiple front ends it's api's driven CMS is a really ideal for content that changes you know more than once for a minute and the reason for that is a build process if you have content that is changing rapidly you can offset that to dynamic functionality with j/s and only build statically the resources that are changing rapidly so that way you know your build process isn't getting bogged down and your site isn't becoming slower another big benefit that we've seen is for large organizations you're able to roll your own CMS through the API and that's just something you can't really do with the get-back CMS right now and the real benefit for this is if you need to provide you know extremely specific interface for a specific kind of editor you as an organization can do that and the real pro here for API driven is there's a lot of choices they've been around the market longer and there's just a plethora of choices available from contentful to get cockpit to so many other options so then let's talk about some cons here and they get back it's harder to use content for multiple front ends and the reason for that is you're using a build tool to process text files so you're you know turning text into HTML if you want to use a mobile backend or create mobile apps you have to process that content differently so there's a little more overhead there it's not great for content that changes more than once per minute and the reason for that is again because you're relying on a build tool to build all of your content if builds builds take time if you're using a tool like Jekyll builds can take up to 30 or 40 seconds depending on how big your site is and if you've got content changes coming in you know 1020 times every minute I mean you just gotta have a build pipeline that's backing up a big con for the get back CMS right now is there's limited choices get back is a fairly new thing in the space and you know there's you know there's about a dozen or less choices out there right now depending on the static site generator that you're using and the last thing is content queries can be limited depending on the CMS if the CMS has an API you can do content queries that way otherwise you're gonna have to again rely on you know baking the different kind of content queries you have into your build process and the API driven approach a big con is storage and API usage limits they all come with them so what it means is you're gonna hit a wall depending on you know how much traffic your site is getting or how many times you're building your site or is in the gift based approach you know storage and usage is free because you're just running a build process devs and editors using different workflows so what that means is internally you're gonna have to train developers and content editors separately depending on how things are working backups and versioning is highly dependent on the CMS and this can be a big problem depending on which CMS you choose some of them have great backups and versioning contentful does a really amazing job of this but some of the other options don't have it at all which means you as a developer then have to take on that overhead again and what the big last thing is you have less control over content model and formatting because it's uh because you know you're relying on the the CMS to send the content back to you in a rest like API it means that you have to learn their proprietary format and you get less control over that and depending on your needs that might be something that you don't like so the TLDR for this the the too long didn't read is get back is really really good for websites that are static first and that can be progressively improved using javascript to add dynamic functionality and it's also really great for generating other formats like RS x or sr xml or json or even ebooks and I'll give some examples of that shortly and the API driven CMS is really really great for dynamic applications or platforms that have a website and mobile apps or it's a web app and mobile apps or for publications that you know have content that changes rapidly multiple times per minute because you can you can query that content on the front end with JavaScript so I want to get into some quick examples here just to give you guys some context for you know how people are using these different tools in the wild so I'll start off with US Forestry is actually built on a get back CMS using our CMS it's built using the static site generator Hugo which is really really fast we actually have dynamic functionality on the site using JavaScript use our session cookies to add in logged in State and it gives that you the users access to their sites and all that kind of thing and it works really well and it's hosted on a CDN everything's there all of our HTML is pre baked or CSS or JavaScript or images so it gets served lightning-fast another great example is the static ecommerce website called pretty fly fpv comm it's built by one guy here in the States and he basically sells accessories for first-person vision equipment and there's a really great quote for him where he actually tackled this project initially with the traditional stack and came to the conclusion that you know for 90% of small businesses out there the amount of work needed to make these stacks even remotely as optimized as a static site is is just completely overkill because the stack is just so simple and for him it's get back tis he's gonna get back CMS he's again using Hugo he's doing his ecommerce via a snip cart so he's pre building all of the pages and then decorating all of those pages with snippet carts jsapi to add all of the e-commerce state and everything and it's really really fast and it's really simple and it has no server overhead whatsoever so that means he can host all of his assets and HTML on a CDN and it's like fast the next example I want to go over is Nasty Gal and they do some really really cool stuff they've got a statically generated website using some proprietary technologies and they have they have they have a plethora of iOS and mobile apps and then they also create these single page applications called lookbooks which are basically stories that pull in content from their e-commerce website and teach people about the latest trends in fashion and let people buy those things right there using dynamic functionality powered by JavaScript on the front end so they're actually API drive driven using contentful they use static site generation for their e-commerce website using proprietary technologies instead of a traditional open-source static site generator their whole site is a single page app enhanced using JavaScript they use technologies like react and view or an angular those kind of things and all of their mobile apps and single page apps are powered by the REST API and the next thing we have is multi format publishing and this is the Getty foundation it's and this is a really cool example of using this technology so they actually have been digitizing arts and old literary works and they generate a responsive website that people can consume this art online they also generate eBook formats you can put on your your Kindle or your Kobo they're generating a downloadable PDF formats and that are print ready and then they actually take that generated PDF and make it sellable as a print copy in their store and this is actually get backed powered by this static site generator middleman which is generating that responsive web site eBook formats print-ready PDF all in one go with a simple build process and they're actually serving at all through a CDN so that users are getting it as fast as possible and can consume all of these content and it just makes it a no-brainer for them and then the last thing we have is a multi-platform application and the example using here as we were calm which is a company that aggregates co-working spaces all over the world and they have a website which is a static site that's enhanced with single page app technology and they also have mobile apps for people to interact with the community and it's API driven on contentful there again using single page app technology on top of their static site and they're powering their mobile apps via the REST API are you actually using a rails back-end on top of the content file API to handle some functionality that they need for these applications and so they're hosting all of that on a CDN they're there pre-baking as much HTML as possible and then serving the JSO ver CDN and the reason they use API driven in this case is again because they've got a whole bunch of different applications and using the API based approach just gives them that single source of truth they need but when it comes down to it what are these cell sites all have in common well they're fast reliable and they're much much more secure than the traditional stack the stack is dead simple and it's a lot smaller whether it's API driven or get back it's just way better for devs and it's empowering both content managers and developers to use the tools they want so when it all comes down to it you'd need to choose the right tool for the job but the tool you use and how you use it and how effectively it meets the needs you're using is what Matt or the actual tool itself doesn't so the more I want everyone to get out of this is whether you choose get backed or API driven you should do it on a case-by-case basis for the project you're using because they both serve you know really specific needs and they both do certain jobs really really well so that's it guys and if you have any quickly if you have any questions just shoot away can you elaborate how build process and API interact with its with each other to me it sounded you either build or you use API is directly from front and maybe I misunderstood that absolutely so what we've been seeing with a lot of these build tools and static site generators is they'll actually consume the api's at Build time so you'll authenticate with the API during your build process it'll pull in the content that you want to pre-bake you want to turn into HTML markup and then you'll then on the front-end using javascript you'll query more from the api as needed does that make sense it does so how does the bill to know that data within the API driven system has changed and which pieces of the site need to be rebuilt that's a great question so depending on the tool you're using and the build environment you have we'll see you'll either see the CMS will talk to your build environment and let it know it's changed or you'll see people using web hooks basically to inform the build environment that a change has happened in the CMS to update it but what we've been seeing a lot is people will for content that changes off and they'll actually pre-baked as much markup as they can and they'll actually pull that content in client-side using javascript and render that into the page so it's it's a delicate balance they have to play there I'm curious I'm curious how many of the security vulnerabilities you mentioned with WordPress might be mitigated by just using gotcha yeah so if you do use the API I there is some context where you can put WordPress behind his security behind a firewall on your own server you still have to expose the API obviously the one thing we've seen with a lot of customers at the forestry for example is they come in and they want to use this modern process because you know WordPress is still very opinionated and the API still doesn't give you the control you want so you're if you're taking an API based based approach it's actually a lot nicer to move into these API driven CMS's which you know are built content first and give developers that like you know detailed control they want over their content model and I'll just add to that the people that I know that have used the wordpress api have had to do quite a bit to it to really make it you know fit their needs yeah one common thing we see a lot we I had a user that I was talking to a couple weeks ago that said they gave WordPress ago and then decided to take you know a static approach with Hugo and his big problem was is he was a big big user of advanced custom fields like one of the most popular plug-ins for you know adding you know metadata to WordPress pages and it didn't play well with the WordPress REST API so he had to do a lot of who's trying to do a lot of legwork to actually get all of those fields in and just came to the conclusion that just wasn't worth the overhead in the effort which going back to that example from pretty fly fbv is that's exactly what he's getting at is you can use tools like WordPress for this modern stack but there's just a whole bunch of extra legwork and overhead to make it you know as performant and as reliable as these tools are whereas if you just make the move to these tools it's there already so I have a question I've heard the argument against and as you know I'm a big fan of the gift based approach and I've heard an argument against it that once you keep their content and their code completely separate so here we've got you know one commit might be you know a user updating their stuff from forestry and the next commit might be a developer what do you think of that I mean is that it is that a real problem or is it a problem that we're just kind of ignoring that we might regret day it's something that I know we and other players in the get back space are aware of I've seen a couple cool solutions where people have separated their content and their codebase and they kind of marry it all together inside a single git repo and you'll see like for example in people taking the API driven approach where for example using contentful and they're using you know their spaces and they're you know segregating all their content into you know separate spaces and then they've got their code base and yet we're actually seeing people taking that same kind of mental model and applying it to the git approach where you know your content is in a git repo your codebase is in a git repo you're putting them together and your build process and it's working exactly the same way as API driven approach so I think it's kind of a non-issue it's just we as leaders in the space need to figure out the right approach and kind of educate the world on how to do it thank you yeah so a couple more questions then sure so so the API driven approach seems to be great except that it doesn't really solve the performance problem because the data is still loaded from a some API from somewhere that is equally slow as the servers that originally served HTML in the old model right how does it fundamentally change and obviously if vendors fast as fast if not it's not right yeah so but it's the same problem as we had with a dynamic version yeah and so that it that is the big challenge with the API driven approach is the the whole Mantor there is pre-baked as much markup as you can so at a build time you know pulling as much as you can from that API so that you can serve as much of it as statically as possible and depending on the tool you're using you're doing that with plugins or or for example in Gatsby you you know clearing the API and Gatsby's turning that into its content model and then you can use that to build static sites but it's definitely an issue there where you're still as a developer having to deal with some kind of DevOps overhead to make that whole process work whereas in the get back approach you know all of your contents living and get and your pre-baking it and then anything that you can't pre-baked like e-commerce functionality and stuff you're just decorating that markup after the fact with you know JavaScript to get that functionality so like again going back to the the cognitive load example that I was talking about forget backed it it's it's more intuitive people get it so it's kind of easier to understand in the API driven approach you can get the exact same performance and you can get to the same place but it just requires you know adding more into that stack to achieve the same effect great set up for my second question so if I have a lot of data yeah and big website how do I incrementally build it because I don't need to rebuild every page but today's tools seem to be very centric on let's build a whole thing every time something changes yeah so that honestly all comes down to what you're actually using to as a build tool whatever's generating your markup so for example the two the two static site generators that Forestry supports Jekyll and Hugo actually both support incremental building and so when Scott comes up to show you guys a quick demo of forestry you'll actually see that previewing in our CMS is is very fast either in Hugo or Jekyll for that exact reason is they'll look at basically what content has changed what files have changed and they will only rebuild that page there's still a there's still a concern there when it comes to actually deploying the site the the logic there is rebuild everything and send it all up and again that all depends on what tool you're using because Hugo is lightning fast as but was saying Hugo can build a thousand pages in a second so depending on the tool you're using building every page becomes a non-issue and I want to add I think you can confirm this maybe but natla Phi has on one of their plans it's it's one of the enterprise plans I think but where they do they don't do the incremental build but they'll do an incremental yeah putting the pages up on them no really when you build only the change files will end up being deployed to the CDN so the builds are pretty fast and said with jekyll and hugo and whatever you're using and then our system will check against what we have in our cache and we'll only deploy stuff to each change so even if you have 20,000 60,000 files but you only change two then we'll just deploy two yeah and that is definitely the key depending on who you're using as either a deployment tool or a hosting provider you're looking for those features those basically those you know incremental deployment if you're using a build tool that's deploying 5,000 built pages over FTP it's gonna be really slow so hosting providers like nella Phi and CI tools are you know changing the game that way sure so I understand our thinking only changes is never a problem that's that's an easy part yeah so what if you have a hundred api's and the your application uses all of them and well and this CMS let's say yacht or not and how do you track what needs to be rebuild because that means that the application logic need to need to be somehow extract it into a build process yeah so that's a great question and a great example of this is if we were to take contentful for example and Jeckle the way contentful interfaces with Jekyll is a ruby plugin for Jekyll and what they essentially do is when you query the API during your build process they turn the API responses into files and Jeckle can then if the difference on files build the build so again that's where that approach can be challenging because you're taking API responses and turning them into files or you're adding in over ahead yourself to track the difference in the API yep not an option Oh help me out maybe a bit here the answer your question is they they don't they still build everything all the time yeah it the deployment is is easy to solve that's the rsync or whatever the incremental building that chris is referring to is generally on a preview or on a like watch command so like hugo server or jekyll serve it will do an incremental build when you change a file but if you're running hugo build or jekyll build it still builds everything from scratch well I what do you mean by dependency management yes web Jen had that feature a long time ago but it stopped being maintained about six years ago yeah it's a great question awesome no other questions great guys thanks for giving the time to listen and I will hand over to Scott to give you guys a quick demo of forestry or get back CMS you

Channel: The New Dynamic

Views: 29,701

Rating: 4.9496403 out of 5

Keywords: static, static websites, jamstack, javascript, markup, apis, jekyll, hugo, contentful, gatsbyjs, thenewdynamic, netlify

Id: KX4G49ZrvY0

Length: 54min 56sec (3296 seconds)

Published: Wed Oct 11 2017