ساخت داشبورد مالی پایدار با API سرویکس

یک داشبورد مالی در محیط تولید نباید API محافظت شده داده بازار Servix را مستقیم از مرورگر فراخوانی کند. credential و پاسخ احرازشده را پشت بک اند برنامه خود نگه دارید و فقط قرارداد داشبوردی را به هر کاربر واردشده بدهید که مجاز به مشاهده آن است.

این الگو API Key را از bundle مرورگر، URL، HTML عمومی، analytics و گزارش خطای سمت کاربر دور نگه می دارد. همچنین همه بینندگان داشبورد از یک cache مشترک استفاده می کنند و برای هر tab یک حلقه polling جدا سهمیه مصرف نمی شود.

معماری پیشنهادی سمت سرور

Signed-in dashboard
        |
        v
Application backend  <---->  shared cache
        |                        ^
        | single-flight refresh |
        v                        |
Authenticated Servix API -------+

Scheduler / worker ----> history cache ----> chart endpoint
Monitoring <---------- safe status, latency, freshness, cache age

1. مرورگر view داشبورد را با مجوز کاربر از بک اند شما می گیرد و هرگز credential سرویکس را دریافت نمی کند.
2. بک اند cache مشترک را بر اساس endpoint، کد نماد و بازه تاریخ درخواستی می خواند.
3. فقط یک worker کلید منقضی شده cache را تازه می کند. درخواست های هم زمان از داده cached قابل قبول استفاده می کنند یا وضعیت unavailable روشن می گیرند.
4. بک اند پیش از جایگزینی cache و metadata تازگی، پاسخ احرازشده Servix را اعتبارسنجی می کند.
5. مرورگر وضعیت های fresh، stale، loading و unavailable را جدا نمایش می دهد و مقدار ساختگی تولید نمی کند.

انتخاب endpoint احرازشده مناسب

credential را فقط از سرور قابل اعتماد و در هدر X-API-Key ارسال کنید. آن را در secret manager نگه دارید، برای هر محیط کلید جدا داشته باشید، دسترسی مشاهده را محدود کنید، پس از احتمال افشا آن را بچرخانید و هرگز هدر یا بدنه پاسخ احرازشده را در لاگ ننویسید.

اعتبارسنجی تازگی و دسترس پذیری پیش از نمایش

برای هر نماد، فیلدهای providerSupported، latestValueAvailable، businessTime، sourceTime، insertTime، qualityStatus، qualityMessage، availabilityStatus و stale را ارزیابی کنید. وضعیت های FRESH، STALE، MISSING و UNKNOWN را حالت های صریح محصول بدانید.

• مشاهده جاری را فقط پس از عبور schema و وضعیت مورد انتظار از اعتبارسنجی نمایش دهید.
• داده cached مورد تایید را با زمان منبع و برچسب stale نشان دهید و ظاهر تازه به آن ندهید.
• برای داده missing، unknown، malformed یا بدون پوشش، وضعیت unavailable نمایش دهید. صفر، قیمت تخمینی یا مشاهده قدیمی بدون هشدار جایگزین نکنید.
• زمان داده را از زمان پایان HTTP و زمان render شدن component داشبورد جدا نگه دارید.

فرکانس تازه سازی و کنترل هم زمانی

فاصله تازه سازی را بر اساس تحمل واقعی محصول برای تازگی، وضعیت تازگی اعلام شده سرور، ترافیک و محدودیت درخواست روزانه پلن فعال انتخاب کنید. فرکانسی را که محصول نیاز ندارد وعده ندهید. وقتی بیننده ای وجود ندارد، سرعت تازه سازی را کم کنید و هنگام نبود دسترسی یا سهمیه polling را متوقف کنید.

read cache
if cached result is acceptable:
    return cached result

if this process acquires the refresh lock:
    fetch once from Servix
    validate contract and freshness
    replace cache only with an accepted result
    release lock
else:
    return an explicitly stale cached result when policy permits
    otherwise return unavailable

اگر چند instance برنامه cache مشترک دارند، distributed single-flight lock به کار ببرید. lease قفل را محدود کنید، آن را در مسیر finally آزاد کنید و در شکست refresh آخرین cache تاییدشده را نگه دارید. با jitter کوچک زمان بندی، همه نمادها و instanceها را هم زمان تازه نکنید.

برنامه ریزی سهمیه پیش از انتشار

هر درخواست احرازشده زیر مسیر /api/v1/assets پیش از اجرای endpoint یک واحد از سهمیه روزانه رزرو می کند. بنابراین برنامه ظرفیت باید درخواست های تلاش شده، retryها و درخواست هایی را که بعدا در پردازش برنامه یا اعتبارسنجی شکست می خورند نیز حساب کند.

daily request budget =
    refresh cycles × protected endpoint calls per cycle
    + scheduled history jobs
    + cache warmups
    + bounded retry reserve

بودجه درخواست را با ترافیک شبیه تولید اندازه بگیرید، حاشیه عملیاتی نگه دارید و نتیجه را با محدودیت فعلی نمایش داده شده در حساب مقایسه کنید. cache مشترک بک اند و single-flight refresh کنترل بسیار بهتری از polling برای هر کاربر یا tab فراهم می کنند.

retry محدود و fallback شفاف

نمودار تاریخی بدون burst درخواست

تاریخچه را در job بک اند یا هنگام cache miss دریافت کنید، نه از هر مرورگر. بازه بلندتر را به پنجره های پشتیبانی شده تقسیم کنید، پنجره های کامل را بیشتر از پنجره جاری متحرک cache کنید، درخواست های هم پوشان را یکی کنید و نقطه ها را به ترتیب زمان بسازید. timestampها را اعتبارسنجی و رکورد تکراری یا خراب را پیش از رسم حذف کنید.

هنگام انتظار نمودار loading skeleton نشان دهید. اگر فقط بخشی از بازه موجود است، ناقص بودن نمودار را اعلام کنید و روی بخش گمشده خط پیوسته نکشید. payload احرازشده خام را از صفحه عمومی، analytics و telemetry خطای کاربر دور نگه دارید.

monitoring امن اتصال

• درخواست ها را بر اساس operation، دسته امن status و محیط بشمارید.
• latency، نرخ timeout، تعداد retry، cache hit ratio، سن cache و رقابت single-flight lock را اندازه بگیرید.
• برای خطای تکراری احراز هویت، پایان سهمیه، افزایش stale یا unavailable و توقف jobهای refresh هشدار بسازید.
• request ID سرور و metadata غیرحساس تازگی را برای correlation ثبت کنید. API Key یا مقدار بازار را در log، trace، برچسب metric، analytics یا بدنه خطا ننویسید.

چک لیست اجرا و مسیرهای بعدی

• احراز هویت API Key و نمادهای پشتیبانی شده را مرور کنید.
• بین endpointهای قیمت جاری و API تاریخچه مسیر مناسب را انتخاب کنید.
• وضعیت های خطا و محدودیت درخواست را پیاده کنید و واحد و تازگی را با روش شناسی سرویکس هماهنگ کنید.
• از hubهای عمومی نرخ ارز، طلا و سکه برای شناخت پوشش بدون انتشار مشاهده قابل خواندن توسط ماشین استفاده کنید.

ساخت حساب و فعال سازی دسترسی API · مقایسه پلن ها و محدودیت درخواست روزانه