یک ایده برای هوشمندتر شدن کاربردهای ایجکسی

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

بنده یه ایده ای دارم که بنظرم میتونه مفید باشه و شکل ایجکسی این کاربردها رو هوشمندتر بکنه.

میتونیم برای درخواستهای ایجکس مورد نظر یک تایمر هم بذاریم و مثلا در برنامه تشخیص بدیم که پاسخ عملیات ایجکسی که در جریان هست بیش از حد به تاخیر افتاده (مثلا بعد از 30 ثانیه تکلیفش مشخص نشده و هنوز درحالت انتظار باقی مونده) و بعد اون درخواست قبلی رو Abort کنیم و یک درخواست جدید بفرستیم.

میتونیم این جریانات رو یه جوری به کاربر هم نشون بدیم. مثلا تصویر لودینگ متوقف بشه و دوباره استارت بشه و یه پیام موقت و کوتاه هم به شکلی نشون میدیم که کاربر رو متوجه میکنه که برنامه داره بصورت هوشمند چه کاری انجام میده (دوباره تلاش میکنه). البته احتمالا باید تعداد این تلاشها رو به تعداد مشخصی محدود کنیم و در نهایت اگر برنامه موفق به دریافت پاسخ نشد، Retry ها خاتمه یافته و یه پیام خطا داده بشه یا در محل مورد نظر بجای محتوایی که قرار بوده دریافت بشه درج بشه.

تنها چیزی که منو به شک وا میداره اینه که شاید این روش از بعضی نظرها اصولی نباشه، چون بصورت طبیعی ممکنه به عللی منجمله بار سنگین سرور، دریافت پاسخ خیلی زیادتر از حد معمول طول بکشه. البته فکر میکنم 30 ثانیه زمان قابل قبولی باشه.
ضمنا اینکه مرورگرها خودشون Timeout ندارن هم شک برانگیزه. ولی فکر میکنم بتونیم این مسئله رو با این دلیل توجیه بکنیم که تصمیم این امر بر عهدهء برنامه نویس هست که باید تشخیص بده عملیات مورد نظر از نظر ماهیت و اهمیت طوری هست که وجود یک Timeout براش مشکل ساز نباشه یا خیر. چون واقعا در بعضی موارد احتمالا نباید هیچ دخالتی کرد و سرخود درخواست مجدد فرستاد یا درخواست رو Abort کرد و این رفتار ممکنه سایدافکت های مضری داشته باشه.
ضمنا نمونه های کاربرد این روش رو در سایتها و نرم افزارهای معتبر زیاد ندیدم، اما فکر کنم یه جاهایی هم دیده باشم! دقیقا یادم نیست. حالا اینم خودش سواله که چرا کمتر سایتی این روش رو اعمال کرده. البته ممکنه این امر بخاطر سرعت و کیفیت بالاتر ارتباطات اینترنتی اونا بوده باشه که به ندرت دچار وضعیت ها و خطاهایی میشن که برای ما نامعمول نیستن.

3 دیدگاه در “یک ایده برای هوشمندتر شدن کاربردهای ایجکسی

  1. قضیه فراتر از هوشمند کردن هستش
    برای یک سایتی که طراحی میکردم برای کاربران باید برای هر درخواست در کمترین زمان پاسخ میرسید در کل برای یک درخواست سه حالت ممکن بود اتفاق بی افته
    1- به سرور نمیرسید
    2- به سرور میرسید ولی نتیجه به کلاینت نمیرسید
    3- همه چی به خوبی خوشی تموم میشد و جواب می رسید به کلاینت

    برای بند سوم که همه چی خوش و خرم بود عالی بود ولی بند های 1و2 چی ؟
    مثل همیشه از کادر لودینک استفاده کرده بودم اومدم و هر درخواستی که با آژاکس ارسال میشه رو واسش تایمر درست کردم یعنی هر چندتا درخواست هم که با هم اجرا بشه مشکلی نبود (کاربر روی مثلا 5 تا دکمه کیلک کنه یعنی 5 درخواست ارسال بشه هر کدوم مجزا تایمر داشتن ) حالا برای هر درخواست سه بار بازه زمانی دو ثانیه ای رو درست کردم یعنی هر درخواست تا سه مرحله اگه با شکست مواجه میشد پیغام عدم ارسال به کاربران نشون میدادم بعد پنل لودینک رو میبستم

    حالا حساب کن وضعیتی رو که درخواست در بار اول به سرور میرسید ولی برگشت به کلاینت واسه خاطر اتمام زمانش لغو شده بود و درخواست تکرار شده بود تا سه مرحله و یه عالمه مشکل یکی دوتا که نیست هزار تاست

    • بسیار خوب اشاره کردید به ظرافت ها و پیچیدگی های برنامه نویسی. خیلی افراد اغلب نوجوان و کم سواد هستن که تا دوتا کد مینویسن و برنامه درست میکنن اسم خودشون رو میذارن برنامه نویس، و این در حالی است که این ظرافت ها و حالات و سناریوهای مختلف رو اغلب تحلیل و پیاده سازی نمیکنن که هیچ، اصلا به فکرشون هم نمیرسه چون اصولا اینطور سواد و مهارت و بینش رو ندارن!
      برنامه نویسی از نظر کیفیت حقیقتا سطوح مختلف داره و فقط هم بحث تمیزی کد و پیاده سازی شیء گرایی و الگوهای طراحی نیست (چون بعضیا فکر میکنن اینا رو که یاد گرفتن و پیاده کردن دیگه برنامشون درست و حسابیه و اوج مهندسی نرم افزار محسوب میشه!)، بلکه بحث الگوریتم و منطق و اینطور ظرافت ها و اینکه تمام حالات عمده رو پیشبینی و تست و براشون تمهید بکنی هم هست. طرف ایجکس کار میکنه فکر میکنه شاهکار کرده و به خودی خودش یه پیشرفت بزرگیه برای برنامش، غافل از اینکه پیاده سازیها ناقص و مشکل دار هستن و بعضا حتی مشکلاتی رو ایجاد یا تشدید میکنن که در روش کلاسیک و ساده تر قبلی وجود نداشتن و ضمنا بعضی جاها اصلا از نظر اصولش نباید ایجکس کار میشده و همون روش کلاسیک در کل مناسب تر بوده. برای خیلی ها برنامه نویسی با شوخی و بازی و سرهم بندی تفاوت زیادی نداره و مسئله ای تخصصی و جدی نیست، شاید چون هرکس فقط با یک مقدار هوش و سواد میتونه بیاد توی این رشته و کارهای جلوه داری بکنه.

      • برای مورد آخر که فرمودید، چیزی که بالبداهه بنظرم میرسه اینکه یک مشخصه رندوم (البته احتمالا بهتره که یک sequence number رو هم بهش اضافه کنیم برای اطمینان از یکتا بودن و یکسری کاربردهای دیگر احتمالا) برای هر مجموعه درخواستهای یکسانی که ارسال میکنیم داشته باشیم که سمت سرور موقعی که درخواستی دریافت و انجام میشه اون مشخصه موقتا ذخیره میشه و اگر در آینده نزدیک درخواست جدیدی با همون مشخصه وارد شد مشخص میشه که قبلا اون درخواست ارسال و انجام شده، بعدهم پاسخی که به کلاینت ارسال میشه همون پاسخ عادی درخواست موفق میتونه باشه یا اینکه شایدم یه چیزی که به سمت کلاینت اطلاع بده اون درخواست قبلا دریافت و انجام شده. طبیعتا سمت کلاینت هم ما باید باز تمهید بکنیم که اگر چند پاسخ موفق دریافت شد یا یک یا چند پاسخ حاکی از تکراری بودن و قبلا دریافت و انجام شده بودن درخواست دریافت شد این تشخیص داده بشه و درست هندل بشه.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

*

شما می‌توانید از این دستورات HTML استفاده کنید: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>