وب مدرن، رابط کاربری و تجربه‌ی وب · فصل ۵ — Error Model، REST، Streaming و Webhook · 51
SSE و Server-to-Client Streaming
می‌تواند «SSE و Server-to-Client Streaming» را در یک feature محدود طراحی/پیاده‌سازی کند و correctness، accessibility یا failure behavior مرتبط را اثبات کند.
خلاصهٔ درس
می‌تواند «SSE و Server-to-Client Streaming» را در یک feature محدود طراحی/پیاده‌سازی کند و correctness، accessibility یا failure behavior مرتبط را اثبات کند.
خروجی این درس
می‌تواند «SSE و Server-to-Client Streaming» را در یک feature محدود طراحی/پیاده‌سازی کند و correctness، accessibility یا failure behavior مرتبط را اثبات کند.
_Locale: fa-IR · Lesson: WEB-007 · Public order: 51_
خروجی و artifact کاری
این درس برای ساختن رکورد evidence تحویل و ادامه SSE نسخه ۱ است: یک artifact تصمیم که مشاهده، فرض، محدودیت و evidence موردنیاز را از هم جدا می‌کند. هدف حفظ یک مدل قابل‌انتقال است، نه حفظ‌کردن نام ابزارها.
می‌تواند «SSE و Server-to-Client Streaming» را در یک feature محدود طراحی/پیاده‌سازی کند و correctness، accessibility یا failure behavior مرتبط را اثبات کند.
مدل مرزی
Server-Sent Events یک stream رویداد از server به client روی HTTP فراهم می‌کند. API ساده آن می‌تواند سؤال‌های اصلی را پنهان کند: identity رویداد، reconnect، replay window، duplicate، buffering واسط، پایان stream و وضعیت UI پس از gap. در این درس SSE به‌عنوان مسیر تحویل قابل‌تکرار بررسی می‌شود، نه تضمین exactly-once.
در هر بخش سه برچسب نگه دارید: «مشاهده‌شده»، «استنباط محدود» و «نیازمند بررسی». اگر evidence در دسترس نیست، نتیجه را unknown ثبت کنید؛ نام ابزار یا pass شدن یک happy path جای evidence را نمی‌گیرد.
1. SSE یک‌طرفه است
server رویداد متنی UTF-8 می‌فرستد و browser دریافت می‌کند. command از client به server همچنان به request HTTP یا transport دیگری نیاز دارد.
2. Framing جزئی از contract است
fieldهای event، id، data و retry line-based هستند و یک خط خالی event را تمام می‌کند. data چندخطی و comment باید آگاهانه مدیریت شوند.
3. Event ID فقط resume protocol را ممکن می‌کند
client می‌تواند آخرین ID دریافتی را هنگام reconnect اعلام کند، اما retention و replay policy باید در server ساخته شود؛ Last-Event-ID به‌تنهایی storage ایجاد نمی‌کند.
4. Duplicate و gap مسئله application هستند
race هنگام reconnect می‌تواند event را تکرار کند یا داده بیرون replay window را از دست بدهد. consumer باید با event ID idempotent باشد و gap جبران‌ناپذیر را صریح نشان دهد.
5. Infrastructure رفتار مشاهده‌شده را تغییر می‌دهد
proxy buffering، connection limit، idle timeout، compression و topology روی latency و عمر stream اثر دارند. pass شدن local رفتار production را ثابت نمی‌کند.
روش پنج‌مرحله‌ای
- event type، event ID پایدار، data schema، heartbeat rule و رفتار پایان stream را تعریف کنید.
- retention window و پاسخ به resume ID قدیمی یا ناشناخته را روشن کنید.
- reducer سمت client را idempotent بسازید؛ ID اعمال‌شده دوباره اثر نگذارد و progress در صورت نیاز monotonic بماند.
- disconnect، duplicate replay، resume قدیمی، frame خراب و slow consumer را عمداً probe کنید.
- evidence local را از فرض deployment درباره buffering، timeout و ظرفیت connection جدا ثبت کنید.
مثال حل‌شده
یک job رویدادهای progress با IDهای 41، 42 و 43 می‌فرستد. client پس از اعمال 41 و 42 قطع می‌شود و با ID 42 reconnect می‌کند. server رویدادهای 42 و 43 را replay می‌کند؛ UI با ID پایدار duplicate 42 را نادیده می‌گیرد و 43 را اعمال می‌کند. probe دوم با ID 10 و پس از پایان replay window انجام می‌شود و server به‌جای تظاهر به continuity، reset-required می‌فرستد. این فقط policy local را اثبات می‌کند.
ماتریس تصمیم و evidence
| موضوع | مرز/مالک | evidence | تصمیم یا محدودیت |
|---|---|---|---|
| stream baseline | IDهای 41 تا 43 | eventهای unique اعمال شدند | framing و reducer local pass |
| reconnect اجباری | replay از 42 | duplicate 42 نادیده گرفته شد | idempotence مشاهده شد |
| resume منقضی | ID بیرون retention | reset-required نمایش یافت | gap پنهان نشد |
| proxy با buffering | در local اجرا نشد | نامعلوم | deployment probe لازم است |
خطاهای محتمل و روش اصلاح
- هم‌معنا دانستن SSE با ارتباط bidirectional
- ادعای exactly-once صرفاً به‌دلیل وجود event ID
- فرض persistence خودکار با Last-Event-ID
- تعمیم تست local به proxy و timeoutهای production
برای هر مورد، ادعا را محدود کنید، یک counterexample بسازید و بنویسید کدام مشاهده می‌تواند آن را تأیید یا رد کند.
تمرین انتقال
سناریو را طوری تغییر دهید که یکی از فرض‌های مثال دیگر برقرار نباشد. بدون کپی‌کردن تصمیم قبلی، رکورد evidence تحویل و ادامه SSE نسخه ۱ را دوباره بسازید؛ سپس تفاوت decision rule و تفاوت دادهٔ ورودی را توضیح دهید.
این درس چه چیزی را ثابت نمی‌کند
این درس certification، تضمین production یا پوشش همه implementationها را ادعا نمی‌کند. نتیجه فقط در مرز سناریو، sourceهای تاریخ‌دار و observationهای ثبت‌شده معتبر است.
خودسنجی
- [ ] آیا مسئولیت‌ها را از نام framework یا tool جدا کرده‌ام؟
- [ ] آیا دست‌کم یک failure probe و نتیجه موردانتظار آن را نوشته‌ام؟
- [ ] آیا fact، inference و design choice از هم مشخص‌اند؟
- [ ] آیا non-claim و evidence گمشده را ثبت کرده‌ام؟
- [ ] آیا transfer را روی context تغییرکرده و بدون پاسخ آماده انجام داده‌ام؟
منابع و مرز تازگی
sourceها در 2026-09-19 طبق Bible منجمدشده مرور شده‌اند. تاریخ review_due یک trigger برای بازبینی نسخه‌ای است؛ هیچ بسته‌ای نباید درجا و بدون نسخه جدید تغییر کند.
- S-WHATWG-SSE — WHATWG HTML defines EventSource, text/event-stream framing and Last-Event-ID behavior. (https://html.spec.whatwg.org/dev/server-sent-events.html; review: 2026-10-17)
- S-MDN-SSE — MDN documents data/id/retry fields and browser reconnection behavior as implementation guidance. (https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events; review: 2026-10-17)
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
WEB-007-S1 retrieval
WEB-007-S2 application
WEB-007-S3 diagnosis
WEB-007-S4 decision
WEB-007-S5 transfer
ملاک‌های ارزیابی (rubric)
| Dimension | Critical | Sufficient evidence |
|---|---|---|
| contract correctness | yes | Implementation and explanation preserve the owned semantic/behavioral contract. |
| evidence quality | yes | Observed evidence, mutation and repair are traceable and do not rely on appearance alone. |
| scope discipline | yes | Adjacent lesson outcomes and unsupported generalizations are explicitly deferred. |
| transfer independence | yes | Changed-context task is solved without decisive scaffold. |
A submission passes only when every critical dimension is sufficient and the learner states missing evidence honestly. AI suggestions are not observed evidence; the learner remains accountable for the final bounded judgment.
منابع و تازگی
مطالعهٔ موارد (case studies)
فایل‌های آزمایشگاه
با fixture امن محلی، رکورد evidence تحویل و ادامه SSE نسخه ۱ را بسازید. ابتدا prediction را بنویسید؛ سپس baseline و failure probeهای اعلام‌شده را ثبت کنید و observation مثبت و منفی را نگه دارید. transfer را بدون کپی تصمیم مثال انجام دهید.
starter عمداً classification یا risk decision نهایی را انتخاب نمی‌کند. evaluate_record.py و evidence template را تکمیل کنید. اجرای python3 ../run_checks.py فقط environment و شکل fileها را بررسی می‌کند و تصمیم محتوایی شما را grade نمی‌کند.
مرز ایمنی: Local non-destructive fixture only; no credentials, privileged host changes or required outbound network.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)