tnpl.me

codestyle

Config

Config needs restart to be updated, static, stored in file, override by env variable, small number of config

Example: DB config, server listen port, remote host location

Feature flag

Feature flag and settings can be changed at runtime without restart or down time. Both are similar but I want to draw a bold line separate them.

Feature flag is temporary, has to be clean up or removed someday in the future. It is about roll out, release, use context to decide who, when, where, which version to enable which can be apply to users partially, or globally. It is usually controlled by engineers, or technical operation team.

Setting

Setting is permanently. It has been designed to be in the code without creating technical debt.

It likes a feature which has a real user use case for example to adjust behavior of the system.

It should be safe to be uses, changes, enables, disables in numerous times. It should be test throughout.

Any feature flags that has been rolled out and stable, can be transitioned to setting such as kill switch.

Example: Site title, User role & Permission, Look & feel, Content to be shown

Below is a comparison table:

Config Feature flag Setting
When to changes Before start Runtime Runtime
Lifetime Temporary/Permanently Temporary Risky, moderate tested
Safety Very safe, well tested Permanently Safe, well tested
User Engineer/Operator Engineer/Operator Normal user
Affects Global/All users Partial/Global Global/Depends on each feature
Tech Debt Low High Medium
Amount of configurable Low High Medium
Rate of changes Rarely Occationally On demand

#codestyle

Related to Opinionated guide on how to write a log

I would like to write in more detail about where to put log, the benefits, disadvantages, and how to mitigate that.

I want to put a context that we're developing web services, whether public access or internal use. No matter what protocol is used, HTTP with JSON, gRPC, Thrift, etc. I think my guide may adapt to all of these kinds of technology.

So, where to put logs?

Read more...

เคยลองเปิด log message ที่ตัวเองเขียนไหมครับ? รู้สึกอย่างไรกับ log เหล่านั้น? มีประโยชน์ตามที่ต้องการหรือเปล่า? และเมื่อระบบมีปัญหาลองเปิด log message อ่านดูอีกครั้ง คิดว่า log เหล่านั้นให้ประโยชน์กับเราขนาดไหน?

ผมลองใช้เทคนิคเหล่านี้ในการเขียน log มันทำให้ log มีประโยชน์มากขึ้น

1. Use structured log

ส่วนตัวผมแนะนำ log เป็น JSON format เนื่องจากสามารถใส่ข้อมูลชนิดต่างๆ ได้หลากหลาย มีโครงสร้างชัดเจน หากจะใช้ structure แบบอื่นก็ทำได้ ขอให้ parse ข้อมูลใน log ได้ง่าย แต่สิ่งที่ไม่ควรทำคือ log แบบไม่มีโครงสร้างที่ชัดเจน

ตัวอย่าง:

{"timestamp":"2021-04-21T10.30.15.412Z","level":"INFO","message":"Order created","orderId":"ORD1","userId":"U1","subsystem":"SvcName.Package.Class.Method"}
Read more...