DEV Community: meotism

Consistency Thinking

meotism — Mon, 23 Mar 2026 03:03:11 +0000

Nay chúng ta sẽ bàn luận về vấn đề dữ liệu, liệu dữ liệu phải luôn luôn chính xác 100% ngay lập tức?

Hầu hết mọi người sẽ nói là có chứ, dữ liệu phải chính xác mới đúng. Nhưng trong hệ thống phân tán quy mô lớn câu hỏi ấy sẽ là một cái bẫy. Bây giờ chúng ta sẽ mổ xẻ phân tích tại sao?

1. Lầm tưởng dữ liệu

Statement: "Dữ liệu phải luôn cập nhật real-time cho tất cả mọi người"

Trong hệ thống lớn, đó là một thảm hoạ chính vì sẽ làm chậm hiệu suất hệ thống, chi phí cao và khó mở rộng

Vì vậy consistency(tính nhất quán) không cần là giá trị tuyệt đối, là 1 sự đánh đổi chi phí vận hành, tốc độ, trải nghiệm người dùng, độ tin cậy của dữ liệu

2. Định nghĩa lại tư duy về Consistency

Consistency là mức độ đồng bộ dữ liệu giữa các nơi trong hệ thống tại một thời điểm cụ thể. Thay vì hỏi dữ liệu đúng không sẽ hỏi các câu hỏi khác như là:
Ai cần thấy dữ liệu đúng? Cần thấy dữ liệu đúng trong bao lâu? Đúng ngay hay độ trễ vài giây là chấp nhận được?
Từ những câu trả lời chúng ta sẽ chọn ra mô hình phát triển phù hợp

3. 4 Mô hình Consistency

-- Strong Consistency

Mọi lượt đọc luôn thấy dữ liệu mới nhất. Dùng cho: Payment, Banking, Stock, Inventory

-- Read after write

Người dùng thấy ngay dữ liệu họ vừa cập nhật. Dùng cho: Profile update, Post bài, Setting cá nhân.

-- Monotonic Reads

Không bao giờ thấy dữ liệu quay ngược thời gian, tức là không bao giờ thấy tin nhắn trong quá khứ hiển thị r biến mất sau đó xuất hiện lại. Dùng cho: Chat, notification, timeline

-- Eventual Consistency

Mọi nơi sẽ đồng bộ nhưng từ từ. Dùng cho: Search, Feed, Analytics, Cache, Recommendation.

4. Ví dụ thực tế

Cập nhật tên profile:

Phân tách 1 hành động thành nhiều lớp yêu cầu nhất quán khác nhau - tư duy đúng.
"Consistency là trade-off giữa tốc độ, chi phí, UX và độ chính xác"
Dựa trên các yếu tố:

That's it, Happy reading and happy coding!

Hints:

Claude code best Practices

meotism — Tue, 23 Dec 2025 06:42:06 +0000

Fundamental

Essential commands: Bash mode (cmd)
- Make documentation
- create todo list
- shift+tab or /model: change model
- Check memory: /memory
- space key or esc: press one to interrupt, press twice to go back previous prompt in your session
Debugging:
- Screenshot
- Write test for flow or feature
- Using TDD by Claude
Make Claude.md:
- Project Overview: Appname, platform, tech stack, architecture, …
- Getting current Date:(notes for tech stack,…)
- Todo list
- Development Environment
- Common build issues & Solutions
- Testing & debugging
- Common mistake to avoid
- Feature Development workflow
- Documentation Structure
Message queue: mean you prompt and agent processing and you typing new prompt, they push in queue and process later but can affect previous prompt.
Long prompt: should push it to prompt.md stage markdown file

Intermediate

Using GitHub workflows:
- Planning and thinking features
- Use Planning mode: choose model by cmd: /mode
- Thinking modes: “think” < “think hard” < think harder < ultra think
- Using research: Read link docs and research how to build api … or read pdf to implement…
- Create PRDs: features, user experience guides API, documentation and technical design docs.
Automatic change tracking: /changelog day
Github action Integration:
- /install-github-app: you can action using by comment at push request
Think like product manager:
- Clear, relevant context and constraints base on md file
- Review code and understand everything has implemented and working to verify output at higher levels of abstraction

Master

Using multiple agent: Use parallel subagent to brainstorm …(and choose once)
Collaborate git work tree: git worktree add {address location} and prompt to created features
- When done, ask agent to merge each of work trees in one folder and fix conflict if exist
Custom slash commands: 2 custom cmd
- /changelog
- /create-command
Subagents: cmd /agents to create sub agent delegate task handle
MCP server: database MCP - ex: mongoldb-mcp, postgres mcp, supabase
- Interactive with browser:click on UI
- Figma MCP

Read more on: https://code.claude.com/docs/en/cli-reference
That's it! Happy reading and happy coding!

Optimize performance APIs

meotism — Wed, 04 Jun 2025 01:57:13 +0000

Hi there! Hôm nay chúng ta cùng thảo luận về chủ đề làm sao để cải thiện hiệu suất APIs hiệu quả.

1. Ghi Log

Là một trong những chức năng cốt lõi của một ứng dụng, ghi lại thông tin hỗ trợ tối ưu hiệu suất và khắc phục sự cố.

2. Cached

Phương án dễ nhất là sử dụng cache qua: Redis vs Memcached
Client -> data -> cache(if not) -> dbs

3. Lập trình không đồng bộ

Sử dụng nhiều tác vụ xử lý trong 1 process.
Client -> server -> task chính -> nhiều task phụ
Thường được triển khai thông qua thread, message queue, event pub sub,...

4. N+1

Xử lý các trường hợp N+1 query trong database, sử dụng in hoặc join để tối ưu gọi xuống db nhiều trong 1 tiến trình hoặc tạo các temporary table(views) xử lý trước (đánh đổi giữa thời gian và không gian)

5. Pool connection

Tùy theo framework/package để thiết lập 1 pool connection nhiều process sử dụng chung pool connection truy cập đến database

6. Payload JSON

Giảm bớt payload request đến server(bớt số lượng tham số càng ít càng tốt, định dạng file có thể nén lại gửi đến server)

7. Pagination

Thêm các param để lấy data phân trang cho các API trả kết quả dạng list data như:(page, per_page) hoặc (offset, limit),...

That's it! Happy reading and happy coding!

CATALOG OF DESIGN PATTERNS

meotism — Thu, 27 Mar 2025 07:46:13 +0000

Khi lập trình bạn đã bao giờ gặp các lỗi như: code khó đọc, code trùng lặp, import bị vòng lặp, lỗi cú pháp,... thì các bạn nên thử áp dụng các mẫu design patterns trong source code của mình.
Thường thì một lập trình viên sẽ chủ yếu viết code đáp ứng giải quyết được các nghiệp vụ và tối ưu code sau khi hoàn thành. Trong các trường hợp ấy đôi khi có sử dụng qua một số phương pháp tối ưu giống mẫu design patterns tuy nhiên lại không biết đó là gì và phương pháp đó thế nào giống như mình vậy. :D Nên hôm nay mình sẽ hỗ trợ các bạn tìm hiểu và triển khai các mẫu design patterns thường được sử dụng.

1. Định nghĩa design pattern

Design pattern là các mẫu thiết kế giải quyết các vấn đề theo từng loại và mục đích sử dụng trong quá trình phát triển phần mềm.
Sử dụng design pattern khi dự án cần maintain về lâu dài, giải quyết chung một vấn đề, tái sử dụng các function, làm chung giữa nhiều members trong team,...

2. Phân loại mẫu design patterns

Design patterns chia làm 3 nhóm chính:

1- Creational design patterns:

Cung cấp các cơ chế đối tượng khởi tạo, giúp tăng độ linh hoạt và tái sử dụng mã nguồn đã tồn tại. Một số mẫu: Factory method, Abstract factory, builder, prototype, singleton

2- Structural design patterns:

Trình bày cách lắp ráp các đối tượng và classes vào trong cấu trúc lớp hơn, trong khi vẫn giữ được cấu trúc flexible và hiệu quả. Một số mẫu: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy

3- Behavioral design pattern:

Liên quan đến các thuật toán và việc phân công trách nhiệm giữa các đối tượng. Một số mẫu: command, iterator, mediator, memento, observer, state, strategy, template method, visitor

3. Một số mẫu design patterns

1- Factory Method (aka: Virtual Constructor)

Factory Method thuộc nhóm creational design pattern, cung cấp interface cho creating objects trong 1 superclass, cho phép các subclasses để thay đổi loại đối tượng vừa được khởi tạo.

Problem:
Ứng dụng quản lý logistics phiên bản đầu tiên chỉ quản lý vận chuyển bằng xe tải, nên phần lớn code sẽ nằm trong Truck class.
Sau một thời gian, ứng dụng của bạn trở nên phổ biến hơn. Vào một ngày công ty nhận một chục yêu cầu từ các công ty vận tải biển vào trong hệ thống của bạn. Hiện tại, hầu hết code của bạn được ghép nối với class Truck. Việc thêm Ships vào
ứng dụng sẽ yêu cầu thực hiện thay đổi đối với toàn bộ codebase. Bạn sẽ nhận ra phải thay đổi với các điều kiện chuyển đổi hành vi của ứng dụng tùy thuộc vào class vận chuyển
Solution:
Factory method pattern sẽ hỗ trợ thay thế các đối tượng construction và gọi tới các phương thức factory đặc biệt. Đối tượng trả về là thường sẽ refer đến các "product"
Trong ví dụ này mình sẽ khởi tạo 1 interface Transport có phương thức deliver() tuy nhiên deliver() trong Transport không được implement thay vào đó sẽ return về các class kế thừa từ interface trên. Cả Truck và Ship class nên được implement Transport interface, sẽ khai báo phương thức deliver. Tương ứng với từng class khơi tạo sẽ có các phương thức khác nhau: Truck sẽ vận chuyển trên đất liền trong thùng còn Ship sẽ vận chuyển trên biển và trong container.
Pros:
Bạn tránh được sự kết hợp chặt chẽ giữa người tạo và các sản phẩm cụ thể.
Nguyên tắc trách nhiệm đơn lẻ. Bạn có thể di chuyển mã tạo sản phẩm vào một nơi trong chương trình, giúp mã dễ hỗ trợ hơn.
Nguyên tắc mở/đóng. Bạn có thể giới thiệu các loại sản phẩm mới vào chương trình mà không làm hỏng mã máy khách hiện có.
Cons:
Mã có thể trở nên phức tạp hơn vì bạn cần giới thiệu nhiều lớp con mới để triển khai mẫu.
Kịch bản tốt nhất là khi bạn giới thiệu mẫu vào hệ thống phân cấp hiện có của các lớp người tạo.

2- Singleton

Singleton thuộc nhóm creational design pattern cho phép chắc chắn 1 class chỉ có 1 instance và cung các điểm kết nối đến instance.

Problem:
Singleton pattern giải quyết được 2 vấn đề cùng lúc, tuy nhiên vi phạm tính single responsibility principle
Đảm bảo class chỉ có 1 khởi tạo: Cho các trường hợp Clients có thể không nhận ra họ đang làm việc với các đối tượng giống nhau trong cùng một thời điểm
Cung cấp điểm truy cập đến khởi tạo đó: Giống như biến toàn cục, Singleton pattern dẫn bạn kết nối đến đối tượng từ bất cứ đâu trong chương trình. Tuy nhiên, nó cũng bảo vệ khởi tạo từ việc ghi đè bởi các code khác.
Solution:
Triển khai Singleton có 2 bước thông thường:
Tạo mặc định constructor private, tránh các đối tượng khác sử dụng toán tử new với Singleton class
Tạo một phương thức creation tĩnh hoạt động như là một constructor. Trong phương thức này sẽ gọi private constructor và lưu nó trong giá trị tĩnh. Các lệnh gọi vào phương thức nào đều trả về đối tượng đã lưu trong cached.
Pros:
Bạn có thể chắc chắn 1 class chỉ có 1 instance.
Bạn có điểm kết nối đến instance đó.
Đối tượng Singleton chỉ khởi tạo khi có yêu cầu lần đầu tiên truy cập.
Cons:
Vi phạm tính single responsibility principle.
Singleton có thể làm xấu design và tăng sự phụ thuộc giữa các components.
Một số môi trường đa luồng cần xử lý Singleton đặc biệt.
Khó tạo các unit test vì test framework dựa vào kế thừa và không thể tạo các data ghi đè các phương thức tĩnh.

3- Adapter

Adapter thuộc structural design pattern cho phép các đối tượng và các interface không tương thích cộng tác với nhau

Problem:
Khi truyền tải dữ liệu từ nhà cung cấp data chứng khoán sang Core hệ thống máy để đưa vào thư viện phân tích thì truyền tải các kiểu dữ liệu khác nhau, tuy nhiên mình(Core hệ thống máy) không thể can thiệp chuyển đổi dữ liệu của các kênh khác (thư viện phân tích, nhà cung cấp)
Solution:
Tại Core hệ thống máy mình sẽ tạo đối tượng đặc biệt là adapter để chuyển đổi các interface của một đối đối tượng thành 1 đối tượng khác mà các kênh (thư viện phân tích, nhà cung cấp) có thể hiểu được
Ví dụ:
XML -> XML -> JSON => XML -> XML và Adapter(convert XML->JSON) -> JSON
Pros:
Nguyên tắc trách nhiệm đơn lẻ. Bạn có thể di chuyển mã tạo sản phẩm vào một nơi trong chương trình, giúp mã dễ hỗ trợ hơn.
Nguyên tắc mở/đóng. Bạn có thể giới thiệu các loại sản phẩm mới vào chương trình mà không làm hỏng mã máy khách hiện có.
Cons:
Độ phức tạp của code tăng. Đôi khi chỉ cần thay đổi lớp dịch vụ sao cho phù hợp với phần còn lại của mã của bạn là đơn giản hơn.

4- Decorator

Decorator thuộc structural design pattern cho phép thêm các hành vi mới của đối tượng bằng cách cho đối tượng vào trong đối tượng đặc biệt wrapper chứa các hành vi mới

Problem:
Giả sử có Notifier class có các class con: SMS Notifier, Facebook Notifier và Slack Notifier. Một số người muốn sử dụng kết hợp gửi thông báo giữa SMS và Facebook, một số lại muốn gửi Slack và SMS, một số gửi thông báo Facebook và Slack,... Bạn phải tìm cách khác về cấu trúc class thông báo để phù hợp hơn
Solution:
Tạo một đối tượng wrapper liên kết với Notifier. Wrapper chứa các phương thức giống với Notifier và ủy thác cho Wrapper tất cả các yêu cầu nhận được. Tuy nhiên, Wrapper nhỏ hơn có thể thay thế kết quả trước hoặc sau khi nó được chuyển đến Wrapper chính
Theo ví dụ, Notifier sẽ có class BaseDecorator và trong phương thức construction sẽ chứa tham số Notifier(wrapper: notifier) và phương thức send(message). Class BaseDecorator sẽ có các class con khác như: SMS Decorator, Facebook Decorator, Slack Decorator với phương thức send(message) khác nhau tương ứng
Pros:
Có thể mở rộng hành vi của đối tượng mà không cần tạo mới một subclass.
Bạn có thể thêm hoặc bớt nhiệm vụ của đối tượng trong thời điểm đang hoạt động.
Bạn có thể kết hợp chung bởi wrapping một đối tượng vào trong nhiều decorators khác nhau.
Bạn có thể chia nhỏ một class lớn thành nhiều biến thể hành vi của các class nhỏ hơn.
Cons:
Rất khó khi xóa 1 wrapper cụ thể từ một ngăn xếp wrappers.
Khó khi khởi tạo một decorator khi hành vi không phụ thuộc vào trật tự của ngăn xếp wrappers.
Khởi tạo ban đầu của các đối tượng trông rất xấu.

5- Observer

Observer thuộc nhóm behavioral design pattern cho phép bạn định nghĩa các cơ chế đăng ký thông báo cho nhiều đối tượng về các events xảy ra mà đối tượng đang quan sát.

Problem:
Ví dụ khách hàng có thể ghé cửa hàng mỗi ngày và kiểm tra sản phẩm mới ra mắt có hàng không. Tuy nhiên khi sản phẩm đang trong quá trình vận chuyển thì hầu hết lần ghé đều vô nghĩa. Mặt khác, cửa hàng có thể gửi email(spam) đến tất cả khách hàng đồng thời về 1 sản phẩm sắp ra mắt. Điều này sẽ giúp một số khách hàng không phải đi đến cửa hàng liên tục. Đồng thời, nó sẽ làm phiền những khách hàng khác không quan tâm đến sản phẩm mới.
Solution:
Khởi tạo các trạng thái đối tượng pub-sub.
Observer pattern hỗ trợ bạn thêm các cơ chế đăng ký cho các pub để các sub đăng ký hoặc hủy đăng ký các luồng event từ pud đó.
Pros:
Nguyên tắc mở/đóng. Bạn có thể giới thiệu các loại sản phẩm mới vào chương trình mà không làm hỏng mã máy khách hiện có.
Bạn có thể thành lập mối quan hệ giữa các đối tượng ngay lập tức
Cons:
Người đăng ký(sub) nhận thông báo theo thứ tự ngẫu nhiên

6- Template Method

Template method thuộc nhóm behavioral design pattern được định nghĩa là bộ khung thuật toán của lớp cha tuy nhiên cho phép các lớp con ghi đè lên các bước thuật toán mà không thay đổi cấu trúc của nó.

Problem:
Giả sử khi bạn xử lý data nhiều file khác nhau(doc, csv, pdf) nhưng sẽ có các bước chung trong quá trình xử lý.
Solution:
Template Method pattern giúp chia nhỏ thuật toán thành loạt các bước, chuyển đổi các bước thành các phương thức và đưa một loạt lệnh gọi phương thức vào trong 1 "template method". Các bước có thể là trừu tượng hoặc là định nghĩa mặc định. Như ví dụ trên ta sẽ tạo một class DataMiner trong đó có các phướng thức là các bước ví dụ như: 1,2,3,4,... thì sẽ có class PDFMiner có các phương thức(2,3), DocMiner(1,2,3), .... và có thể thay đổi khởi tạo các phương thức nhưng không thay đổi các đặc tính của class DataMiner.
Pros:
Bạn có thể cho phép class con ghi đè chỉ một số phần nhất định của thuật toán lớn, khiến chúng ít bị ảnh hưởng bởi những thay đổi xảy ra với các phần khác của thuật toán.
Bạn có thể lấy code trùng lặp vào class cha để không phải khởi tạo trong các class con.
Cons:
Một số class con có thể bị giới hạn bởi khung thuật toán.
Bạn có thể vi phạm nguyên tắc thay thế Liskov bằng cách ngăn chặn triển khai mặc định thông qua class con.
Các phương thức ban đầu khó bảo trì hơn vì có nhiều bước hơn.

7- Strategy

Strategy thuộc nhóm behavioral design pattern được định nghĩa là một gia đình của thuật toán, đẩy từng phương thức vào trong một class mở rộng, và làm các đối tượng có thể hoán đổi được cho nhau

Problem:
Giả sử bạn cần di chuyển ra sân bay thì sẽ có các chiến lược(strategy) khác nhau: Đi xe đạp (0 phí, 30 phút); Đi xe buýt(tốn 2 đồng, 20 phút); Đi xe ô tô(3 đồng, 10 phút)
Solution:
Tạo một interface Strategy là bối cảnh(context) và có các lớp khác nhau tùy theo các chiến lược. Theo cách này, bối cảnh trở nên độc lập với các chiến lược cụ thể, do đó bạn có thể thêm các thuật toán mới hoặc sửa đổi các thuật toán hiện có mà không cần thay đổi code của bối cảnh hoặc các chiến lược khác.
Pros:
Bạn có thể cô lập các chi tiết triển khai của một thuật toán khỏi mã sử dụng thuật toán đó.
Bạn có thể thay thế kế thừa bằng thành phần.
Nguyên tắc Mở/Đóng. Bạn có thể giới thiệu các chiến lược mới mà không cần phải thay đổi ngữ cảnh.
Cons:
Nếu bạn chỉ có một vài thuật toán và chúng hiếm khi thay đổi, thì không có lý do thực sự nào để làm phức tạp chương trình bằng các lớp và interface mới đi kèm với mẫu.
Người dùng phải nhận thức được sự khác biệt giữa các chiến lược để có thể chọn một chiến lược phù hợp.
Rất nhiều ngôn ngữ lập trình hiện đại có hỗ trợ kiểu chức năng cho phép bạn triển khai các phiên bản khác nhau của một thuật toán bên trong một tập hợp các hàm ẩn danh. Sau đó, bạn có thể sử dụng các hàm này chính xác như cách bạn sử dụng các đối tượng chiến lược, nhưng không làm tăng số lượng dòng code của bạn bằng các lớp và giao diện bổ sung.

Happy reading and happy coding!
Nguồn tham khảo:
https://refactoring.guru/design-patterns/creational-patterns
https://lptech.asia/kien-thuc/design-pattern-la-gi-cac-loai-design-pattern-thong-dung
dive-into-design-patterns

Data protection for API of Backend

meotism — Mon, 24 Feb 2025 04:41:37 +0000

Hi, mình là Meotism và hôm nay mình chia sẻ các cách bảo vệ dữ liệu API với tư cách Backend Developer.

Authentication và authorization
Dùng để xác thực người dùng và kiểm tra quyền truy cập người dùng, sử dụng thông qua token
Cơ chế signature
Generation signature để kiểm tra sự thay đổi trong quá trình gửi request, chống thay đổi payload khi truyền tải.
Time mechanism
Cơ chế này dùng để xác thực thời gian request có còn hợp lệ không. Ví dụ tạo một short link tồn tại sau 1 phút thì khi truy cập vào link client sẽ gửi thêm thời gian request đến API để kiểm tra hợp lệ thời điểm truy cập
Rate limits
Cơ chế dùng để hạn chế số lượng requests tới server trong khoảng thời gian cụ thể. Ví dụ: 1000 requests/1 phút
IP access limit
Cơ chế cho phép những clients có IP truy cập đến API server thông qua blacklist và whitelist
encrypt data
Mã hoá dữ liệu khi truyền dữ liệu

That's it! Hi vọng bài viết giúp ít được cho mọi người.

Happy reading and happy coding!

Day before an interview how I prepare

meotism — Sat, 21 Dec 2024 08:35:22 +0000

Chào các bạn, lâu rồi mình không lên bài viết mới. :D Trong thời buổi layoff ngành IT cao, mình xem được một video hay về chuyện chuẩn bị cho buổi phỏng vấn. Video này của tác giả "kproductmanager" mình sẽ take notes lại để các bạn nắm thông tin và lưu lại để mình sử dụng về sau. :D Nội dung như sau:

Nên dành ít nhất 1 tiếng để hiểu những kinh nghiệm mà nhà tuyển dụng đang tìm kiếm, công ty đang xin việc đang làm về mảng gì, giá trị gì cho xã hội và những câu hỏi mà nhà tuyển dụng đã hỏi các ứng viên trước.
Tìm kiếm các thông tin công ty trên blind, glassdoor, exponent, medium, ... Bạn có thể tìm thấy 1 danh sách các câu hỏi của các ứng viên trước và bạn có thể chuẩn bị gây ấn tượng với nhà tuyển dụng.
Sau đó hay xem mô tả chi tiết công việc, xem kỹ các yêu cầu bằng cấp hoặc phần nhiệm vụ công việc để so sánh với khả năng bản thân thì điều gì mình nổi bật hãy cố gắng thuyết trình trong buổi phỏng vấn.
Tìm kiếm các nguyên tắc, văn hoá hoặc giá trị công ty. Các thông tin giúp bạn hiểu công ty đang quan tâm nhân viên thế nào và bạn cố gắng nên đưa những văn hoá, nguyên tắc đó vào trong buổi phỏng vấn nếu có thể.
Cuối cùng, bạn nên viết ra các câu trả lời cho tất cả các câu hỏi dự kiến trong buổi phỏng vấn đồng thời bao gồm các giá trị của công ty và kinh nghiệm làm việc liên quan của bạn.

Và đó là toàn bộ nội dung mà tác giả chia sẻ. Bạn có thể follow tại: https://www.instagram.com/kproductmanager để xem các nội dung khác của anh ấy.

Happy reading and happy coding!

Cơ bản Service Mesh

meotism — Tue, 24 Sep 2024 04:49:25 +0000

Hi, mình là Meotism. Bài viết này sẽ hỗ trợ các bạn hiểu sơ lược về Service Mesh để triển khai mô hình Microservices.
Nội dung bài viết sẽ có 3 phần chính:

Khái niệm
Thành phần trong Service Mesh
Đánh giá Service Mesh

1. Khái niệm Service Mesh

Service Mesh là một layer hạ tầng trung gian trong mô hình Microservices, được sử dụng điều khiển và giám sát toàn bộ các luồng packets (network traffic) được gửi nhận giữa các services (service-to-service)thông qua các APIs bằng các giao thức(HTTP/1.1, HTTP/2, TCP TLS/mTLS).

2. Thành phần trong Service Mesh

Có 2 thành phần chính trong Service Mesh:

Data Plane
Control Plane

Data Plane là vùng triển khai mô hình network là tập hợp các Sidecar Proxy với các Sidecar giám sát các luồng packets gửi nhận của từng instance services. Các ứng dụng Data Plane như: Service Discovery, Load Balancing, Authentication and Authorization, Request Tracing, Traffic Management, Fault Injection, Rate Limiting, Data Observability. Một số Data Plane phổ biến là NGINX, HAProxy,...

Control Plane là trung tâm điều khiển mọi hoạt động của của service-mesh, để thiết lập cấu hình của Sidecar Proxy và thu thập, cung cấp dữ liệu giám sát và phân tích network trong nội bộ Microservices. Một số Control Plane phổ biến như Istio, Consult,...

3. Đánh giá Service Mesh

***** Ưu điểm:

Quản lý và kiểm soát giao tiếp mạng vào/ra giữa các services hiệu quả.
Dễ dàng quan sát, phân tích lỗi liên quan đến network tại các services.
Đinh danh và xác thực các kết nối mạng giữa các instance service.
Triển khai và kiểm thử rất tiện và hiệu quả, chỉ cần config một lần sẽ không cần config những lần sau và không quan tâm đến vấn đề network và giao tiếp giữa các services.

***** Nhược điểm:

Phức tạp hơn khi triển khai ứng dụng theo mô hình Microservices.
Làm tăng độ trễ cho thời gian thực thi ứng dụng & giao tiếp, do request phải đi qua những Sidecar Proxy kiểm tra.
Không định danh được các third-party tích hợp với các services hoặc hệ thống bên ngoài như: routing type — loại định tuyến (static routing, dynamic routing) , transformation mapping — ánh xạ chuyển đổi giữa các giao thức kết nối (HTTP rest <-> gRPC)

Happy Reading and happy Coding!

*References: *

Backend example tutorial

meotism — Fri, 17 Mar 2023 02:06:50 +0000

I. Python tutorial example:

Tạo môi trường ảo (virtual environment)

Step 1: CMD: pip install virtualenv
Step 2: Truy cập vào folder project, CMD: python -m venv env
Step 3: Kích hoạt môi trường ảo, CMD: env\Scripts\activate (Đối với Win), source env/bin/activate (Đối với linux)
Step 4: Cài đặt các thư viện cần thiết cho project <2>
Step 5: Để out môi trường ảo sử dụng CMD: Deactivate

Cài đặt các thư viện cần thiết cho project

Step 1: Tạo tệp txt chứa tên các thư viện cần thiết cho project (thường tên file là requirements.txt)
Step 2: pip install –r requirements.txt
Một số câu lệnh cần thiết:

pip freeze: liệt kê tất cả thư viện đã được cài đặt tại môi trường ảo
pip uninstall –r requirements.txt: xóa tất cả thư viện đã cài được viết trong txt.

II. Flask tutorial example:

Flask là framework chứa nhiều thư viện để triển khai project website hoàn chỉnh.
Sử dụng thư viện flask_restful để tạo ra các apis xử lý và tương tác CRUD dưới DB.
Input các API: Query parameters, Path parameters, Request Body, HTTP methods
Notes: HTTP methods có 4 loại chính GET(lấy dữ liệu), POST(tạo dữ liệu), PUT(sửa dữ liệu), DELETE(xóa dữ liệu). Với method GET thì không nên có Request Body
Ví dụ về Path và Query parameters:

GET/users?limit=5 (trả về 5 giá trị đầu khi query select user)
GET/users/{id} => GET/users/3 (trả về kết quả query select user where id =3) Output các API: JSON, XML, CSV, HTML, text

III. Common Python ORM (SQLalchemy)

ORM là object relational mapping dùng để dễ dàng kết nối giữa đối tượng class map với bảng trong database. Thông qua ORM sẽ hỗ trợ các hàm tương ứng với các câu lệnh query dưới DB.
Đọc thêm tại: ORM Mapped Class Overview — SQLAlchemy 2.0 Documentation

IV. Redis – Cache (Flask queue)

Redis – cache dùng để lưu các dữ liệu tạm thời trong bộ nhớ đệm, ngoài ra còn dùng để xử lý các logic làm tăng hiệu suất và khả năng mở rộng.
Flask queue
Đọc thêm tại: Asynchronous Tasks with Flask and Redis Queue | TestDriven.io

V. APIs Gateway, Service Discovery (Library Kong)

APIs Gateway, service Discovery dùng cho các kiến trúc phần mềm Microservice. Một hệ thống có nhiều servers nên để có thể kết nối truyền dẫn input và output giữa các server nên phải dùng Service Discovery. APIs Gateway dùng để khi apps gọi API sẽ được điều hướng đúng đến API của server chứa API đó thông qua prefix url. Ngoài ra APIs Gateway dùng để authen xác thực khi gọi các APIs.
Đọc thêm tại: Building a geocoding plugin for the Kong Gateway using Python | Kong Inc. (konghq.com)

VI. Docker

Đọc thêm tại: DevOps with Docker | DevOps with Docker
Happy Reading and happy Coding!

ACID Property in Database

meotism — Fri, 10 Feb 2023 05:50:27 +0000

Hầu hết các bạn lập trình viên làm việc với cơ sở dữ liệu đều đã nghe qua các tính chất ACID trong cơ sở dữ liệu. Tại bài viết này mình sẽ giới thiệu lại cho các bạn các tính chất của transaction trong cơ sở dữ liệu quan hệ.
Đầu tiên ACID là viết tắt các chữ cái đầu của Atomicity, Consistency, Isolation, Durability. Để CSDL đúng chuẩn và có độ tin cậy cao thì phải có đủ 4 tính chất này.

Ta đi vào chi tiết từng tính chất:

Atomicity: giao dịch xử lý tất cả hoặc không có gì. Tính chất này đảm bảo có nhiều hơn 1 giao dịch xử lý thì tất cả giao dịch đều được thực hiện hoặc không có giao dịch nào thành công.
Consistency: Tính chất đảm bảo rằng trong phiên giao dịch phải được thực hiện hoàn toàn thì mới ghi nhận xuống CSDL, nếu trong quá trình chạy gặp sự cố thì giao dịch sẽ rollback lại trả về trạng thái ban đầu.
Isolation: Tính chất này đảm bảo các giao dịch sẽ được cô lập không cho cùng truy cập chung vùng nhớ.(Tránh dữ liệu bị ghi đè hoặc tạo dữ liệu không chính xác).
Durability: Tính chất đảm bảo trường hợp CSDL bản mới bị lỗi không thể mở hay sử dụng sẽ khởi động lại các dữ liệu có sẵn trước khi bị lỗi.

Happy Reading and happy Coding!
Nguồn tham khảo: https://blog.sqlauthority.com/2016/04/10/acid-properties-database-interview-question-week-066/

CI / CD pipeline

meotism — Fri, 03 Feb 2023 03:47:24 +0000

CI/CD pipeline là tập hợp các quy trình xây dựng và triển khai sản phẩm ứng dụng.
CI/CD là viết tắt của Continuous Integration(tích hợp liên tục) và Continuous Delivery(triển khai liên tục).
Một số công cụ hỗ trợ CI/CD:
AWS CodePipeline, Github Action, GitLab CI/CD, Jenkins, ...

Trong tích hợp liên tục có các quy trình sau:

Plan, Code, Build, Test Continuous delivery bao gồm các quy trình:
Release, Deploy, Operate Trong đó:
Plan stage: Lên kế hoạch và triển khai bắt đầu dự án.
Code stage: Lập trình viên sẽ code và thay đổi code liên tục trên source code.
Build stage: Code được build và triển khai qua Docker. Nếu xảy ra lỗi thì các lập trình viên phải sửa trước khi qua bước tiếp theo
Test stage: sẽ có unit test và integration test. Việc test thực hiện để đảm bảo chương trình chạy được và đúng với thiết kế ban đầu.
Release stage: Phần code đó đã có thể triển khai cho thành sản phẩm việc chạy thử(release môi trường staging) để các bạn testers kiểm tra các flow chính của chương trình. Nếu có feedback thì các lập trình viên điều chỉnh code phù hợp với nghiệp vụ.
Deploy stage: Sau khi testers kiểm tra xong thì triển khai sản phẩm trên môi trường production cho người dùng cuối sử dụng.
Operate stage: Bảo trì và phát triển hệ thống phần mềm.

Happy Reading and happy Coding!

Web's working principles

meotism — Sat, 27 Aug 2022 03:02:00 +0000

*Web's working principles theo 4 bước:

Client sử dụng giao thức TCP/IP để connect server.
Client gửi package HTTP request đến server.
Server trả về package HTTP response đến client. Nếu trong package request có chứa dynamic scripts, server sẽ chạy scripts trước.
Client nhận package HTTP response và mất kết nối từ server, bắt đầu rendering HTML. URLs: truy cập web pages. DNS: domain name server sẽ lấy địa chỉ IP của host. Các thông báo đến client:

1xx Informational
2xx Success
3xx Redirection
4xx Client Error
5xx Server Error

REST là các phương thức của truyền tải http:
GET - display <=> Read
POST - create <=> Create
PUT - update <=> Update
DELETE - delete <=> Delete

*Policy CORS
Cors là cơ chế hỗ trợ bảo mật cho các đường truyền request-origin và chuyển dữ liệu giữa client và servers. Nó cho phép truy cập across domain khác.

Lỗi CORS policy: Khi bạn call API tới server mà không có header Access-Control-Allow-Origin hoặc giá trị không hợp lệ thì phát sinh lỗi không lấy dữ liệu từ API.
Cách khắc phục: Enable CORS tại server Tại nginx: add_header Access-Control-Allow-Origin *;

Tại web application(ví dụ go):
func enableCors(w http.ResponseWriter) {
(*w).Header().Set("Access-Control-Allow-Origin", "")
}
và thêm enableCors(&w) tại các hàm handler

Docker basic

meotism — Fri, 26 Aug 2022 10:28:15 +0000

------link: https://devopswithdocker.com/part-1/6-docker-hub
-- install docker using the reposity:
Set up the reposity:
sudo apt-get update
sudo apt-get install \
ca-certificates \
curl \
gnupg \
lsb-release
Add Docker's GPG key:
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
Set up the repository:
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
Test installed by running hello-world image:
docker run hello-world
-- About docker image and container:

Docker image chứa source code, thư viện,... và các file cần thiết để chạy 1 ứng dụng.
Docker image chỉ có tính chất read-only nên hay được gọi là snapshots(không thể start hay run image).
Docker container là runtime environment. Mỗi container hoạt động độc lập, 1 container lỗi không làm ảnh hưởng đến container khác và không làm ảnh hưởng đến server.
Image có thể tồn tại mà không cần container, container chạy cần có image trong container đó.

--- From dockerfile to image to container:
=> 3 useful flags. -i (interactive), -t (tty) and -d (detached).
-it allows you to interact with the container by using the command line.
Dockerfile như là bản vẽ thiết kế, trong này hướng dẫn các step cụ thể để docker dựa vào và build ra image.
Để tạo image từ dockerfile dùng câu lệnh docker build, để tạo container từ image sử dụng câu lệnh docker create. Để chạy ứng dụng bạn start các service trong container đó.
-- Some cmd about docker:
Attach container
Ý nghĩa: Attach một màn hình cho phép nhập input và hiển thị output
List images: docker images -a
build image: docker build
run container:docker run
-- Bắt đầu test container:
Để sử dụng docker exec, bắt buộc phải run docker container.
Để run docker container:
cmd: docker run -d --name container-name alpine watch "date >> /var/log/date.log". Câu lệnh sẽ tạo mới 1 docker container. -d để tách container từ cmd để chạy trên nền docker. alpine là image được dùng trong container đó. watch "date>>/var/log/date.log" là cmd muốn chạy trong container đó. đoạn lệnh này sẽ chạy 2 phút/lần và in ra thời gian hiện tại.
-- Tìm tên docker container:
cmd: docker ps -a
-- execute bash command in docker container:
docker run -it /bin/bash(PATH có thể xem qua docker container ls -a)
-- Docker Exec Multiple Commands:
docker exec bash -c "command1 ; command2 ; command3"

--- Docker-compose:
dùng để chạy multi-container cho docker. Sử dụng file YAML để config các service của phần mềm. Cách làm qua 3 bước:

Khai báo app's environment trong Dockerfile.
Khai báo các services cần thiết để chạy application trong file docker-compose.yml
Chạy docker-compose up để start và run app. (Notes: Nếu muốn dừng: # Stop services only docker-compose stop # Stop and remove containers, networks.. docker-compose down # Down and remove volumes docker-compose down --volumes # Down and remove images docker-compose down --rmi ) #Theo dõi Logs từ các dịch vụ docker-compose logs [SERVICES]

-- Volume:
Volume chỉ đơn giản là folder có thể chia sẻ giữa các container hay các máy chủ, và nó đồng bộ với nhau. Ví dụ mình muốn sửa code ở ngoài mà vẫn muốn nó thay đổi trong container, ta phải volume để mount nó.
câu lệnh:
docker volume create [volume_name]
docker volume ls
docker volume inspect volume_name
docker volume rm [volume_name][volume_name1]...(remove)
docker volume prune(remove all)
(ngoài ra còn có backup and restore container sử dụng volume)
-- env (FROM, RUN, ENV, CMD, ENTRYPOINT, ARG)
*FROM ImageName:
*RUN : thực thi các lệnh command line, thường được sử dụng để cài đặt các gói phần mềm.
*CMD : thực hiện lệnh mặc định khi khởi tạo container từ image(có thể ghi đè dòng lệnh)
*ENTRYPOINT : Khá giống CMD đều dùng để thực hiện lệnh khi khởi tạo container nhưng không ghi đè dòng lệnh cũ.
*ARG : chỉ khả dụng trong quá trình build docker image (như trong câu lệnh RUN), không khả dụng sau khi image được tạo ra và các container được khởi động từ nó (ENTRYPOINT, CMD). Bạn cũng có thể sử dụng giá trị ARG để set giá trị ENV để làm việc trong đó.
*ENV : là các giá trị ENV có sẵn trong container, nhưng cũng có các lệnh RUN được chạy trong quá trình Docker build, bắt đầu xuất hiện và khả dùng từ dòng lệnh mà chúng được khai báo.
*COPY : sao chép dữ liệu
*ENV : thiết lập biến môi trường. Ví dụ: PATH
*VOLUME : thêm ổ đĩa, thư mục là volume chia sẻ giữa các container
*USER : tên user
*WORKDIR : thư mục làm việc
*EXPOSE : thiết lập cổng mà container lắng nghe(EXPOSE port 3210)

env Dockerfile: sử dụng file .env
Dùng để thiết lập môi trường sẽ được dùng trong quá trình docker build image. VD env Dockerfile sau câu lệnh build:
"FROM ubuntu
ARG BUILD_TIME =abc
ENV RUN_TIME=123
RUN touch /env.txt
RUN printenv > /env.txt"
Có thể override env Dockerfile qua câu lệnh docker build -t temp --build-arg BUILD_TIME=def . và file docker sẽ có dạng như sau:
"docker run temp cat /env.txt
HOSTNAME=b18b9cafe0e0

RUN_TIME=123

HOME=/root

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
BUILD_TIME=def
PWD=/"
env Docker-compose: sử dụng file docker-compose.yml

-- Different between env Dockerfile and env Docker-compose