How we are solving for enterprise sites on the Jamstack
Real architectural assessments
Long build times
Splitting large sites into logical sub-sections
There’s an occasional misconception that since Jamstack sites and applications don't rely on traditional server architectures, they aren't able to handle powerful, and dynamic enterprise experiences. Well, the Jamstack, like any other technology, has evolved a lot since inception and is currently capable of handling large sites and enterprise applications.
In this post, we'll walk through some practical strategies you can employ to leverage the Jamstack offerings for your enterprise projects and applications.
There are lots of assumptions that big companies make about how exotic their requirements are (because it has always been expensive and complex, so we MUST need the most expensive, most specialist tools, right?). Often, companies don’t make real assessments of their requirements because they base them on capabilities they see on a list of features from large enterprise software vendors.
Better education and more intentional assessments of enterprise infrastructural requirements can offer a solution to this. As a community, it falls on us to collectively educate ourselves and others about the perceived complexities of enterprise applications. Making real assessments of enterprise stacks and representing them accordingly as it relates to the Jamstack would ultimately lead to better solutions.
Enterprise sites are sometimes very large, with many thousands of pages. Over time regular addition of content by the teams managing it can also see the site size and its build time swell. Seeing that the Jamstack architecture is based on pre-generating all the site's pages at build time, and hosting it on a CDN, build times can get unfavourably long for very large sites.
The disadvantages of that is:
This is a common challenge when dealing with large sites on the Jamstack. However, a number of techniques have become popular in addressing this challenge, some of which are:
This approach encourages you to break out your large site into smaller, focused micro sites that are independent of each other. Then, tie them back together using Netlify redirects and proxies. A theoretical exmple would be:
www.company.comthat links off to multiple other pages like
docsas standalone micro sites which will be available as independent sites.
(www.company.com), you can use Netlify redirects or proxies to connect the micro sites back to your primary site as:
www.company.com/docs- With proxies or
docs.company.com- With redirects, depending on your preference.
If this theory sounds a bit too vague, please refer to this indepth guide for a better understanding