The Back End of the Front End – APIs (Part 2)
Written by Cecelia Martinez
This is the second in a three-part series about front-end development (Part 1 is available here). It will focus on JavaScript, but many of the concepts here translate to other languages.
What is an API?
Technically, an API is any application programming interface. Many people describe an API like a counter at a deli — you use the API to make requests and receive responses (hopefully containing what you ordered!).
This process could be in the form of functions in a library that you use to interact with underlying functionality. For example, you’ve likely already used Browser APIs like Fetch or the famous Document Object Model (DOM). Every time you use the fetch() function, you are accessing the Fetch functionality via its API.
This reason is why libraries and frameworks like Vue refer to their library of functions as an API. It’s the programming interface used to interact with the application.
There are also third-party Web APIs, such as the Twitter API or this amazing API that generates dog pictures. We do not manage these APIs or necessarily see how they function, we simply rely on the API to function properly so we can use it how we need to.
In addition, an API allows your application’s user interface to interact with its back end to retrieve and update data and perform business logic functions. These are the types of APIs we’ll focus on in this article.
Rest APIs
REST APIs are a common standard for modern APIs. The deli counter is always open and ready for orders with this type of API. We’ll cover some basics here, but I recommend reading this guide on REST APIs from Smashing Magazine, as well as the HTTP Zine by Julia Evans.
A REST API consists of various endpoints that you access based on the type of information. In our analogy, these would be like a restaurant with different counters for the deli, the bakery, and for hot food. Each of these counters is like an endpoint, with a cashier ready and waiting for your request.
You make requests to these endpoints using Methods. The most common methods are GET, POST, PUT, DELETE.
For example, you might make a GET request to the /api/bakery endpoint to see what’s on the menu. Or, you could make a DELETE request to /api/hotfood if you change your mind and want to cancel your order.
You can customize your requests by using paths on the endpoint, query parameters, or by passing headers and/or a body with your request.
Back-end engineers typically develop APIs, but front-end engineers must understand an API in order to properly interact with it and handle responses. Applications with REST APIs tend to be more tightly coupled between the front and back ends.
GraphQL
A newer type of API is a GraphQL API. We can continue our restaurant counter analogy, but in this case, there’s a single counter and you can make any combination of requests at a single endpoint.
Let’s say you want to look at the bakery menu and check the price on a spiral ham and a hot sandwich. You would have to make three requests with a REST API:
With a GraphQL API, you can request all the data you need at one time. For instance, a request would look more like this:
GraphQL APIs use “types” and “fields” as the syntax for requests. These are, essentially, objects and properties. You can also leverage arguments (like passing the “item” to our query above), aliases, fragments (reusable components of a query), and variables.
In addition to queries, you can also update data on your server using mutations. These are similar to POST, PUT, and DELETE requests in a REST API.
Serverless APIs
Most applications — regardless of whether they use REST or GraphQL — deploy the API on a server that is available at all times to receive requests. Again, think of the 24-hour restaurant counter.
Another option that is increasingly popular is a serverless architecture for an application API. Let’s define a few terms that are often grouped together:
Serverless
A function, API, or architecture that does not use a live running server. This refers to leveraging external APIs and/or vendors that offer on-demand servers to handle requests only when they occur.
Microservices
An API architecture that, instead of having a single layer that handles an application’s data and business logic, uses multiple packages or functions that are narrow in scope.
Jamstack
Jamstack is an approach to web development that uses JavaScript, APIs, and Markdown to pre-build and serve static sites via CDN while leveraging serverless APIs instead of a traditional back end.
If you’re interested in learning more about Jamstack, I recommend the free eBook, “Modern Web Development on the Jamstack” by Mathias Biilmann and Phil Hawksworth of Netlify.
Again, serverless refers to the API’s architecture, not the syntax. It means that your application is not dependent on a dedicated API server. It is often used alongside microservices and/or Jamstack architecture, but it’s not a requirement that they be used together.
API Considerations
While back-end engineers typically handle API development, the increasing popularity of client-side APIs has required front-end developers to better understand this area of the application. The following are some considerations when deciding which API approaches to use in your application.
Modularity
Modularity is a consideration when you’re deciding whether to apply a microservices API architecture.
A monolithic application with a tightly-coupled UI and API can provide predictability and consistency to a codebase, but any changes will be more complex than with a serverless architecture.
Because the APIs in a serverless architecture typically only handle a single task, updating a function or swapping it out entirely doesn’t require an overhaul of the entire application to prevent regressions.
Maintenance
Maintenance is a consideration for all API-related decisions. If you are using microservices, how do you plan to organize and update the packages? How comfortable are you maintaining external services?
A GraphQL API may be more maintainable for one organization, while another prefers a REST API because it’s more consistent with their data model. Always consider the maintainability of your chosen API architecture and syntax.
Reliability
Reliability depends on your site’s expected traffic, your front end’s delivery method (server-rendered or pre-rendered and delivered via CDN), and any third-party services’ or vendors’ reliability.
Sudden spikes in traffic can be harder to manage with a traditional server API, particularly if a server also handles the front-end content’s delivery.
Developer Experience
Certain approaches may be more appealing than others depending on your interest, skill level, and available tooling. It will also depend on the constraints of your application and organization.
Hopefully, you now have a better understanding of the types of APIs you may encounter as a front-end developer. Keep an eye out for this series’s next installment, focused on databases, coming up in November.
__________________________________________________________________________
Cecelia Martinez is a Women Who Code Track Ambassador and a Success Engineer at Cypress.io.