تا یک ساعت دیگه قسمت دوم + هدیه کتاب 📖
منتظر باشین 🔥

رودمپ تست نویسی قسمت دوم، با QA Lead اکالا 🔬
این ویدئو رو ببین و کتاب تست نویسی رایگان بگیر 📖

توی قسمت دوم از پلی لیست تست‌نویسی، می‌ریم سراغ ادامه‌ی رودمپ؛ این بار تمرکز روی تست‌های non-functional، و کلی تست‌ دیگه که شاید کمتر درباره‌شون شنیده باشی، مثل Spike Test، Soak Test، AB Testing، Snapshot و حتی Failover Database Test.

مباحثی که احتمالا براتون جذابه و صحبت میکنیم:
1. معرفی ابزار هایی برای Performance Test.
2. بررسی فرق Load، Stress، Soak و Spike تست.
3. بررسی تست قناری.
4. تست Smoke چیست؟
5. بررسی هرم تست.
6. بررسی کلی ابزار و مفهوم تست.

🕹 لینک ویدئو: مشاهده ویدئو و شرکت در قرعه کشی

📱 پلی لیست: مشاهده پلی لیست
📱 کانال تلگرام: @hasanxdev
📱 تلگرام رف هاب: @refhubOfficial

😇رودمپ: https://github.com/hasanxdev/Test-Roadmap-For-Developers

تا الان 3 نفر اون قسمتی که آدرس کانال قرعه کشی رو میاریم توی ویدئو رو دیدن و جوین شدن به گروه قرعه کشی ☺️
استقبال کنید در ویدئو های بعدی سعی میکنیم بیشتر کتاب هدیه بدیم بهتون ✌🏻

سوال جالبی از من پرسیده شد جهت افزایش دانش شما عزیزان به اشتراک گذاشتیم ❤️

🤔 سوال توسط amirmohammad Fathollahi پرسیده شد:
من برای api gateway دنبال best practice هستم با ocelot
هرچی ویدیو میبینم صرفا در حد اینه route کنه
ولی راجع به معماری و هندل کردن چندین پروژه حرفی نزدن
اگه کسی منبع خوب یا سمپل کد میشناسه معرفی کنه ممنون میشم
توی معماریش چه کار هایی میکنن چه چیز هایی رو بهش میسپرن
آیا صرفا فقط برای reverse ازش استفاده میکنن یا rate limiting و authentication هم بهش میسپرن
بیشتر سوالم راجع به معماریش هست

💡 جواب:
در واقع API Gateway رو یا باید خودمون پیاده سازی کنیم یا از ابزارهایی مثل Kong استفاده کنیم.
اگر خودمون پیاده سازی کنیم طبیعتاً دسترسی کامل به همه چیز داریم ولی Kong مثلا بهمون یک Dashboardهم میده و شاید در یک سری جاها به اندازه یک API Gateway اختصاصی دست آدم باز نباشه.

حالا وقتی میخواهی خودت پیاده کنی Per Environment باید Config های Routing خودت‌رو داشته باشی یعنی روی Develop با Production باید Configهاشون فرق داشته باشه چونکه آدرس ها در Develop Local و Production قطعا متفاوت هست.
یکی از Best Practiceهایی که معمولا در API Gateway ها در نظر می‌گیرند Code Less می‌کنندش یعنی هیچ کدی داخلش نمی‌گذارند و واقعاً شبیه Gateway عمل میکنه، بدون هیچ Business Logic خاصی.

درباره Rate limit باید بهتون بگم که Trade-off زیاد دارد!
یک موضوع infrastructure ای هست یعنی در لایه Application پیاده نمیشه چون Bottleneck برنامه میشه و اگر مشکل داشته باشه میتونه برنامه بندازه یا کند کنه همچنین میتونه single point of failure باشه.
پیچیدگی Rate Limit زمانی هست که چندین Instance از برنامه ما بالا باشه به همین دلیل Application Layer جای خوبی نیست براش اما اگر برنامه شما اینقدر کوچک هست که یک Instance فقط از API Gateway دارد، بنظرم دوباره فکر کنید آیا واقعاً به microservice نیاز داشتید یا نه!
حالا فرض میکنیم که شما به API Gateway نیاز داشتید و Rate Limit هم قرار هست پیاده کنید بنظر من بهتره در لایه Application خودتون پیاده سازی بشه و اگر واقعاً یک چیز نیاز دارید که خیلی Global باشه و زیرساخت ندارید مثل تیم DevOps بنظرم API Gateway جای خوبی هست

اما در کیس Authentication خیلی Trade-off نداریم!
کنترل رو می‌سپارن به خود Application ها، همان‌طور که گفتم خیلی سعی میشه API Gatewayها Code Less باشن فرض کنیم سرویس A با مدل AModel احراز هویت میشه و سرویس B با مدل BModel و این میتونه در API Gateway پیچیدگی ایجاد کنه و از نظر Separation of Concerns باید API Gateway یک Gateway بمونه واقعاً
به این دلیل که Authentication میتونه خیلی پیچیدگی ایجاد کنه من حداقل ندیدم جایی احراز هویت رو روی Gateway پیاده کنند، ولی این کار نشدنی نیست.
در بعضی از مدل های احراز هویت نیاز هست که Token برای سرویس اصلی که Authentication رو پیاده سازی کرده ارسال بشه و اگر ما در API Gateway احراز هویت رو پیاده سازی کرده باشیم این میتونه باعث بشه API Gateway خودش گلوگاه باشه که درخواست‌ها رو کند کنه و وقتی کندی در سیستم میبینیم نمی‌دانیم سرویس واقعاً مشکل دارد یا API Gateway

اگر نظری دارین در کامنت ها برام بنویسید 👇
Channel: @hasanxdev

فقط امروز تا 12 شب وقت دارید ویدئو رو کامل ببینید و در قرعه کشی شرکت کنید هم یاد بگیرید هم کتاب جایزه ببرین 🥳

فردا شب قرعه کشی انجام میشه با توجه به اینکه تا الان 10 نفر کامل ویدئو رو دیدن شانس شما توی برنده شدن خیلی بالاس

لینک ویدئو: https://youtu.be/61tdLL5sy8I