برای آشنایی بیشتر یه مثال هم اضافه کنم:

اگر از rich error استفاده نکنیم، برای هندل کردن ارور های مختلف مجبور بودیم از یک سولوشن دیگه بجز exception استفاده کنیم و یا اینکه بیایم و برای هر ارور به این صورت exceptionبنویسیم:

class UserNotFoundErr(Exception):
    pass


class IpBlockedErr(Exception):
    pass


class TooManyRequestErr(Exception):
    pass


class UserConflictErr(Exception):
    pass

در handler هم باید این کار رو میکردیم:

from examples.without_rich_error.service import get_user_service
from examples.without_rich_error.exception import UserNotFoundErr, UserConflictErr, TooManyRequestErr, IpBlockedErr


def get_user_handler(user_id: int):
    try:
        print(service.get_user_by_id(user_id=user_id))
    except UserNotFoundErr as err:
        print("user not found code is 404", err)
    except UserConflictErr as err:
        print("user conflict code is 409", err)
    except TooManyRequestErr as err:
        print("too many request code is 429", err)
    except IpBlockedErr as err:
        print("ip blocked code is 403", err)

در این صورت هرچقدر تعداد exceptionها بیشتر شود مدیریت کردن آنها نیز سخت تر خواهد شد. همچنین قدرت مشاهده گری سیستم با استفاده از exception ها نیز پایین می آید در صورتی که ما در rich error تمامی ارور هایی که در لایه های مختلف رخ داده باشند رو داشتیم.

اگه کد رو با rich error جایگزین کنیم:

from examples.with_rich_error.api import base_response_with_error, base_response


def get_user_handler(user_id: int):
    try:
        ...
    except Exception as err:
        return base_response_with_error(error=err)

از آنجا که ما یک ارور غنی داریم و از کد ها استفاده کردیم به راحتی میدانیم که این ارور به چه معنی است و حتی به سادگی http error مناسب را برگردانیم.

#rich_error #python

@Syntax_fa

زمانی که داشتم این کدارو میزدم فقط منو خدا میدونستیم چی به چیه
ولی الان فقط خدا میدونه🥹

پ.ن:
وقتی بعد چند وقت رو پروژه های قدیمت برمیگردی

#fun

@Syntax_fa

▎📊 Raw Queries and Connection Proxy in Django

▎🔍 How to Get Raw Queries in ORM

در جنگو، اگر ویژگی .query یک QuerySet را چک کنیم، می‌توانیم پرس‌وجو SQL مربوطه را دریافت کنیم. به عنوان مثال:

from author import models
all_authors = models.Author.objects.filter(email__endswith='@gmail.com').values_list('name').query

خروجی:

SELECT "author_author"."name" FROM "author_author" WHERE "author_author"."email"::text LIKE '%@gmail.com'

▎⚠️ چالش!

در جستجوهای ORM جنگو، دستورهایی داریم که غیر از QuerySet هستند و استفاده از .query باعث ایجاد خطا می‌شود. به عنوان مثال:

from author import models
author_count = models.Author.objects.filter(email='a').count().queries

خطا:

Traceback (most recent call last):
File "<console>", line 1, in <module>
AttributeError: 'int' object has no attribute 'query'

▎🛠 راه‌حل با استفاده از Connection Proxy

برای حل این مشکل، از connection در django.db استفاده می‌کنیم:

from django.db import connection
from author import models

author_count = models.Author.objects.filter(email='a').count()
connection.queries[-1]

خروجی:

{'sql': 'SELECT COUNT(*) AS "__count" FROM "author_author" WHERE "author_author"."email" = \'a\'', 'time': '0.166'}

▎📌 توجه!

شی connection فقط زمانی نتیجه می‌دهد که سرور جنگو در حالت DEBUG=True در حال اجرا باشد!

▎📝 نوشتن Debug Queries برای درک Connection Proxy

from django.db import connection
from django.db import reset_queries

def database_debug(func):
    def inner_func(*args, **kwargs):
        reset_queries()
        results = func(*args, **kwargs)
        query_info = connection.queries
        print(f'function_name: {func.__name__}')
        print(f'query_count: {len(query_info)}')
        queries = [f'{query["sql"]}\n' for query in query_info]
        print(f'queries: \n{"".join(queries)}')
        return results
    return inner_func

📌 توجه! تابع reset_queries تمام پرس‌وجوهای ذخیره شده در connection را پاک می‌کند!

▎🔧 استفاده از کد:

@database_debug
def regular_query():
    blogs = models.Blog.objects.all()
    return [blog.author.name for blog in blogs]

خروجی:

function_name: regular_query
query_count: 4
queries:
SELECT "blog_blog"."id", "blog_blog"."noscript", "blog_blog"."content", "blog_blog"."author_id"

▎💡 توضیح کد:

با استفاده از دستور reset_queries تمام پرس‌وجوهای ذخیره شده در connection را حذف می‌کنیم تا فقط کوئری‌های خواسته شده دیباگ شوند. سپس کوئری‌های داخل inner_function که دکوراتور شده‌اند اجرا می‌شوند و شی connection حاوی لیست از پرس‌وجوها می‌شود. بعد از آن، تمام پرس‌وجوها را از connection.queries بازیابی می‌کنیم.


🔗 منبع : کتاب django in productions

▎Django Serializers: Related Fields in Serializer


وقتی با مدل‌های مرتبط در Django کار می‌کنیم، نمایش اطلاعات کامل آن‌ها در سریالایزرها می‌تواند چالش‌برانگیز باشد. خوشبختانه، Django REST Framework (DRF) ابزارهای قدرتمندی برای این کار در اختیار ما قرار می‌دهد.

سریالایزر DRF به‌طور پیش‌فرض برای فیلدهای مرتبط در هنگام سریال‌سازی داده‌ها از مقدار primary key استفاده می‌کند. به عنوان مثال:

class Author(models.Model):
    name = models.CharField()
    last_name = models.CharField()

class Blog(models.Model):
    noscript = models.CharField()
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

class BlogSerializer(serializers.ModelSerializer):
    class Meta:
        model = Blog
        fields = "__all__"

خروجی BlogSerializer به شکل زیر خواهد بود:

{
    "noscript": "black python",
    "author": 3
}

حالا اگر بخواهیم به جای PK، اطلاعات اضافی از Author نمایش دهیم، چند راه حل وجود دارد:

▎1. استفاده از depth:
با تنظیم پارامتر 1 = depth در Meta کلاس سریالایزر، می‌توانید مشخص کنید که تا چه عمقی از روابط مدل‌ها سریالایز شوند. این روش ساده و سریع است، اما کنترل کمتری بر روی داده‌های خروجی به شما می‌دهد.

class BlogSerializer(serializers.ModelSerializer):
    class Meta:
        model = Blog
        depth = 1

خروجی BlogSerializer به شکل زیر خواهد بود:

{
    "noscript": "python black",
    "author": { "name": "amirhossein", "id": 1, "last_name": "some last name" }
}

▎2. استفاده از Nested Serializers:
با تعریف سریالایزرهای تو در تو، می‌توانید کنترل کاملی بر روی فیلدهایی که می‌خواهید از مدل‌های مرتبط نمایش دهید داشته باشید. این روش انعطاف‌پذیرتر است، اما نیاز به نوشتن کد بیشتری دارد , مثال:

class AuthorSerializer(serializers.ModelSerializer):
    class Meta:
        model = Author
        fields = ("name",)

class BlogSerializer(serializers.ModelSerializer):
    author = AuthorSerializer()

    class Meta:
        model = Blog
        fields = "__all__"

خروجی به شکل زیر خواهد بود:

{
    "noscript": "black python",
    "author": { "name": "amirhossein" }
}

▎مشکل N + 1 در هنگام استفاده از Depth یا Nested Serializer:
حتما باید در queryset خود از select_related یا prefetch_related استفاده کنید تا از بروز مشکل N + 1 جلوگیری کنید!

▎Django Serializers: Validators

1 : field level validators
برای اعتبار سنجی داده ها در سطح فیلد در drf باید از دستور زیر پیروی کنید:

class BlogSerializer(serializers.ModelSerializer):
        ....
       def validate_<field name>(self, value): # validate_email
               if vlaue in "_" :
                       serializers.ValidationError("some error")
               return value

2 : object level validator

class BlogSerializer(serializers.ModelSerializer):
     ....
     def validate(self, attrs):
          if attrs.name == attrs.noscript :
               serializers.ValidationError("name and noscript can not be same")
          return value

▎Django Serializers: to_internal_value
متود to_internal_value در ModelSerializer قبل از اجرای اعتبارسنجی داده ها به داده های خام دسترسی دارد و میتوانید برای تغییر داده ها یا اضافه کردن داده ها قبل از اعتبارسنجی از اون استفاده کنید:

class BlogSerializer(serializers.ModelSerializer):
    ....
    def to_internal_value(self, data):
          data["user"] = self.context["user"]  # افزودن شی user به data
          return super().to_internal_value(data)

نکته:
اقا حتما موقع return از super().to_internal_value(data) استفاده کنید و return data استفاده نکنید ; چون اینطوری باعث میشه تمام validatorهای modelSerializer که از روی مدل شما بطور پیشفرض ساخته شده , غیرفعال بشن!

▎Django Serializers: to_representation

ما میتوانیم این رو ش را override کنیم تا قبل از داده های سریالی که نمونه سریالسازبر میگرداند،
دستکاری داده ها را انجام دهیم , مثال:

class BlogSerializer(serializers.ModelSerializer):
    ....
    def to_representation(self, instance):
         resp = super().to_representation(instance)
         resp['noscript'] = resp['noscript'].upper()
         return resp

برای اطلاعات بیشتر به کتاب :django in production مراجعه کنید.

نکات مهم اجرای جنگو با Gunicorn

توضیح درباره Gunicorn
نمیخوام توضیحات زیادی بدم حوصلتون سر بره پس همون سه خط معرفی که تو وب سایت gunicorn نوشته رو براتون یکم شفافش میکنم:
اسمش مخفف green unicorn هستش
جی یونیکورن یک http سرور هستش که از استاندارد WSGI(Web server gateway interface) برای اجرای برنامه های وب پایتون استفاده میکنه.
استاندارد WSGI برای این بوجود اومد تا هر فریم ورک وب پایتونی روش خودشو واسه ارتباط پیاده نکنه و همه از یه استاندارد مشخص استفاده کنن.

در ادامه میگه gunicorn برای unix هستش و برای سیستم عامل هایی مثل مک و لینوکس طراحی شده.

بعدش میگه که جی یونیکورن از مدل pre-fork worker استفاده میکنه حالا این به چه معنیه؟
جی یونیکورن کاری که میکنه اینه قبل اینکه شروع به پردازش درخواست ها کنه، میاد و به اندازه ای که تنظیم کردید worker ایجاد میکنه که هر worker درخواست هارو بطور مستقل پردازش میکنه.

بعدشم میگه با فریم ورک های وب مختلفی سازگاره که اینم میتونیم دلیلش رو این بدونیم داره برای ارتباط از استاندارد WSGI استفاده میکنه.

قسمت آخرشم میگه light resource هستش و منابع کمی مصرف میکنه همچنین برای ترافیک بالا عملکرد خوبی داره.

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

مثال اول

gunicorn --chdir config config.wsgi:application -b 0.0.0.0:8000

اگه با این دستور جی یونیکورن رو اجرا کنید باید به این نکته دقت کنید بصورت پیشفرض براتون فقط یدونه worker میسازه که این اصلا خوب نیست. خود جی یونیکورن پیشنهاد میده حتی اگه یدونه core دارید 4 تا ورکر بسازید و یه فرمولی هم داده که میگه«تعداد هسته های سی پی یو رو ضربدر 2 به علاوه یک کنید»
همچنین به شما اطمینان داده همین تعداد ورکر هزاران ریکوئست رو میتونن پاسخ بدن پس تعداد ورکر هارو الکی زیادش نکنید.
البته به کیس شما هم بستگی داره.
دستور بهتر برای اجرا اینه تعداد ورکر هارو مشخص کنیم:

gunicorn --workers 5 --chdir config config.wsgi:application -b 0.0.0.0:8000

مثال دوم:
فرض کنید کاربر ها تو اپلیکیشن شما فایل هایی رو آپلود میکنن. شما پنج تا ورکر دارید.
وقتی پنج تا کاربر همزمان فایل آپلود کنن بنظرتون چه اتفاقی میوفته؟
پنج تا ورکر شما گیر یه io افتادن و مشغولن و درخواست های دیگه کاربرا انجام نمیشه. خب این وضعیتی نیست که باب میلیتون باشه!
برای حل این مشکل کافیه از gevent توی جی یونیکرون استفاده گنید؛

gunicorn --workers 1 -k gevent --chdir config config.wsgi:application -b 0.0.0.0:8000

با فلگ -k نوع کلاس ورکر رو مشخص میکنیم. حالا چرا از gevent استفاده میکنیم؟
کتابخونه gevent برای مدریریت همزمانی طراحی شده. میشه گفت یک نمونه lightweight thread هستش که این مدل موقع عملیات های IO سوئیچینگ انجام میده و در این صورت اگه به io خوردید براتون هندل میکنه.

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

#python #django #gunicorn #gevent

@Syntax_fa

شب همگی سینتکسیا خوش باشه😉

بطور خیلی خلاصه اول ازتون میخوام که با دقت از این دو تا ویدیو فرانت اند وبسایت syntax دیدن کنید و انتخاب خودتون بهمون بگید که کدوم یکی از لحاظ تناسب و سایز ویجت ها و فونت ها به نسبت desktop بردیگری برتری داره؟

(جزئیات هر فرانت رو زیر ویدیو درج میکنم)

فرانت اند (۱)

توضیحات :
رفقا دیزاین سایز هر دو فرانت اند 1440 در 1024 هست ، اندازه desktop که فرانت اند نشون میده ۱۳۶۶ در ۷۳۸ هست .
اینجا برای اینکه آیتم ها ظاهر خودشون رو در هر نوع desktop حفظ کنه از scale کردن استفاده کردیم (بعضی جاها کل آیتم scale شده ، بعضی جاها برخی قسمت ها) .

طراحی فونت ها براساس متریال دیزاین هست و چون desktop ما از design size کوچیک تره ،برای اینکه ظاهر مینیمال و جذاب خودشو حفظ کنه از تمام فونت ها 2px کم کردیم و خروجی نهایی این شده

فرانت اند (۲):

توضیحات :
Design size: 1440 x 1024
Desktop size : 1366 x 738

توی این دیزاین هم برخی آیتم هارو scale کردیم اما تفاوت قابل توجه در فونت ها و ویجت هایی که parent فونت ها هستن وجود داره .
ما تو این دیزاین size فونت هارو برای تمام desktop size ها ثابت قرار دادیم و مقدار ویجت والد رو بر اساس padding فونت ها بدست آوریم که خروجی شده این ویدیو

کتاب django in production رو دادم به notebook llm و یه پادکست ساخته برامون که این کتاب درمورد چیا صحبت میکنه و یه دید کلی میده نسبت به کتاب.


پ.ن: سرویس notebook llm خلاصه مقاله یا کتابی که بهش دادید رو مثل یه پاکست که دو نفر دارن درمورد اون مقاله صحبت میکنن درمیاره!

SOURCE

@Syntax_Fa

🔍 بررسی استراتژی جداسازی عملیات چک کردن وجود و بازیابی اطلاعات از دیتابیس

دو رویکرد اصلی در این زمینه در نظر داریم:

1️⃣ جداسازی مسئولیت‌ها:
در این روش، دو متد جداگانه داریم:
- check_user_exists(user_id)
- get_user_by_id(user_id)

مزایا:
✅ رعایت Single responsibility(SRP)
✅ خوانایی و وضوح بیشتر کد
✅ امکان استفاده مجدد از هر متد به صورت مستقل

معایب:
❌ افزایش تعداد کوئری‌های ارسالی به دیتابیس

2️⃣ ترکیب عملیات در یک متد:
در این روش، یک متد واحد داریم:
- get_user(user_id)

مزایا:
✅ کاهش تعداد کوئری‌های ارسالی به دیتابیس
✅ بهبود کارایی

معایب:
❌ احتمال نقض اصل Single responsibility
❌ کاهش خوانایی و وضوح کد

🤔 حالا سوال این است: کدام رویکرد بهتر است؟

پاسخ: بستگی دارد!

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

3️⃣ رویکرد میانه:
در این روش، یک متد اصلی داریم که می‌تواند مبنای سایر عملیات باشد:

class UserService:
    @staticmethod
    def get_user(user_id: int) -> Optional[User]:
        try:
            return User.objects.get(id=user_id)
        except User.DoesNotExist:
            return None

    @staticmethod
    def check_user_exists(user_id: int) -> bool:
        return UserService.get_user(user_id) is not None

    @staticmethod
    def get_user_or_raise(user_id: int) -> User:
        user = UserService.get_user(user_id)
        if user is None:
            raise ObjectDoesNotExist(f"User with id {user_id} does not exist")
        return user

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

شما کدام رویکرد را ترجیح می‌دهید؟

@Syntax_fa

شرکت SpaceX در موفقیتی تاریخی، تونسته بوستر Super Heavy رو روی برجی که از اون پرتاب شده بود، روی دو بازوی مکانیکی این برج با دقت فوق العاده ای فرود بیاره!

@normal_developer

Linter & pylint

لینتر ابزاری است که برای تحلیل کد استفاده می‌شود تا مشکلات احتمالی در کد را شناسایی کند. این ابزارها به توسعه‌دهندگان کمک می‌کنند تا با شناسایی خطاهای سینتکس، استانداردهای کدنویسی و مسائلی مانند memory leak و ... را شناسایی کنند و کیفیت کد را بهبود بخشند.

کاربردهای Linter

1. شناسایی خطاهای سینتکسی:
لینتر می‌توانند خطاهای سینتکسی را قبل از اجرای کد شناسایی کنند.

2. بهبود خوانایی کد:
با پیشنهادهایی برای رعایت استانداردهای کدنویسی می دهد، خوانایی کد را افزایش می‌دهند.

3. کاهش باگ‌ها:
با شناسایی مسائل بالقوه، به کاهش تعداد باگ‌ها کمک می‌کنند.

4. یکنواختی کد:
با اطمینان از رعایت استانداردهای یکسان در سراسر پروژه، یکنواختی کد را حفظ می‌کنند.

معرفی Pylint

پای لینت یک ابزار Linter برای زبان Python است که به تحلیل کد Python می‌پردازد تا مشکلات مختلفی مانند خطاهای سینتکسی عدم رعایت استانداردهای PEP 8 و مسائل منطقی را شناسایی کند.

ویژگی‌های Pylint

- شناسایی خطاهای نحوی و منطقی:
Pylint می‌تواند خطاهای نحوی و منطقی را در کد شناسایی کند.

- پیشنهاد برای بهبود کد:
با ارائه پیشنهادهایی برای بهبود کد، توسعه‌دهندگان را در نوشتن کدهای تمیزتر و بهینه‌تر یاری می‌دهد.

- پشتیبانی از استانداردهای PEP 8:
با بررسی کد نسبت به استانداردهای PEP 8، به رعایت بهترین شیوه‌های کدنویسی کمک می‌کند.

- گزارش‌دهی جامع:
گزارش‌های کاملی از مشکلات موجود در کد ارائه می‌دهد که شامل امتیازدهی به کیفیت کد نیز می‌باشد.

مثال نحوه استفاده از pylint:

pip install pylint

بعد از نصب کردن با دستور

pylint .

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

pylint --generate-rcfile > .pylintrc

در فایل .pylintrc می توانید بر حسب نیاز خودتان برخی از لینتر هارا غیر فعال کنید یا تنظیماتشان را تغییر دهید.

نحوه استفاده کاربردی از لینتر:
میتوانید در github workflow از لینتر استفاده کنید و اگر مشکلی شناسایی شد اکشن با خطا مواجه شود. همچنین می توانید از ابزار pre commit استفاده کنید و لینتر را تعریف کنید تا هر زمانی که کامیت جدیدی زده میشود بررسی کند اگر خطایی وجود دارد جلوی کامیت را بگیرد.

#linter #pylint #python

@Syntax_fa

Docker in Docker (DinD)

به اجرای Docker در داخل یک کانتینر اشاره دارد.

یک مثال کاربردی اش پایپ‌لاین CI/CD است:
- در برخی مواقع ممکن است پروژه ما برای اجرا و تست نیاز به یک سری backing service ها مثل redis و ... داشته باشد. در این صورت ترفندی که می زنیم را می توان اینطور بیان کرد که داخل کانتینر، کانتینر های مورد نیاز پروژه مان را آپ می کنیم.

مثال:

ci.yml
name: CI

on:
  pull_request:
    types: [opened, edited, reopened, synchronize, ready_for_review]
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements/test.txt

      - name: dockerUp
        run: sudo make docker-test-up

      - name: Test
        run: make test

      - name: dockerDown
        run: sudo make docker-test-down

و داخل فایل Makefile:

.PHONY: test

ROOT=$(realpath $(dir $(lastword $(MAKEFILE_LIST))))

test:
  python manage.py test

docker-test-up:
  docker compose -f $(ROOT)/docker-compose-test.yml up -d

docker-test-down:
  docker compose -f $(ROOT)/docker-compose-test.yml down

چالش DinD در موارد بیشتر

1. امنیت:
- اجرای Docker در Docker می‌تواند خطرات امنیتی به همراه داشته باشد، زیرا کانتینر داخلی به Docker Host دسترسی دارد.

2. پیچیدگی شبکه:
- کانفیگ شبکه می‌تواند پیچیده شود، به ویژه اگر نیاز به ارتباط بین کانتینرهای داخلی و خارجی باشد.

3. عملکرد:
- ممکن است عملکرد ضعیف‌تری نسبت به اجرای Docker به صورت مستقیم روی سرور داشته باشد.

نحوه استفاده

برای استفاده از Docker in Docker، می‌توانید از ایمیجی مانند docker:dind استفاده کنید. یک نمونه ساده از اجرای DinD به صورت زیر است:

docker run --privileged --name dind-container -d docker:dind

استفاده از فلگ --privileged ضروری است تا کانتینر به منابع سیستم دسترسی کامل داشته باشد.

جایگزین‌ها

در بسیاری از موارد، استفاده از روش‌های جایگزین مانند Docker خارج از کانتینر یا استفاده از ابزارهایی مانند Kubernetes می‌تواند مشکلات مربوط به DinD را حل کند و امنیت بیشتری فراهم کند.

#DinD

@Syntax_fa

ممکنه شما هم برای هاستینگ سایت یا اپلیکیشنتون از لیارا (liara.ir) استفاده کنید.
حدودا از سال ۱۴۰۰ سرویسای دم دستی که لازم داشتم رو میبردم روی لیارا یا حداقل نسخه اولیه رو اونجا ران میکردم.
سایت شخصی خودم رو هم اونجا ران کردم چون میخواستم از قابلیت های آماده ش استفاده کنم و زیاد روی تنظیم زیرساخت زمان نذارم و بیشتر روی توسعه تمرکز کنم.
ولی تو چند ماه اخیر واقعا با لیارا مشکل پیدا کردم و برام نه صرفه داره که ازش استفاده کنم و نه کیفیتشون مثل قبل خوبه.
تو ماه های جدید برای هر قابلیتی دارن یه قیمتی میدن.
فرض کنید یه سایت ساده با مثلا پایتون با کمترین منابع ران کنید روی لیارا. ببینیم چقد در میاد:

هزینه PaaS ماهانه: ۹۹ هزار تومن (512 مگابایت رم - ۰.۵ هسته پردازنده- ۵ گیگ حافظه)
هزینه بسته امکاناتی: ۷۴ هزار تومن (برنزی)
هزینه دیتابیس پستگرس: ۹۹ هزار تومن (۵۱۲ مگابایت رم - ۰.۵ هسته پردازنده - ۵ گیگ فضای ذخیره سازی)

جمعا: ۲۷۲ هزار تومن ماهانه معادل حدود 4.5 دلار در ماه
حالا اگه شما بخواید یه سرور مجازی بگیرید از یه دیتاسنتر خوب مث هتزنر یا OVH هم حدود ۵ دلار در ماه هزینه داره.
ولی منابعی که مثلا هتزنر دراختیارتون قرار میده میشه ۴ گیگابایت رم، ۲ هسته پردازنده، ۴۰ گیگ فضا!
به اضافه اینکه کیفیت زیرساختی خیلی بهتری داره.
در ادامه بنچمارک GTMetrics از یه سرویس نسبتا پرتصویر و عکس که روی هتزنر دارم و سایت شخصی خودم که هیچی نداره رو میذارم.

@Normal_Developer

اگه کانفیگ های v2ray که پول هم دادی براش کار نمیکنه این پست رو چک کن:

https://news.1rj.ru/str/normal_developer/25

@syntax_fa