Welcome back, fellow engineers! We're excited to share that weekly issues of LUC’s newsletter have returned. We’ve got some exciting newsletter updates in store as well!

This week’s issue brings you:

• GraphQL vs REST: Navigating the Evolving Landscape of API Design

• Must Know Best Practices for Optimizing API Endpoints (Recap)

• Understanding The OSI Model (Recap)

• Concurrency is NOT Parallelism (Recap)

READ TIME: 5 MINUTES

GraphQL vs REST: Navigating the Evolving Landscape of API Design

The year 2000 forever changed the API landscape. It was the year REST was born. The “rest” is history (bye-bye SOAP).

REST has been the predominant architecture for APIs for the past couple of decades, but there has been an alternative solution growing in popularity since 2015 — GraphQL.

GraphQL is technically not an API architectural style, but rather a query language for APIs. It offers a flexible approach for data access and manipulation, contrasting with the structured architectural constraints and principles of other architectural patterns. This positions GraphQL as an alternative tool to REST and other API architectures for API interactions.

Now, let’s dive into the nuances of REST and GraphQL, their distinct characteristics, the upsides and downsides of each, and where each technology shines best.

Decoding REST

Representational State Transfer (REST) is an architectural style that is commonly used for web-based APIs alongside HTTP as the transport protocol.

Below are some of the hallmark characteristics of REST:

Statelessness: Essential to REST, statelessness dictates that the server should not store any user information between requests. Each request from the client must contain all the necessary information for the server to process it.

Separation of concerns: REST enforces a clear division where the client and server operate independently, enhancing modularity and facilitating maintenance.

Uniform interface: RESTful APIs utilize standard HTTP methods like GET, POST, and DELETE, ensuring a uniform and predictable interface.

Resource-based approach: Central to REST is its focus on resources — objects, entities, or data within a system, each uniquely identified by URIs. This contrasts with approaches centered around methods or functions.

Standard media types: RESTful APIs typically communicate using standard formats like JSON, XML, or plain text, with the ability to handle various media types as per client requests. This standardization simplifies the interaction and parsing of responses.

The Good and the Bad of REST

REST offers many benefits, below are a few of the primary benefits:

🔷 Simplicity and flexibility: Leveraging standard HTTP methods, makes it easy to understand and implement. It also supports multiple data formats.

🔷 Scalability: Its stateless nature allows REST services to handle a large volume of requests and horizontally scale with ease.

🔷 Cacheability: By enabling responses to be cached on the client side, REST significantly boosts performance and reduces server load.

As with all technologies, there are inescapable downsides:

🔶 Over-fetching and under-fetching: REST APIs can return excessive data (over-fetching) or require multiple calls for complex data (under-fetching).

🔶 Rigid structure: Adhering to RESTful principles can sometimes lead to inflexibility in API design and implementation.

🔶 Less efficient for complex queries: REST can be less efficient for applications that require complex queries to aggregate data from multiple sources, as this often necessitates multiple API calls.

Understanding GraphQL

Introduced by Facebook in 2015, GraphQL presents a new way of building APIs. In some ways, GraphQL can feel like the opposite of REST.

Contrary to the REST approach, which can necessitate multiple requests to obtain interconnected data, GraphQL provides a more streamlined method. Rather than having multiple endpoints for each resource or entity, it provides a single endpoint.

GraphQL provides strong typing enforced by a schema that clearly defines available data types and their query formats, ensuring structured and predictable interactions. This allows users to define their specific data requirements. In response, resolvers will then fetch the actual data, which can come from a variety of sources and the server will package the data to match the structure that the client requested.

It efficiently delivers the requested data in a single query. Rather than over-fetching and under-fetching data, you get only what you require. This precision in data retrieval improves performance as well as user experience.

The Upsides and Downsides of GraphQL

There are some strong benefits GraphQL provides over a REST approach:

🔷 Efficient data loading: Ideal for applications with complex data structures and relationships, minimizing over-fetching and under-fetching issues.

🔷 Single network request: Multiple data needs can be consolidated into a single network request, reducing the overhead of multiple API calls.

🔷 Real-time data with subscriptions: GraphQL supports real-time updates, a feature not inherently present in REST.

🔷 Rapid front-end development: Front-end teams can make data changes without heavy reliance on back-end modifications.

However, there are also some drawbacks and challenges that need to be fully taken into consideration:

🔶 Performance issues with complex queries: Complex queries in GraphQL can sometimes lead to performance problems, particularly if not properly managed or optimized.

🔶 Caching challenges: Unlike REST, which can easily leverage HTTP caching, GraphQL requires more sophisticated strategies for effective caching.

🔶 Added complexity: GraphQL adds a layer of complexity to the system in comparison to REST.

🔶 Steep learning curve: The paradigm shift GraphQL introduces can require a significant investment in learning and adaptation.

Comparing REST and GraphQL: The Context Matters

When it comes to choosing between REST and GraphQL, the decision hinges on the specific requirements of your application.

Ideal Use Cases for REST

• Web services and APIs: REST is well-suited for building standard web services and APIs, especially for Internet-facing applications.

• Microservices architecture: Its stateless nature and scalability make REST ideal for microservices-based distributed systems.

• CRUD applications: REST is a natural fit for applications with a clear resource model and straightforward CRUD (Create, Read, Update, Delete) operations.

• Mobile applications: RESTful APIs provide a lightweight and flexible way to serve data to mobile apps, accommodating varied network conditions.

• Legacy system compatibility: REST’s maturity means it's often more compatible with older systems and technologies.

Optimal Scenarios for GraphQL

• Applications with complex, interrelated data: GraphQL excels in environments where clients need to retrieve nested or interrelated data in a single request.

• Real-time applications: Such as chat apps or live data feeds, benefit from GraphQL's real-time data updates with subscriptions.

• Rapidly evolving front-end requirements: The flexibility of GraphQL is particularly advantageous in fast-paced development environments, where the ability to quickly adapt and iterate on the front-end without extensive back-end changes is crucial.

• Microservices architectures: Useful for aggregating data from various microservices into a unified API layer.

Summing Up

GraphQL and REST operate in distinctly different approaches to data access and manipulation. This gives rise to a distinct set of advantages and tradeoffs for each, as well as different scenarios in which they perform best.

REST stands as a proven, reliable choice for standard web services in both simple applications and complex systems, with simplicity being a standout feature.

On the other hand, GraphQL is a powerful alternative for applications requiring complex data retrieval and real-time interactions, but it can add a lot of complexity.

Must Know Best Practices for Optimizing API Endpoints (Recap)

Optimized API endpoints are key to building robust, scalable, and user-friendly applications.

Core techniques and best practices for API optimization include optimizing SQL queries, caching, payload compression, pagination, asynchronous processing, rate limiting, input validation, monitoring and logging, robust authentication/authorization, and encrypting data in transit.

API optimization isn’t optional—it’s essential for delivering high-performance, secure, and efficient services. By adopting these best practices, you’ll lay the groundwork for APIs that excel in performance and security.

Check out the full post here for an explanation of each best practice.

Understanding The OSI Model (Recap)

The OSI Model is a conceptual framework that standardizes how different systems communicate over a network. It divides network interactions into seven layers, each responsible for specific functions, ensuring data flows from one device to another in a structured way. Key concepts include:

• Encapsulation: as data moves from the top (Application layer) to the bottom (Physical layer), each layer adds its own header, wrapping the data for transmission.

• Decapsulation: on the receiving end, the process reverses as each layer removes its corresponding header, eventually delivering the original data to the application.

The OSI model promotes interoperability across different systems, simplifies troubleshooting, and ensures reliable, consistent communication across global networks.

Layers: Application, Presentation, Session, Transport, Network, Data Link, Physical.

For an explanation of each layer, see the full post here.

Concurrency is NOT Parallelism (Recap)

As Rob Pike (one of the creators of Golang) succinctly put it: “Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once."

Concurrency — Manages several tasks on a single processor, creating an illusion of simultaneous execution by switching between tasks. This optimizes processor time, especially when tasks wait for others to complete.

Parallelism — Performs multiple tasks simultaneously by efficiently utilizing multiple processors or cores in a computing system.

For more details between the two, check out the full post here.

That wraps up this week’s issue of Level Up Coding’s newsletter!

Join us again next week where we’ll explore and visually distill more important engineering concepts.