Thanks for all of your questions during my talk at Frontend United: JAMstack: Silly name. Serious business.
- I've tried to answer all the questions which came in via Slido.
- I hope you'll excuse my typos and spelling errors as I type these answers quickly during the other conference talks 🤪
- Please don't hesitate to ask more questions via @philhawksworth
- Slides for the talk are online: https://noti.st/philhawksworth/tWfQIB/jamstack-silly-name-serious-stuff
Shouldn't we call if MAJstack. because the pre-rendered markup is progressivley enhanced with (optional) JavaScript.
LOL! I'm game! It would clear up some regular misconceptions about JAMstack sites relying on JavaScript. I'll see if we can rename the JAMstack Conference!
How do you deal with large assets that you don't want to host on a service like YouTube?
In many ways, the way we might approach serving large files (if they are not being served from a related service) on a JAMstack site, is similar (but a little simpler) to how we would on a traditional architure. That is to leverage a CDN (Content Delivery Network) to serve these large assets for you. On a traditional architecture, we might need to manage how those assets get cached in the CDN. On the JAMstack this can be managed for us by defailt, since every asset is bing served from a CDN bey default.
With Netlify, this can go further and support Git Large File Storage to help you version control these big assets for you without them cluttering up your got repos. Check out Netlify Large Media for more info
What if you had a site with +200,000 pages?
That's a challenge. Generating very large sites is a limitation for static site generators at the moment. Some, like Hugo are very rapid indeed, but will still result in long build times for very very large sites.
Some sites might explore ways that they might shard their structures so thay different sections can be built independandtly of each other to make the builds smaller. Some sites can still benefit from this pre-generation deployments because even a long build of a number of hours can be faster than other arduous long-running deployments. In those cases, during development, content samples can be used to have developers building against a sampled sub-set of the content URLs to provide fast builds during dev, and then a longer prod build. But there are limits to when that can work
For Netlify, what about search engines indexing old verisions of the site?
A canonical URL in your HTML head can help here. Pointing to your production URL.
Why LAMP instead of XAMP since XAMP has awider scope of OSs?
No reason. I just mentioned LAMP as a common example for comparison that people would relate to.
Off topic, but what was used to put the slide deck together?
That was Keynote. I exported the sldies as PDF for sharing
What's the point of JAMstack if the content of our changes?
JAMstack sites can automaticallt rebuild and redeploy whenever content changes. This even alllows content to be managed in the same versioned was as the code. Or managed in an external resource.
As a simplisitic example, my own blog site automatically regnerates to include my lated tweets whenever I post a tweet on twitter. I wrote a post about it. Automation is your friend!
What's the advantages compared with Docker?
Although docker can help with provisioning your servers and ensuring that they are the same in difference environments, you are still keeping a server alive and running and ready to service each request. With the JAMstack, you need no server at all at request time. So your need to scale and secure the environments go away. Serving static assets directly from a CDN and cliser to where your visitors are rewuesting from, will always be faster and more scalable.
What happens at build time for very big sites? Is every page built again?
As per the answer to question 3, this is a challenge. There are some capabilities in Netlify to cache assets between builds, but that gets tricky when you need to start planning and managing caching strategies and incremental builds. Severla statci site generators are searching for a good way to support incremental builds, but that is a challenging hurdle.[
I've played with ways to make a page available immediately on a URL as soon as it has been created in a decoupled content management system, but before the subsequent build has completed. To do this, I used Netlify's redirect and custom 404 handling to make a 404 for pages attempt to access the content API directly, and if finding a page in the API, rending it client-side with JavaScript. When the pre-generation later completes, requests to the same URL will no longer return a 404 and instead will return the page as usual. It's a fun technique to explore.
What twitter activity are you running that makes Twitter Trigger Hook to re-deploy your site?
I use IFTTT to watch my twitter feed and then fire a webhook that I defined in Netlify to rebuild my site.
There was a lemon first, then apple, now kiwi :) Why?
LOL! Yeah, I was hintin at how sometimes, in complex systems, deployments result in unexpecte consequences. 🍋🍏🥝😆
What ae the common tools to help with deployment of JAMstack sites. Maybe like docker?
Docker won't give you a JAMstack site. Since it will give you a server from which to serve your site. But if you are askling about tools to help with the generation of the assets, and their deployments, then there are several options:
- Netlify (Disclaimer: where I work!): for CI/CD, and hosting on a CDN. this gives you all the things I mentioned and runs your builds in a container thanks to Kubernetes before propoagating your site to the CDN.
- Surge.sh: Command line deployments to a static hosting
- Zeit Now: Command line and CI/CD deployments to a CDN
- Circle CI: For continuous integration and running of your builds. Perhaps then paired with API-based deployemnts to a hosting provide (such as Netllfy provides)
When working with CI/CD, is the easier deployment of JAMstack really a difference to the configured deployment of another stack?
Yes. Although there as some similarities. Having a scripted, automated deployment to ay stack is a nig win. And it's the way I have always wished to deploy things to stacks other than the JAMstack. They help with repeatability, and confidence and many of the things I mentioned. But the difference is that on those tradtionaly stacks, the result of the deoployments may impact manby systems and alter them in ways that is hard to quickly walk back or understand. The JAMstack adds the abulity for the deployments to readily support immutability, and the chance to instantly revert or even have multiple environments (like stage/test/prod) all running at the same time and being identical. (since everything is served directly from the same CDN).
Won't the ammassment of API requests (e.g. on e-commerce sites) be a performance bottleneck?
This would be the same consideration if, rather than hitting an external API, we were servicing those requests internally in our system. In fact the overhead of doing that in pur system might be more complicated to optimise and debug if it were not cleanly abstracted in the way you wpuld with an API. ("Small pieces, loosley joined" and all that).
With a dedicated e-commerce API (or whatever API), the optimisation is far more focuessed and less likey to be complicated by other tasks such as populating the page view as part of the same work.
This model can actually be far more performant.
What about large sites? Won't each build take too long?
Yeah, this can be a challlenge. See questions 3 and 9.