DEV Community: Divya

Encore; a JAMuary retro

Divya — Sun, 02 Feb 2020 03:17:40 +0000

Every year for the past 5 years, I've started the new year with the fervent goal to write more frequently. As is often the case, enthusiasm is quickly overshadowed by immense self doubt. Despite my best intentions, I'm often left with only a handful of published posts and a smattering of half baked drafts by the end of nearly every one of those years. This year, I decided to give myself a significant head start in my writing goals by writing every day for the entire month of January. To give structure to this content, I themed this project around all things JAMstack and in the spirit of a good pun called it #JAMuary. The goal of this project was to answer questions about the JAMstack, and identify common misunderstandings of a surprisingly elusive term. In the spirit of transparency and openness, I thought I'd share some of my learnings from this project.

TLDR;

Create a content calendar
Research all the things
Plan main ideas of your post the day before
Short posts > Long posts
Change tasks when you hit writer's block
Believe in youself ❇️

Prep

When I embarked on my month long journey, I had prepared a content calendar with specific topics to address every single day. The hope in doing this was to break down a rather gargantuan task into manageable, actionable tasks and to remove the anxiety of ambiguity altogether. With a clear plan, I had no choice but to keep to my schedule of writing every day. To prepare for a month full of content, I trawled the internet for all sorts of JAMstack content from talks to blogposts and stack overflow posts. This research helped me get the pulse of the community and seed questions that I could then tackle in my posts.

The process of organizing a content calendar for the month proved to be an iterative one. Throughout the course of the month, I reviewed this calendar and course corrected to make sure my content was specifically addressing the needs and doubts of the community. This sometimes meant changing the topic of a planned post to respond directly to feedback and questions I received from my posts. Thought it threw a wrench to my otherwise perfect plan, it was a great way to engage with the community.

To maximize my chances of completion, I also restricted the length of posts to 1-2 paragraphs. In my opinion, smaller microposts are much easier to write and from a reader's perspective, easier to skim. Because my posts were posed as answers to a question, the shorter length meant I could get to the point quickly and succinctly. To give more context to the question at hand and allow readers to explore ideas further, I chose to include resources as additional reading. This was also a great way for me to highlight the work of so many wonderful folks in the community.

Writing Process

Contrary to what you may be inclined to believe, I have terrible writing habits. As a perfectionist, I frequently agonize over the starting few sentences of a post and spend far longer than I'd like to admit tweaking words and sentences. This bad habit of mine meant that the process of starting posts was an incredibly excruciating one. Thankfully, writing for 31 days has a striking effect on one's stamina and by week 2 (probably closer to 3), I was able to get a post out much faster (~1-2 hours).

Since posts were typically written on the day they were published, I'd start the day with writing and try to finish them before my mid to late morning meetings. Posts were then reviewed in the sliver of time between meetings and published by early afternoon central time. The relevant tweets were then tweeted.

Productivity Boosts

Writing is a pretty focused task that demands significant concentration to follow a thought through to its logical conclusion. Unfortunately, concentration is a scarce resource these days and a strong willpower is necessary to stay on track. In spite of my enthusiasm, there were days when I simply didn't want to write. One strategy I found that worked for me was to get a workout in right when inspiration and motivation hit a low. I'm a pretty active person and exercise helps me sleep better, and cope with stress and anxiety. Even 5 minutes of a HIIT workout is enough to pick my mood up and set me up for a productive day.

In conclusion

A caveat worth noting is that writing marathons are incredibly unsustainable in the long run. When done in short spurts however, i.e. 24 days or 31 days, they are great to establish good writing habits and identify your own writing style and quirks—turns out, I say however a lot. Organizing a theme around the marathon also helps with giving structure to writing and inspiration on what to write and how. They're particularly excellent to deepen knowledge and contend with your own biases with regards to a specific topic.

As crazy as these marathons may seem, I do hope that you'll give it a try. I think you'd be surprised by how much and how well you'll write as a result of it.

What's the future of the JAMstack?

Divya — Fri, 31 Jan 2020 21:48:44 +0000

In the last 5 years since its inception, the JAMstack has grown from relative obscurity to a vibrant community of headless CMSes, pluggable APIs and SSGs. With such meteoric growth, also came the broadening of the JAMstack category. Today, the JAMstack is more than just some JavaScript, APIs and Markup served statically from a CDN. Single Page Applications (SPAs), serverless functions and even edge workers (arguably) are categorized (or at least self categorize) as “JAMstack” and have all furthered the confusion around an already elusive term. Though the growth of the JAMstack category has been fairly organic, it's success is due in no small part to significant advancements of the web as a platform. Modern CDNs for one are incredibly capable of handling complex business logic and operations (like redirects) that were once reserved to the origin server. The emergence of technologies such as edge workers, and functions at the edge have also made it easier to architect complex application and pushes the boundary of what's possible on the browser. With the JAMstack approaching maturity, these developments are only expected to continue and a JAMstack site today may very well not look anything like a JAMstack site of the future. Nevertheless, exciting times lie ahead for the JAMstack and we hope you'll join us on this journey to building scalably, securely and fast.

This post marks the end of #JAMuary. Thank you to all readers and followers, until next year, spread the JAM.

Do I have to rebuild my entire JAMstack site for every new change?

Divya — Thu, 30 Jan 2020 21:03:13 +0000

A recommended best practice on the JAMstack is to trigger a new site build and deploy for every new change that comes through. This ensures that sites are kept consistent across a globally distributed set of CDN servers. As you can imagine with this setup, build times increase as sites scale. In the case of data-driven industries like e-commerce where content (that significantly drives revenue) is ever changing, time is of the essence. In order to stay competitive and relevant, updates need to be instantaneous. The JAMstack approach of atomic deploys poses a challenge to larger sites like these with over thousands of pages since builds tend to be lengthy.

A key strategy to speeding up large site builds is by building incrementally. Incremental builds is the concept of re-building only the parts of a site that changed. To accomplish this, older content that doesn't change remains cached, while modified content is regenerated and updated to the cache. This way, deployments are perceived as instant. In spite of how ostensibly simple incremental builds may seem, they are in fact a tricky business. Most notably, incremental builds require pinpointing exact changes and updating the build appropriately. Because of the complexity of incremental builds, many SSGs have yet to implement them (without charging for them) and this technique remains fairly inaccessible for now.

A more accessible way to achieving faster builds is to decouple dynamic content like price from the prebuilt markup itself. APIs like Commerce Layer allow you to inject content at request time while serverless functions enables you to leverage dynamic server side functionality at the edge as needed. The combination of static with dynamic means that you can stay confident that time sensitive content is always up to date.

For more on incremental builds with regards to SSGs, check out React Static, an SSG built for React and the only SSG that currently supports incremental builds (for free)

Is it possible to do realtime messaging on the JAMstack?

Divya — Wed, 29 Jan 2020 21:01:03 +0000

Real-time feedback can positively influence the overall user experience of a website. When a user requests help or time sensitive information (like realtime bus schedules or stock market prices), providing a timely response keeps them engaged and up to date with critical information. To achieve this experience with as little latency as possible, websites employ a system where data is streamed or pushed to users via delivery mechanisms such as Publish/Subscribe. The general concept here is real-time messaging where data is pushed as fast as possible to facilitate the distribution and delivery of messages. By design, real-time messaging is built to be consumed or used literally in real-time or as events occur. In the context of static sites on the JAMstack, achieving real time messaging via a Pub/Sub pattern can be a challenge. To receive a message, the receiving application needs to be proactive and attentive to events as they happen. For this to work, a long lived connection needs to be established so that the publisher can properly notify subscribers of incoming changes. In a JAMstack setup where content is pre-rendered, updating data means having to rebuild the site and invalidate the CDN cache. Rebuilding a site takes time, and there’s often a chance that data is stale by the time a site build is complete.

Though the JAMstack doesn’t lend itself well to patterns like Pub/Sub, accomplishing real-time messaging is possible within a JAMstack model. Web hooks are one way that this can be done. With webhooks, a web service can provide other services with real time information without the need for a constant connection. Compared to the observer model, webhooks are a simple way to accomplish event driven workflows like “If this then that” and applications can easily communicate when something new happens. Though publishing updates to a site still requires an entire rebuild, end users can be notified of changes through other means like Slack notifications, text messages. To be notified of new form submissions for instance, webhooks can be used to trigger notifications through the delivery mechanism of your choosing. In the event that a webhook is unavailable, Zapier offers a slew of service integrations so you can easily glue services together at the click of a button.

Compared to traditional approaches to realtime messaging where information is “pulled" or “polled”, realtime messaging on the JAMstack has to be event driven to work. It requires a service to explicitly notify a site of incoming changes. For more on accomplishing event driven workflows on the JAMstack, check out the Netlify documentation on outgoing webhooks

Can I create a rich content experience on the JAMstack?

Divya — Tue, 28 Jan 2020 21:16:14 +0000

Authorability is a key contributor to the success of the JAMstack. Despite the JAMstack's superior performance in speed and relative cost over other methodologies, the mass adoption of the JAMstack hinges on its ability to operate in a cross functional team where not everyone is technical.

Content today is incredibly advanced. Thanks to the growing popularity of visual storytelling where text is combined with interactive visuals and compelling graphics, content authors must deliver stunning content experiences to keep users engaged. This entails authoring content that seamlessly blends text with different forms of media like charts and images. In the realm of the JAMstack where raw content is generally represented as markdown, authoring such "rich experiences" is a challenge. This is largely because content is decoupled from code in a typical JAMstack setup and there is huge disparity between how content is created and how content is displayed.

A rich authoring experience demands collaboration between code and content. This way, content creators can craft content that supports the work of developers and vice versa. MDX is one way in which this becomes possible. MDX is a file format, parser and loader that extracts and renders JSX components inside markdown files at build time. Compared to conventional setups where markdown is not configurable beyond injecting HTML directly into files, MDX gives content authors and authoring tools direct access to exposed JavaScript components. When used alongside a design system, developers and content authors can collaborate while still maintaining their relative independence.

The tablestakes for a rich content experience on the JAMstack is high.
Only with developments in authoring can the JAMstack become the defactor standard for modern web development. For more on MDX as a rich content experience, check out this fantastic talk by Josh Dzielak at JAMstack conf London

Does the JAMstack still use servers?

Divya — Mon, 27 Jan 2020 20:38:47 +0000

A common contention around the JAMstack paradigm is that the lack of servers is a misnomer. Though the JAMstack ethos claims to serve content without web servers, servers still play a crucial role in the JAMstack when it comes to executing and serving content statically. Taken at face value, the assertion to move away from servers is a touch misleading. However, the main premise of the JAMstack is a departure from traditional approaches to web development where content is rendered dynamically on a server. On the JAMstack, content is instead pre-rendered and hosted statically from a CDN. The server (in the traditional sense) only ever runs at build time and sends static assets to the CDN which caches them for delivery upon request.

It’s worth noting that there is a distinction between a CDN and a traditional web server. A CDN or content delivery network, helps speed up the access and delivery of website assets via a distributed network of edge servers. Compared to a web server, an edge server is an entry point into a network and serves as a connection between disparate networks. As a result of its existence at the “logical extreme” of a network, (static) content lives as close as possible to a user and can be served up with minimal latency and/or page load time. This is in contrast to origin servers where 100% of content is rendered on the fly for every single request. When relying on an origin server for content, latency becomes an issue since every request must be routed through to the physical location of the origin server regardless of where that request comes from. Because internet traffic is limited to the speed of light, the further a user is from an origin server, the longer the request time. By serving content statically from a CDN, the JAMstack therefore speeds up request times drastically, thereby giving users a lightning fast experience.

Can I run a server with the JAMstack model?

Divya — Sun, 26 Jan 2020 22:07:22 +0000

A core principle of the JAMstack is that sites are not dependent on servers (i.e. origin servers in the traditional sense). Unlike conventional server side rendered sites, sites built on the JAMstack are rendered in advance (pre-request) and served to users directly from a CDN or edge server. Advancements in CDN technology has made it possible for JAMstack sites to run traditionally server side logic like authentication and role based redirects at the edge. In spite of these advancements, modern CDNs are not on par with full fledged origin servers. A notable difference between the two is in their level of configurability.

As opposed to servers that are configurable by the developer to the most minute detail, CDNs are preconfigured by the service provider like Fastly, Netlify and Akamai. Because custom logic available on the CDN is a low level implementation unique to the CDN, developers cannot add further functionality to the CDN. Without an application server or a language runtime, it is simply not possible to run a custom NodeJS, or Python backend on a CDN.

Running a server however doesn't preclude a site from being JAMstack. Sure, you can't run a server directly on the CDN, and rendering a site entirely server side isn't exactly JAMstack-like. But running a server that provides a service via an API perfectly falls within the realm of possibilities on the JAMstack. Often, within the JAMstack model, functionality is outsourced to external services in order to avoid the burden of having to build custom functionality. However, building custom logic for your application and running a separate server for it counts as JAMstack so long as the backend is decoupled from the frontend.

What more can a CDN do on the JAMstack?

Divya — Sat, 25 Jan 2020 18:29:34 +0000

Compared to their predecessors, modern CDNs are not limited in their capacity and can do a lot more than serve static assets. The emergence of edge computing bolstered modern CDNs with the capability to handle crucial business logic like redirects and authentication at the edge. By forgoing the extra trip to the origin server, edge logic at the CDN layer brings the server ever closer to the user. With the increasingly blurred distinction between what an edge server can do and what an origin server can do, CDNs are increasingly being referred to as Application Delivery Networks (ADNs). With an ADN, logic once reserved for origin servers an now be implemented at the edge. Cache invalidation is one such example of this. In the context of an ADN, a new site build invalidates the old cache and replaces it with the updated content. Given the difficulty of managing the cache of a globally distributed network of edge servers, a CDN/ADN that updates its own cache quickly and reliably with every site build is incredibly convenient. This is doubly the case since CDNs of the past used to rate limit the cache purge and provided little control over how the cache was managed.

The ability to run functions at the edge is yet another powerful feature of the CDN. Previously, functionality like A/B testing, authentication and form validation could only be handled at the server level. The introduction of Cloudflare workers and Amazon Lambda@Edge has made it possible to execute functions from the edge layer and provide dynamic functionality to a JAMstack site without the added cost of a server. Running functions at the edge layer means that content can now be delivered with close to zero origin infrastructure. On the fly functionality like image optimizations, and access control can also be achieved with this model. The advancements in CDN technology has been a key catalyst for the rise of the JAMstack. If you're keen on learning more about the advances of the CDN, check out Netlify Edge, the ADN built by Netlify to deliver blazing fast sites and modern workflows.

Why is a JAMstack site fast?

Divya — Fri, 24 Jan 2020 19:26:26 +0000

Speed is a notable characteristic of a JAMstack site. With a JAMstack setup, sites are served as static assets, and avoid the extra round trip to the origin server for content. Pre-rendering sites ahead of time means that the time it usually takes to build a site is significantly reduced, and content can be served immediately upon request. The cache plays a crucial role in making this possible. Caching greatly improves site load times by enabling access to resources that have either been fetched from a previous site visit or retrieved in advance.

It’s worth mentioning that the technique of leaning on the cache to speed up load times is not unique to the JAMstack. Monolithic, server side sites similarly depend on the cache to optimize server response time. Though the first request incurs a lengthy Time To First Byte (TTFB) (because of the need to travel to the origin server), subsequent requests can be served from the cache for quick and fairly consistent content delivery. Despite this, static sites still come up tops in terms of speed as opposed to monolithic sites. This is largely a result of how the cache is managed in either setup. As the popular adage goes, cache invalidation is one of the hardest problems in computer science. In a monolithic setup, the cache needs to be invalidated appropriately so content served to users is the most up to date. While there are solutions to handling this like Fastly’s Surrogate Key HTTP headers to categorize and tag cached assets, and the stale-while-revalidate header to keep stale content around while waiting for revalidation, crafting caching strategies takes a lot of time and effort. Not to mention, a poorly executed caching strategy can cause unexpected errors and redundant trips to the server that add time to page load. In the context of the JAMstack, the cache is automatically populated and persisted with every new site build. This means that developers can simply rely on the build process to handle cache invalidation and remain confident that their content is fast and never stale. The sole reliance on edge nodes for content delivery also means that sites are fast from being served as close to the user as possible.

If you’re keen on digging into numbers around how fast JAMstack sites really are and how the cache can be optimized for speedier, more reliable sites, check out these fantastic resources:

Are your keys secure on the JAMstack?

Divya — Thu, 23 Jan 2020 18:49:47 +0000

If you use an API in your JAMstack site, chances are you’ll need an API key to access that service. When invoked at build time, API requests can be kept secure since keys are stored server side. For more dynamic functionality like comments however, API requests need to be made in the browser. This poses the risk of exposed API tokens since traffic can be easily analyzed and requests can be traced back to the initial requester. In some unique cases (e.g. Firebase and Mapbox), keys simply identify your project and keeping them public is par for the course. In most, API keys must be kept private. A simple way to keep keys secure when making requests client side is to proxy your request or use an API gateway to sign requests so it passes through an authentication process before returning successfully.

Many CDN providers like Netlify provide proxying services so requests to an API can properly be verified. In Netlify, an API request can be proxied by adding an {X-From = "Netlify"} header attribute in your redirects configuration. Requests can also be signed with a JSON Web Signature (JWS) so that a remote service can properly verify the origin of the requester. In either of these instances, access to an end server is verified at the edge nodes and doesn’t require a full round trip to authentication servers. This means that requests can be made secure without the burden of extra load time. While this is an incredibly easy and efficient way to secure a service from malicious users, it does require having control over that endpoint. An alternative to proxying and signing requests, is to pass an request through a serverless function. Under the hood, serverless functions proxy requests on your behalf and save you the extra configuration time needed to set up proxying. The downside to this is of course that serverless functions often come with hard limitations on response times so ensuring that the API adheres to that is key.

Contrary to popular opinion, securing API keys and requests on the JAMstack is not impossible. For more tips and tricks on securing your API keys on the JAMstack (using Netlify), check out these resources:

• Netlify Docs on proxying requests
• Stack Overflow post on securing API keys on JAMstack
• Keeping API keys safe with serverless functions

What makes the JAMstack secure?

Divya — Wed, 22 Jan 2020 21:00:44 +0000

Security is a huge concern when building for the web. Even with countermeasures in place, keeping websites safe from attack can seem like an endless endeavor. This is especially the case in monolithic server side setups where countless third party plugins are exposed to enable administrators easy access to content and configurations. However convenient they may be, they create a massive surface area for malware penetration. Because they require frequent (and often buggy) updates, plugins are notoriously insecure. Sites that heavily rely on plugins and the frequent update cycles they demand, therefore often run the risk of either breaking or being pwned altogether. The need for such setups to be constantly running and available further increases the surface area for attack. Every site visit demands a trip to the server and a re-execution of the build. This results in critical endpoints being exposed and increases the overall risk for attack.

As trivial as this may seem, reducing a website’s vulnerability to attack can be achieved by simply going static. In a static setup, files are read only and there is no real code or build process to be run. Though servers are still involved in a JAMstack setup—mainly to run the build process—they remain in relative obscurity since only built static files are exposed to the public via a CDN. Moreover, the distributed nature of the JAMstack API ecosystem mean that services are incredibly decoupled from one another. In the event that the CDN or an external facing API were to be compromised, you can still remain confident that the underlying infrastructure is safe and the safety of your site is not in jeopardy. With no databases, plugins, or dynamically running builds, the risk of code injection on a JAMstack style site is dramatically reduced.

JAMstack or not, security on a site is never 100% guaranteed and a robust security strategy requires some effort. HTTPS is one obvious and simple way to get started with making your JAMstack sites secure. For more convincing on why you’d want HTTPS on your static JAMstack setup, check out this timelessly relevant post over on the Netlify blog.

What does the M in JAMstack actually mean?

Divya — Tue, 21 Jan 2020 19:17:08 +0000

The M in JAMstack is the root of much confusion. Though it officially stands for Markup i.e. HTML, many assume the M to mean Markdown. Given that it is common practice to use a Static Site Generator(SSG) with the JAMstack, and that SSGs render HTML from Markdown, it’s unsurprising that the acronym is thus misconstrued. Compared to Markdown, Markup is far more expansive and encompasses templating languages (e.g. Markdown) and data serialization languages (e.g. YML and JSON) alike. Specifically, markup in the JAMstack terminology refers to “pre-rendered” markup or content served in its final form, HTML. The distinction here is the delivery mechanism of content. Within the JAMstack model, content is not delivered dynamically via a web server tasked with building pages at runtime. Rather, markup is prebuilt upfront and served to the browser via a CDN. The power of serving content this way rests in build tools and processes like Gulp, Grunt and now Webpack and Babel. These tools not only combine content with templates, they enable sites to take advantage of modern advances in JavaScript and CSS way before browsers even ship them. The strength of compiling at build time also means that calls to external APIs and services can be made ahead of time. Oftentimes, APIs add bloat to a site especially when executed at runtime. Running APIs at the build stage means teasing apart the underlying infrastructure from the live site so neither site performance nor uptime suffers when an external API b0rks unexpectedly. This also means that individual APIs can be considered in isolation and further highlights the decoupled architecture that the JAMstack pushes for.

The ambiguity of the acronym aside, the M in JAMstack emphasizes how content is delivered, instead of what format that content was in prior to pre-rendering. Content on the JAMstack can effectively come from anywhere, but as long as it’s pre-rendered it counts as “M”.

If you’d like to dig into the M in JAMstack, there’s a fantastically written post by Brian Rinaldi that might be of interest. Check it out over on his blog: https://remotesynthesis.com/blog/m-is-for-markup

And to start digging into building the Js, As and Ms in JAMstack, https://templates.netlify.com/ is a great starting point.