Different clients (or even the same client) have different needs in terms of how certain pages should be served to the user. When working with a client, we ask questions to find out the needs and requirements for certain pages to try to find the best solution. Content on the pages can have serious implications with regards to the best way of serving them to the end user. Is it a page with just some text that rarely requires updating, or does certain content rely on being up-to-date? And would a couple of minutes delay pose a potential problem? Is there only one page of this type, or could there potentially be thousands? With those ideas in mind, let’s explore a couple of examples with a fictional eCommerce website:
These are three entirely different page types with different considerations as to how to handle the content and caching. With the tooling of the Jamstack, we are able to build efficient solutions that best serve the specific use cases of the client.
Building on the flexibility aspect, it’s not a big leap to look at the scalability of a Jamstack site. I mentioned the caching above, and that is some of the “secret sauce” that goes into the Jamstack solutions.
A blog that has a total of ten posts (and is not likely to ever grow much larger) requires a different approach than a blog that has hundreds or thousands of entries and can scale even further. The Jamstack offers us the tools to best meet our clients’ demands, and it allows us to think with the client to see which pages are expected to be highly trafficked and which content is expected to change. One approach we can apply is for the ten newest posts to be pre-built for the users, while the rest gets created when a user visits that specific blog. The page gets built and stored in a CDN. The next user that visits that page then gets that same page from the CDN, resulting in a super snappy process. Why don’t we pre-build all the pages? Well, we could for ten pages, but if the client wants to be able to grow their blog to hundreds of blogs, we may want to take an approach that is future proof. Building everything at build time takes more time per added blog page, and the posts beyond the first ten blogs actually don’t receive enough traffic to warrant that.
Having a futuristic eye on these kinds of considerations, reviewing previous patterns, and communicating with our clients regarding future expectations allows us to pick the best tool for the job.
Every client has different wants, tastes, requirements, and needs. Our team is here to listen, assess, and advise regarding the best way forward. One of the benefits of building Jamstack web pages is the high degree of customizability that they offer. Jamstack sites are highly modular, which allows us to customize nearly every aspect of the site to meet the needs of the business or the user.
The use of APIs and microservices architecture in Jamstack sites allows us to easily integrate with a wide range of third-party services, such as content management systems (CMSs), e-commerce platforms, and payment gateways. In doing so, we can create customized and flexible web pages that can adapt to the (changing) needs of the business or the user. For example, a Jamstack site might use a static site generator like Gatsby/Vercel for the frontend, a headless CMS like Contentful for managing content, a payment gateway like Stripe for processing payments.
Overall, the customizability of Jamstack web pages is one of the key advantages of this architecture, enabling us to create highly customized, flexible, and scalable web applications that meet the unique needs of their business or users.
The key characteristic of a Jamstack site is the separation of the frontend presentation layer from the backend functionality, with APIs acting as the glue between the two. The strict separation of these layers means that Jamstack sites are more secure than traditional web applications. In its purest form, there is no server-side code or database that can be compromised, and no dynamic content that can be injected with malicious code.
Coming back to the initial statement about how using the Jamstack allows us to focus on the most impactful areas of our expertise: it’s worth noting the ecosystem that surrounds some of the Jamstack tooling. As an agency, we have the luxury of being able to follow industry trends and apply that knowledge across multiple clients. Certain new features may be rolled out for a framework (say Gatsby v5 or NextJS13). The best way to fully embrace these new features, and to understand the benefits as well as some of their limitations, is to implement them and use them in production for a while. We often find that a certain project will be served by the benefits of one of these new features, which after successful implementation can then be rolled out to other clients as well. Work can be transferable because of the stack we have chosen, allowing us to roll out these features in a more efficient manner for our clients.
The Jamstack is a joy to work with for our developers as it abstracts away some of the more complex tasks, allowing us to focus on the work that matters the most to the client. The abstraction does not come at a price, as we are still able to customize to our heart’s content with the right third-party integrations. For the client, this means that the work gets delivered quicker, reliably, and with an increased focus on business requirements over technological requirements.
Sign up for our email newsletter. Nothing spammy about it. Just a monthly rundown of what we’re sharing.