There's an API for that

Towards the end of last year, I had the opportunity to have a discussion with Bryan Robinson about the Jamstack, and 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, a topic that I will further delve into today. The "there's an API for that" analogy came from 2009 when Apple trademarked the "there's an app for that" slogan - indicating that users of their iPhone could do virtually anything because of the vast number of apps found in their app store.

Incidentally, this has also produced one of my favourite memes from back in the day:

Jamstack and APIs

Right, let's get back to our statement at hand. For those who are not familiar with the Jamstack: it's short for JavaScript, APIs and Markup. I like the definition by Phil Hawksworth: "A modern architecture: Create fast, secure sites and dynamic apps with JavaScript, APIs and pre-rendered Markup, served without web servers."

The key lies within the fact that a Jamstack site does not require a web server - or in other words, Jamstack sides do not need an origin server, which means that we can't have server-side code execution simply because we don't have a server at all capable of doing it. Usually, this would mean that our website can only consist of HTML, CSS and client-side JavaScript. Something that could almost be considered to be static. But, static is the new dynamic! The JavaScript language has seen an incredible amount of development, and today modern web browsers can leverage all the new capabilities of the language - such as fetch to consume any REST endpoint.

It wasn't only the language that developed, but at the same time, a multitude of service providers has appeared, offering various services for web developers. These are SaaS (Software as a Service) or "API as a Service" companies, meaning that they offer an SDK or an API which can be easily integrated into any web application. And there are multiple benefits to this. Let's discuss these.

If you'd like to learn more about the Jamstack, please visit Jamstack.training - a training portal brining you free video courses.

Benefits

To me, the most crucial benefit is that there's no need to manage infrastructure. (This also enables us to avoid having an origin server). Think about what it means to have something as simple as a contact form. We'd need to have a form, which sends data via (ideally) an HTTP POST request to a server, where some server-side code gets executed (probably PHP). And we now have multiple options: we can save that data in a database - which could live on another server. Or we need to send a notification - or two - one for the person sending the message, and the other one to ourselves so that we can receive the message at the first place. This, in turn, means that we need to have a mail client setup and configured on our server.

Setting everything up has it's own pitfalls, but think about what happens when the site becomes popular, and now, instead of receiving 10 messages per week, we receive 1,000 per day. Are the infrastructure and code in place capable of handling this increased load? Do we need to go back to the drawing table and rethink our architecture? Do occasional peaks slow down other parts of our website? There are a lot of questions that we need to answer and ponder about.

Now, what if, we would use a service that allows us to manage contact forms - including the processing of data? This way, all of the worries, as mentioned earlier, fall to the service provider. All we need to do is to call the appropriate API, and they do all the work for us. The process is entirely transparent for us. If there's a growing demand, their infrastructure will handle that most such services providers will automatically scale up or down based on the demand.

Another important benefit to mention is that companies providing such services are experts in their domain. Companies do one thing, and they do it best. A company specialising in image and media delivery will only do that, and therefore we can have confidence that their services will reflect their knowledge. This is true for nearly every service provider out there today.

And the other good news in today's ecosystem is that there's an API for everything. Some services allow us to send emails, do authentication, manage images and videos, including transformation and optimisation, store data, manage payments, create a custom search engine and even complete e-commerce solutions. Remember, all these companies only work on their solution/product, and they are experts.

Providers often also offer a free tier - some more generous than the other, but I found that for basic projects, the free tiers usually are more than enough. The paid tiers sometimes come with extra features, and often, the costs are still bearable. Typically, these companies leverage the fact that large enterprises use them as well, and in that case, they charge a higher fee (which is usually customised and negotiable).

API to API communication

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

Drawbacks?

What we have discussed so far sounds jolly good, but I was also thinking about a side-effect to this approach. Now, we could get into an argument about what happens if the service provider is experiencing an outage. One can hope that they have sufficient backup systems of course, but working in tech means that bugs happen and there's no real discussion to have here. Likewise, if something goes pear-shaped with your infrastructure or deploy flow, you need to fix it. End of.

But there's one more thing. I am no lawyer, and I know very little about privacy policies and other legal stuff, but I think it's an exciting topic to visit: what happens to the data that goes through/stored by these third party services? Furthermore, what happens if such a service (or the company providing it) shuts down completely. Of course, there are alternative solutions to everything, but what happens with your data - is it deleted? Is it packaged up and sent to you? Companies disappearing without a warning sign these days is rare. Still, I have had interesting discussions with a few people in the industry who were reluctant to use a lot of services for this exact reason.

Conclusion

To sum things up, I'd recommend that before you start implementing a complex solution, you take a look at available service providers and compare their offerings and see which one would be most suited for your use-case. If you decided to work with the Jamstack, utilising service providers will become increasingly important.