How far can you take the JAMstack?

Critics have often made the argument that the JAMstack doesn’t scale well despite its many benefits like improved site performance and better security. This criticism isn’t without reason. In the worst of cases, frontloading your build process can result in lengthy build times. It can also mean compromising on core implementation details by relying on external APIs, not to mention having to trust that an API will be available and consistent in the long run. However valid these criticisms may be, the power of the JAMstack and its ability to scale comes from its flexibility. The JAMstack by design gives developers the option to curate a desired architecture for a site and iteratively work on functionality without holding back deploys to production. This is possible because of the vast and growing API ecosystem. With access to so many external third party services, developers can prototype a site quickly and offload complex tasks to APIs. What’s more, the decoupled, compartmentalized approach of using single purpose services (an auth service that handles authentication, a payments service to handle payments, a CMS to handle content etc) means there is room to switch them out or even build out a custom API down the road.

The examples of companies both small and large who have bet on the JAMstack for scalability and performance is extensive and rapidly growing. If you’re curious to learn just who these companies are, check out my earlier post on Who is using the JAMstack? and dive into videos from JAMstack conf 2019 where companies like Restaurant Brands International, Loblaw and Citrix cover enterprise use cases for the JAMstack.