You are starting to design the architecture of a new application, or a mobile app, a website, a game, something that interacts with an end-user. Likely, you need to make a connection (server-side or client-side) to a service to request information from a database, a third-party end-point.
At this point, you are going to need to decide how you are going to make this connection. Nowadays, you’ll have three major alternatives to choose from SOAP, RESTful, or GraphQL. This is an important decision, unfortunately, not everyone understands the differences between them. And they are quite different.
Simple Object Access Protocol (SOAP)
SOAP is the oldest of the three. Created in 1998 by employees at Microsoft at the time, it’s actually a protocol, which means that it’s just a set of rules for exchanging information between computers. It uses XML as the standard format to communicate.
Essentially, it defines a convention so that the messages exchanged can be understood, as such, it follows strict standards. Think of a language, like English, Japanese, German, any language needs to follow a set of established rules in order for people to be able to speak phrases and sentences and be understood.
At the same time, it’s usually considered quite secure and is still in use by large corporations that require high standards in security, like finance, government offices, medical networks.
- Security; strict rules for exchanging messages.
- Ubiquitous (universal) as it can operate on top of several networking protocols such as HTTP, HTTPS, SMTP, and others.
- Robustness of XML language; attaching metadata for the content being sent it’s quite straightforward. Also, due to its similarity with HTML, the ramp-up to get web developers to understand XML is not extensive by just adhering to a few concepts such as namespaces, envelopes, and body, etc.
- Adding up to the previous metadata item, you can have strongly typed data, which allows you to have an extra layer of certainty on the information gathered.
- Complexity, the setup to get it started can be burdensome.
- XML overhead: the verbosity of XML documents may be a disadvantage. Incidentally, parsing large XML files can result in system slowness plus, the proper communication of the systems demand a well-formed XML document, with most XML parsers having a low tolerance for malformed messages.
- Responses can’t be cached.
Representational State Transfer (RESTful)
Rest is currently, by large, the dominating solution to communicate between end-points, until now that is. It was created in the year 2000. Interestingly, its architecture was introduced as a doctoral dissertation by Roy Fielding, a cofounder of Apache HTTP Server.
The actions that can be taken on the server leverage the standard HTTP Methods: POST, GET, PUT, and DELETE. These methods can be mapped to the known CRUD actions: Create (POST), Read (GET), Update (PUT), Delete (DELETE), which goes to show how well thought REST was designed.
Likewise, REST leans on the established HTTP response codes for communicating the result of an action: 404 for a resource not found, 200 for successful, and so on.
REST pros: the list of advantages of this architecture is long, however, we can mention some key elements, such as:
- Being stateless, it’s very fast and reliable.
- As presented in the doctoral dissertation by Dr. Fielding, its definition is very strong.
- The response payload can be presented in several formats: XML, plain HTML or Text, or JSON, which is of lately, the preferred method.
- Responses can be cached, which means that performance can be augmented by reducing roundtrips between the data source and the emitting server.
- Similarly to SOAP, unless a convoluted request was created and convened between the sender and the receiver, usually the data returned can’t be limited properly. A lot of “extra” information is received from the server.
- Due to ‘simplicity’ being one of its characteristics, sometimes RESTful APIs are extremely forgiving, which leads to engineers feeling unease with the unpredictability of the communications.
- Following up from the previous item, data is not strongly typed, which means that type checks and validation of content must be performed on the client-side as extra work.
Facebook designed this query language, and released it to the public in 2015, to deal with the problem of retrieving in a single query potentially millions of rows of data per second, data that could very well come from several different servers, and thus, the performance of the system was their number one concern.
An interesting trivia tidbit is that its name comes from an actual mathematical concept known as Graph Theory, which considers the relations of elements, otherwise known as vertices, and their connections, or edges. GraphQL’s logo is in fact the representation of a “planar graph”, which is a graph that, when drawn on a flat surface (it’s diagram), can be drawn without edges crossing. If you are interested in Graph Theory you should pick up Richard J. Trudeau’s Introduction to Graph Theory, it’s a great read with lots of both every day and pure mathematic applications and examples.
- The main advantage of GraphQL is the ability for you to retrieve only the elements you need. Since it is a query language, you could map the elements you need from within your query and get back exactly those elements. No overhead.
- Data returned can be strongly typed (as it is with SOAP), which ensures the integrity of data.
- Minimize the round trips from server to client by acting as a “super-fetcher” of data, having that end-point retrieve data from different places, and returning it in one go.
- Being “only” a query language, GraphQL needs a framework to sit on top of to be functional. That’s why you’ll see GraphQL being paired with clients such as Apollo, Helios, or Relay.
- No caching for results, which can be circumvented by using a third-party library.
- Since GraphQL is after all a language, developers do need to learn a new syntax.
What’s Next and Further Reading
More subjects that you can explore:
Learn to appreciate two of the main wrenches of Jest’s Unit Testing toolset
Dockerize your Next.JS application
Learn to use Docker for packaging your Next.JS app for testing or deployment for staging or production
Is Behavior-Driven Development right for your Project?
An approach for Product/Software development that involves the whole team and focuses on the behavior of the user
When and how should you use LocalStorage, SessionStorage, IndexedDB, Cookies, third party Library or Server-Side