[Frontend System Design] Client-Server API. Part 1 | REST

Summary

This video explores the different client-server communication protocols, focusing on REST, its advantages, limitations, and when it is suitable. It explains how REST is ideal for simple applications, public APIs, and CRUD operations due to its simplicity and flexibility. However, it also highlights issues like overfetching, underfetching, and scalability concerns, especially for complex applications and microservices. The video suggests alternatives like GraphQL and gRPC when performance and data efficiency become critical. It concludes with a look ahead at other approaches such as GraphQL and RPC for more specialized use cases.

Takeaways

• 😀 REST APIs are flexible and simple, making them suitable for most applications but come with certain limitations like over-fetching and under-fetching.
• 🛠 REST follows six key principles: uniform interface, statelessness, cacheability, client-server architecture, layer system, and optional code on demand.
• 📚 HATEOAS (Hypermedia as the engine of application state) is an important REST principle that makes the client less dependent on backend logic.
• 🔄 Over-fetching occurs when more data is fetched than needed, leading to inefficiency, while under-fetching happens when the necessary data isn't retrieved, causing additional requests.
• ⚙️ REST's simplicity and scalability are beneficial for simple applications and public APIs, where ease of use is the priority.
• 💡 When using REST, be cautious of the potential for future complexity, especially when dealing with a growing system that requires maintaining backward compatibility.
• 🔍 Versioning REST APIs effectively can become challenging, and poorly implemented versioning can cause maintenance headaches.
• 📈 For scenarios involving performance and microservices, alternative protocols like GraphQL or gRPC may be more efficient than REST.
• 🌐 GraphQL is ideal for avoiding over-fetching and under-fetching issues, allowing clients to specify exactly what data they need.
• ⚡ gRPC and RPC-based approaches are often more suitable for high-performance needs and service-to-service communication, offering faster speeds than REST.
• ⚖️ System design must balance simplicity with future scalability, considering the long-term maintenance cost of different API architectures.

Q & A

What is one of the main advantages of REST APIs?

One of the main advantages of REST APIs is its unification. It ensures consistency across different teams, protocols, and customers, making it adaptable for various applications.

What is a key disadvantage of REST APIs in terms of flexibility?

A key disadvantage of REST APIs is that it can lead to over-fetching or under-fetching of data, causing inefficiencies and unnecessary complexity, especially when the API is used across multiple teams or projects.

Why is REST considered a good choice for public APIs?

REST is considered a good choice for public APIs because it is simple, widely understood by developers, and supports multiple APIs. It is often the default choice for public-facing APIs.

What are some of the problems with adding fields to a REST API endpoint?

Adding fields to a REST API endpoint can increase coupling between the frontend and backend teams, potentially causing over-fetching for other teams using the same API. It may also reduce the unification of the API.

How does the unification of REST APIs impact the developer experience?

The unification of REST APIs ensures consistency, but it can be a disadvantage when flexibility or customization is needed. This rigidity can affect the overall developer experience, especially in complex or dynamic systems.

In what case might a full-stack team handle the problem of missing fields in an API endpoint?

A full-stack team may handle the problem by adding the required fields themselves, which simplifies the solution but doesn't eliminate the challenge of maintaining API unification.

Why is it important to consider scalability and system maintenance costs in system design?

Considering scalability and maintenance costs early in the design process helps ensure that the system remains efficient and sustainable over time. This is crucial for avoiding legacy code and managing long-term operational costs.

When is it better to switch from REST to GraphQL?

Switching from REST to GraphQL is advisable when facing issues like over-fetching or under-fetching data, particularly in mobile environments where traffic consumption is a concern. It is also beneficial for complex response structures.

What are some scenarios where REST is not well-suited, and what alternatives are there?

REST is not suitable for service-to-service communication in microservices or when speed is critical. Alternatives like gRPC (for synchronous operations) or RabbitMQ (for message queue operations) are more efficient and faster.

What is the main disadvantage of REST when used in complex applications?

In complex applications, using REST can turn the API into legacy, unsupported code quickly, as the simplicity of REST does not scale well for complex systems, leading to potential issues with long-term maintenance.