کانفیگ uWSGI و Nginx روی Socket

قبلا Nginx و uWSGI رو به صورت زیر اجرا کرده بودم که وقتی طول URL زیاد میشد ارور 502 میگرفتم. ارور رو بررسی که کردم دیدم uWSGI ارور میده. و ماکسیموم طول هدر برابر است با 4096 ولی طول این url بیشتره. Nginx رو به صورت زیر اجرا کرده بودم.

nginx.conf

و Dockerfile ای که مربوط به uWSGI هست به صورت زیر اجرا شده بود:

بعد –buffer-size رو بهش اضافه کردم که درست بشه

اما مشکل حل نشد. مشکل اینجا بود که Nginx به صورت پراکسی کل درخواست http رو به uWSGI میفرسته ولی بهتره که درخواست رو خودش پردازش کنه و بعد روی socket درخواست رو به uWSGI بده چون اون پروتکل wsgi رو بهتر و با پرفورمنس بهتر مدیریت میکنه.

قبلا uWSGI هم درخواست های http رو پردازش میکرد هم به عنوان یک application server درخواست های wsgi رو مدیریت میکرد یعنی Nginx یک reverse proxy معمولی بود ولی بهتره که http رو nginx مدیریت کنه و uWSGI به عنوان application server کار کنه که این از نظر پرفورمنس بهتره.

حالا که uWSGI رو روی socker کانفیگ کردیم باید Nginx هم درخواست ها رو روی socket بگیره و بده. بنابراین تنظیمات جدید به صورت زیر میشه:

معماری scrapy

عکس زیر معماری و روند کار scrapy را نشان میدهد. روند کار خیلی جالبه

scrapy بخش های زیر رو داره

spiders: در واقع اون کدی هست که ما میزنیم و میخایم با روش خودمون از سایت های مختلف دیتا بگیریم و به روش خودمون ذخیره کنیم. در واقع اون کدی که ما میزنیم توی بخش spider قرار میگیره. مثلا میگیم از فلان سایت این قسمت های صفحه رو بگیر و ذخیره کن

Engine: موتور scrapy که در واقع مدیریت و ارتباطات بین اجزای مختلف رو داره

ITEM PIPELINES: توی این قسمت میگیم که دیتایی که گرفتیم چه بلایی سرش بیاد. مثلا بگیم توی دیتابیس یا فایل ذخیره بشه. تمیز کردن دیتا و صحت سنجیش هم همینجا انجام میشه.

Downloader: وظیفه گرفتن یک صفحه و دادنش به Engine رو داره

Scheduler: درخواست ها رو توی صف میزاره و سر وقتش به جریان میندازه

Downloader middleware: تمامی درخواست های بین Downloader و Engine از این واسط ها رد میشه. میتونه خیلی از درخواست ها رو بلاک کنه میتونه response ای که میگیره رو به Engine نده و با درخواست های بعد جمع کنه یه جا بده. درخواستهایی که جوابش رو داره دیگه نفرسته و هر چیزی رو کنترل کنه

Spider middleware: بین Engin و Spider میشینه درخواست ها رو به Engine میفرسته و جوابش رو به Spider میده از دوباره Item هایی که از Spider میاد رو بر میگردونه و این وسط تغییرات لازم رو انجام میده.

یه درخواست مسیرهای زیر رو میگذرونه توی Spider. عکس بالا یک Spider رو نشون میده.

اول متد start_request یک آبجکت Request رو به callback ای به اسم pars() میفرسته.

pars() اگه لازم باشه درخواست رو به یه callback دیگه میفرسته و درنهایت Response ای که از Downloader میگیره رو به Item تبدیل میکنه به Item pipline میفرسته که توی دیتابیس ذخیره بهشه یا به Feed Exports مفرسته که توی فایل ذخیره بشه

Base64 ASCII و بایناری و utf-8

ASCII یک استاندارد کدگذاری داده هاست که توی ارتباطات کاربرد داره. این استانداره 128 کاراکتر داره که 95 عدد اون نوشتنی هستند. جدول زیر نشون دهنده کاراکترهای این استاندارد هستند.

بایناری که همان دودویی هست نقش مهمی توی کامپیوتر بازی میکنه خیلی از فایلها محتوای دودویی دارن مثل عکس ویدیو و pdf و هر فایل دیگه ای. علاوه بر همه اینها ممکنه توی یک برنامه یک آبجکت یا داده ساختار هم باشه که طبیعتا این هم دودویی هست. شامل 0 و 1

نکته مهم اینه که خیلی از پروتکل های ارتباطی قابلیت ارسال محتوای دودویی رو ندارن مثل HTTP یا SMTP یعنی اگر یک ایمیل داشته باشید نمیتونید باهاش فایل بایناری بفرستید. ولی ما همه تست کردیم و شده چراکه اون اپلیکیشن ایمیل اول اون فایل دودویی رو به یک استاندارد دیگه تبدیل میکنه و میفرسته و در مقصد هم اون رو دوباره به دودویی تبدیل میکنه و تحویل گیرنده میده. چراکه پروتکل های گفته شده بر اساس تکست کار میکنن محتوایی که قابل پرینت شدن باشن نه دودویی. بنابراین اگر از طریق این پروتکل ها یا توی JSON بخوایم یک محتوای دودویی بفرستیم اول باید به تکست encode بشه بعد توی مقسد از تکست به بایناری decode بشه.

استانداردی که برای این کار استفاده میشه Base64 هست. Base64 مخصوص تبدیل کردن محتوای دودویی به ASCII های قابل چاپ هست. کاراکترهای موجود در Base64 شامل A تا Z به اضافه a تا z به اضافه 0 تا 9 به اضافه + / = هستند. یعنی از 000000 تا 111111 رو شامل میشه بنابراین هر بایت به یک کاراکتر تبدیل میشه و میتونیم روی وب یا پروتکل های دیگه که بر اساس تکست کار میکنن بفرستیم.

آیا فرستادن فایل های بایناری روی وب و تبدیل به Base64 کار خوبیه؟ کاربردهایش چیه؟

1.اتچ کردن فایل بایناری توی ایمیل

2.ارسال فایل بایناری روی HTTP یا SMTP با JSON یا XML

3.ذخیره کردن آبجکتهای کوچیک بایناری توی فایل متنی

4.امبد کردن فایل های بایناری مثل عکس توی HTMLیا CSS

استفاده از Base64 حدود 33 درصد افزایش حجم خواهد داشت بنابراین استفاده از این برای فایل بزرگ توصیه نمیشه. برای فایلهای حجیم باید فایل مستقیم بدون encodeشدن از سرور دانلود شه چرا که تبدیل حجم زیاد خودش از هر نظر هزینه بر هست و فایل حجیم هم نیازی نیست که توی HTML بخوایم امبد کنیم و بهتره لینک دانلود بدیم یا استریم کنیم.

حالا ما میخوایم یک فایل pdf توی بروزر نشون بدیم یک راه حل اینه که فایل رو مستقیم لینک بدیم توی فرانت اند از pdf viewer خود بروزر استفاده کنیم یا iframe چون این دوتا میتونن فایل pdf که بایناری هست رو نشون بدن.

به دلایلی من تصمیم گرفتم که pdf رو هر صفحه شو به یک عکس تبدیل کنم و توی فرانت نشون بدم آیا میتونم این کار رو بکنم. HTTP میتونه فایل بایناری بفرسته ولی توی HTML نمیتونم فایل بایناری امبد کنم اصلا base64 برای همین اختراع شده که تبدیلش کنم به base64 که توی html قرار بگیره.

حالا میتونم توی بک اند تبدلیش کنم به base64 و بفرستم سمت فرانت و فرانت مستقیم بزاره توی html یا میتونم pdf رو به صورت بایناری بفرستم فرانت و اونجا base64 اش کنم و توی فرانت بزارم توی html. ترجیه میدم توی بک اند این کار رو بکنم.

توی کد بالا یک صفحه از pdf رو میگیره و از بایناری تبدیلش میکنه به Base64 که برای امبد شدن توی HTML خوبه و میفرسته و ابته قبل از فرستادن تبدیل میکنه به utf-8 و این دیگه چیه؟

مساله اینجاست که تابع bs64encode فایل بایناری رو به کاراکترهای Base64 تبدیل میکنه ولی هنوز هم تایپش بایناریه یعنی مقدارش کاراکتر base64 ولی وقتی میزنیم print(type(… میبینیم که بایناری هست نوعش مثل b’VGhpcyBpcyBhIGJhc2U2NCBlbmNvZGVkIHN0cmluZw==’

خوب این مشکلش چیه توی پایتون مشکلی پیش نمیاد چون ظاهرا پایتون میخات بفرسته تبدلیش میکنه به str ولی برای اینکه explicit باشیم باید به utf-8 اونو دیکد کنیم که دیگه تایپش هم str بشه. در ضمن بروزر های مدرن هم این تبدیل رو خودشون ظاهرا هوشمندانه انجام میدن.

ببینید ما اول بایناری رو تبدیل کردیم به base64 و همینطور که توی جدول ها معلومه base64 خودش زیرمجموعه ASCII هست و از طرفی خود ASCII زیرمتجموعه UTF-8 هست بنابراین توی این کیس مشکل خاصی هم پیش نمیاد. ولی اگر تبدیل برعکس باشه ممکنه مشکل ایجاد بشه.

حالا که همه چی اوکی هست چرا نهایتا باید تبدیل کنیم به utf-8 وقتی که خود بروزر و پایتون می فهمند که string هستن.

1.باید Explicit باشیم. شاید در آینده مشکلی پیش بیاد بهتره مستقیم خودمون تبدیل کنیم به utf-8 که تبدیل به string بشه

2.رشته string و utf-8 استاندارد وب هست. وقتی با وب کار میکنیم همیشه تبدیل کنیم به utf-8

3.شاید یک اپلیکیشن یا بروزر صراحتا به string بودن داده گیر بده پس استاندارد وب رو رعایت کنیم

پینوشت خود utf-8 چیه؟

utf-8 استاندارد کد کردن محتوا و بیشترین انطباق رو با unicode داره یعنی خیالمون راحته که اکثر زبانها و کاراکتر های چاپی و غیرچاپی رو شامل میشه. توسط بیشتر از 95 درصد مرورگرها پشتیبانی میشه و Unix هم کاملا باهاش کار میکنه. پس از این به بعد خواستیم داده ای انتقال بدیم بهتره تبدیل کنیم به utf-8.

اگر بایناری بود اول تبدیل کنیم به base64 که از بایناری به محتوای متنی تبدیل بشه بعد تبدیلش کنیم به utf-8 که توی بهترین استاندارد و در type یک رشته string باهاش کار کنیم.

جلوگیری از لاگین همزمان با یک نام کاربری

اگر بخایم یک نام کاربری نتونه همزمان توی دو تا سیستم لاگین کنه باید چیکار کنیم؟ باید یک Middleware بنویسیم که اگر سشن کاربر با سشن ذخیره شده قبلی برابر نبود اون رو پاک کنه و جدید رو بنویسه.

حالا این میدلویر رو باید اضافه کنیم

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

اینکه این کد به درستی کار میکنه کافیه؟

آیا اینکه کد زیر به درستی کار میکنه کافیه؟

تابع بالا به درستی کار میکنه اما با تابع زیر جایگزینش کردم:

توی کد اول از دو فرم استفاده شده اما صرفا جهت رندر شدن توی HTML و از هیچ کدوم از قابلیت های دیگه فرم استفاده نشده. توی فرم هر صحت دیتای هر فیلد بر اساس دیتابیس بررسی میشه و صحت سنجی میشه. هر ارور مرتبطی با کل فرم یا هر کدوم از فیلدها در صورت وجود به کاربر نشون داده میشه. تمامی validation های لازم بعد از صدا زدن تابع is_valid انجام میشه. تمامی این موارد توی کد اول انجام نشده و در کل از فرم جنگو اصلا استفاده نشده. بخاطر همین کد دوم قابل اعتمادتره و قطعا باگهای کمتری دیده خواهد داشت. از طرفی واقعا کد دوم خواناتر و زیباتر هست.

چطور برای دو مدل که با هم ارتباط دارند Form و View بنویسیم

دو فرم که با مدل های آنها با هم ارتباط دارند رو میشه توی یک فرم به شکل زیر ساخت:

view باید به شکل زیر باشه

پر شدن فیلد اتوماتیک توی فرم

توی یک فرم یک فیلد داریم بنام full_name که بر اساس first_name و last_name توی view باید ساخته بشه. برای اینکه بشه توی فرم و view ازش استفاده کرد توی fields مربوط به فرم اونو آوردیم.

چون این فیلد اتوماتیک ساخته میشه نمیخایم توی وب نشون داده بشه بنابراین expert_form.fields['full_name'].widget = forms.HiddenInput() ولی مشکل اینجاست که قبل از اینکه فرم post بشه ارور میگیریم که این فیلد باید پر بشه از طرفی Hidden هست.

راه حل این شد که باید توی __init__ فرم این رو از حالت required خارج کنیم.

بهترین روش استفاده از فرم ها توی جنگو

فرم در جنگو قابلیت های زیادی داره و من توی پروژه های مختلف هر بار چالش هایی داشتم که به مرور متوجه شدم که این قابلیت ها خیلی میتونه کمک کنه.

1.فرض کنید که توی یک فرم از یک مدل ما میخایم که یک فیلد رو نشون کاربر نده و اون رو پنهان کنه برای اون کار باید از HiddenInput استفاده کرد link_form.fields['provider'].widget = forms.HiddenInput()

2.فرض کنید به همون فیلد فرم میخایم یه مقدار اولیه بدیم که دیگه نیاز نباشه کاربر فیلدی رو پر کنه. link_form.initial = {'provider': svc}

3.هر فیلد توی یک فرم یک queryset داره که متونید اون رو تغییر بدید و مثلا یه فیلدش رو کم کنید یا sort کنید. self.fields['provider'].queryset.order_by('name')

4.یکی از نکات مشکلسازی که وجود داره. اگر میخاید فیلدهای یک فرم رو توی view تغییراتی بهش بدید (از اون چیزی که کاربر وارد میکنه) باید اون فیلد رو save کنید و اون instance ساخته شده رو تغییر بدید و بعدش commit کنید. link_instance = link_form.save(commit=False)

5.اگر بخایم مقدار وارد شده توسط کاربر رو بگیریم باید از cleaned_data استفاده کنیم. link_form.cleaned_data['provider'].name

6.توی خود کلاس Form میتونید برای هر فیلد محدودیت هایی ایجاد کنید و در صورت تخطی از اون محدودیت ها ValidationError برگردونید.

Form و View ای که تمامی این موارد رو توش داره رو در کدهای زیر میبینید. هر بار نیاز به زدن چنین فرمهایی بودیم بد نیست یه سری به اینا بزنیم.

و فرم مربوطه

دسترسی به پارامترهای URL از توی Template Django

اگر نیاز شد که به متغیرهای توی URL دسترسی پیدا کنیم، میتونیم ببینیم که توی request چی پیدا میشه. طبیعیه که هر چیزی که توی یک فرم توی مرورگر میبینیم باید توی request پیدا بشه. برای این مورد از request.resolver_match استفاده میکنیم مثل:

چند فرم و یک view در جنگو

توی یه اپلیکیشن یه فایل HTML داریم که سه تا فرم توشه ولی فقط با یه فرم داره رندر میشه. مشکل اینجاست که اینجوری پر از باگه. حتی ممکنه فرم اول رو سابمیت کنی کد فرم بعدی هم اجرا شه در حالی که اصلا لازم نیست هم از نظر performance ای یه کد اضافی داره اجرا میشه هم ممکنه دیتای فرم بعدی رو خراب کنه. برای اینکار به سه تا input فرم ها هر کدوم یه اسم یکتا دادم مثلا:

حالا توی فرم چک میکنیم که این فیلد توی request هست یا نه:

این جوری اگر درخواست POST باشه فقط اون فرمی که سابمیت شده کدش اجرا میشه و لازم هم نیست که برای هر فرم یک view جدا هم بنویسیم.