Forwarded from Python BackendHub (Mani)
یکی از اشتباهات رایج و خیلی بد تو دیزاین دیتابیس که من دیدم خیلی انجام میدن اینه که سعی میکنن state یک entity رو با چند boolean ست کنند.
مثلا برای یوزر داریم:
is_active
is_banned
یا شما میتونی برای پردازش یک دیتایی اینطوری هم ذخیره کنی:
is_pending
is_success
اما خیلی پرکتیس بدیه. چرا؟ به ۲ دلیل:
۱. حالت هایی به وجود میاد از ترکیب این boolean ها که رخ دادنش ممکن نیست. مثلا چطوری میشه is_pending=true باشه و is_success هم true باشه؟ حالا هرچی جلوتر برید و تعداد boolean هاتون بیشتر شه این ترکیب هایی که امکان رخ دادنشون وجود نداره خیلی بیشتر میشه. مثلا ۴ تا boolean میشه ۱۶ حالت. آیا واقعا همه ۱۶ حالت رو دارین؟!
۲. راه حل دوم خیلی بهتره! راه حل دوم چیه؟استفاده از یک Enum تو دیتابیستون.
PENDING
SUCCESS
FAILED
حالا یک جایی نیازه که ایمیل بزنید اگه این پردازش موفقیت آمیز نبود. خیلی راحت میتونید رو همه حالت ها match case کنید. و در نهایت یک assert never هم قرار بدید.
اینطوری فردا اگه یک state جدید اضافه کنید به اپلیکیشنتون, همه جای کدتون ارور تایپینگ میخورید تا مجبور شید رفتار و ساید افکت state جدید رو تو همه جا هندل کنید.
@PyBackendHub
مثلا برای یوزر داریم:
is_active
is_banned
یا شما میتونی برای پردازش یک دیتایی اینطوری هم ذخیره کنی:
is_pending
is_success
اما خیلی پرکتیس بدیه. چرا؟ به ۲ دلیل:
۱. حالت هایی به وجود میاد از ترکیب این boolean ها که رخ دادنش ممکن نیست. مثلا چطوری میشه is_pending=true باشه و is_success هم true باشه؟ حالا هرچی جلوتر برید و تعداد boolean هاتون بیشتر شه این ترکیب هایی که امکان رخ دادنشون وجود نداره خیلی بیشتر میشه. مثلا ۴ تا boolean میشه ۱۶ حالت. آیا واقعا همه ۱۶ حالت رو دارین؟!
۲. راه حل دوم خیلی بهتره! راه حل دوم چیه؟استفاده از یک Enum تو دیتابیستون.
PENDING
SUCCESS
FAILED
حالا یک جایی نیازه که ایمیل بزنید اگه این پردازش موفقیت آمیز نبود. خیلی راحت میتونید رو همه حالت ها match case کنید. و در نهایت یک assert never هم قرار بدید.
اینطوری فردا اگه یک state جدید اضافه کنید به اپلیکیشنتون, همه جای کدتون ارور تایپینگ میخورید تا مجبور شید رفتار و ساید افکت state جدید رو تو همه جا هندل کنید.
match state:
case State.FAILED:
email_to_user()
case State.SUCCESS | State.FAILED:
pass # do nothing
case _:
assert_never(state)
@PyBackendHub
🔥9👍4
🚀 معرفی FastAPI
ـ FastAPI یه فریم ورک پایتونیه که باهاش میشه داخل پایتون api توسعه داد که تازگیا خیلییی بین پایتون کارا سرو و صدا کرده.
ـFastAPI یه فریمورک مدرن برای ساختن APIبا پایتون و ویژگی هایی مثل async/await که بهینه شده و... . خیلی از شرکتهای بزرگ مثل Netflix و Uber برای توسعه سرویسهاشون از FastAPI استفاده میکنن، و دلیلش هم مشخصه: سریع، ساده و انعطافپذیره.
💡 چرا FastAPI محبوبه؟
سریعترین فریمورک پایتون: FastAPI به لطف استفاده از Starlette و Pydantic، یکی از سریعترین فریمورکهای پایتون حساب میشه.
کدنویسی سریعتر: تایپهینتهای پایتون باعث میشه نوشتن کدها هم سریعتر باشه و هم باگهای کمتری داشته باشی.
مستندات خودکار: یکی از بهترین ویژگیهای FastAPI اینه که خودش بهطور اتوماتیک با Swagger UI و ReDoc مستندات API رو برات میسازه.
پشتیبانی از async/await: فست خیلی خوب از کدونیسی async ساپورت میکنه و یکی از دلایل محبوبیتشه.
🛠 ـFastAPI و کار با دیتابیس
وقتی میخوای با دیتابیس کار کنی، معمولاً از ORMها استفاده میکنی. تو FastAPI دو تا گزینه معروف داریم:
ـSQLAlchemy
ـSQLModel
حالا کدوم بهتره؟ بیاین دقیقتر بررسی کنیم:
ـ🔍 SQLAlchemy؛ قدیمی و قدرتمند
ـSQLAlchemy یکی از معروفترین ORMها برای پایتونه که زیاد استفاده میشه. انعطافپذیری بالایی داره و برای پروژههای پیچیده و بزرگ گزینه خیلی خوبیه.
مزیتها:
کنترل کامل روی کوئریها و عملکرد دیتابیس
پشتیبانی از تراکنشها و مدلهای پیچیده
جامعه کاربری بزرگ و منابع آموزشی زیاد
چالشها:
سینتکسش برای تازهکارها ممکنه سخت و پیچیده باشه
نوشتن کدهای زیاد برای مدلسازی
ـ🌀 SQLModel؛ ساده و مدرن
ـSQLModel یه کتابخونه جدیدتره که توسط خالق FastAPI یعنی Sebastián Ramírez توسعه داده شده. هدف SQLModel اینه که کار با دیتابیس رو سادهتر کنه و کدنویسی رو شبیه به Pydantic (برای ولیدیشن) بکنه.
مزیتها:
سینتکس خیلی ساده و خوانا
پشتیبانی از تایپهینتهای پایتون
هماهنگی عالی با FastAPI
کمتر شدن کدنویسی و مدلسازی سریع
چالشها:
هنوز نسبت به SQLAlchemy به بلوغ کامل نرسیده
برای پروژههای خیلی پیچیده ممکنه محدودیتهایی داشته باشه
⚡ مقایسه کدها
مدلسازی با SQLAlchemy:
مدلسازی با SQLModel:
همونطور که میبینید، SQLModel خیلی تمیزتر و کوتاهتره و شبیه به Pydantic میشه.
🎯 بالاخره SQLAlchemy یا SQLModel؟
اگه تازهکار هستی یا پروژهت کوچیکه و میخوای سریع کارت راه بیفته، SQLModel گزینه بهتریه. سینتکس سادهای داره و هماهنگیش با FastAPI عالیه.
ولی اگه پروژهت بزرگه یا نیاز به کنترل کامل و قابلیتهای بیشتر ORM داری ، SQLAlchemy انتخاب بهتریه.
خلاصه:
پروژههای کوچیک و متوسط SQLModel
پروژههای بزرگ و پیچیده SQLAlchemy
امید وارم مفید بوده باشه :)
ـ FastAPI یه فریم ورک پایتونیه که باهاش میشه داخل پایتون api توسعه داد که تازگیا خیلییی بین پایتون کارا سرو و صدا کرده.
ـFastAPI یه فریمورک مدرن برای ساختن APIبا پایتون و ویژگی هایی مثل async/await که بهینه شده و... . خیلی از شرکتهای بزرگ مثل Netflix و Uber برای توسعه سرویسهاشون از FastAPI استفاده میکنن، و دلیلش هم مشخصه: سریع، ساده و انعطافپذیره.
💡 چرا FastAPI محبوبه؟
سریعترین فریمورک پایتون: FastAPI به لطف استفاده از Starlette و Pydantic، یکی از سریعترین فریمورکهای پایتون حساب میشه.
کدنویسی سریعتر: تایپهینتهای پایتون باعث میشه نوشتن کدها هم سریعتر باشه و هم باگهای کمتری داشته باشی.
مستندات خودکار: یکی از بهترین ویژگیهای FastAPI اینه که خودش بهطور اتوماتیک با Swagger UI و ReDoc مستندات API رو برات میسازه.
پشتیبانی از async/await: فست خیلی خوب از کدونیسی async ساپورت میکنه و یکی از دلایل محبوبیتشه.
🛠 ـFastAPI و کار با دیتابیس
وقتی میخوای با دیتابیس کار کنی، معمولاً از ORMها استفاده میکنی. تو FastAPI دو تا گزینه معروف داریم:
ـSQLAlchemy
ـSQLModel
حالا کدوم بهتره؟ بیاین دقیقتر بررسی کنیم:
ـ🔍 SQLAlchemy؛ قدیمی و قدرتمند
ـSQLAlchemy یکی از معروفترین ORMها برای پایتونه که زیاد استفاده میشه. انعطافپذیری بالایی داره و برای پروژههای پیچیده و بزرگ گزینه خیلی خوبیه.
مزیتها:
کنترل کامل روی کوئریها و عملکرد دیتابیس
پشتیبانی از تراکنشها و مدلهای پیچیده
جامعه کاربری بزرگ و منابع آموزشی زیاد
چالشها:
سینتکسش برای تازهکارها ممکنه سخت و پیچیده باشه
نوشتن کدهای زیاد برای مدلسازی
ـ🌀 SQLModel؛ ساده و مدرن
ـSQLModel یه کتابخونه جدیدتره که توسط خالق FastAPI یعنی Sebastián Ramírez توسعه داده شده. هدف SQLModel اینه که کار با دیتابیس رو سادهتر کنه و کدنویسی رو شبیه به Pydantic (برای ولیدیشن) بکنه.
مزیتها:
سینتکس خیلی ساده و خوانا
پشتیبانی از تایپهینتهای پایتون
هماهنگی عالی با FastAPI
کمتر شدن کدنویسی و مدلسازی سریع
چالشها:
هنوز نسبت به SQLAlchemy به بلوغ کامل نرسیده
برای پروژههای خیلی پیچیده ممکنه محدودیتهایی داشته باشه
⚡ مقایسه کدها
مدلسازی با SQLAlchemy:
from sqlalchemy import Column, Integer, String
from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()
class User(Base):
__tablename__ = "users"
id = Column(Integer, primary_key=True, index=True)
name = Column(String, index=True)
مدلسازی با SQLModel:
from sqlmodel import SQLModel, Field
class User(SQLModel, table=True):
id: int = Field(default=None, primary_key=True)
name: str = Field(index=True)
همونطور که میبینید، SQLModel خیلی تمیزتر و کوتاهتره و شبیه به Pydantic میشه.
🎯 بالاخره SQLAlchemy یا SQLModel؟
اگه تازهکار هستی یا پروژهت کوچیکه و میخوای سریع کارت راه بیفته، SQLModel گزینه بهتریه. سینتکس سادهای داره و هماهنگیش با FastAPI عالیه.
ولی اگه پروژهت بزرگه یا نیاز به کنترل کامل و قابلیتهای بیشتر ORM داری ، SQLAlchemy انتخاب بهتریه.
خلاصه:
پروژههای کوچیک و متوسط SQLModel
پروژههای بزرگ و پیچیده SQLAlchemy
#python #fastapi
🔆 CHANNEL | GROUP
❤21👍5
❤10
Forwarded from Python BackendHub (Mani)
خیلیا منظور این متن رو متوجه نشدن، قرار نیست شما انجین دیتابیس بنویسی. ولی همین که بدونی چیه و بتونی راجبش ۵ دقیقه حرف بزنی خیلی مهمه چون بیشتر روز باهاش درگیری. یا بهتره خوده raw sql رو یاد بگیری تا اینکه orm django رو بدون یاد گرفتن sql استفاده کنی ازش.
ایا میشه بدون دونستن sql از جنگو استفاده کرد؟ بله. آیا در این صورت شما skilled worker محسوبمیشین؟ نه.
خیلی وقتا ممکنه بخاطر دانش بیشترتون، یک راهکار بهتر به ذهنتون برسه که برد بزرگی رو برای بیزنس رقم بزنه. به خاطر دانش بیشترتون، کدتون ممکنه باگ کمتری داشته باشه که براتون پروموشن خواهد داشت. و …
نقل قول ازنظرر Kurt Guntheroth، با ۴۰ سال سابقه و نویسنده چند کتاب معروف:
Some software jobs you can get after a 2-year Associate’s Degree from a community college, or a 9-month boot camp, just like a blue-collar job.
Some software jobs don’t require much independent thought and analysis. How hard is it to arrange content on a web site? (Yes, I know, as hard as you want to make it. But not always).
Some software jobs are done in assembly-line fashion. Pull the next feature card off the stack and start coding, pull the next bug report off the list and start looking for a fix. Your job has no beginning and no end, just an endless stream of little tasks (called sprints), with no time to rest in between, just like a blue-collar job.
Some bosses of software people are Dickensian horrors, driving their team to work long, uncompensated hours. Never a word of praise, but the sure prospect of getting fired for not toeing the mark, just like a blue-collar job.
But those same bosses will insist software is a white collar job, because if it ever did become a blue-collar job, they would have to pay time-and-a-half for overtime (in the US).
I think what’s true is that the software profession is diverging into two levels of skill, professional software developers, and programmers. Once upon a time it was like this, but the original reason for programmers (typing code onto punch cards and running it on batch terminals) went away. Now we’ve got easy problems solved by programmers with limited education, and really hard problems, solved by highly educated and trained professionals.
@PyBackendHub
ایا میشه بدون دونستن sql از جنگو استفاده کرد؟ بله. آیا در این صورت شما skilled worker محسوبمیشین؟ نه.
خیلی وقتا ممکنه بخاطر دانش بیشترتون، یک راهکار بهتر به ذهنتون برسه که برد بزرگی رو برای بیزنس رقم بزنه. به خاطر دانش بیشترتون، کدتون ممکنه باگ کمتری داشته باشه که براتون پروموشن خواهد داشت. و …
نقل قول ازنظرر Kurt Guntheroth، با ۴۰ سال سابقه و نویسنده چند کتاب معروف:
Some software jobs you can get after a 2-year Associate’s Degree from a community college, or a 9-month boot camp, just like a blue-collar job.
Some software jobs don’t require much independent thought and analysis. How hard is it to arrange content on a web site? (Yes, I know, as hard as you want to make it. But not always).
Some software jobs are done in assembly-line fashion. Pull the next feature card off the stack and start coding, pull the next bug report off the list and start looking for a fix. Your job has no beginning and no end, just an endless stream of little tasks (called sprints), with no time to rest in between, just like a blue-collar job.
Some bosses of software people are Dickensian horrors, driving their team to work long, uncompensated hours. Never a word of praise, but the sure prospect of getting fired for not toeing the mark, just like a blue-collar job.
But those same bosses will insist software is a white collar job, because if it ever did become a blue-collar job, they would have to pay time-and-a-half for overtime (in the US).
I think what’s true is that the software profession is diverging into two levels of skill, professional software developers, and programmers. Once upon a time it was like this, but the original reason for programmers (typing code onto punch cards and running it on batch terminals) went away. Now we’ve got easy problems solved by programmers with limited education, and really hard problems, solved by highly educated and trained professionals.
@PyBackendHub
❤4👍1
Python BackendHub
خیلیا منظور این متن رو متوجه نشدن، قرار نیست شما انجین دیتابیس بنویسی. ولی همین که بدونی چیه و بتونی راجبش ۵ دقیقه حرف بزنی خیلی مهمه چون بیشتر روز باهاش درگیری. یا بهتره خوده raw sql رو یاد بگیری تا اینکه orm django رو بدون یاد گرفتن sql استفاده کنی ازش.…
این پستو منظورش هست
https://t.iss.one/ninja_learn_ir/508
https://t.iss.one/ninja_learn_ir/508
Telegram
Ninja Learn | نینجا لرن 🥷
🚫 اگه مثل توضیحات بالا عمل میکنید، یک مهندس نرمافزار نیستید.
™️ @DjangoIR
〰️〰️〰️〰️〰️〰️
© @DjangoEx
™️ @DjangoIR
〰️〰️〰️〰️〰️〰️
© @DjangoEx
👍6👎1
دوستان گرامیم
یلداتون مبارک باشه ❤️🍉
امید وارم پیش خانواده خوش و خورم باشید ☺️
یلداتون مبارک باشه ❤️🍉
امید وارم پیش خانواده خوش و خورم باشید ☺️
❤17❤🔥7
از Redis کجاها استفاده کنیم؟ کجاها استفاده نکنیم؟ 🤔
ـRedis یکی از سریعترین و محبوبترین ابزارهای in-memory data store تو دنیاست. این ابزار هم به عنوان database، هم cache و هم message broker استفاده میشه . اما این که هرجایی ازش استفاده کنی، اصلا کار درستی نیست. تو این پست میخوایم بررسی کنیم کجا Redis انتخاب خوبیه و کجا بهتره سراغش نری.
کجاها از Redis استفاده کنیم؟
1⃣ ـCaching 🗃️
وقتی یه داده رو مدام از دیتابیس اصلی میخونی و نیاز به سرعت بالا داری، Redis میتونه به عنوان یه کش عالی عمل کنه. مثلا:
کش کردن نتایج کوئریهای سنگین 🔍
ذخیره صفحات رندر شده 📄
ذخیره session data برای کاربرها 👤
2⃣ـ Real-Time Analytics 📊
اگه میخوای یه داشبورد real-time بسازی که اطلاعات رو لحظهای نشون بده، Redis با ساختارهای داده سریعش (مثل sorted sets) میتونه خیلی کمککننده باشه.
3⃣ ـRate Limiting 🚦
وقتی میخوای تعداد درخواستهای کاربرها رو محدود کنی، مثلا برای جلوگیری از حملات DDoS یا اسپم، Redis یه گزینه عالیه.
4⃣ Pub/Sub Systems 📩
برای ارتباط بین سرویسها یا ارسال پیام در سیستمهای real-time مثل چتها، Redis با قابلیت publish/subscribe خیلی خوب عمل میکنه.
5⃣ـ Leaderboard ها و سیستمهای امتیازدهی 🏆
ساختار داده sorted sets برای ساختن رتبهبندیهای real-time (مثل امتیاز بازیکنها) ایدهآله.
کجاها از Redis استفاده نکنیم؟
1⃣ ذخیرهسازی دادههای پایدار 🛠
ـRedis یه in-memory database هست. یعنی دادهها رو تو حافظه ذخیره میکنه، نه روی دیسک. اگه برق بره یا سیستم ریاستارت بشه، دادهها ممکنه از دست برن. برای دادههایی که نمیخوای از دست برن، از دیتابیسهایی SQL مثل PostgreSQL یا Mysql یا ... استفاده کن.
2⃣ حجمهای بالا 📦
اگه حجم دادههات خیلی زیاده و رم کافی نداری، Redis انتخاب خوبی نیست. مثلا ذخیرهسازی دادههای سنگین مثل فایلها یا لاگها.
3⃣ آنالیزهای پیچیده 🤔
اگه نیاز به کوئریهای پیچیده داری (مثل join یا aggregation)، بهتره از دیتابیسهای relation-based مثل MySQL یا PostgreSQL استفاده کنی.
اشتباهات رایج در استفاده از Redis ‼️
1⃣ استفاده از Redis برای همهچیز ⚠️
خیلیا وقتی Redis رو یاد میگیرن، فکر میکنن باید همهچیز رو توش ذخیره کنن. ولی این ابزار برای همه نوع داده مناسب نیست. مثلا برای ذخیره تراکنشهای مالی یا دادههای حساس، بهتره از دیتابیسهای دیگه استفاده کنی.
2⃣ تنظیم نکردن TTL ⏳
اگه از Redis به عنوان کش استفاده میکنی ولی TTL (زمان انقضای دادهها) رو تنظیم نکنی، ممکنه حافظه پر بشه و سیستم کرش کنه.
3⃣ نادیده گرفتن محدودیت رم 🧠
ـRedis همه دادهها رو تو رم ذخیره میکنه. اگه حجم دادههات از ظرفیت رم بیشتر بشه، سیستم به مشکل میخوره.
4⃣ مدیریت نکردن replication 🔄
برای سیستمهای حساس، باید replication رو تنظیم کنی تا در صورت خرابی سرور اصلی، دادهها از بین نرن.
5⃣ عدم مانیتورینگ 📡
خیلیها Redis رو راه میندازن ولی هیچ وقت مانیتور نمیکنن که چقدر حافظه مصرف میشه یا چقدر latency داره. این اشتباه میتونه باعث مشکلات جدی بشه.
پیشنهاد: قبل از استفاده از Redis، نیازمندیهات رو مشخص کن و مطمئن شو این ابزار برای پروژهت مناسبه.
امید وارم مفید بوده باشه :) شیر یادت نره
ـRedis یکی از سریعترین و محبوبترین ابزارهای in-memory data store تو دنیاست. این ابزار هم به عنوان database، هم cache و هم message broker استفاده میشه . اما این که هرجایی ازش استفاده کنی، اصلا کار درستی نیست. تو این پست میخوایم بررسی کنیم کجا Redis انتخاب خوبیه و کجا بهتره سراغش نری.
کجاها از Redis استفاده کنیم؟
1⃣ ـCaching 🗃️
وقتی یه داده رو مدام از دیتابیس اصلی میخونی و نیاز به سرعت بالا داری، Redis میتونه به عنوان یه کش عالی عمل کنه. مثلا:
کش کردن نتایج کوئریهای سنگین 🔍
ذخیره صفحات رندر شده 📄
ذخیره session data برای کاربرها 👤
2⃣ـ Real-Time Analytics 📊
اگه میخوای یه داشبورد real-time بسازی که اطلاعات رو لحظهای نشون بده، Redis با ساختارهای داده سریعش (مثل sorted sets) میتونه خیلی کمککننده باشه.
3⃣ ـRate Limiting 🚦
وقتی میخوای تعداد درخواستهای کاربرها رو محدود کنی، مثلا برای جلوگیری از حملات DDoS یا اسپم، Redis یه گزینه عالیه.
4⃣ Pub/Sub Systems 📩
برای ارتباط بین سرویسها یا ارسال پیام در سیستمهای real-time مثل چتها، Redis با قابلیت publish/subscribe خیلی خوب عمل میکنه.
5⃣ـ Leaderboard ها و سیستمهای امتیازدهی 🏆
ساختار داده sorted sets برای ساختن رتبهبندیهای real-time (مثل امتیاز بازیکنها) ایدهآله.
کجاها از Redis استفاده نکنیم؟
1⃣ ذخیرهسازی دادههای پایدار 🛠
ـRedis یه in-memory database هست. یعنی دادهها رو تو حافظه ذخیره میکنه، نه روی دیسک. اگه برق بره یا سیستم ریاستارت بشه، دادهها ممکنه از دست برن. برای دادههایی که نمیخوای از دست برن، از دیتابیسهایی SQL مثل PostgreSQL یا Mysql یا ... استفاده کن.
2⃣ حجمهای بالا 📦
اگه حجم دادههات خیلی زیاده و رم کافی نداری، Redis انتخاب خوبی نیست. مثلا ذخیرهسازی دادههای سنگین مثل فایلها یا لاگها.
3⃣ آنالیزهای پیچیده 🤔
اگه نیاز به کوئریهای پیچیده داری (مثل join یا aggregation)، بهتره از دیتابیسهای relation-based مثل MySQL یا PostgreSQL استفاده کنی.
اشتباهات رایج در استفاده از Redis ‼️
1⃣ استفاده از Redis برای همهچیز ⚠️
خیلیا وقتی Redis رو یاد میگیرن، فکر میکنن باید همهچیز رو توش ذخیره کنن. ولی این ابزار برای همه نوع داده مناسب نیست. مثلا برای ذخیره تراکنشهای مالی یا دادههای حساس، بهتره از دیتابیسهای دیگه استفاده کنی.
2⃣ تنظیم نکردن TTL ⏳
اگه از Redis به عنوان کش استفاده میکنی ولی TTL (زمان انقضای دادهها) رو تنظیم نکنی، ممکنه حافظه پر بشه و سیستم کرش کنه.
3⃣ نادیده گرفتن محدودیت رم 🧠
ـRedis همه دادهها رو تو رم ذخیره میکنه. اگه حجم دادههات از ظرفیت رم بیشتر بشه، سیستم به مشکل میخوره.
4⃣ مدیریت نکردن replication 🔄
برای سیستمهای حساس، باید replication رو تنظیم کنی تا در صورت خرابی سرور اصلی، دادهها از بین نرن.
5⃣ عدم مانیتورینگ 📡
خیلیها Redis رو راه میندازن ولی هیچ وقت مانیتور نمیکنن که چقدر حافظه مصرف میشه یا چقدر latency داره. این اشتباه میتونه باعث مشکلات جدی بشه.
پیشنهاد: قبل از استفاده از Redis، نیازمندیهات رو مشخص کن و مطمئن شو این ابزار برای پروژهت مناسبه.
#برنامه_نویسی #db #redis
🔆 CHANNEL | GROUP
🔥15👍6❤3
اگه تجربه ای دارید یا چیزی دوست دارید به برنامه نویسای کشورتون بگید میتونید به پیوی من بفرستید تو کانال قرار بدم 👇
@mohammad_strout
@mohammad_strout
🔆 CHANNEL | GROUP
👍4❤1
👌19👍9❤2👎1
❤9👏2👌1