#160 - Tại sao Javascript developer thích sử dụng axios hơn fetch?
Discover more from Grokking Newsletter
#160 - Tại sao Javascript developer thích sử dụng axios hơn fetch?
Grooking Newsletter đã chính thức trở lại sau 2 tuần nghỉ Tết cổ truyền. Ban biên tập hy vọng sau khoản thời gian nghỉ ngơi thư giãn cùng người thân và bạn bè, quý bạn đọc có thêm nhiều năng lượng để thực hiện các dự định trong năm mới và tiếp tục cùng đồng hành với Grokking Newsletter trong thời gian tới.
Nếu bạn đọc thấy hay, mong các bạn ủng hộ Grokking bằng cách forward email cho những bạn bè làm software engineering!
Những bài viết hay
Tại sao Javascript developer thích sử dụng axios hơn fetch? — betterprogramming.pub
Fetch là một "built in" được tích hợp sẵn trong Javascript hỗ trợ thao tác gọi API từ web client (chi tiết về Fetch API bạn có thể xem thêm tại đây). Bởi vì là một built in, do đó bạn không cần phải cài đặt Fetch, tuy nhiên hầu hết các Javascript developer không thích sử dụng fetch mà thường tìm một giải thay thế tiện lợi hơn. Trong các giải pháp thay thế, axios là phương án phổ biến nhất. Vậy tại sao developer thích dùng axios hơn fetch?
JSON
Fetch trả về một response object, developer phải dùng thêm một method khác (phổ biến là response.json()) để đọc dữ liệu của response object. Một điểm trừ nữa cho fetch là nó không được tích hợp sẵn trong NodeJS.
Axios mặc định trả về json object, do đó lập trình viên có thể thao tác một cách dễ dàng.
Xử lý lỗi (Error Handling)
Với Fetch bạn luôn phải kiểm tra status của response (response.ok) để biết API trả về thành công hay lỗi.
Ngược lại, bạn có thể xử lý error khá dễ dàng với axios. Trong trường hợp API trả về HttpStatus khác 2xx, Promise sẽ reject và trả về lỗi thay vì resolve như fetch. Do đó developer có thể catch lỗi và xử lý một cách dễ dàng.
Kiểm tra tiến độ
Bạn không thể giám sát tiến độ upload trong fetch, tuy nhiên bạn có thể kiểm tra được tiến độ download bằng cách sử dụng ReadableStream object (code tương đối phức tạp)
Axios có thể giám sát được cả upload lẫn download, code tương đối đơn giản
Http Interceptor
Mặc định, Fetch không cung cấp HTTP Interceptor, developer phải override fetch() nếu muốn có HTTP Interceptor.
Http Interceptor là một trong những tính năng nổi bật của axios, bạn có thể dùng axios interceptor cho các mục đích khác nhau nhưng error handling, thiết lập các custom header như Authorization, v.v.
Timeout
Để thiết lập timeout cho fetch, bạn phải dùng tới AbortController tương đối phức tạp, với axios điều này hết sức đơn giản chỉ với một dòng config
timeout: 5000
Sự tương thích
Fetch chỉ hỗ trợ Chrome 42+, Safari 10.1+, Firefox 39+, and Edge 14+, chi tiết bạn có thể xem tại Can I Use - https://caniuse.com/?search=Fetch
Axios hỗ trợ tương đối rộng rãi, ngay cả IE11. Chi tiết bạn có thể tra cứu thêm trong Axios Documentation - Ihttps://github.com/axios/axios#browser-support
Những lỗi phổ biến nhất khi phát triển các ETL pipelines
Các dự án về Data Warehouse từ lâu đã trở thành một phần của cơ sở hạ tầng CNTT của hầu hết các công ty lớn. Các quy trình ETL (Extraction-Transformation-Loading) là một phần của các dự án này, nhưng các nhà phát triển đôi khi cũng mắc những lỗi tương tự khi thiết kế và duy trì các quy trình này. Trong bài viết, tác giả giới thiệu một số sai lầm phổ biến dễ mắc phải trong các giai đoạn phát triển ETL.
Trong bài viết, tác giả muốn thu hẹp phạm vi phân tích trọng tâm vào các vấn đề:
Data warehouse bao gồm traditional SQL DWH (Oracle Database, MS SQL Server, etc.)
Khái niệm về single version of the truth and historical truth khi mô hình hoá Data Warehouse
ETL-process đề cập đến quá trình tải dữ liệu từ một hoặc nhiều hệ thống nguồn vào Data Warehouse .
Data Warehouse thường được tạo ra từ một thời gian nhất định và luôn có một số nhóm phát triển đang độc lập làm việc trên đó.
Từ đây, tác giả đề cập một cách chi tiết về các sai sót dễ gặp phải và cách khắc phục trong quá trình phát triển ETL:
Sử dụng SYSDATE hoặc các hàm tương đương cho business logic
Data Profiling không được thực hiện trước khi quá trình phát triển bắt đầu
Sử dụng "static" script từ hệ thống nguồn
Phát triển trên một lượng dữ liệu nhỏ
Sử dụng sai giữa techical và business date
"Mechanical" implementation
The Node.js Architecture! — medium.datadriveninvestor.com
Hầu hết chúng ta đều biết, developer sử dụng Javascript để phát triển ứng dụng trên nền tảng NodeJS, tuy nhiên NodeJS khổng chỉ được xây dựng bằng Javascript mà cả C++ nữa và sử dụng nhiều thư viện khác nhau, trong đó có 2 thư viện phụ phuộc quan trọng nhất là V8 và LIBUV.
V8 là một javascript engine được phát triển bởi Google. Nó phụ trách việc chuyển javascript code thành mã máy để máy tính có thể hiểu và thực thi.
LIBUV cung cấp cho NodeJS quyền truy cập vào hệ điều hành máy tính, mạng, hệ thống file, v.v. LIBUV là một thư viện mã nguồn mở được viết bằng C++. Ngoài việc tập trung xử lý truy xuất I/O bất đồng bộ (asynchronous I/O), LIBUV còn phát triển hai tính năng rất quan trọng khác là event loop và thread pool.
Ngoài V8 và LIBUV, NodeJS còn được tạo ra từ các thư viện khác như HTTP parser, C-ARES (DNS queries), OpenSSL và Zlib.
Góc Distributed System
Disaster Recovery, cách tiếp cận Always On!
Làm việc trong các hệ thống phân tán, chắc chắn bạn sẽ được nghe hoặc tiếp xúc với bài toán Disaster Recovery. Sự cố là điều không thể tránh khỏi và các kỹ sư luôn luôn chuẩn bị các phương án để phòng ngừa Disaster xảy ra cũng như cách khắc phục khi nó xảy ra. Các phương án phổ biến như thiết lập một hệ thống hoàn toàn tương tự hệ thống chính, hoạt động ở chế độ hot, warm hoặc cold standby (là chế độ chờ và sẵn sàng ngay lập tức thay thế hệ thống chính khi có sự cố), thường được gọi là phương pháp FailOver. Góc Distributed System tuần này chia sẻ một cách tiếp cận mới, được sử dụng ngày càng nhiều trong các hệ thống phức tạp và quan trọng, được Google lần đầu tiên công bố áp dụng trong hệ thống Google Ads của họ, có tên gọi là Natively Multihomed Architecture, hay còn được gọi là Kiến trúc Always On. Kiến trúc này có lợi thế so với các cách tiếp cận cũ là sử dụng ít tài nguyên hơn mà đem lại mức độ sẵn sàng (high availability) và tính nhất quán (consistency) cao hơn.Ý tưởng chính của kiến trúc này là xây dựng các hệ thống giống hệt hệ thống gốc (nhiều hơn 1), tất cả cùng hoạt động (Always On) và tải được phân phối nhịp nhàng giữa các hệ thống. Khi một hệ thống có dấu hiệu xử lý chậm, workload sẽ được tự động phân bổ nhiều hơn tới những hệ thống còn lại.Để hiểu thêm về kiến trúc này, mời bạn đọc những bài viết dưới đây:
Bài viết gốc của Google Ads về kiến trúc Multihomed: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44686.pdf
Một số hệ thống khác của Google cũng được build với kiến trúc này như là Spanner, Photon hay Mesa.
Code & Tools
This Week Sponsors
POPS is a creative, innovative & hyper-growth working environment where storytelling meets technology.
POPS is the leading digital entertainment company in Southeast Asia. With over 12 years in entertainment, we provide thousands of exclusive, high-quality, carefully curated local and international contents and bring a unique entertainment experience through POPS Original series, concerts, movies, comics, esports and more.
We are on a journey to find talents who are passionate about technology and love to develop POPS APP the digital entertainment product with the latest technologies such as: OTT, Video On Demand, Microservices, etc. to give end users in the region great experiences with an all-inclusive digital entertainment platform.
Góc Tuyển Dụng
Visit https://popsww.com/en/careers for current job openings.
Quotes
Every great developer you know got there by solving problems they were unqualified to solve until they actually did it.
- Patrick McKenzie