The A in JAMstack is a powerful feature to building modern websites. They give developers the autonomy to abstract otherwise complex functionality and maintain the dynamism of websites despite a static architecture. Still, relying on third parties to provide critical functionality like authentication and payments is a daunting endeavor. For one, third parties add weight to your site. Whether executed at build time or run time, APIs take time to process and can result in either slower build times or page load times. The added risk to relying heavily on external APIs is the complexity they bring to the build process. Sure, APIs abstract complicated functionality but they also create an added “cognitive overhead” for developers—that is to say the number of logical connections and jumps your brain needs to make to contextualize a particular API is high. Because APIs in the JAMstack are often outsourced, no two APIs operate similarly. As a result, integrating or configuring an API in an existing setup requires substantial code switching and carries the risk of overcomplicating an otherwise lean, straightforward stack.

In spite of the potential risks that APIs bring, the decoupled approach of the JAMstack still reduces the overall burden of maintenance. The move towards an API driven architecture offers flexibility and promises an improved developer experience, but doesn’t make the claim to prevent over-engineering. Instead, the JAMstack approach pushes developers to think critically about their sites, and make conscious decisions on what and how to consume and build. Compared to monolithic setups where developers are stuck with choices that frameworks choose for them, the JAMstack provides developers with a stack that they can choose for themselves from back to front. The JAMstack in all its glory encourages building complexity consciously.

To explore all the services you can use with the JAMstack, check out these resources:

https://serverless.css-tricks.com/services/major
https://www.thenewdynamic.org/