สรุป Backend Meetup 2023

งานวันนี้จัดที่ ARIS ครับของกินพร้อม หัวข้อประมาณนี้ครับ

Backend Responsibility

สำหรับ Session นี้เป็น Session แห่ง Keyword ครับ ว่า Backend มีอะไรที่เกี่ยวข้องบ้าง

• ภาษา backend พวก c# / java / php / go / node เป็นต้น
• Database Type
  - Data Model
  ➡ Relational / OLAP
  ➡ NoSQL Document / Key Value / Column Family / Graph
  - Multi-Model Database - ใช้ได้หลาย Data Model ร่วมกัน
  - Vector DB สำหรับ AI เพิ่งเคยได้ยิน

• Business Logic
• เข้าใจ http request / response
• Framework - ช่วยให้งานไวขึ้น มีอะไรกันบ้าง .NET อยู่ท้ายเลย

• เข้าใจ Create Read Update Delete
• เข้าใจเรื่อง Execution Type
  - Sequential Execution / Interleaved Execution / Parallel Execution
  - Synchronous / Asynchronous
  - Concurrent / Parallel
• Version Control: ตอนนี้ก็ Git
• API: SOAP / Rest / gRPC / WebSocket / GraphQL

- GraphQL มาแก้ API เรื่องเดียวกัน แต่มีหลายแบบ web / mobile มี ซ้ำซ้อน graphQL มาให้ Client มาขอ Field ที่ต้องการได้เองเลย
- gRPC - lightweight soap contract

• Protocal: http / http/2 (GRPC ใช้) / quic / udp
• Optimize & Debug: - ระหว่างมา Rewrite Blog มันขึ้น Feed มา เอามาแปะสักหน่อย

• Design Concept: Refactor / Clean Code / TDD

• Architecture
  - Monolith / Microservice
  - Modular / Layer
  Note: Enterprise Architecture องค์กรใหญ่จะใช้กัน โดยจะเป็น IT Blue Print บอกว่ามีอะไรบ้าง ลงที่ไหนได้ เวลาทำจริงต้องคุยกับ Solution Architecture จะได้รู้ควรอยู่ที่ไหน เพราะที่เจอบ่อยๆ Vendor + Business OK แต่ ไม่คุยกับ IT
  เอาจริงๆ บ ผมทำอยู่ชอบท่านี้นะ Vendor + Business OK แล้วดันให้ Golive เลย แต่ภาระมาคนทำงานที่ต้องมา Re-work
• Data Structure Array Queue List Stack
• Database Design
  - Master Data / Transactional Data / Master-Detail / De-normalize (Reporting / Analytic)
  - Hierarchy / Graph
  - Streaming / Replica
  Note: ผมฟังแล้วคิดว่าน่าจะพวก Streamlined Object Modeling อาจจะผิดก็ได้นะ
• App workload Pattern
  - Simple - General Purpose
  - Multi-Tenants - App เดียวกัน Run บน Enviroment เดียวกัน แต่ปรับบางอย่างให้มีความ Unique พวก Theme / Logo
  - Real-Time App
  - High Volume CRUD
  - Data warehouse
• Scaling Vertical (เพิ่ม Spec) / horizontal (เพิ่ม Instance) ถ้าเลือกแบบ horizontal วิธีการ Implement ไม่เหมือนกับ Vertical ในการทำ app
• Testing - Unit Test / Integration Test / API Test
• API Management

สรุป อาจจะไม่ต้องมารู้ทั้งหมดก็ได้

- ไม่ได้จำเป็นต้องเลือกใช้ทุกอย่าง ตามบริบทที่เจอ
- แล้วตอนลงมือทำ ไม่แตะหมด อาจจะแบ่งตาม Role / Responsibility ในองค์กร

สิ่งที่สำคัญ: การเก็บองค์ความรู้ (Business Domain) ที่ตัว Backend ขมวด และจัดไว้ มันที่มูลค่าทางธุรกิจ ซึ่งหลายทีจะประสบปัญหาในการดูแล เพราะ คนออก เป็นต้น

Slide: BackEnd Resposibilities

เรื่อง log เรื่องเล็กเรื่องไม่ log เรื่องใหญ่

ที่มาของ log: มาจาก ship’s log ที่ใช่่คำนวณความเร็วเรือ/การเส้นทางในการเดินทาง พอนานเข้าเอามาปรับใช้เรื่อง IT โดยตัว log เรื่องง่ายๆ แต่ทำปวดหัว ตอนที่ต้องมาหาสาเหตุ

Is Logging a requirement?
Ans: ไม่ แต่ต้องมีหลักฐานตอนทำงาน เอาไว้สืบคดี แต่ถ้าเยอะไปก็ไม่ดี

Choose the Right Log Level (Ref: What is Debug Logging? (crowdstrike.com))

• DEBUG ใช้สำหรับตอน Dev อยากรู้ค่าอะไร ที่หลุดประจำ console.log มาตรวจการทำงาน ทำ test แทนไหม //ผมเองก็เคย
• INFO regular operation
• WARN เตือนอะไรบางอย่าง เช่น กลุ่ม system instability / connectivity issues เป็นต้น
• ERROR runtime issues
• FATAL generally result in the shutdown บอกก่อนตาย

ส่วนตัว ผมไม่เคยใช้ WARN/FATAL เลย จับเข้า Error 555

Log ที่ดีทำอย่างไร

• Key เขียนให้มันบอก ว่ามันมีมา เพื่ออะไร / หาว่าใครต้องการใช้มัน
• Log ควรบอกตำแหน่งที่มีน Error จริงๆ
  - Speaker มียกตัวอย่าง จริง Error อยู่ที่ API A แต่ออกมาแล้วเป็น XML ตัวที่ใช้ ดัก Parse JSON เลยกลายเป็น Error ซ่อน Error
  - ที่ผมเจอ เรื่อง Exception พอมา Rewrite Blog อีกที เพิ่มนึกได้ T__T ลืมแชร์ เขียนไม่ดีมันซ้อนมิด และบอกผิดจุด
• เคสไหนที่ควรลง log หรือ ไปใช้ metric แทน พวก warn ย้ายไปใช้ Metric แทนไหม ? เพราะ Logging มากไปก็ไม่ดี เปลืองเงิน ถ้าย้ายไปใช้ Cloud
  ถ้าคุม Cost ลองดู Cloud Logging cost management best practices | Google Cloud Blog

Common mistake

• Ignoring important logs (Error without log)
  - เช่น บอกเลข order แต่เขียนได้ตอน dev แหละ ตอนหาจริง มันจะหายาก เพราะมีข้อมูลที่ไม่จำเป็นเยอะ
• Use Fatal in libraries ตัว Library ที่เราใช้บอกว่าจัดการ Log Level ได้ไม่ดี จริงๆมันไม่ได้พัง แต่บอกว่ามันพัง เลยทำให้ตัว App เข้าใจผิด หรือไม่ Log เกิดความจำเป็นไป เสียเงินเพิ่ม
• Logging at the wrong level - ตามหัวข้อ Choose the Right Log Level
• Useless message - มีแต่ไม่สื่อ ทำให้ยากตอนดูเคสจริงๆ
• Sensitive Information ตาม PDPA / GDPR บางข้อมูลไม่ควรเขียนลง เช่น พวก PII/ Financial / Health / Authentication Credentials (Log user pass ลงไป อันนี้ผิดนะ) / Compliance Data / Personal Communications (Chat ส่วนตัว) / Biometric เป็นต้น

ถ้า microservice มาดู 10 Rules to Microservice Logging. This article is about the 10 most… | by Stephan Niedermeier | Medium

Production Log ควรมีอะไร > Error / warn ควรไปใช้แทน metric / info ที่จำเป็น และใครต้องการใช้มัน

Slide: https://pallat.github.io/#/

Art of Maintaining Simplicity

- What is simplicity ?

• Simplicity vs Complex
  - Simplicity เรียบง่าย ตรงไปตรงมา
  - Complex ใช้เวลานาน ยากในการหาข้อสรุป ถ้าเป็น Code ต้อง Refactor แล้ว
• Complex vs Advance
  - Complex งง ไม่เป็นระเบียบ / เผื่ออนาคตจนเกินไป
  - Advance พัฒนาจนเหมาะกับสถาการ์ในอนาคตระดับนึง / เรียนรู้และเก่งได้

- Factor

Code: ตรงบริบท ตรงตาม business ตามผู้ใช้

• บริบท ตัวอย่างตัวแปร i j k หรือ comment
• อยู่กับปัจจุบัน ไม่เผื่ออนาคตเกินไป คนที่มาดูต่อเข้าใจยาก
• Functional Programming

Architecture:

• อยู่กับโจทย์ ปัญหา และทำ Architecture และตอบให้ได้ว่าทำไปทำไม โดยแนะทำแบบ Evolutionary Architecture / Just Enough Architecture
• จะรู้ไงว่า Architecture มันพอแล้ว
  - โจทย์ ทำไปทำไม
  - Architecture Fitness Function พวก Test Coverage / DORA Metrices / Monitoring ...

Practices:

• Programmer - Code
• Engineer - คิดถึงความยั่งยืน / cost / หาเหตุผลว่าทำไปทำไม
• Practice
  - TDD - พอทำแล้ว จะได้รู้ interface friendly กับการใช้ไหม
  - Continuous Integration จะได้ลด long lived branch ยิ่งนาน ยิ่งมี source of truth
  - Continuous Deployment ยิ่งนาน ยิ่งน่ากลัว เพิ่มความถี่ได้ ลดความเสี่ยงลง
  - Continuous Delivery (แยก release) blue green canary
  - Other: feature flag / pair programming / monitoring

Planning & Prioritization:

• งานยาก เข้าใจ business แตกงายย่อยได้
• Link ความสัมพันธ์ กับรอบข้าง จัดการ Dependency ได้

Stakeholder Management: - วาง vison ร่วมกันสร้าง value มากกว่า idea

Psychological safety: - free to share ให้กล้าถามแสดง idea จะได้เข้าใจตรงกัน / empthay / safe

Key Takeaway: Start Simple + Continuous Improvement

Slide: Art of maintaining Simplicity

ท้าย Session มีคุยเรื่อง

• ชื่อตัวแปร ถ้ายาวๆจะทำยังไง มีหลายแบบ ให้จาก Business เลย / คุยเพื่อศัพท์กลาง และแจ้งทีม
• Lib ชื่อซ้ำ ทำยังไง แก้โดย เพิ่ม Prefix / ทำ Function ครอบ (Design Pattern - adapter)

Reference

• Backend Day Meetup | Eventpop | Eventpop
• Live: https://www.facebook.com/ARISEBYINFINITAS/videos/708133674258795/