RESTTraditional ways are not always the best

I’ve been working as a Software Developer for the past four years. Where I have taken part in creating business solutions for clients in the public and private sector. During my years in software development. I’ve been lucky enough to learn and work with various types of software architectures such as; Event Driven, CQRS, GraphQL and REST. REST being the keyword for this article. The goal for this article is to make us more open to other architectures than always going for the traditional way of how we do things in backend development.

So REST API..?

For those who have worked in the field of Software development you have heard the term REST API. But for those who haven’t. REST “Representational State Transfer” is a Web based architecture that uses HTTP Protocol. This architecture has been around in the software field since 2000 and is still being used in web services built in various programming languages. The architecture helps us to build applications, so that we can easily exchange data over the network using its HTTP methods.

Following methods you would see in a REST based architecture is

• GET — That provides a read only access to a resource
• POST — Often used to create a new resource
• DELETE — To remove a resource
• PUT — Used to update a existing resource or sometimes create a new one

Unspoken pain points with REST architecture

REST API’s will live on for many years in the software development space.

One potential drawback of using REST architecture for building API’s is that it can lead to a large and complex codebase. This is especially true when working on a domain with a complex set of requirements, as it may require the creation of multiple controllers and endpoints to properly reflect the domain. This can become even more challenging if you are using a monolithic architecture and not splitting your service into multiple microservices. This can lead to a codebase becoming unwieldy and difficult to maintain.

Another issue that can arise with REST API’s is that as the API evolves over time, it can become increasingly difficult to maintain and update. This can lead to breaking changes to the API’s interface, which can cause problems for existing clients who are forced to rely on older versions of the API.

From a client perspective, working with REST API’s can also be less efficient as it often requires multiple trips to the server to gather all the necessary data. This can consume more time and resources and load on your service. This is caused by the fact that clients may not have control over what data is returned or not returned when making a request to your service. Which requires the need of better communication between backend and frontend developers.

While REST architecture remains popular in the software development space, it’s important to consider these potential pain points and weigh them against the benefits before choosing it as the architecture for your API.

Even though there are pain points with REST. It’s most definitely a huge step into a better direction compared to how we did things back in the days. As a developer you’ve probably heard about SOAP API’s. SOAP uses XML as it’s message format. Which can be in the long run difficult to read and less flexible to use with it’s rigid set of rules for message format and structure.

Let’s shed some light on other architectures and solutions.

CQRS — Command, Query Responsibility Segregation

CQRS also known as Command Query Responsibility Segregation, is an architectural pattern that separates the reading and writing of data in an application. It involves separating the objects/models responsible for handling operations queries (read) from the objects/models responsible for handling operations commands (write). This separation allows for a more flexible and scalable architecture as the read and write operations can be optimized and scaled independently.

The main advantage of CQRS is that it allows developers to write code that is more flexible and scalable. This is done by only using two endpoints, one for reading and one for writing. Which can make the service perform better. CQRS can also be used with other architectures and patterns such as Event Driven and Domain Driven Design. Which will give you the benefit of focusing on building a solution that best reflects the business domain and making the communication between microservices easier. If you want to learn more about this be sure to read my Event Driven Architecture article here: https://medium.com/netcompany/event-driven-architecture-c24341efca8a

It’s important to note that while CQRS can be useful in many cases, it is not always the best approach and the solution will often times depend on the specific problem you are trying to solve. Implementing CQRS can be complex and in some cases makes it a bit harder to understand, depending on the complexity of the domain and it’s problem.

GraphQL

GraphQL was developed internally by Facebook (Meta) and was released back in 2015. GraphQL is a query language for APIs that gives clients the possibility of requesting the data they need and nothing more.

GraphQL is often used as an option for REST. As mentioned before in the pain-points section of REST. The Client has to in many cases do multiple requests to different endpoints to retrieve all necessary data. GraphQL is built to allow clients to make request through a single endpoint on the server. Clients will then proceed to do requests in the form of a GraphQL query. Which is in a special format for describing the data you want to retrieve. A simple example could look something like this.

The same goes for create, delete and update. These types of actions will be done through a GraphQL mutation. A mutation is an operation that allows clients to make changes to data through the server. An example of this would look something like this.

A GraphQL server is built on top of standard HTTP Server that you would see in a REST API. The difference is that the requests and responses would use GraphQL query language instead of the standard HTTP methods we are used to.

GraphQL has many advantages over REST but also some pain points. It often requires the developers to think and design your API in a different way. You would experience things like caching, consistency and security can become overall difficult concepts to work with in GraphQL. Challenges like this are worth considering if you were to go the route of using GraphQL over other architectures.

Summary

When it comes to building services, there is no one size fits all type of solution. Each architecture mentioned has it’s own strengths and weaknesses. Often time the best choice will depend on the specific needs of your application. It’s important to take a step back and consider all options before making a decision. While traditional architectures such as REST have their advantages but also has it’s limitations as mentioned earlier.

The goal of this article is to encourage developers to consider multiple architectures and weigh the pros and cons before making a decision.

This has led me throughout my experience, to always take a more in-depth look at what needs to be solved, and leading me to make the right choice when choosing an architecture for a project. Doing this can help you save a lot of time and create new potential opportunities for your projects.