طراحی میکروسرویس در جنگو بخش اول شروع کار با جنگو

در این بخش پوشش میدیم جنگو رو و مناسب کسانی است که به تازگی باهاش آشنا شده‌اند موارد پوششی این بخش شامل ساختار جنگو، چرخه حیات درخواست (request) و پاسخ (response) ، دستورات پایه‌ای جنگو، کنترل جریان در اپلیکیشن، هندلرهای جنگو، ساخت فایلهای url و view و دانش template ها، بعد از اتمام این بخش شما توانایی دانستن دانشی از web application ها و ساخت rest api با جنگو و چگونه ارائه دادن درخواست داده و باز گرداندن پاسخ بدست خواهید آورد

نکته: دانش پایتونی در خصوص موارد بالا الزامی می‌باشد

جنگو یک فریمورک وب اپلیکیشن بر پایه پایتون هستش، که هر کاربری میتواند با استفاده از آن اقدام به ساخت web application و web api کند، که بسیار ساختارمند و سریعتر از برخی دیگر از زبانهای سمت وب(داخل کتاب اشاره به php دارد) می باشد، که میتوان پروژه‌های بزرگ را با آن به راحتی پیاده سازی کرد.جنگو، از پایتون پشتیبانی می‌کند به این معنا که میتوان از تمامی ویژگی‌های پایتون مانند objects, class, polymorphism, list, tuple, dictionary و ... را در آن استفاده کرد

پایه جنگو، پایتون می‌باشد پس تمامی سینتکس کدها و تلفیق آنها شبیه پایتون است ،جنگو از یک مفسر (interpreter) داخلی برای اجرای فایل‌ها استفاده می‌کند، ما میتونیم بصورت جداگانه اجرا کنیم فایلهای جنگو رو در یک مفسر پایتونی


ما بارها درباره طراحی الگوی ساختار MVC شنیده‌ایم، که فرم کامل آن به شکل Model, View, Controller می‌باشد این الگوی طراحی برنامه رو به سه قسمت منطقی تقسیم میکند، هر قسمت عملکرد متفاوتی دارد و هر قسمت ساخته شده برای هندل کردن جنبه‌هایی از یک برنامه هستش، به این معنا که تمام ساختار یک پروژه توزیع شده در سه بخش قرار میگیرد، جنگو هم تقریبا شبیه با MVC و از الگوی طراحی(معماری) MVT View استفاده میکند، طراحی پروژه‌های جنگو تقسیم شده در سه بخش هستش که ساخت وهندل کردن ساختار پروژه‌های بزرگ رو راحت میکنه

مفهوم MVT

بخش M مورد استفاده برای هندل کردن داده ،مانند واکشی داده از دیتابیس و انتقال داده به ویو

بخش V ویو مربوطه به ذخیره سازی و منطق تجاری(business logic) پروژه که مرتبط هست با مدل و تملیپت

بخش T فرانت، به این معنا که صفحات html و GUI مرتبط با کار، میان داخل بخش تمپلیت، که با مدل و ویو بطور مستقل ارتباط میگیرد

بیایید یک نگاه به ساختار جنگو بیاندازیم

├── first_django_project
│   ├── asgi.py
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

1 directory, 6 files

هنگام آغاز پروژه با جنگو یک دایرکتوری با نام مدنظر ما ساخته میشود که داخل آن یک دایرکتوری دیگر با همان نام وجود دارد و جنگو بصورت اتومات یکسری فایل با نام‌های مختلف نیز برای ما میسازد ،مانند نمونه بالا که برای اجرای پروژه حیاتی میباشند، هر فایل مفهوم متفاوت و عملکرد خاصی دارد، بیایید اندکی بررسی کنیم

در پایتون متد init (dunder init) که یک سازنده کلاس هستش، این احرا میشه وقتی یک نمونه کلاس ساخته میشه، در جنگو هم فایل (dunder init.py) در مرحله اول اجرا میشود،ما میتونیم ازین فایل استفاده کنیم برای مثال ما بسته‌هایی رو داریم که در جاهای مختلف ازش استفاده میکنیم کافیه در این فایل واردش کنیم


فایل settings.py
این فایل اصلی است، ازین جهت بسیار حائز اهمیت می‌باشد که تمامی پیکربندی‌های پروژه در آن نوشته میشود

ALLOWED_HOSTS = []

در این لیست ما میتونیم یک یا چندین ip بنویسیم که میخواهیم پروژه به آن گوش بدهد، اگر چیزی ننویسیم پیش فرض localhost رو مدنظر میگیره

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

در این لیست ما میتونیم برنامه‌های خودمون رو تعریف کنیم داخل این لیست و خود جنگو برخی برنامه‌های پیش فرض را هم داخل آن جا داده که برای اجرای پروژه ذکر شده

ROOT_URLCONF = 'first_django_project.urls'

این متغیر مسیر پیش فرض url روت پروژه رو معرفی میکنه

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

این دیکشنری برای اتصال به دیتابیس مهم است و شامل اطلاعات درایور و پارامترهای ارتباطی با دیتابیس می باشد، که جنگو بصورت پیش فرض sqlite3 رو تنظیم میکنه


فایل دیگر ما که urls.py است، ما در این فایل URRهای پروژه رو تعریف میکنیم، که مورد استفاده برای کاربران پروژه جهت پردازش request و response هستش

لینک وبسایت

#microservice
#django

@code_crafters

در این فایل است که با ویو ارتباط میگیریم و تمامی urlهای پروژه که توسط جنگو و برای کاربران تعریف شده است قرار دارد


فایل uwsgi.py وقتی استفاده میشه که ما مستقر میکنیم پروژه رو بر روی سرور برنامه، در جنگو این فایل ایجاد میکنه تنظیمات رو برای استقرار، با استفاده از این فایل وب سرور میتونه به راحتی با اپلیکیشن جنگو‌ ارتباط برقرار کند،

فایل manage.py ازین جهت حائز اهمیت است که جنگو با کمک این فایل پروژه رو استارت میکنه (به زبان دیگر setup پروژه جنگو با این فایل اجرا میشه) اگر دقت کنید پوشه داخلی (first_django_priject) با این فایل در یک سطح ساخته میشوند که نشان از اهمیت یکسان آن دو هست


برای اجرای پروژه جنگویی ما دو گام پیش رو داریم:

ابتدا با دستور 
django-admin startproject first_project_django
که ساختار اولیه پیش فرض ساخته میشود با نام مدنظر ما (first_project_django)

سپس با دستور 
python manage.py runserver 
پروژه روی ip مدنظر ما (اگر در قسمت allow host تعریف شده باشد ip مدنظر ما و در غیر این صورت در ip پیشفرض 127.0.0.1) بر روی پورت پیش فرض 8000 اجرا خواهد شد همچینین میتونیم با پاس دادن پورت مدنظرمون به دستور پورت پیشفرض رو هم تغییر داد 
python manage.py runserver 8001

اگر در مرورگر خود 127.0.0.1:8000 رو وارد کنیم خروجی رو میبینیم


جریان احرایی برنامه جنگویی
با دستور بالا پروژه جنگویی اجرا میشه

۱-درون فایل manage.py، فایل settings.py ذکر شده که به معنای فایل تنظیمات است
۲- درون فایل settings بخش‌های کدی وجود دارد که خط به خط هر بخش اجرا میشود

۱- ماژول‌های ضروری جهت اجرا رو import میکند

۲- مسیر پروژه رو میسازه

۳-در بخش allow host هر مقدار ip رو‌تعریف میکنیم و سپس پروژه در اون ip خاص استارت خواهد شد

۴-در بخش بعدی تمامی appها لود شده که ما در install app تعریف کرده‌ایم

۵-در بخش بعدی مجموعه URLها رو در بخش روت تعریف میکند، که تعریف شده داخل فایل urls.py 

۶-حالاجستجو برای پوشه templateها شروع میشه که چون تعریف نشده مقدار خالی رو تنظیم میکنه

۷-در بخش دیتابیس اجرا میکنه کد رو و با دیتابیس پروژه ارتباط برقرار میکند

۳-پس از اجرا کردن فایل settings سرور استارت زده و در ip با پورت مدنظر ما در دسترس قرار میگیرد


جنگو‌ چگونه درخواست‌هارو‌هندل میکنه
۱-متغیر ROOT_URLCONF از فایل settings رو لود میکن
۲-این منغییر را بصورت گلوبال تنظیم کرده و سپس مسیر را برای یافتن URLهای تعریف شده توسط کاربر مشخص می کند

۳-هر url تعریف شده به یک تابع نسبت داده شده است

urlpatterns = [
    path('admin/', admin.site.urls),
]

۴-که بعد از کاما مشخص شده و هنگام صدا زدن تابع مدنظر رو اجرا میکنه


شرح مراحل کنترل جریان درخواست:

وقتی URL توسط کاربر نهایی صدا زده می‌شود، درخواست از طریق سرور جنگو منتقل میشه و بررسی میکنه که URL خواسته شده در فایل موجود هست یا نه

در مرحله اول درخواست کاربر بصورت شی HttpRequest ارسال میشه، سپس برای ارسال پاسخ از یک شی HttpResponse استفاده میشه
اگر url درخواستی کاربر وجود داشته باشد تابع نسبت داده شده آن در فایل views.py فراخوانده میشود

صفحات خطای پیش فرض:

خطای 400: اگر کاربر ارسال کنه درخواستی رو و به خطا بخوره جنگو مقدار تابع django.views.defaults.bad_request()
صدا میزنه و یک استثنا پیش فرض با وضعیت رو برمیگردونه

خطای 403:اگر کاربر ارسال کنه درخواستی و اجازه دسترسی نداشته باشد مقدار تابع  django.views.defaults.permission_denied()
صدا زده میشود

خطای 404: اگر کاربر ارسال کنه درخواستی رو و با خطای نبود URL مواجه بشه مقدار django.views.defaults.page_not_found()
صدا زده میشه

خطای 500: اگر کاربر ارسال کنه درخواستی رو و با خطای سرور مواجه بشه مقدار تابع django.views.defaults.server_error()
صدا زده میشه

درخواست HTTP:
یک پکت از داده هاست که معمولا استفاده میشه برای اشتراک اطلاعات از یک ماشین به دیگری و معمولا فرمت داده‌های آن باینری هستش، به زبان ساده تر ارتباط بین کلاینت و سرور است، برای این انتقال نیاز به روش‌هایی داریم که در زیر مطرح میکنیم:

مقدار get
این روش برای دریافت داده از طریق ارسال داده‌های مرتبط به سرور استفاهده میشه، دارای طول محدود داده جهت ارسال است، اطلاعات و داده‌ها در url قابل مشاهده است و انتقال داده آن ناامن است

مقدار post
برای ارسال داده‌های حساس کاربر به سرور مناسب است، داده ها در url قابل مشاهده نیست و امنتر از get می‌باشد و محدودیت ارسال اطلاعات آن نیز بیشتر

لینک وبسایت
#microservice
#django

@code_crafters

مقدار connect
این درخواست یک خط لوله (pipline) را به سرور ایجاد خواهد کرد و بعد از احرازهویت و سنجش آن را تایید و ایجاد میکند

مقدار put
این روش شبیه به مقدار post است دقیقا با این تفاوت که اگه بارها اون رو تکرار کنیم یک مقدار یکسان به ما خواهد داد در حالیکه در post ممکن مقادیر متفاوت ایجاد گردد، این روش مناسب ایجاد یا تغییر منابع با آپلود داده است

مقدار delete
اگر کاربر بخواهد هر داده‌ای رو حذف از دیتابیس این بهترین روش است


ایجاد فایل ویو و پیکربندی url پیش تعریف کاربر
طبق الگوی MVT ،بیزنس لاجیک در فایل view تعریف میشه، و این فایل توسط URLها صدا زده میشه و همچین رابط بین مدل و تمپلیت است، پوشه داخلی و در کنار settings.py یک فایل با نام views.py میسازیم

from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, world. this is my first URL.")

ابتدا ماژول مدنظر خودمون رو ایمپورت کرده و سپس تابع ویوی مدنظر خودمون رو میسازیم و در فایل urls.py اون رو صدا میزنیم

from . import views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('polls/', views.index),
]

پایه لاگ‌ها و در دسترس بودن نوع لاگ
توسعه دهندگان سعی میکنن تمام رخ‌دادهای خطا رو در پروژه مدیریتی کنن اما گاهیی ممکن هست رخ‌دادی رو فراموش یا مدیریت نکنند، برای گرفتن جریان برنامه و اون خطا پایتون ماژولی دارد با نام logger که مصرف داخلی جنگو نیز دارد، لاگر پایتون به چهار قسمت تبدیل شده:
بخش loggers:
هنگام تعریف لاگرها باید در اولین نقطه برنامه و بالاترین قرار بگیرند، لاگرها انواع مختلفی دارند که داده‌هارو بطور متفاوتی مدیریت میکنند، در خصوص آنها بیشتر صحبت خواهیم کرد

بخش Handler:
هندلرهارو میتونیم موتور لاگرها بدونیم، که تعریف میکنند رفتار هر پیغام رو، که بستکی به نوع لاگر دارد، ما میتونیم پیغام‌ها یا ارورهارو بعنوان یک پیام به لاگر پاس دهیم، میتونیم لاگ‌هارو در کنسول چاپ یا در فایلهای مجزا در دسترس قرار دهیم

بخش Filters:
فیلتر ارائه‌دهنده‌ای است که کنترل اضافی را بر روی رکوردهای گزارش ارائه می‌کند که از لاگر به کنترل‌کننده منتقل می‌شود

بخش Formatters:
ما تعریف میکنیم فرمتی رو برای رکوردها، که چاپ کنن متن رو، همچنین میتونیم فرمت مدنظر خودمون رو تعریف کنیم برای چاپ لاگ‌ها


انواع لاگ‌ها

DEBUG:
استفاده میشه برای چاپ و نوشتن اطلاعات اندکی درباره سیستم و برنامه

INFO:
استفاده میشه برای گرفتن اطلاعاتی از سیستم

WARNING:
بیشتر استفاده میشه بوسیله سیستم ارائه دهنده اطلاعات برای مشکلات جزئی که در سیستم رخ میده

ERROR:
این لاکر اطلاعات مهم را میگیرد، که روی میدن در سیستم و برنامه

CRITICAL:
برای چاپ پیامی استفاده میشه که سیستم یا برنامه دارای مشکل جزئی است

اجرای لاگر
لاگرها به سادگی در جنگو اجرا میشن، در بخش اول ما پیکربندی میکنیم فایل settings رو و میسازیم فایل لاگ رو، و اشاره میکنیم نوع لاگ رو در کد

یک نمونه ساده از پیکربندی لاگر

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'file': {
            'level': 'DEBUG',
            'class': 'logging.FileHandler',
            'filename': '/home/debug.log',
        },
    },
    'loggers': {
        'django': {
            'handlers': ['file'],
            'level': 'DEBUG',
            'propagate': True,
        },
    },
}

برای دیدن خروجی و اجرا در برنامه هم بصورت زیر در ویو

import logging

logger = logging.getLogger(name)

logger.debug('this is example of debug logger')
logger.info('this is example of info logger')
logger.warn('this is example of warn logger')
logger.error('this is example of error logger')

و برای تغییر فرمت هم

formatters = {
'f': {'format':
'%(asctime)s %(name)-12s %(levelname)-8s %(message)s'}
},

لینک وبسایت

#microservice
#django

@code_crafters

توسعه API در جنگو

در این قسمت ما شروع میکنیم به پیاده سازی api و یادگرفتن آن در جنگو و پیاده سازی کردنش، api در میکروسرویس جایگاه بسیار حائز اهمیتی دارد

ایده اصلی API
یک api مجموعه‌ای ازعملیات‌هاست که اجرا میشه و خروجی تولید میکنه، پایه‌ترین آن انتقال داده بر روی شبکه از یک نقطه به نقطه دیگر است، برای مثال ما یک برنامه‌موبایلی داریم که کاربر با وارد کردن اطلاعات خود میتواند داخل اپ ما ثبتنام و لاگین کند و یا از طریق سایر برنامه‌های دیگر با وارد کردن اطلاعات برای مثال به داشبورد خودش منتقل بشه، از دیگر موارد مهم در api میتوان به هندل کردن موارد امنیتی اشاره کرد، امنیت داده، کنترل سخت افزار و نرم افزار و ....، امروزه با استفاده از api میتوانیم یک بخش کد یا برنامه رو توسعه داده و در جاهای مورد نیاز دیگر از آن استفاده کرد

ساخت یک اپ در جنگو
اجازه بدید یک اپ جنگو بسازیم جهت نگهداری کدها، کارایی اپ جنگو در مناسب بودن هندل کردن بخش‌های جداگانه هر ماژول است، اگر در ماژولی تغییر ایجاد کنیم نباید روی دیگر ماژول‌ها تاثیر گذار باشد، ما کار رو در یک پروژه جدید با نام django_project01 پیش میبریم و یک اپ داخل آن با نام first_app میسازیم

django-admin startproject django_project01

cd django_project01

python manage.py startapp first_app

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

.
├── django_poject01
│   ├── asgi.py
│   ├── __init__.py
│   ├── pycache
│   │   ├── init.cpython-310.pyc
│   │   └── settings.cpython-310.pyc
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── first_app
│   ├── admin.py
│   ├── apps.py
│   ├── __init__.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
└── manage.py

4 directories, 15 files

جنگو برای اپ نیز یکسری فایل تولید میکند(که از بررسی آن سر باز میزنیم، اپ را در فایل settings به لیست install apps اضافه میکنیم)

ما میتونیم ویوهای خودمون رو به دو شکل CBV و FBV در فایل views.py بنویسیم


برای قسمت fbv(function base view)

from django.http import HttpResponse
import json


def get_method_example(request):
    userid = request.GET.get('userid', '')
    resp = {}
    if userid:
        resp['status'] = 'Success'
        resp['status_code'] = '200'
        resp['data'] = userid
        return HttpResponse(json.dumps(resp), content_type='application/json')
    
@csrf_exempt
def get_method_example(request):
    userid = request.POST.get('userid', '')
    resp = {}
    if userid:
        resp['status'] = 'Success'
        resp['status_code'] = '200'
        resp['data'] = userid
        return HttpResponse(json.dumps(resp), content_type='application/json')

دو تابع درست کرده‌ایم یکی برای درخواست‌های GET و یکی برای درخواست‌های POST، حال با اضافه کردن دوتا url به پروژه میتوانیم هر دو ویو رو با برنامه postman تست کنیم


برای قسمت cbv(class base view)

from django.http import HttpResponse
import json
from django.views import View

class ClassBaseViewExample(View):
    def get(self, request):
        userid = request.GET.get('userid', '')
        resp = {}
        if userid:
            resp['status'] = 'Success'
            resp['status_code'] = '200'
            resp['data'] = userid
            return HttpResponse(json.dumps(resp), content_type='application/json')

    def post(self, request):
        userid = request.POST.get('userid', '')
        resp = {}
        if userid:
            resp['status'] = 'Success'
            resp['status_code'] = '200'
            resp['data'] = userid
            return HttpResponse(json.dumps(resp), content_type='application/json')

برای cbv یک کلاس با دو تابع نوشته شده که مشابه کدهای قبلی می باشد و اکنون با نوشتن یک urlبرای آن میتوان هر دوتابع این ویو رو در postman تست کرد


برای مثال در قسمت url اصلی پروژه

from django.contrib import admin
from django.urls import path
from first_app import views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('get_method/', views.get_method_example),
    path('post_method/', views.post_method_example),
    path('cbv_method/', views.ClassBaseViewExample.as_view()),
]

لینک وبسایت

#microservice
#django

@code_crafters

🎙قسمت سوم سری پادکست‌های توسعه چابک (Agile)

✅ توی این قسمت یک مقدار توی مفهوم اجایل و مفهوم پروژه بیشتر صحبت کردیم و یکم بیشتر با اسکرام آشنا شدیم.

✅ توی قسمت بعد می‌ریم سراغ توضیحات بیشتر راجب فریمورک اسکرام.

☁️ ممنون می‌شم نظراتتون رو بشنوم که استفاده کنیم.

آیدی بنده:
@AminAlih47

#agile

@code_crafters

من بارها و بارها گفتم که در زندگی نه خواسته شما و نه اهداف شما از اهمیت بسیار کمتری برخوردارن، چیزی که در موفقیت بشدت تاثیر گذار هست میزان استفاده شما از فرصت‌هاییست که براتون رخ میده، این مسئله در تمام زندگی شما صدق میکنه براتون و قرار نیست همیشه براتون فرصت بیافته که از بعضی‌هاشون به هر دلیلی چشم پوشی کنید

احساس خوشبختی انسان هم در گرو این هست که حس موفقیت روزانه و بلند مدت داشته باشه یا نه ،پس خودتون رو با میل به خواسته‌های غیرمعقول و فانتزی‌های احمقانه در ذهنتون درگیر نکنید

#free

@code_crafters

طراحی میکروسرویس با جنگو بخش دوم میکروسرویس چیست

میکروسرویس ها روندهای جدید توسعه هستند. امروزه شرکت ها معماری میکروسرویس را برای توسعه پروژه ترجیح می دهند. این یک راه حل بسیار فشرده برای یک پروژه است. مدیریت ماژول را آسان می کند و اجرای پروژه را سریعتر می کند. همچنین به توسعه سریعتر پروژه کمک می کند. این دلایل ذکر شده و بسیاری موارد دیگر باعث تقاضای میکروسرویس می شود.

معرفی میکروسرویس
برای میکروسرویس تعریف خاصی وجود ندارد و ممکن هست هر فرد به شکلی آنرا تعریف کند اما دو تعریف عمده آن به شکل زیر است
۱-میکروسرویس‌ها، سرویس‌های کوچک و مستقلی هستند که باهم کار میکنند
۲-میکروسرویس‌ها معماری سرویس گرا با زمینه‌های محدود هستند،بطور مستقل و با یک جزء دیگر در داخل ارتباط برقرار میکنند، این معماری بسیار خودکار و و سیستم‌های نرم افزاری را تکامل می‌دهد

بیایید ببینیم که آیا از معماری سرویس گرا (SOA) آگاه هستید یا خیر، سپس ماژولار بودن پروژه و ارتباط از طریق پیام را نیز می دانید. اگر از شیوه های DevOps آگاه هستید، در مورد استقرار خودکار نیز می دانید. هر دو بیشتر به رویکرد میکروسرویس نزدیک هستند.


سه اصل مهم در طراحی میکروسرویس‌ها:
۱-از میکروسرویس برای استقرار سیستم‌ها و پروژه‌های بزرگ استفاده کنید: برای تمام مقیاس‌های پروژه استفاده از میکروسرویس اشتباه است، بلکه مناسب پروژه‌های بزرگ است که مدیریت آن چالش برانگیز باشد، اما خود این موضوع هم سردرگم کننده هستش اینکه کدوم پروژه رو کوچیک، متوسط، بزرگ بنامیم، منتها اگر سیستم ما دارای بار بالایی از درخواست کاربر است و نیاز به مقیاس پذیری دارد، میتوانیم رویکرد میکروسرویس رو پیاده سازی کنیم(در حجم تعداد اپ نیز تعداد اپ بالا میتواند به این منزله باشد)

۲-این رویکرد هدف‌محور است: مهم نیست که وقتی با مشکل مواجه می‌شویم، باید از رویکرد میکروسرویس پیروی کنیم. امروزه بسیاری از متخصصان برای توسعه پروژه به این رویکرد اشاره می کنند زیرا هدف آنها تنها ارائه راه حل مشکلات نیست، همچنین برای دید بیشتر و حفظ سهولت در ماژول ها، چنین معماری را در عمل به کار می گیرند.

۳-قابلیت تعویض ماژول ها: در پروژه های توسعه یافته قبلی که با رویکرد میکروسرویس ساخته نشده اند، امکان تغییر هر جزء از پروژه کمتر است. قبل از تغییر سازنده کامپوننت باید در مورد تغییرات برنامه ریزی کند، وابستگی کد خاصی را پیدا کند، در صورت عدم موفقیت کد به هر دلیلی، مراحل بازگشت را فهرست کند و تاثیر کد را مشخص کند. پس از همه، تغییرات نیاز به انجام عملیات تست واحد و سپس آزمایش ادغام با کل محصول دارند


در برخی سناریوها، پروژه ها بسیار پیچیده هستند یا وابستگی‌های حیاتی شدیدی دارند، در چنین شرایطی در مورد مسائل آینده یا افزایش حجم بار، ما مجبوریم به جای تغییر، اجزا را حفظ کنیم، که این بزرگترین ضرر یک رویکرد است

در میکروسرویس ها، کل پروژه را بر اساس ماژول ها به یک جزء‌های کوچک تقسیم می کنیم. بطوری که امکان تکرارپذیری را بر روی هر جزء فراهم می کند که تعمیر و نگهداری پروژه رو راحتتر میکند

اپلیکیشن‌های میکروسرویس دارای بخش‌های مهم زیر هستند:
● به اندازه های کوچک تقسیم می شوند
● برای برقراری ارتباط نیازمند انتقال پیام هستند
● مقید به زمینه‌ها هستند
● توسعه انها بصورت مستقل هستش
● استقرار هر بخش مستقل هست
● متصل به کنترل کننده مرکزی نیستند
● ساخت ها توسط فرآیندهای خودکار مستقر می شوند

به شکل آرمان گرایانه به میکروسرویس‌ها نگاه نکنید و با این تصور که در دنیای واقعی قابل پیاده سازی نیست، اگر تصور میکنید که میکروسرویس‌ها توسط بانک‌ها، سیستم‌های بیمارستانی و هتلی پیاده سازی میشه سخت در اشتباه هستید هیچکدام از میکروسرویس استفاده نمیکنند بلکه بیشتر توسط شرکت‌های فعال در حوزه محتوای جریانی(stream content) مورد استفاده قرار میگیرد، استفاده و پیاده سازی میکروسرویس یک انتخاب فردی هست و محدود به دامنه‌ای نیست، اما هدف از آن دو مورد تمرکززدایی و استقلال می‌باشد

تمرکززدایی:به این معنی است کل کارهای داخلی پروژه شامل اجرای هر ماژول، مدیریت وظایف و جابجایی کامل پروژه دیگر توسط یک سیستم واحد، مدیریت و کنترل نمیشود

استقلال: به این معنی است که به تیم‌های توسعه خود برای تولید نرم افزار ایمان داشته باشیم

مزیت این دو رویکرد این است که تغییرات در نرم افزار آسانتر و سریعتر میشود و امکان تصمیم گیری سریعتر را فراهم میکند


ادامه در وبسایت

لینک وبسایت


چندتا نکته بگم
بخش دوم و سوم کتاب بشدت پربار و پر از تحربه‌هایی هست که در دنیای واقعی با اون سروکار داریم و درکی از مسائل برامون مشخص نبود، من سعی کردم در حد توان بخش‌های مهم رو برسونم

#microservice
#django

@code_crafters

موقعیت: وقتی پروژه و ایده‌ رو به مهندسین نرم افزار و سنیورهای داخل گروه‌های تلگرام میدی و فکر میکنی با قیمت کم و مدیریت خودت تمومش کردی



#fun

@code_crafters

فصل پنجم کتاب همزمانی

ارتباط بین فرآیندی

ما نمیتونیم همیشه تضمین کنیم که همیشه وظایف همزمان در سیستم مستقل هست، گاهی وقت یک اجرای یک وظیفه وابسته به خروجی وظیفه دیگری است،اگر همچین مسئله‌ای روی بده برنامه باید بداند چه وقتی کار کند، ارتباط بین وظایف بخش جدایی ناپذیر سیستم‌های همزمانی است و اگر نتوانیم این مورد رو هندل کنیم دستاوردی نداشتیم در این فصل به این مسئله میپردازیم


انواع ارتباط
سیستم عامل مکانیزم‌هایی براتون فراهم میکنه تا بتونید در فرآیندها و رشته‌ها امکان ارتباط گرفتن رو ایجاد کنید این مکانیسم رو با نام IPC میشناسیم

( خب IPC مجموعه‌ای از روش‌ها برای تبادل اطلاعات بین چندین فرآیند یا رشته در حال اجرا در یک سیستم عامل است. این فرآیندها می‌توانند در یک یا چند رایانه متصل به هم توسط یک شبکه اجرا شوند.)
خود IPC به معنای ارتباط بین فرآیندی هستش اما این به این معنا نیست که فقط در فرآیند مورد استفاده هست، در واقع هر فرآیند حداقل یک رشته دارد و ارتباط هم فقط توسط رشته ها صورت میگیرد 

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

محبوبترین نوع‌های IPC دو مورد هستند، اشتراک حافظه (shared memory) و ارسال پیام (message passing)


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

اگر دو‌پردازنده در یک رایانه به مکان حافظه فیزیکی یکسانی اشاره داشته باشند یا زمانی که در رشته‌های درون یک برنامه اشیا مشابهی را به اشتراک میگذراند IPC حافظه مشترک یافت میشه کدها در کامنت


اشتراک‌گذاری حافظه مزایا و معایب خودش رو داره

مزایا
این رویکرد سریع‌ترین و کم مصرف ترین ارتباط ممکن رو فراهم میکنه، اگرچه سیستم عامل به تخصیص خافظه مشترک کمک میکمند اما در ارتباط بین وظایف شرکت نمیکند، در این حالت سیستم عامل بطور کامل حذف شده و موجب سرعت بالاتر و کپی داده کمتر میشود
تصور اول در کامنت ها


معایب
لزوما امن‌ترین ارتباط بین وظایف نیست ،سیستم عامل حفاظت از حافظه مشترک را فراهم نمیکند برای مثال ممکن هست دو تسک همزمان بهواهند به حافظه مشترک برای تغییر دادن یا خواندن اقدام کنند، به دلیل این روش بیشتر مستعد خطاست و توسعه دهندگان باید با محافظت از آن مجدد کد بنویسند

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


ارسال پیام
پرکاربردترین مکانیسم که توسط تمامی سیستم‌عامل ها پشتیبانی میشود، هر وظیفه با یک نام منحصر بفرد شناسایی میشود و وظایف با ارسال و دریافت پیام به و از وظایف نامگذاری شده تعامل دارند ،سیستم عامل یک کانال ارتباطی ایجاد میکند و فراخوانی‌های سیستمی مناسبی را برای وظایف در این رویکرد از طریق این کانال را فراهم میکند

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

فلسفه زبان گولنگ اشتراک گذاری حافظه از طریق ارتباط است و با این شعار (از طریق اشتراک حافظه، ارتباط برقرار کنید، بلکه با برقراری ارتباط، حافظه را به اشتراک بگذارید)


حالا درک میکنید چرا میگیم گولنگ، این بچه زاده دوران تایمینگ و کلاک هستش

تکنولوژی‌های زیادی برای این مکانیسم وجود دارد که رایج ترین انها در سیستم‌عامل‌های مدرن شامل لوله‌ها pipes، سوکت‌ها و صف‌های پیام

شاید براتون جالب باشه که بدونید سلری از همین مکانیزم تبادل پیام در بین اجزای خودش استفاده میکنه

ادامه مبحث در وبسایت...

لینک وب‌سایت

#concurrency

@code_crafters

طراحی میکروسرویس با جنگو بخش سوم طراحی سیستم میکروسرویس

یکی از مسایل مهم در میکروسرویس‌ها طراحی درست و دقیق ماژولهای آن است در این بخش در این خصوص صحبت خواهیم کرد، همچنین موضوعات کلیدی مانند نکات مهم برای ایجاد معماری میکروسرویس و توسعه سرویس را پوشش می‌دهیم

رویکرد میکروسرویس
در سطح اولیه توسعه دهندگان زیادی در ساخت سرویس‌ها حضور دارند، اما زمانی که به معماری میکروسرویس روی میاوریم طراحی دقیق سرویس‌ها بصورت جداگانه و بر اساس نیازها جهت توسعه حائز اهمیت هستش، همچنین باید این رو در نظر بگیریم سرویس‌ها چگونه باهم ارتباط میگیرند

اگر برای هر سرویس تصمیم درستی گرفته باشیم میتوانیم رفتار سیستم را تغییر و اصلاح کنیم، کار همزمان بر روی همه سرویس‌ها بسیار سخت می‌باشد

اگر ما از رویکرد مدل‌پایه استفاپه کنیم میتونیم به راحتی مفهوم سازی کرده و راحب سیستم صحبت کنیم

مدل طراحی میکروسرویس به پنج بخش تقسیم میشود
Service, Solution, Process, Organization, Culture

بخش service
طراحی خوب میکروسرویس ها و API های برای سیستم مهم هستند. در یک سیستم میکروسرویس، سرپیس‌ها بلوک‌های ساختمان اتمی را تشکیل می‌دهند که کل ارگانیسم از آن ساخته می‌شود.اگر بتوانیم طراحی، محدوده و مقیاس خدمات خود را تعیین کنیم، می توانیم پیچیدگی را کاهش دهیم و آن را ساده کنیم

بخش solution
این بخش ارائه میده این چنین معماری و راه حلی که برای هر سرویس متفاوت باشد و همچنین نمایی از آینده رو نشون میده. هنگامی که ما میکروسرویس را طراحی می کنیم، باید همیشه نگران هماهنگی ورودی ها و خروجی های چندین سرویس باشیم. سیستم آینده نگر سیستم مطلوب تری را ارائه می دهد. به عنوان مثال، اگر ما روی ویژگی‌های ایمنی و مسیریابی در اجرای سطح اول کار کنیم، می‌توانیم پیچیدگی هر سرویس را کاهش دهیم.

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

بخش organization
سازمان عامل مهمی برای موفقیت میکروسرویس ها است. زیرا هر سازمانی دارای ساختار تیمی و لایه های کاری متفاوتی است. این بر اساس نحوه کار ما بر روی محصول و نحوه ارتباط ما است

بخش culture
فرهنگ نیز عامل مهمی است. این ناملموس است اما همچنین یک عامل مهم برای معماری میکروسرویس ها است. فرهنگ مجموعه‌ای از ارزش‌هاست که بین همه کارکنان سازمان مشترک است. به عبارت ساده، اگر فرهنگ سازمانی ما خوب باشد، آنها از ایده های جدید یا استراتژی های توسعه جدید مانند سرویس خرد استقبال می کنند. با این رویکرد، سازمان بر روی محصولات خود تسلط پیدا می کند و توسط محصولات می تواند بر بازار تأثیر بگذارد.

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

ادامه موضوع در وبسایت ...

لینک وبسایت

#microservice
#django

@code_crafters

انتخاب محل ذخیره سازی تصاویر: فایل سیستم یا پایگاه داده؟

تصمیم گیری در مورد بهترین راه برای ذخیره سازی تصاویر بین Blob (Binary Large Object)در پایگاه داده و فایل سیستم (مانند S3) همیشه بحث برانگیز بوده.

پایگاه داده یا فایل سیستم؟ کدوم بهتره؟

اول از همه، بریم سراغ مزایای هر کدوم:

پایگاه داده:

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

فایل سیستم (مانند S3):

حجم کم و هزینه مناسب: اگه تصاویر زیادی با کیفیت بالا دارید، ذخیره کردنشون تو پایگاه داده باعث میشه بکاپ هاتون خیلی سنگین بشن و هزینه تون بره بالا. در حالی که فایل سیستم ها این مشکل رو ندارن.
دسترسی مستقیم از CDN: با استفاده از CDN می تونید بدون نیاز به طی کردن لایه های برنامه و پایگاه داده، به فایل ها از هر جای دنیا دسترسی داشته باشید. این کار سرعت نمایش تصاویر رو هم بیشتر می کنه.
اشتراک گذاری راحت: اگه نیاز دارید تصاویر رو با افراد یا سرویس های دیگه به اشتراک بذارید، فایل سیستم ها این کار رو خیلی ساده تر می کنن.
سرعت بالا برای استریم: اگه برنامه شما به عملکرد بالایی برای استریم ویدیو یا تصاویر زنده نیاز داره، فایل سیستم ها گزینه مناسب تری هستن.

پس کدوم رو انتخاب کنیم؟

خب، بستگی به نیاز شما داره!

تصاویر کوچیک: اگه تصاویر شما حجم کمی دارن (مثلا چند صد کیلوبایت)، مثلا عکس پروفایل یا مدارک شناسایی، ذخیره کردنشون تو پایگاه داده منطقی تره.
تصاویر بزرگ و به اشتراک گذاری شده: اگه پلتفرمی دارید که کاربرا تصاویر بزرگی رو آپلود و به اشتراک میذارن، بهتره از فایل سیستم استفاده کنید.
آپدیت کم: اگه تصاویر زیاد آپدیت نمی شن و بیشتر جایگزین یا حذف می شن، نیازی به استفاده از ویژگی های ACID پایگاه داده ندارید و فایل سیستم گزینه بهتر و به صرفه تریه.

در نهایت...

هیچ راه حل کاملی وجود نداره و انتخاب بهترین روش به نیازهای شما بستگی داره.

#Database #General
@Code_Crafters

در این پست  قراره تمایز اغلب گیج کننده بین function  و  method  هارو  را بررسی  کنیم🥸
هر دو بلوک های اساسی در  پایتون هستند اما اهداف کمی تفاوت دارد. ما آنها را در کنار هم در قالب جدول با هم مقایسه خواهیم کرد و نمونه های کد واقعی را برای نشان دادن نحوه استفاده از هر کدام ارائه می دهیم. چه مبتدی باشید و چه به دنبال تقویت مهارت های پایتون خود باشید، این تفکیک دقیق به شما درک روشنی از زمان و نحوه استفاده موثر از function  ها و method  ها می دهد.                                                                                                                                                                                                                                                                                   

تابع(functios)در پایتون چیست؟                                                                                                                در پایتون، یک تابع یک بلوک از کد است که برای انجام یک کار خاص طراحی شده است. توابع به تقسیم برنامه ما به قطعات کوچکتر و ماژولار کمک می کنند. با ایجاد برنامه های پیچیده تر، توابع را می توان مجدداً مورد استفاده قرار داد و کد شما را سازماندهی و مدیریت کرد.                                                                                                                                                                                                                           مثالی از یک تابع:

def greet(name):
    return f"Hello, {name}!"

print(greet("ali"))  # Output: Hello, ali!

متد در پایتون چیست؟
متد، به عکس تابع، یک تابع است که به یک شیء مرتبط است. در پایتون، متدها مستقل نیستند و باید بر روی یک شیء یا داخل یک کلاس فراخوانی شوند. متدها به طور ضمنی از یک شیء استفاده می‌کنند که برای آن فراخوانی شده‌اند.
برای درک بهتر به مثال زیر توجه کنید.

class Greeter:
    def __init__(self, name):
        self.name = name
    
    def greet(self):
        return f"Hello, {self.name}!"

g = Greeter("ali")
print(g.greet())  # Output: Hello, ali!

در اینجا، greet یک متد از کلاس Greeter است و بر روی نمونه g از آن کلاس فراخوانی می‌شود.

در ادامه چند مثال عملی رو باهم بررسی میکنیم.
Function:

def factorial(n):
    if n == 0:
        return 1
    else:
        return n * factorial(n-1)

print(factorial(5))  # Output: 120

در اینجا یک تابع ساده برای به دست اوردن فاکتوریل یک عدد داریم.(5!)

Method:

class Car:
    def __init__(self, make, model):
        self.make = make
        self.model = model

    def description(self):
        return f"{self.make} {self.model}"

my_car = Car("Toyota", "Corolla")
print(my_car.description())  # Output: Toyota Corolla

در اینجا تابع description  یک متود است که جزئیات مربوط به یک نمونه خودرو رو نشون میده.


درک تمایز بین توابع و متودها در پایتون برای نوشتن کد واضح و موثر بسیار مهم است. توابع ماژولار بودن و قابلیت استفاده مجدد را ارائه می دهند، در حالی که متود ها ما را قادر می سازند تا رفتارهای درون اشیاء را با رعایت اصول برنامه نویسی شی گرا محصور کنیم. اینکه یک تابع یا یک روش را انتخاب کنید تا حد زیادی به نیازهای خاص برنامه و ترجیحات طراحی شما بستگی دارد. با درک این مفاهیم، ​​می توانید از انعطاف پذیری و استحکام پایتون در پروژه های برنامه نویسی خود استفاده کنید و کد خود را سازماندهی و پویا تر کنید.
در قسمت کامنت ها جدولی رو برای اختلاف بین function و method میتونید مشاهده کنید
منبع

#python

@code_crafters

در این پست  نکات و ترفند های پیشرفته مدل های جنگو رو بررسی خواهیم کرد.🥸
از جمله: ...indexing, custom managers, inheritance

ارث بری مدل ها به شما امکان می دهد یک مدل پایه با اطلاعات رایج ایجاد کنید و آن را در مدل های دیگر گسترش دهید. جنگو از سه نوع model inheritance پشتیبانی می کند:
abstract base classes, multi-table inheritance, and proxy models

Using Abstract Models:
روشی فوق‌العاده برای جمع‌بندی اطلاعات و رفتار مشترک هستند. برای یک abstract model هیچ جدولی در دیتابیس نشان داده نمی شود. در عوض، فیلدها و متدهای آن توسط زیر کلاس‌ها به ارث می‌رسند.
Example:

class BaseProfile(models.Model):
    bio = models.TextField()
    avatar = models.ImageField(upload_to='avatars/')

    class Meta:
        abstract = True

class StudentProfile(BaseProfile):
    graduation_year = models.IntegerField()

class TeacherProfile(BaseProfile):
    office = models.CharField(max_length=100)

در اینجا BaseProfile مانند یک الگو عمل میکند.StudentProfile, TeacherProfile هر دو دارای فیلد های bio , avatar خواهند بود اما هر کدام در جدول های پایگاه داده خودشان ذخیره میشوند.


Custom Managers :
در جنگو Custom Managers به شما این امکان را می دهند که عملکردهای سطح جدول را به مدل های جنگو خود اضافه کنید. آنها را می توان برای کپسوله کردن و عملیات های crud پیچیده و ارائه یک API تمیزتر برای مدل استفاده کرد.
Example:

class ActiveProfileManager(models.Manager):
    def get_queryset(self):
        return super().get_queryset().filter(deleted=False)

class Profile(models.Model):
    name = models.CharField(max_length=100)
    deleted = models.BooleanField(default=False)
    objects = models.Manager()  # The default manager.
    active_objects = ActiveProfileManager()  # Our custom manager.

# Usage:
active_profiles = Profile.active_objects.all()

این custom manager تمامی query های شمارو بر اساس "deleted" فیلتر میکند.


Models Migrations:
مدیریت Migrations مدل‌ها
در جنگو migrations به شما امکان می‌دهند تا طی زمان، طرح پایگاه داده خود را تکامل دهید. مدیریت مناسب migrations ها برای حفظ یک پروژه سالم بسیار حیاتی است.

توصیه‌ها:

برنامه‌ریزی migrations خود: سعی کنید هنگام امکان‌پذیر بودن، مهاجرت‌ها را ترکیب کنید و آن‌ها را به کنترل نسخه منتقل کنید.
تست migrations: همیشه migrations را به صورت محلی و در محیط استیجینگ تست کنید، قبل از اعمال آن‌ها در محیط تولید.
استفاده از دستور makemigrations برای تولید فایل‌های migrations
استفاده از دستور migrate برای اعمال migrations ها
استفاده از دستور sqlmigrate برای پیش‌نمایش دستور sql


Proxy Models:
مدل‌های پروکسی برای تغییر رفتار یک مدل، مانند defualt ordering یا custom manager بدون ایجاد جدول پایگاه داده جدید استفاده می‌شوند.

Example:

class OrderedProfile(Profile):
    class Meta:
        proxy = True
        ordering = ['name']

# Usage:
ordered_profiles = OrderedProfile.objects.all()

این پروکسی مدل تمامی profile هارا بر اساس نام نشان میدهد.

Multi-table Inheritance:
این نوع وراثت زمانی استفاده می شود که هر مدل در سلسله مراتب به تنهایی یک موجودیت کامل در نظر گرفته شود که به طور بالقوه به جدول پایگاه داده دیگری مرتبط است.به زبان ساده هر مدل به تنهایی می‌تواند در یک جدول جداگانه در پایگاه داده نمایش داده شود، به جای اینکه همه اطلاعات در یک جدول واحد ذخیره شود.

class Place(models.Model):
    name = models.CharField(max_length=50)

class Restaurant(Place):
    serves_pizza = models.BooleanField(default=False)

مدل Restaurant از مدل Place ارث‌بری می‌کند. این بدان معنی است که همه فیلدهای Place به صورت اتوماتیک به Restaurant ارث می‌برده شده و Restaurant از همه ویژگی‌های Place استفاده می‌کند.
این الگو به شما امکان می‌دهد که یک مدل (در اینجا Restaurant) را برای ارث‌بری از ویژگی‌ها و رفتارهای یک مدل دیگر (در اینجا Place) استفاده کنید، در حالی که همچنان می‌توانید به آن فیلدها و ویژگی‌های جدیدی را اضافه کنید.

ادامه مطالب در پست بعد
#python

@code_crafters

در ادامه پست قبلی:
Indexing:
ایندکس ها برای بهبود عملکرد عملیات پایگاه داده، به ویژه برای مجموعه داده های بزرگ، ضروری هستند.
به عنوان مثال، فرض کنید شما یک جدول کاربران دارید و می‌خواهید بر اساس نام آن‌ها جستجو کنید. بدون ایندکس، پایگاه داده باید هر رکورد را از ابتدا تا انتها بررسی کند تا نام مورد نظر را پیدا کند. اما با ایجاد یک ایندکس بر روی فیلد نام، پایگاه داده می‌تواند به سرعت به رکوردهای مرتبط با نام مورد نظر دسترسی پیدا کند.

Example:

class User(models.Model):
    username = models.CharField(max_length=100, db_index=True)
    email = models.CharField(max_length=100)

    class Meta:
        indexes = [
            models.Index(fields=['username'], name='username_idx'),
            models.Index(fields=['email'], name='email_idx')
        ]

Overriding Model Methods:
وقتی در Django یک مدل ایجاد می‌کنید، می‌توانید رفتارهای خاصی را برای عملیات‌های مختلف مدل، مانند ذخیره‌سازی یا حذف، سفارشی‌سازی کنید. این کار به شما این امکان را می‌دهد که قبل یا بعد از انجام یک عملیات، کارهای خاصی انجام دهید. شما میتوانید عملیات save , delete ,.... رو بازنویسی کنید.

Example:

class MyModel(models.Model):
    name = models.CharField(max_length=100)

    def save(self, *args, **kwargs):
        self.name = self.name.upper()
        super().save(*args, **kwargs)

در این مثال، هر زمان که یک نمونه از MyModel ذخیره می‌شود، مقدار فیلد name به حروف بزرگ تبدیل می‌شود قبل از ذخیره‌سازی و سپس عملیات ذخیره‌سازی انجام می‌شود.


Soft Deletion:

استفاده از Soft Deletion به شما این امکان را می‌دهد که آیتم‌ها را به عنوان حذف شده علامت‌گذاری کنید، اما در واقع آن‌ها را از پایگاه داده حذف نکنید. به این تکنیک "حذف نرم" یا "حذف موقت" نیز گفته می‌شود. این روش برای نگهداری تاریخچه داده‌ها، امکان بازگردانی آیتم‌های حذف شده و همچنین حفظ ارتباطات بین آیتم‌های مختلف مفید است.
Example:

class SoftDeleteModel(models.Model):
    is_deleted = models.BooleanField(default=False)

    def delete(self, *args, **kwargs):
        self.is_deleted = True
        self.save()

هر یک از این تکنیک ها مجموعه ای از مزایای خاص خود را ارائه می دهد و می تواند به طور قابل توجهی بر کارایی و عملکرد پروژه های شما تأثیر بگذارد. با اجرای این استراتژی‌ها، می‌توانید از قابلیت‌های قدرتمند مدل‌سازی جنگو برای ساخت برنامه‌های کاربردی وب قوی‌تر و مقیاس‌پذیرتر بهره ببرید.
منبع
#python

@code_crafters

کلاس دیاگرام اولیه پروژه‌ی فعلی

تو شرکت‌ها کسانی هستند که بهشون طراح و معمار سیستم میگیم کارشونdesign systemهستش،چکاری میکنند؟

میان پروژه ورودی شرکت رو تحلیل میکنن و بیزنس مدل‌های اون رو در میارن و معماری مناسب روجهت پیاده سازی شدن پروژه بر اساس بیزنس مدل‌ها مشخص میکنن،دیاگرام روطراحی میکنن و میفرستن سمت توسعه دهندگان جهت پیاده سازی پروژه بر اساس اون معماری و بیزنس مدلهای مشخص میشه،اینکار رو معمولا در پروژه‌های بزرگ که نیاز هست بر اساس میکروسرویس وDDDپیاده سازی بشه انجام‌ میدن،این پیاده سازی بر اساس اصول سازمانی هر شرکت مخصوص خودش صورت میگیره این مسئله کمک میکنه تا تیم و یا تیم‌های فنی از چهارچوب سازمان خارج نشده و دید یکسانی از پروژه داشته باشن،آماده کردن اون بر اساس میزان بزرگی پروژه زمان بر هست،طراح سیستم بایدآینده نگری نسبت به پروژه داشته باشه تاهزینه‌های شرکت رو بشدت کاهش بده ونقش حیاتی درمشخص کردن هسته بیزنس ایفا میکنه،اشتباه در طراحی این دیاگرام در مرحله اول اون موجب آسیب رسیدن به دیتابیس و داده‌های اون خواهد شد و در مرحله بعدی به کوئری‌ها و پرفورمنس پروژه میرسه
#microservice

#daily

@code_crafters

در ادامه کار بعد از کلاس دیاگرام(در واقع کلاس دیاگرام لایه‌های دیتا data layers رو برامون مشخص میکنه) میرسیم به پیدا کردن بیزنس‌های تجاری پروژه، طبق ساختاری که از دیتا لایرها هستش، کاری که صورت میگیره این هست که دنبال الگوهایی میگردیم، که طبق اون بتونیم دومین‌هامون رو شناسایی کنیم و بر اساس خروجی اون بتونیم سرویس‌هامون رو تشخیص و تفکیک بدیم، هر دومین ممکنه طبق دیدگاه و برآورد شما به یک یا چند سرویس تقسیم بشه

مهمترین دومین در پروژه رو طبق الگوی سرویس مشخص میکنیم، الگوی سرویس همون هسته بیزنس پروژه هستش (قلب تپنده هر سیستمی)، بیشترین بخش کد و توسعه رو شامل میشه، خبره ترین توسعه دهندگان تیم بر روی این بخش متمرکز میشن تا سرویس‌ها رو به بهترین شکل ممکن بالا بیارن پر هزینه ترین دومین برای هر سیستمی هستش و شکست در اون جبران ناپذیر خواهد بود، دومین دیگر مربوط به الگوی کاربران هستش که از اسمش مشخص هستش، دومین بعدی ما بخش مربوط به الگوی درآمدزایی خواهد بود، دیدگاه و تفکر شما در پیدا کردن دومین‌ها و تبدیل اون به سرویس‌های مجزا بسیار حائز اهمیت هستش

#microservice

#daily

@code_crafters

باینری ها در PostgreSQL: ذخیره سازی اطلاعات خام

تصور کنید می‌خواهید عکسی از گربه‌تان را در PostgreSQL ذخیره کنید. چطور می‌توانید این کار را انجام دهید؟

پایگاه داده PostgreSQL نوع داده‌ای به نام bytea را ارائه می‌دهد که برای ذخیره اطلاعات باینری مانند تصاویر، فایل‌های صوتی و ویدئوها ایده‌آل است.

تفاوت باینری و رشته‌های کاراکتری:

* رشته‌های باینری مانند "بایت‌های خام" هستند و می‌توانند هر نوع داده‌ای را ذخیره کنند، از جمله صفر و کاراکترهای غیرقابل چاپ.
* رشته‌های کاراکتری برای ذخیره متن مناسب هستند و محدودیت‌هایی در مورد کاراکترهای مجاز دارند.

فرمت‌های ذخیره سازی:

هگزادسیمال: هر بایت به عنوان دو رقم شانزده‌گانی نمایش داده می‌شود (مثلاً "00" برای بایت صفر). این فرمت خوانایی بیشتری دارد.
نوع Escape: برخی از بایت‌ها با کاراکترهای خاص علامت‌گذاری می‌شوند. این فرمت قدیمی‌تر است و کاربرد کمتری دارد.

کاربردها:

۱.ذخیره تصاویر، فایل‌های صوتی و ویدئوها
۲.ذخیره داده‌های باینری مانند کدهای برنامه
۳.ذخیره اطلاعات رمزنگاری شده

مثال:

فرض کنید می‌خواهید تصویر گربه‌تان را با نام cat.jpg در پایگاه داده ذخیره کنید:

INSERT INTO photos (name, data)
VALUES ('cat.jpg', BYTEA('\xFF\xD8\xFF\xE0'));

نکات:

پایگاه داده PostgreSQL از نوع داده BLOB (Binary Large Object) نیز برای ذخیره داده‌های باینری پشتیبانی می‌کند. فرمت ورودی BLOB با bytea متفاوت است، اما توابع و عملگرهای مشابهی دارند.
می‌توانید از توابع و عملگرهای مختلفی برای کار با داده‌های bytea استفاده کنید، مانند LENGTH(), SUBSTRING() و COMPARE().

نتیجه:

نوع داده bytea یک ابزار قدرتمند برای ذخیره و مدیریت داده‌های باینری در PostgreSQL است. با استفاده از این نوع داده، می‌توانید انواع مختلف اطلاعات را به طور کارآمد و ایمن ذخیره کنید.

#PostgreSQL
@Code_Crafters

ذخیره سازی اطلاعات خام ولی در حجم بالا با Blob در PostgreSQL

در پایگاه داده PostgreSQL نوع داده‌ای به نام bytea را ارائه می‌دهد که برای ذخیره اطلاعات باینری مانند تصاویر، فایل‌های صوتی و ویدئوها ایده‌آل است. اما گاهی اوقات با داده‌های باینری خیلی بزرگتر از حد معمول سروکار داریم. در اینجاست که مفهوم BLOB یا "Binary Large Object" به کمک ما می‌آید.

تعریف BLOB چیست؟

در واقع BLOB یک نوع داده در PostgreSQL است که برای ذخیره داده‌های باینری بسیار بزرگ مانند:

۱. فایل‌های چند گیگابایتی
۲. مجموعه داده‌های علمی
۳. تصاویر با وضوح بالا
۴. فایل‌های ویدئویی با کیفیت بالا

استفاده می‌شود.

مزایای استفاده از BLOB:

* ذخیره سازی داده‌های حجیم: BLOB ها می‌توانند داده‌هایی با حجم تا 1 ترابایت را ذخیره کنند.
* کارایی: BLOB ها برای ذخیره سازی داده‌های باینری بهینه شده‌اند و می‌توانند عملکرد بهتری نسبت به ذخیره سازی داده‌های باینری در قالب رشته‌های متنی ارائه دهند.
* انعطاف پذیری: BLOB ها می‌توانند برای ذخیره هر نوع داده باینری، صرف نظر از نوع و فرمت آن، استفاده شوند.

نحوه استفاده از BLOB:

برای استفاده از BLOB در PostgreSQL، باید مراحل زیر را انجام دهید:

1. نوع داده BLOB را در جدول خود تعریف کنید:

CREATE TABLE my_table (
  id INT PRIMARY KEY,
  data BYTEA
);

2. با استفاده از دستور INSERT، داده‌های BLOB را در جدول ذخیره کنید:

INSERT INTO my_table (id, data)
VALUES (1, lo_import('image.jpg'));

3. با استفاده از دستور SELECT، داده‌های BLOB را از جدول بازیابی کنید:

SELECT data FROM my_table WHERE id = 1;

نکات مهم:

برای ذخیره و بازیابی BLOB ها، باید از توابع lo_import و lo_export استفاده کنید.
پایگاه داده PostgreSQL ابزارهای مختلفی برای مدیریت BLOB ها ارائه می‌دهد، مانند توابع و عملگرهای خاص.
برای اطلاعات بیشتر در مورد BLOB ها، می‌توانید به مستندات PostgreSQL مراجعه کنید.

مثال:

فرض کنید می‌خواهید یک ویدیو با حجم 2 گیگابایت را در PostgreSQL ذخیره کنید. می‌توانید مراحل زیر را انجام دهید:

1. نوع داده BLOB را در جدول خود تعریف کنید:

CREATE TABLE videos (
  id INT PRIMARY KEY,
  title VARCHAR(255),
  data BYTEA
);

2. با استفاده از دستور INSERT، ویدیو را در جدول ذخیره کنید:

INSERT INTO videos (id, title, data)
VALUES (1, 'My Video', lo_import('video.mp4'));

3. با استفاده از دستور SELECT، ویدیو را از جدول بازیابی کنید:

SELECT data FROM videos WHERE id = 1;

با استفاده از BLOB ها، می‌توانید هر نوع داده باینری را در PostgreSQL ذخیره کنید و به آنها دسترسی داشته باشید. این امر PostgreSQL را به یک راه حل قدرتمند برای ذخیره سازی و مدیریت داده‌های باینری تبدیل می‌کند.

در ادامه، چند نمونه دیگر از کاربردهای BLOB در PostgreSQL آورده شده است:

۱. ذخیره سازی اسناد و مدارک
۲. ذخیره سازی تصاویر و ویدیوها
۳. ذخیره سازی فایل‌های صوتی
۴. ذخیره سازی پایگاه داده‌های NoSQL
۵. ذخیره سازی داده‌های رمزنگاری شده

جمع بندی:

در واقع BLOB ها یک ابزار قدرتمند برای ذخیره سازی داده‌های باینری در PostgreSQL هستند. با استفاده از BLOB ها، می‌توانید داده‌های حجیم را به طور کارآمد و ایمن ذخیره کنید.

#PostgreSQL
@Code_Crafters

در ادامه مباحث مربوط به طراحی سیستم و معماری آن میریم به سراغ مشخص کردن محدوده و لبه‌های بخش‌های مختلف سرویس، ابتدا دیتا لایه رو مشخص کردیم و سپس دومین‌های تجاری رو پیدا کردیم و اکنون بر روی یک طرح مشخص میکنیم هر سرویس با چه سرویس‌های دیگه ارتباط داره و اشتراکاتشون کجاست(شکل هندسی آن با توجه به هر سیستم متفاوت میگردد) هر سرویس رو با دیتا لایر خودش مشخص میکنیم(در تصویر بلوک‌های زرد رنگ)، یک سیستم میتواند چند دومین تجاری داشته باشد و هر دومین نیز یک یا چند سرویس مجزا بر اساس این طرح بندی در تصویر اولویت‌های ما کامل مشخص خواهد شد و تیم یا تیم‌های توسعه راحت میتوانند تصمیم بگیرند کدام سرویس‌ها پایه و اولویت بالاتری دارن و کدام وابستگی‌های بیشتری ایجاد میکنند و این در پیش برد صحیح و اجرای اولیه بسیار به سازمان کمک میکند، علاوه بر ان میتوان قسمت mvp (نمونه اولیه را نیز مشخص کرد، کادر سبز رنگ)


#microservice

#daily

@code_crafters

رویه ذخیره شده Stored Procedure ناجی برنامه های تحت فشار:
در دنیای برنامه‌نویسی(منظور ما سمت Back-End است نه Front-End 🥸)، بهینه‌سازی و عملکرد روان برنامه‌ها از اهمیت بالایی برخوردار است. در این میان، پایگاه‌های داده نقش حیاتی در ذخیره‌سازی و بازیابی اطلاعات ایفا می‌کنند.

رویه ذخیره‌شده یا Stored Procedure چیست ؟
به صورت خلاصه Stored Procedure یک مجموعه از دستورات SQL است که کار خاصی را انجام میدهد و ما برای آن یک نام مرتبط میگذاریم و در هر جایی که نیاز داشته باشیم آن را فراخوانی میکنیم (اگر پارامتر خاصی نیاز داشته باشد هم میتوانیم به آن پاس بدهیم )

به صورت معمول برنامه نویس ها از ORM هایی مخصوص زبان برنامه نویسی که با آن کار میکنند برای ایجاد کوئری بر روی دیتابیس استفاده میکنند ولی ORM (منظورم هر ORM است حتی اگر معجزه برنامه نویسی قرن باشد!!!) چندین ایراد مهم و اساسی دارند که در ادامه به آن ها اشاره میشود:

۱. شما باید هزینه تبدیل کد هایتان را به SQL پرداخت کنید(با کاهش قدرت برنامه) در نهایت پایگاه داده شما با SQL کار میکند نه زبان برنامه نویسی شما !!!

۲.وقتی از ORM ها استفاده میکنید اگر نیاز به کوئری پیچیده و یا خیلی خاصی داشته باشید قدرت زیادی برای مدیریت این چالش با استفاده از ORM نخواهید داشت.

۳. معمولا برای فراخوانی یک مقدار از پایگاه داده به چندین روش مختلف میتوان این کار را انجام داد که یه سری از این روش ها دارای پرفومنس خوب و بعضی از روش ها دارای پرفومنس وحشتناک هستند
(این مورد مربوط به افزایش پرفومنس در SQL است که توضیح طولانی دارد که در اینجا جای نمیگیرد ولی برای آشنایی بیشتر ساده ترین مورد را اشاره میکنم :
تصور کنید جدولی به نام کارکنان و با ۱۵ ردیف داریم و میخواهید مقدار نام از جدول کارکنان خود را بخوانید با استفاده از ORM خود در نهایت به این کوئری خواهید رسید :

select * from employee;

در حالی که شما فقط به نام کارکنان در این جدول نیاز دارید و این جدول دارای ۱۵ ردیف است که فراخوانی ۱۴ ردیف دیگر بیهوده و هزینه برخواهد بود
و این کوئری نیاز شما را برطرف میکرد :

select name from employee;

که دارای پرفومنس بهتری خواهد بود
{شاید بتوانید جلوی استفاده از * بگیرید و ORM را مجبور به فراخوانی تنها name کنید ولی در موارد دیگر چنین ساده نخواهد بود })
وقتی از ORM خود استفاده میکنید شما کنترل زیادی برای اینکه از چه روشی استفاده کند نخواهید داشت و صرفا کد های ORM خود را خواهید دید

۴. گاها پیش میآید که شما برای فراخوانی مقدار در پایگاه داده با استفاده از ORM کوئری میسازید ولی ORM کوئری عجیبی تولید میکند که فشار فوق العاده ای بر روی برنامه شما وارد میکند.(برای جلوگیری این مورد اگر اصرار به استفاده از ORM دارید باید به موارد پیشرفته ORM خود مراجعه کنید که نیاز به تمرین و زمان است)

از معایب استفاده از Stored Procedure میتوان به این موارد اشاره کرد:

۱. نیاز به دانش خوبی از SQL دارد

۲. در صورت تغییر پایگاه داده نیاز به بازنویسی خواهند داشت

۳.نوشتن برنامه با سرعت خیلی پایین تری پیش خواهد رفت.

مقایسه Stored Procedure با ORM:

در واقع ORMها (Object-Relational Mapping) ابزاری برای نگاشت اشیاء برنامه به ساختارهای پایگاه داده هستند. ORMها به طور خودکار وظایف مربوط به ترجمه کوئری‌ها از زبان برنامه‌نویسی به زبان SQL را انجام می‌دهند.

در حالی که ORMها مزایایی از جمله سادگی و سهولت استفاده را ارائه می‌دهند، اما در مقایسه با Stored Procedureها، معایبی نیز دارند. ORMها می‌توانند به دلیل ترجمه‌های اضافی، باعث افت عملکرد شوند. همچنین، ORMها در مدیریت کوئری‌های پیچیده و خاص، انعطاف‌پذیری Stored Procedureها را ندارند.

در نتیجه :اگر برنامه شما دارای فشار زیادی بر روی پایگاه داده است و همین طور برنامه شما دارای بار زیادی است میتوانید برای مدیریت آن از Stored Procedure ها در پایگاه داده تان استفاده کنید
یا اینکه میتوانید استفاده نکنید و به زیبایی کد های خود با استفاده از ORM به خود افتخار کنید و بگذارید پایگاه داده تحت فشار کد های SQL عجیب شما تبدیل به نفت شود
این مورد کاملا بستگی به برنامه و نیاز شما بستگی دارد.

#Database #General
@Code_Crafters