Flag ไปถึงแอปของคุณอย่างไร

แอปของคุณไม่ได้เรียก FortressFlag ทุกครั้งที่ตรวจสอบ flag การอ่าน flag เกิดขึ้น ในเครื่อง — ทันที ปลอดภัยเมื่อออฟไลน์ ไม่มีเครือข่ายอยู่ในเส้นทาง สิ่งที่เดินทางผ่านเครือข่ายคือการ poll เป็นระยะ และ poll นั้นดึง อะไร ขึ้นอยู่กับว่าคุณอยู่บน plane ไหนในสองแบบ

Client plane แอปของคุณได้คำตอบ ไม่ใช่กฎ

SDK สำหรับ iOS Android และเว็บใช้ client plane อุปกรณ์ส่งตัวตนและแท็กของมัน FortressFlag ประเมินกฎการเจาะกลุ่มของคุณ ฝั่งเซิร์ฟเวอร์ แล้วส่งกลับเฉพาะค่าของอุปกรณ์เครื่องนั้น — แผนที่เล็ก ๆ อย่าง {"new-checkout": true, "dark-mode": false}

อุปกรณ์ไม่มีวันได้รับกฎของคุณ นี่ตั้งใจให้เป็นแบบนั้น ด้วยเหตุผลสองชั้น ตรรกะการเจาะกลุ่มของคุณ (“กลุ่มเบต้า” “อุปกรณ์ภายใน”) เป็นเรื่องธุรกิจของคุณ และไม่ควรถูกส่งไปในสิ่งที่ใครก็แกะออกจากไบนารีของแอปได้ — และ payload ยังคงเล็กจิ๋ว

Client plane ยืนยันตัวตนด้วย คีย์ไคลเอนต์ (ffc_…) ซึ่งฝังไปในแอปของคุณและเป็นสาธารณะโดยการออกแบบ — อ่านเพิ่มในคีย์

Server plane แบ็กเอนด์ของคุณได้ ruleset

Go SDK ใช้ server plane เซิร์ฟเวอร์ของคุณดาวน์โหลด ruleset ทั้งชุด สำหรับหนึ่งโปรเจกต์ + หนึ่งสภาพแวดล้อม — ชนิด ค่าเริ่มต้น กฎ พร้อมเซกเมนต์ที่ถูกคลี่ออกเรียบร้อยแล้ว — และประเมิน flag ในโปรเซสของตัวเอง การตรวจสอบ flag คือการเรียกฟังก์ชันบนข้อมูลที่อยู่ในหน่วยความจำอยู่แล้ว ไม่มีการวิ่งข้ามเครือข่ายต่อการตรวจสอบ ไม่มีเวลาหน่วงต่อคำขอ และการ poll หนึ่งครั้งรับใช้ทั้งโปรเซสของคุณไม่ว่ามันจะรับคำขอกี่รายการ

เพราะ ruleset รวมกฎการเจาะกลุ่มของคุณ plane นี้จึงอยู่หลัง คีย์เซิร์ฟเวอร์ (ffs_…) — ความลับของแท้ ที่ต้องดูแลเหมือนรหัสผ่านฐานข้อมูล และเนื่องจากกฎของคุณไปถึงทุกเซิร์ฟเวอร์ที่ถือคีย์นั้น ข้อสรุปที่คุณต้องนำไปใช้เองคือ อย่าใส่ความลับหรือข้อมูลส่วนบุคคลของผู้ใช้ของคุณลงในเงื่อนไขของกฎ

บน plane นี้ไม่มีตัวตนของอุปกรณ์ โค้ดของคุณส่งคีย์บริบทต่อการประเมินหนึ่งครั้ง — user ID, session ID หรืออะไรก็ตามที่คุณใช้จัดกลุ่ม — และเลขคณิตของ rollout ใช้มันแบบเดียวกับที่ client plane ใช้ device ID ทุกประการ อินพุตเดียวกันจึงตกอยู่ในกลุ่มเดียวกันไม่ว่า plane ไหนจะเป็นผู้ประเมิน

การ poll และเหตุผลที่มันถูก

ทั้งสอง plane poll ตามช่วงเวลา และทั้งคู่ใช้ คำขอแบบมีเงื่อนไข การตอบกลับแต่ละครั้งบรรจุตัวตรวจสอบ (ETag) และเมื่อไม่มีอะไรเปลี่ยนตั้งแต่ poll ครั้งก่อน คำตอบคือ “ไม่มีอะไรเปลี่ยน” ขนาดจิ๋ว — ไม่มีเนื้อหา ไม่มีการประเมินซ้ำ สถานะคงตัวของฝูงอุปกรณ์ที่ไม่ได้เปลี่ยน flag คือกระแสของการตรวจสอบที่แทบไม่มีค่าใช้จ่าย

เมื่อคุณ เปลี่ยน อะไรสักอย่างจริง ๆ — การสลับ กฎ กำหนดเวลาที่ทำงาน — poll ครั้งถัดไปจะรับไปเต็ม ๆ ในทางปฏิบัติ การเปลี่ยนแปลงไปถึงอุปกรณ์ไคลเอนต์ที่ออนไลน์ภายในราวหนึ่งนาที

(หมายเหตุด้านการเรียกเก็บเงินหนึ่งข้อ การตอบกลับ “ไม่มีอะไรเปลี่ยน” ยังนับเป็นกิจกรรมสำหรับจำนวนอุปกรณ์ที่ใช้งานรายเดือน — แต่จำไว้ว่าอุปกรณ์นับหนึ่งครั้งต่อเดือนไม่ว่ามันจะ poll บ่อยแค่ไหน)

คำสัญญาเรื่อง fallback

เหตุขัดข้องของ FortressFlag ต้องไม่ทำให้แอปของคุณล่มเด็ดขาด ทุก SDK เก็บค่าล่าสุดที่ได้รับไว้ในแคชในเครื่องที่ทนทาน และ resolve flag ผ่านลำดับขั้นเดียวกัน

1. ค่าล่าสุดที่ได้รับ — แม้จากการรันครั้งก่อน อุปกรณ์ที่ออฟไลน์มาหนึ่งเดือนให้บริการสิ่งที่มันเห็นล่าสุด ความเก่ายังดีกว่าการถดถอยที่ไม่คาดคิด
2. ค่าเริ่มต้นของโค้ดคุณ — ค่า ณ จุดเรียก — เมื่อไม่เคยได้รับอะไรเลย (SDK ฝั่งไคลเอนต์ลงท้ายที่ false สำหรับการอ่านแบบบูลีนที่ไม่มีค่าเริ่มต้น)

ผลที่ตามมาสองข้อที่ควรรู้

• ข้อมูลรับรองที่ถูกเพิกถอนหรือใช้ไม่ได้ไม่ทำให้แอปของคุณพัง SDK ให้บริการแคชต่อไปและพยายามต่อไป ข้อผิดพลาดไม่มีวันไปถึงผู้ใช้ของคุณผ่านการอ่าน flag
• Payload ที่ SDK ตรวจสอบไม่ได้จะถูกปฏิบัติเหมือนไม่มี payload เลย ทุกการตอบกลับถูกลงลายเซ็น และ SDK ตรวจสอบลายเซ็นก่อนที่อะไรจะเปลี่ยน — ดูการลงลายเซ็น payload
• การเก็บถาวร flag คือการปิดมันจริง ๆ เมื่อ flag หายไปจาก payload SDK จะทิ้งมันออกจากค่าปัจจุบัน และ แคชในการ poll เดียวกัน — ภายในราวหนึ่งนาที อุปกรณ์ออนไลน์ทุกที่จะ resolve เป็นค่าเริ่มต้นของโค้ดคุณ แคชไม่มีวันรักษา flag ที่ถูกลบออกไว้ — ถ้ามันทำ การเก็บถาวรก็จะยุติ rollout อย่างถาวรไม่ได้

ไปต่อที่ไหนดี

• คีย์ — ffc_ กับ ffs_ และทำไมตัวหนึ่งเป็นสาธารณะ ส่วนอีกตัวต้องปลุกใครสักคน
• ตัวตนของอุปกรณ์และการเรียกเก็บเงิน — ตัวตนของ client plane คืออะไร
• ติดตั้ง SDK — เลือกแพลตฟอร์มของคุณแล้วปล่อย flag