Towards the end of last year, I had the opportunity to chat with Bryan Robinson about the Jamstack. Since he also runs the that’s my Jamstack podcast, you can listen to our conversation.

During that informal chat, I talked about the importance of APIs in the Jamstack. The “there’s an API for that” analogy came from 2009 when Apple trademarked the “there’s an app for that” slogan, signalling that iPhone users could do virtually anything because of the vast number of apps in their app store.

This also produced one of my favourite memes from back in the day:

Jamstack and APIs

For those who aren’t familiar with the Jamstack: it’s short for JavaScript, APIs and Markup. I like Phil Hawksworth’s definition: “A modern architecture: Create fast, secure sites and dynamic apps with JavaScript, APIs and pre-rendered Markup, served without web servers.”

The key bit: a Jamstack site doesn’t require a web server. No origin server. That means we can’t have server-side code execution because there’s no server capable of doing it. Normally, this would limit our website to HTML, CSS and client-side JavaScript. Something that could almost be considered static. But static is the new dynamic. The JavaScript language has seen enormous development, and modern web browsers can tap into all the new capabilities (like fetch to consume any REST endpoint).

It wasn’t only the language that progressed. A multitude of service providers appeared at the same time, offering various services for web developers. These are SaaS (Software as a Service) or “API as a Service” companies. They offer an SDK or an API that can be easily integrated into any web application. And this brings multiple benefits. Let’s walk through them.

If you’d like to learn more about the Jamstack, visit Jamstack.training, a training portal bringing you free video courses.

Benefits

The most crucial benefit, to me: there’s no need to manage infrastructure. (This also lets us avoid having an origin server.) Think about what it means to have something as simple as a contact form. You’d need a form that sends data via (ideally) an HTTP POST request to a server, where some server-side code gets executed (probably PHP). Then you’ve got multiple options: save that data in a database (which could live on another server), or send a notification (or two): one for the person sending the message, and another for yourself so you actually receive it. That means you need a mail client set up and configured on your server.

Setting all of that up has its own pitfalls. But think about what happens when the site becomes popular, and instead of receiving 10 messages per week, you’re getting 1,000 per day. Can the infrastructure and code handle that increased load? Do you need to go back to the drawing board and rethink the architecture? Do occasional peaks slow down other parts of the website? Lots of questions to answer.

Now, what if you used a service that manages contact forms, including the processing of data? All of the worries mentioned earlier fall to the service provider. All you need to do is call the appropriate API, and they do the work for you. The process is entirely transparent. If there’s growing demand, their infrastructure handles it, and most such providers automatically scale up or down based on demand.

Another benefit worth mentioning: companies providing these services are experts in their domain. They do one thing, and they do it well. A company specialising in image and media delivery will focus on that, and you can trust that their services reflect their knowledge. This holds true for nearly every service provider out there.

And the good news in today’s ecosystem: there’s an API for everything. Some services let you send emails, do authentication, manage images and videos (including transformation and optimisation), store data, manage payments, create a custom search engine and even build complete e-commerce solutions. Remember, all these companies focus solely on their product, and they’re experts.

Providers often offer a free tier. Some more generous than others, but for basic projects, the free tiers usually cover what you need. Paid tiers sometimes come with extra features, and often the costs are still bearable. These companies typically benefit from large enterprises using them as well, charging a higher (usually customised and negotiable) fee.

API to API communication

A question I get asked often: how would API-to-API communication work, for cases when one API needs to talk to another? Especially if these are two APIs from two different service providers. The answer? Serverless functions. In a nutshell, serverless (lambda) functions (or FaaS, Functions as a Service) are functions executed on the server side (again, managed by a provider), and after execution, the container hosting the function is stopped. This has multiple benefits (and drawbacks). Since we’re talking about doing something “server-side”, we can safely execute server-side code, call various APIs, merge data from them, or do something else entirely. (This also has the added benefit of being able to store sensitive API keys as environment variables.)

Drawbacks?

What we’ve discussed so far sounds great, but I’ve also been thinking about a side effect of this approach. You could argue about what happens if the service provider experiences an outage. You’d hope they have sufficient backup systems, but working in tech means bugs happen and there’s no real discussion to have there. Likewise, if something goes wrong with your own infrastructure or deploy flow, you need to fix it. End of.

But there’s one more thing. I’m no lawyer, and I know very little about privacy policies and other legal matters, but I think it’s a topic worth visiting: what happens to the data that goes through or gets stored by these third-party services? What happens if such a service (or the company providing it) shuts down completely? Alternative solutions exist for everything, but what happens to your data? Is it deleted? Is it packaged up and sent to you? Companies disappearing without warning these days is rare. Still, I’ve had interesting discussions with a few people in the industry who were reluctant to use many services for this exact reason.

Conclusion

Before you start implementing something complex, take a look at available service providers. Compare their offerings and see which one fits your use case best. If you’ve decided to work with the Jamstack, working with service providers will become increasingly important.