จากที่พูดคุยกันเรื่องการออกแบบ serviceว่าแต่ละ service นั้นมักจะมี coupling หรือผูกมัดกับ depedency อื่น ๆ ไม่ว่างทางใดก็ทางหนึ่งดังนั้นเราควรพยายามลด coupling เหล่านั้นลงจาก tight coupling มาเป็น loose หรือ no coupling ไปเลยจะยิ่งดีมิเช่นนั้น อาจจะเกิด Distributed Monolith ขึ้นมาแทนก็ได้
จากหนังสือ Clean Architecture ในบทที่ 1ว่าด้วยเรื่องของการออกแบบและ architectureมีหลายเรื่องที่สะกิดใจและน่าสนใจจึงทำการสรุปไว้นิดหน่อย
อ่านหนังสือเจอเรื่องของ Distributed Monolith !!มักจะมาจากระบบ Monolith ที่มีขนาดใหญ่และซับซ้อนก็เลยไปดูว่า มันเป็นมาอย่างไรเมื่อรู้และเข้าใจ ก็ถึงบางอ้อกันเลยทีเดียวเพราะว่าเจอเยอะมาก ๆ
เป็นคำถามที่น่าสนใจสำหรับการพัฒนา service ที่ดีนั้นควร monitor อะไรบ้างหรืออาจจะเรียกว่า observable serviceเพื่อช่วยให้เราดูการทำงาน ใช้งานต่าง ๆ ของ serviceตลอดจนช่วยให้ง่ายต่อการ detect และแก้ไขปัญหาได้รวดเร็วมากยิ่งขึ้นรวมทั้งยังสามารถนำไปทำงานแบบ automate ได้อีกด้วย
จาก Refcard เรื่อง Getting Started With Observability for Distributed Systemsทำการอธิบายเรื่องต่าง ๆ เกี่ยวกับ Distributed System หรือ ระบบแบบกระจายว่า มันคืออะไร มีข้อดีและข้อเสียอย่างไร จะดูแลรักษา และดูเรื่อง observability อย่างไร เช่น log, tracing และ metric เป็นต้น แต่สิ่งหนึ่งที่น่าสนใจคือ Distributed System มีประโยชน์อย่างไรในเชิง businessโดยทำการสรุปด้วยภาพนี้
ไป review ดูการทำงานของการเขียน SQL statement ใน Databaseพบว่ามีสิ่งที่น่าสนใจ หรือ ปัญหานั่นเอง ประกอบไปด้วย ทำการ update เสมอ ไม่ว่าจะมีข้อมูลตามเงื่อนไขหรือไม่ ทำการ query ข้อมูลบ่อยเกินไป ส่งผลให้ database มีการทำงานมากผิดปกติคำถามคือ จะแก้ไขหรือลดการใช้งาน database อย่างไร
สำหรับการเก็บข้อมูลรูปแบบ JSON ใน PostgreSQL นั้นก่อนหน้านี้จะเก็บใน type JSONซึ่งการจัดเก็บก็คือ type text นั่นเอง จะเหมาะสำหรับเก็บข้อมูล JSON ที่มีรูปแบบที่ถูกต้องไว้และไม่ต้องการการทำ index ของข้อมูลที่จัดเก็บทำให้เพิ่มข้อมูลได้อย่างรวดเร็วโดย use case ที่เหมาะสมคือ log การใช้งานต่าง ๆ หรือพวก history ต่าง ๆ
เพิ่งเห็นว่าทาง supabase ทำการ open-sourceproject ชื่อว่า pg_graphql ออกมาซึ่งเป็น extension สำหรับการเพิ่ม GraphQL เข้าไปใน PostgreSQL กันไปเลยแต่ยังเป็น pre-alpha version นะครับโดยความสามารถที่มีประกอบไปด้วย
หลังจากอ่านบทความเรื่อง Guide: How To Detect and Mitigate the Log4Shell Vulnerability (CVE-2021-44228)เกี่ยวกับแนวทางการแก้ไขปัญหาของ Log4j version 2 แล้วมีสิ่งที่น่าสนใจคือ คำแนะนำต่าง ๆ หรือบทความในโลก online มีทั้งผิดและล้าสมัย มีคำแนะนำที่ไม่ดีมากมาย เช่น แก้ไขด้วย WAF หรือ ทำการ upgrade version ของ Java หรือ update format ของ log เป็นต้น
จากบทความเรื่อง Scaling productivity on microservices at Lyft (Part 2): Optimizing for fast local developmentทำการอธิบายถึงการเพิ่ม productivity ของการพัฒนาระบบของ Lyftซึ่งมีโครงสร้างของระบบตามแนวคิด Microservicesว่าทำอย่างไร จึงจะช่วยให้ developer experience ดีขึ้นโดยสามารถทำงานได้บนเครื่อง local หรือเครื่องนักพัฒนาแต่ละคนให้ได้มากที่สุดมาดูกันว่าทางทีมของ Lift ทำอย่างไรกันบ้าง
