Làm Web với Django

Tìm hiểu, cài đặt và sử dụng PHP Code Sniffer

admin — Fri, 10 Feb 2023 01:51:48 +0000

Tìm hiểu, cài đặt và sử dụng PHP Code Sniffer admin Fri, 02/10/2023 - 02:51

Tìm hiểu về Microservices - Phần 2: Giao tiếp giữa các services

admin — Wed, 02 Nov 2022 14:32:36 +0000

Tìm hiểu về Microservices - Phần 2: Giao tiếp giữa các services admin Wed, 11/02/2022 - 15:32

Tập tành tìm hiểu Headless and Hybrid Drupal 101

admin — Sun, 30 Oct 2022 09:35:48 +0000

Tập tành tìm hiểu Headless and Hybrid Drupal 101 admin Sun, 10/30/2022 - 10:35

Attach

hybrid-drupal.pdf1.21 MB

Tìm hiểu Install NodeJS trong khóa học Node JS (P4)

admin — Fri, 07 Oct 2022 14:46:06 +0000

Tìm hiểu Install NodeJS trong khóa học Node JS (P4) admin Fri, 10/07/2022 - 16:46

Hướng dẫn create a link/URL with querystrings set/get from parameters

admin — Sun, 28 Aug 2022 02:33:11 +0000

Hướng dẫn create a link/URL with querystrings set/get from parameters admin Sun, 08/28/2022 - 04:33

Tập tành Cookie Services: How to Handle Cookies in Drupal & Symfony

admin — Sun, 31 Jul 2022 11:04:18 +0000

Tập tành Cookie Services: How to Handle Cookies in Drupal & Symfony admin Sun, 07/31/2022 - 13:04

Làm sao Disable Clicking Inside a Div with CSS or JavaScript

admin — Mon, 23 May 2022 07:21:00 +0000

Làm sao Disable Clicking Inside a Div with CSS or JavaScript admin Mon, 05/23/2022 - 09:21

GraphQL is the better REST with 1 API Endpoint

admin — Fri, 06 May 2022 09:19:50 +0000

GraphQL is the better REST with 1 API Endpoint admin Fri, 05/06/2022 - 11:19

GraphQL is the better REST

Over the past decade, REST has become the standard (yet a fuzzy one) for designing web APIs. It offers some great ideas, such as stateless servers and structured access to resources. However, REST APIs have shown to be too inflexible to keep up with the rapidly changing requirements of the clients that access them.

GraphQL was developed to cope with the need for more flexibility and efficiency! It solves many of the shortcomings and inefficiencies that developers experience when interacting with REST APIs.

To illustrate the major differences between REST and GraphQL when it comes to fetching data from an API, let’s consider a simple example scenario: In a blogging application, an app needs to display the titles of the posts of a specific user. The same screen also displays the names of the last 3 followers of that user. How would that situation be solved with REST and GraphQL?

Check out this article to learn more about why developers love GraphQL.

Data Fetching with REST vs GraphQL

With a REST API, you would typically gather the data by accessing multiple endpoints. In the example, these could be /users/<id> endpoint to fetch the initial user data. Secondly, there’s likely to be a /users/<id>/posts endpoint that returns all the posts for a user. The third endpoint will then be the /users/<id>/followers that returns a list of followers per user.

With REST, you have to make three requests to different endpoints to fetch the required data. You’re also overfetching since the endpoints return additional information that’s not needed.

In GraphQL on the other hand, you’d simply send a single query to the GraphQL server that includes the concrete data requirements. The server then responds with a JSON object where these requirements are fulfilled.

Using GraphQL, the client can specify exactly the data it needs in a query. Notice that the structure of the server’s response follows precisely the nested structure defined in the query.

No more Over- and Underfetching

One of the most common problems with REST is that of over- and underfetching. This happens because the only way for a client to download data is by hitting endpoints that return fixed data structures. It’s very difficult to design the API in a way that it’s able to provide clients with their exact data needs.

“Think in graphs, not endpoints.” Lessons From 4 Years of GraphQL by Lee Byron, GraphQL Co-Inventor.

Overfetching: Downloading superfluous data

Overfetching means that a client downloads more information than is actually required in the app. Imagine for example a screen that needs to display a list of users only with their names. In a REST API, this app would usually hit the /users endpoint and receive a JSON array with user data. This response however might contain more info about the users that are returned, e.g. their birthdays or addresses - information that is useless for the client because it only needs to display the users’ names.

Underfetching and the n+1 problem

Another issue is underfetching and the n+1-requests problem. Underfetching generally means that a specific endpoint doesn’t provide enough of the required information. The client will have to make additional requests to fetch everything it needs. This can escalate to a situation where a client needs to first download a list of elements, but then needs to make one additional request per element to fetch the required data.

As an example, consider the same app would also need to display the last three followers per user. The API provides the additional endpoint /users/<user-id>/followers. In order to be able to display the required information, the app will have to make one request to the /users endpoint and then hit the /users/<user-id>/followers endpoint for each user.

Rapid Product Iterations on the Frontend

A common pattern with REST APIs is to structure the endpoints according to the views that you have inside your app. This is handy since it allows for the client to get all required information for a particular view by simply accessing the corresponding endpoint.

The major drawback of this approach is that it doesn’t allow for rapid iterations on the frontend. With every change that is made to the UI, there is a high risk that now there is more (or less) data required than before. Consequently, the backend needs to be adjusted as well to account for the new data needs. This kills productivity and notably slows down the ability to incorporate user feedback into a product.

With GraphQL, this problem is solved. Thanks to the flexible nature of GraphQL, changes on the client-side can be made without any extra work on the server. Since clients can specify their exact data requirements, no backend engineer needs to make adjustments when the design and data needs on the frontend change.

Insightful Analytics on the Backend

GraphQL allows you to have fine-grained insights about the data that’s requested on the backend. As each client specifies exactly what information it’s interested in, it is possible to gain a deep understanding of how the available data is being used. This can for example help in evolving an API and deprecating specific fields that are not requested by any clients any more.

With GraphQL, you can also do low-level performance monitoring of the requests that are processed by your server. GraphQL uses the concept of resolver functions to collect the data that’s requested by a client. Instrumenting and measuring performance of these resolvers provides crucial insights about bottlenecks in your system.

Benefits of a Schema & Type System

GraphQL uses a strong type system to define the capabilities of an API. All the types that are exposed in an API are written down in a schema using the GraphQL Schema Definition Language (SDL). This schema serves as the contract between the client and the server to define how a client can access the data.

Once the schema is defined, the teams working on frontend and backends can do their work without further communication since they both are aware of the definite structure of the data that’s sent over the network.

Frontend teams can easily test their applications by mocking the required data structures. Once the server is ready, the switch can be flipped for the client apps to load the data from the actual API.

Add new comment

Rò rỉ bộ nhớ do phải lưu các Observable để subscribe

admin — Sun, 05 Sep 2021 02:16:13 +0000

Rò rỉ bộ nhớ do phải lưu các Observable để subscribe admin Sun, 09/05/2021 - 04:16

Phần 2 - Firebase Cloud Firestore cùng học và tìm hiểu - tháng 8.2021

admin — Sat, 28 Aug 2021 07:22:36 +0000

Phần 2 - Firebase Cloud Firestore cùng học và tìm hiểu - tháng 8.2021 admin Sat, 08/28/2021 - 09:22

10 điểm hạn chế của Firebase

Mặc dù đây là một nền tảng tuyệt vời, nhưng Firebase cũng có một số nhược điểm. Tôi sẽ phân tích ngay bên dưới để bạn có cái nhìn đa chiều hơn về nền tảng này nhé.

Không phải là mã nguồn mở
Người dùng không có quyền truy cập mã nguồn
Firebase không hoạt động ở nhiều quốc gia
Chỉ hoạt động với Cơ sở dữ liệu NoSQL
Truy vấn chậm
Không phải tất cả các dịch vụ Firebase đều miễn phí
Firebase khá đắt và giá không ổn định
Chỉ chạy trên Google Cloud
Thiếu Dedicated Servers và hợp đồng doanh nghiệp
Không cung cấp các API GraphQL

Không phải là mã nguồn mở

Firebase không phải là một tùy chọn mã nguồn mở để phát triển ứng dụng di động. Điều này khiến nó trở thành một lựa chọn không tối ưu cho nhiều nhà phát triển. Người dùng không thể sửa đổi mã nguồn Firebase. Theo tôi thì đây là hạn chế lớn nhất của Firebase và ngăn cộng đồng cải tiến sản phẩm.

Xem phần 1 qua đường link sau: Phần 1 - Firebase Cloud Firestore tự học và tìm hiểu Firebase

Người dùng không có quyền truy cập mã nguồn

Đây là một hạn chế lớn khác của Firebase cho người dùng. Việc không có quyền truy cập vào mã nguồn có thể khá khó khăn đối với một số nhà phát triển. Đặc biệt, đối với các ứng dụng lớn, việc chuyển sang các nhà cung cấp khác không phải là một nhiệm vụ dễ dàng và để thực hiện việc này, toàn bộ Backend sẽ cần được xây dựng lại từ đầu.

Firebase không hoạt động ở nhiều quốc gia

Firebase là một Subdomain của Google. trang Web chính thức của nó là https://firebase.google.com và bị chặn ở nhiều quốc gia. Theo tôi được biết, Google cùng với các dịch vụ khác của Google bị chặn và không thể truy cập được ở nhiều quốc gia, trong đó có Trung Quốc.

Chỉ hoạt động với Cơ sở dữ liệu NoSQL

Cả Firestore và Firebase Realtime Database đều cung cấp cấu trúc NoSQL. Chúng không có tùy chọn nào để sử dụng cơ sở dữ liệu quan hệ.

Mặc dù Firebase đã thực hiện những cải tiến đáng kể trên Cloud Firestore so với RTDB, nhưng việc chạy các truy vấn phức tạp vẫn là một thách thức đối với một số người dùng nhất định.

Với Firebase, người dùng không thể xử lý nhanh chóng việc di chuyển dữ liệu tương tự như cơ sở dữ liệu SQL đơn giản. Firebase sử dụng JSON và hầu như không có tính năng SQL nào. Vì vậy, việc di chuyển từ cơ sở dữ liệu sẽ không dễ dàng.

Truy vấn chậm

Không phải tất cả cơ sở dữ liệu đều lý tưởng cho mọi trường hợp sử dụng và Cloud Firestore cũng không ngoại lệ. Mặc dù đó là một giải pháp tuyệt vời để mở rộng ứng dụng của bạn, cung cấp hỗ trợ truy vấn ngoại tuyến và cập nhật thời gian thực, nhưng nó cũng có những hạn chế như:

Kích thước yêu cầu API tối đa 10 MiB.
Không có truy vấn tổng hợp gốc.
Giới hạn kích thước tài liệu là 1 MiB.
Kết nối đồng thời tối đa 1M.
Truy vấn hiệu suất chậm.

Không phải tất cả các dịch vụ Firebase đều miễn phí

Các chức năng đám mây chỉ khả dụng trên gói Blaze và người dùng không thể dùng thử dịch vụ trong gói Spark.

API Cloud Vision trong tính năng học máy cũng không khả dụng trong gói Spark miễn phí của nền tảng này.. Dịch vụ này chỉ có sẵn cho người dùng của gói Blaze và tính phí 1,5 USD/ k API.

Firebase khá đắt và giá không ổn định

Firebase là một nền tảng phát triển ứng dụng di động có nhiều tính năng nhưng cũng là một nền tảng đắt tiền đối với một số người. Nó cung cấp một gói miễn phí nhưng có hạn chế nhất định.

Firebase cung cấp nhiều tính năng hữu ích hơn nhưng giá cũng sẽ cao hơn so với một nhà cung cấp IaaS thuần túy. Nói chung, tôi cho rằng việc tự lưu trữ một ứng dụng sẽ rẻ hơn so với sử dụng Firebase.

Trước khi sử dụng Firebase, tôi khuyên bạn hãy so sánh chính xác chi phí trả trước của việc thiết lập một cụm tại nhà cung cấp IaaS và chi phí đang thực hiện để duy trì máy chủ so với chạy ứng dụng trực tiếp trên Firebase.

Một khía cạnh khác khiến Firebase trở nên đắt đỏ là nó là một công nghệ độc quyền. Firebase phải bù đắp khoản đầu tư kỹ thuật cho cơ sở người dùng của nó.

Firebase cung cấp dịch vụ theo mô hình định giá dựa trên mức sử dụng và không có cách nào để giới hạn giá cả. Không có bảng giá cố định cho nền tảng và việc theo dõi mức độ sử dụng tài nguyên có thể là một vấn đề phức tạp.

Việc ước tính chi phí của Firebase có thể khó khăn đối với một số người dùng, đặc biệt là khi không thể dự đoán được các yêu cầu về khả năng mở rộng. Việc định giá rất phức tạp và Firebase có giá cụ thể cho mọi tính năng.

Theo thông tin tôi được biết, Firebase từng cung cấp gói Flame. Đó là gói có giá cố định 25 USD / tháng. Nhưng nó đã được gỡ bỏ vào tháng 1/ 2020.