TondTech – Telegram
TondTech
2.65K subscribers
1.48K photos
169 videos
133 files
1.16K links
کالای ما دانش است


تبلیغات نداریم
Download Telegram
دوپامین ارزان.pdf
454.3 KB
شیطان مدرن..
پ.ن، اسلایدها و تایتل مال خودم نیست. ولی جالب بود. رفرنس اصلی رو هم نیافتم متاسفانه
3
Forwarded from Zoomit | زومیت
سرویس‌های ابردراک از ۳۰ بهمن متوقف می‌شود

🔴 ابردراک در بیانیه‌ای با اشاره به محدودیت‌های مالی اعلام کرد که تا پایان بهمن ماه سرویس‌های خود را قطع خواهد کرد:

🔴 در راستای این تصمیم کلیه سرویس‌های ابر دراک ظرف ۱۰ روز آینده قطع خواهد شد و ابردراک متعهد شده است در کوتاه‌ترین زمان ممکن داده‌های کاربران را به صورت ایمن و کامل بازگرداند.

🔴 سینا سلطانی مدیرعامل ابردراک در این بیانیه «اختلاف نظرهای بنیادین با سهامداران» دلیل توقف فعالیت‌های این شرکت عنوان کرده است:

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


🔴 سلطانی اظهار امیدواری کرده ابردراک با ترکیب سهامداری جدید خود بتواند مشکلات را رفع و بار دیگر بتواند فعالیت‌ها و ارائه خدماتش را از سر بگیرد.

👨‍💻 @TheZoomit
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1👎1
Forwarded from Refhub Books
نام کتاب: The molecule of more : how a single chemical in your brain drives love, sex, and creativity--and will determine the fate of the human race
نویسنده: Daniel Z. Lieberman;Michael E. Long
دسته بندی: Unordered
سال انتشار: 2018
تعداد صفحات: 256
قیمت با جلد نرم: 234,680 تومان
📚 **مولکولِ بیشتر**
این کتاب جذاب از **دنیل لیبرمن** و **مایکل لانگ** به نقش دوپامین در زندگی ما می‌پردازد؛ از عشق و خلاقیت گرفته تا جاه‌طلبی و تصمیم‌گیری. اگر می‌خواهید بدانید چطور یک ماده شیمیایی سرنوشت انسان‌ها را تغییر می‌دهد، این کتاب را از دست ندهید!
Forwarded from Delpak Log
جلسه بازاندیشی (Retrospective) در بهبود فرآیند توسعه محصول و بلوغ شیوه‌ همکاری ذینفعان، از اهمیت بسیار و نقش بی‌بدیلی برخوردار است. با این حال این پرسش اساسی مطرح است که آیا «شیوه‌ی مرسوم» برگزاری این جلسات، می‌تواند تاثیری پایدار، ملموس و سودمند داشته باشد؟

اگر چهارچوب‌های اسم و رسم‌دار چابکی را مرور کنید، خواهید دید که همگی شیوه‌ای یکسان را برای برگزاری این جلسه پیشنهاد کرده‌اند:

🔹در آغاز: اعضای تیم با همکاری یک تسهیل‌گر شروع به نوشتن اتفاقات و اقداماتی می‌کنند که به گمان آنها خوب و خوشحال‌کننده بوده‌اند و یا بد و آزاردهنده.

🔹در میانه: سعی می‌شود به شکلی دموکراتیک، برخی از موضوعات مطروحه، انتخاب و به بحث گذاشته شوند.

🔹سرانجام: سعی می‌شود تا بر پایه توافقی جمعی (مبتنی بر آرای اکثریت) برخی اقدامات که به گمان اعضای تیم باعث بهبود و رضایت می‌شود، انتخاب شوند و همگی متعهد به رعایت آنها شوند.

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

نظریه‌ی زمینه (Theory of Context) چیست؟
در حوزه جامعه‌شناسی، تصمیماتی که توسط بازیگران گرفته می‌شود، عموما به طور توامان به خشنودی جمعی و ناخشنودی جمعی دیگر منجر می‌شود. این تصمیمات که باعث اعطا یا سلب امتیاز به/از کسانی ‌می‌شود، ذیل سرفصل «سیاست‌گذاری عمومی» مطالعه می‌شود. از این منظر، جلسه بازاندیشی اسپرینت هم نوعی از سیاست‌گذاری عمومی است که می‌تواند با وضع قوانینی هر چند محلی و محدود باعث شود توزیع امکانات و اختیارات به شکلی انجام شود که عده‌ای رضایتمند و عده‌ای ناراضی شوند. مثلا در ساحت جامعه ایران، نهادی مسؤل در حاکمیت تصمیم می‌گیرد تا در قالب طرح جوانی جمعیت به والدینی که صاحب فرزند می‌شوند امتیاز خودرو اعطا شود. یا در مقیاسی خردتر، در یک تیم عده‌ای تصمیم می‌گیرند که برای افزایش انگیزه، ساعت‌هایی در هفته به مطالعه‌ی آزاد اختصاص یابد.

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

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

نظریه‌ی تغییر (Theory of Change) چیست؟
نظریه‌ی تغییر در کنار نظریه‌ی زمینه، یکی از پایه‌های اساسی تصمیم‌گیری و سیاست‌گذاری است. در حالی که نظریه‌ی زمینه به ما می‌گوید «چرا وضعیت موجود به این شکل درآمده است»، نظریه‌ی تغییر به این پرسش پاسخ می‌دهد که «چگونه می‌توان این وضعیت را تغییر داد؟» نظریه‌ی تغییر نمایانگر یک دستگاه فکری است که نشان می‌دهد برای رسیدن به یک هدف خاص، چه مداخله‌هایی باید انجام شود، چرا باید انجام شود و چه عوامل و شرایطی باید تغییر کنند تا آن هدف محقق شود.

یک نظریه‌ی تغییر مناسب، زنجیره‌ای از روابط علّی و معلولی را شرح می‌دهد که در نهایت به تغییر مطلوب منجر می‌شود. این نظریه نه‌ تنها نقطه‌ی نهایی مطلوب را مشخص می‌کند، بلکه مسیر دستیابی به آن را نیز با جزییات توضیح می‌دهد. این موضوع در حوزه‌ی سیاست‌گذاری عمومی، مدیریت سازمانی و حتی در سطح تیم‌های چابک اهمیت حیاتی دارد.
Learning-With-M-E02
Masoud DaneshPour
☄️ در هفته های گذشته درگیر توسعه یک فیچر بودم و مجبور بودم روی کد های زیادی تغییرات ایجاد کنم و یا باگ هایی رو رفع کنم، در این بین یه سری پیشنهاد به نظرم رسید که وقتی میخوایم روی پروژه در یک شرکت بزرگ کار کنیم، خیلی خوب میشه که اونها رو رعایت کنیم.

✔️این قسمت پادکست در مورد اینه که چطور اسنادی رو آماده کنیم که برای توسعه و نگهداری محصول راه کمتری رو طی کنیم و سریع تر به مقصد بریسیم !

00:52 سلام و معرفی
01:31 تشریح موضوع پادکست
02:34 اسناد مربوط به راه اندازی و تنظیمات اولیه
07:22 اسناد توسعه Feature
08:35 اسناد مربوط به پایش و رفع Bug
10:42 دو نکته مهم !

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

📱 @Learning_With_M
🔗 https://academy.daneshpour.ir

#podcast #tech
👍61
.
🕊11👍3🔥1😢1🤣1
گِرِپ‌- سریع ترین موتور جستجوی کد در جهان

وقتی گیتهاب کم میاره، گرپ اپ وارد میشه!

تا حالا شده دنبال یه قطعه کد بگردی و سرچ گیتهاب اذیتت کنه؟
یا بخوای ببینی یه فانکشن خاص توی کلی ریپو چجوری استفاده شده؟

اینجاست که grep.app می‌تونه نجاتت بده! یه موتور جستجوی سریع برای کد که بهت اجازه می‌ده با Regex بگردی، کدهای اوپن‌سورس رو بکاوی و خیلی راحت‌تر اون چیزی که می‌خوای رو پیدا کنی.
چندتا ویژگی خفن:
- جستجوی سریع و دقیق توی مخازن عمومی GitHub
- پشتیبانی از Regex برای فیلترهای حرفه‌ای
- امکان جستجو توی چندین زبان برنامه‌نویسی

اگه تا حالا ازش استفاده نکردی، یه بار امتحانش کن، شاید عاشقش شدی!

@DevTwitter | <Bahare Zarei/>
👍21
Forwarded from tech-afternoon (Amin Mesbahi)
این روزها تقریبا یکسالگی TUnit است. یه کتابخونه جدید برای نوشتن Unit، Integration، Acceptance و هر جور تست دیگه‌ای توی دات‌نت. حدود ۱۹۱هزار دانلود NuGet داشته و توسعه‌اش فعلا خیلی فعاله و جزو گیت‌هاب ترند هست.

ولی چرا؟
خب می‌دونیم که NUnit عملا پورت شده‌ی JUnit جاوا است، و xUnit انشعابی بهبود یافته از NUnit.
خود NUnit که باقیمانده دوران SharpTestEx و Lin Unit و NUnitEx و NUnitAsp است که حتی ریپوهاشون هم هفت کفن پوسوندن، نزدیک به ۲۰ سال قدمت داره. درسته که همواره به‌روز شده و پوست‌اندازی داشته و امروز یه محصول بالغه؛ ولی مدت‌هاست تغییرات بزرگی نداره و فقط باگ و بوگ (بوگ به مفهوم باگچه، و باگ کوچک است) برطرف می‌کنه. (تاریخچه JUnit هم برمی‌گرده به یه پرواز بین زوریخ و آتلانتا در سال ۱۹۹۷! و الان نسل پنجم خودش رو تجربه می‌کنه)

واقعیت اینه که دنیای تست از نظر مفهوم و ساختار تغییرات انقلابی خاصی نداشته. لذا این لایبری‌ها هم فرصت داشتن تا بالغ و پایدار بشن.

چی‌ شد که TUnit متولد شد؟
اون لک‌لکی که TUnit رو توی گیت‌هاب git push کرد، و خودش هم می‌گه از NUnit و xUnit الهام گرفته، چند تا هدف داشت:
- یکی کدبیس مدرن از ابتدا
- بهبود سرعت اجرای تست

دقت کنید که این داستان «هیچ ربطی» به تیمی که هنوز توی بدیهیات تست‌نویسی گیر کرده و کاوریجش ۳۰ درصده نداره! بلکه برای تیمیه که می‌خواد از یک کتابخونه برای همه نوع تستش استفاده کنه، هزاران تست داره و سرعت اجرای تست‌ها می‌تونه تجربه توسعه‌دهنده و دواپس رو بهبود بده.
مثلا: TUnit از source generators تا جای امکان به جای reflection استفاده می‌کنه و AOT رو به خوبی پشتیبانی می‌کنه.

مثال دوم: کدبیس مدرنش به شما Hooks, Events روی کل Lifecycles تست می‌ده؛ یعنی قبل و بعد از ،TestDiscover ،TestSession، Assembly، Class، Test. مثلا شما با ایونت مطلع می‌شید تست شروع شد، تست وارد فلان مرحله شد و... این هم به درد تست‌نویس می‌خوره هم به‌درد اون بدبختی که پایپ‌لاین DevOps شما رو توسعه می‌ده.

مثال سوم: از بیخ به شما اجازه پاس دادن انواع داده برای تست رو میده. این به معنای ناتوانی xUnit نیست، بلکه پیاده‌سازی راحت‌تر و مدرن‌تره. وقتی شما سرعت 321.7 میلی‌ثانیه TUnit در مقابل ۱۴ ثانیه xUnit به کارتون میاد، که اولا «واقعنکی» (به معنی خیلی واقعی) تست می‌نویسید. دوم اینکه تعداد زیادی تست دارید و... البته این تفاوت زیاد، فقط در برخی موارد است چون TUnit قابلیت AOT دارد و در خیلی از موارد تفاوت حداقل هنوز اینقدرها نیست.

ولی این سرعت توسعه مداوم و یکپارچگی با IDEها وقابلیت Analyzer درونی اونم از ابتدای راه و اقبالی که جامعه دات‌نت بهش داشته، آینده خوبی براش رقم می‌زنه. خدا از من نگذره اگر ذره‌ای قصد «امروزه عصر، عصر توسعه تست با TUnit است» داشته باشم... 😅 ایها‌الناس: شما «بِتِست، بمیر و بِتِست!»

ریپو
مستندات
🔥92
پس رفت یک سازمان Product-Led به سمت مدیریت پروژه زنگ خطریه برای آدمهای کلیدی اون سازمان. این روزها زیاد میشنویم از این طرف و اون طرف که خیلی از سازمان های خوب ما دارن به سمت مدیریت پروژه و بدتر از اون مدیریت کیسه شنی میرن، شاید وقت کردم و کمی درباره ش صحبت کردم باهاتون.
شما تجربه ای ازش دارین ؟
👍3
به دوستان خوبم در #ابر_زس سابق و #آبالون جدید تبریک میگم، حرکت خیلی خوبی انجام شده، و من به اندازه خودم در جریانم که واقعا بچه ها تلاش میکردن نیازهای واقعی بیزنس ها رو کشف کنند. خروجی هم الان دیدم و واقعا یه رشد همه جانبه بود.
قطعا روزهای سخت و پر تلاشی رو گذروندید، اما مطمئنم این روزها خستگیش از تنتون داره درمیاد.
Abalon | آبـالون
بهترین ها رو براتون آرزو دارم..
https://abalon.cloud/
5
Forwarded from refhub
تا امروز، افتخار خدمت به 7000 کاربر عزیز رو داشتیم ❤️
🔥10
مانوئل برگشته با یه دوره اجرایی 🔥
تو این دوره، یه کسب‌وکار واقعی رو قدم به قدم با هم می‌سازیم!
از ایده تا جذب سرمایه 🚀
کد تخفیف 500 تومانی: esmm3
جا نمونی، ظرفیت محدوده👇
esmn.ir/esmum
ایسمینار
لغو11
👎15🔥1
بدرود،
ای حجم آرزویی که در خاک کاشته خواهی شد..
💔40👎1
سرویس Pay.ir که اولین درگاه پرداخت واسط بود (اون موقع برند payline رو داشت سجاد عزیز) و از قوی ترین های بازار، امروز برای همیشه سرورهاش رو خاموش کرد، ظلمی که به pay.ir شد رو به هیچ شکل نمیشه هضم کرد، این سطح از حماقت در حکمرانی یک مملکت که کارآفرین برتری مثل سجاد چاری پور رو به جای تشویق به گسترش خدمات و توانایی هاش با دو سال پرونده سازی و بازی درآوردن به جایی میرسونه که سرویس رو در نهایت خاموش کنه، نوبر که هیچ در سطح جهان بی نمونه ست.
وا اسفا برای این وضع مملکت، وا اسفا برای این وضع اکوسیستم، وا اسفا برای این وضعیتی که در آن گیر افتاده ایم...
رویای کارآفرینی همچنان زخمی خواهد بود بر پیکر نحیف باقی مانده ی این اکوسیستم.
https://www.linkedin.com/feed/update/urn:li:activity:7296496358138494976/
💔14👎1
Forwarded from .NET Fun
جلسات منتورشیپ رو خیلی دوست دارم. کلی آدم خفن با ایده ها و چالش های باحال میان و با هم گپ میزنیم و سعی میکنیم به یه راه حل خوب برسیم.
دمتون گرم که تا الان همراه بودین

برای رزرو جلسه منتورشیپ:
https://adplist.org/mentors/babak-taremi
خوب سرتیفیکت رو به من هم دادن، با این تفاوت که من تایمم خیلی پره، فعلا حتما با بابک جلو برید
🔥6
Forwarded from tech-afternoon (Amin Mesbahi)
✍️مرور چند روش رایج صفحه‌بندی (Pagination) در API Design

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

و این خیلی مهم می‌شه که روش استاندارد و یکسانی داشته باشیم تا یکی شماره صفحه و تعداد رو توی GET نگیره یکی توی POST تا بتونیم هم جلو بار اضافی به سرور رو بگیریم هم کاربری یا توسعه‌دهنده‌ای که با API سر و کار داره دیوانه نشه!

1️⃣ روش Offset & Limit (یا Page & Size)

GET /users?limit=10&offset=20

این روش ساده و سرراسته، و امکان دسترسی مستقیم به صفحه دلخواه رو فراهم می‌کنه. ولی وقتی دیتاست خیلی بزرگ شه، مستعد درخواست‌های عمدی یا سهوی کند کننده است! یا اگر داده‌ها مرتب تغییر کنن، شما یا یه چیزی از قلم می‌ندازی یا تا بری صفحه ۲، دیتای صفحه ۱ افتاده توی صفحه ۲! (نرخ بالای تغییرات) کوئری‌اش هم اینجوریه:
-- SQL Server:
SELECT * FROM users
ORDER BY id
OFFSET 20 ROWS
FETCH NEXT 10 ROWS ONLY;

-- PostgreSQL:
SELECT * FROM users
ORDER BY id
LIMIT 10 OFFSET 20;

-- MongoDB:
db.users.find()
.sort({ id: 1 })
.skip(20)
.limit(10);


2️⃣ روش Cursor-based Pagination
توی این روش به جای استفاده از offset، از یک نشانگر (cursor) استفاده می‌کنیم که به عنوان مرجع برای ادامه‌ی داده‌ها عمل می‌کنه. معمولاً این cursor می‌تونه آخرین مقدار یک فیلد کلیدی مثل id یا تاریخ ایجاد باشه.
GET /users?limit=10&cursor=eyJpZCI6IDIwMH0=

این روش کارایی بهتری توی داده‌های بزرگ داره، یکی از دلایلش اینه که نیازی سورت کردن داده و بعدش رد کردن تعدادی رکورد نداره! بلکه مستقیم (با کمک ایندکس البته) می‌ره سراغ رکورد مورد نظر و تامام. اگر داده‌ها مرتب تغییر کنن، باز کاربر مسیر خودش رو پیمایش می‌کنه و داده‌های تکراری نمی‌بینه یا داده‌هایی رو از دست نمی‌ده.
ولی: پیچیدگی پیاده‌سازیش بیشتره. صفحه ۵ الزامان برای همه و در همه زمان‌ها یک داده‌ رو نشون نمی‌ده.
برای مقیاس بزرگ این روش مناسب‌تره، اون بار تحمیلی سورت و skip توی مقیاس بزرگ کمرشکنه!

3️⃣روش Seek-pagination (Keyset Pagination)
روش seek-pagination یا keyset pagination به روش cursor-based شباهت داره، ولی به صورت صریح از شرایط WHERE استفاده می‌کنه تا رکوردهایی که بعد از آخرین مقدار دیده شده قرار دارن رو برگردونه.
GET /orders?limit=10&last_id=1000

در اینجا فرض می‌کنیم که last_id نشان‌دهنده‌ی آخرین id دیده شده در صفحه قبلی هست. سرور از شرط WHERE id > 1000 استفاده می‌کنه تا رکوردهای بعدی رو برگردونه.

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


4️⃣روش Time-Based Pagination
GET /events?since=2023-10-01&until=2023-10-08


5️⃣روش Hypermedia (HATEOAS) Links
Link: </items?cursor=def456>; rel="next", </items?cursor=abc123>; rel="prev"


6️⃣روش Metadata in Responses
{
"data": [...],
"pagination": {
"total": 1000,
"next_cursor": "def456",
"has_more": true
}
}


💬 اولندش بحث؟ نظر؟ تجربه؟ دُوُمَندش ۴ و ۵ و ۶ رو توضیح ندادم که الکی مثلا کنجکاوی ایجاد کنم، هزاران و میلیان‌ها ری‌اکشن ⚙️ بدید که توضیح بدم و بگم چرا روش HATEOAS روش منطبق با REST principles ذیل discoverability است!! 😅 سِوُمَندش دون بپاشم برای پرداختن عمیق‌تر به اهمیت ایندکس و درک ساختاریش، بعد از یخورده مطلب حول طراحی API نوشتم...

#API_Design
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
Forwarded from tech-afternoon (Amin Mesbahi)
✍️2️⃣ توضیح روش‌های ۴ تا ۶ صفحه‌بندی (Pagination) در API

4️⃣ روش Time-Based Pagination
وقتی داده‌هامون به ترتیب زمان ثبت می‌شن (مثلاً رویدادهای یک سیستم لاگ یا خبرنامه‌های زنده)، می‌تونیم با استفاده از پارامترهایی مثل since و until بازه‌ی زمانی دلخواهمون رو مشخص کنیم.
مثال:

GET /events?since=2025-01-01&until=2025-01-10

اینجا API رو طوری طراحی می‌کنیم که همه‌ی رویدادهایی که بین اول تا دهم ژانویه اتفاق افتاده رو برگردونه.

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

5️⃣ روش Hypermedia (HATEOAS) Links
روش HATEOAS (Hypermedia As The Engine Of Application State) یکی از اصول کلیدی REST هست. توی این روش، پاسخ‌های API شامل لینک‌هایی به صفحات بعدی یا قبلی هستند. این لینک‌ها معمولاً در هدر یا بدنه‌ی پاسخ قرار می‌گیرند و به کلاینت می‌گن «برای ادامه اینجا رو ببین» یا «صفحه قبلی اینجاست».
مثال:
Link: </items?cursor=def456>; rel="next", </items?cursor=abc123>; rel="prev"

توی این مثال، لینک‌های next و prev به کلاینت کمک می‌کنن بدون اینکه خودشون URL ها رو بسازن، به صفحات بعدی یا قبلی دسترسی پیدا کنن.

بزرگ‌ترین مزیتش علاوه بر استاندارد بودن، اینه که کلاینت‌ها نیازی به دونستن ساختار URL‌ها ندارن؛ API خودش مسیر بعدی رو بهشون میگه. در ضمن به راحتی می‌شه لینک‌های مختلف (مثلاً first، last، یا حتی لینک‌های مرتبط) رو اضافه کرد.از طرفی مدیریت و تولید این لینک‌ها به دقت نیاز داره تا همه‌ی روابط درست تعریف بشه؛ و استفاده از هدرهای HTTP اضافی ممکنه برای برخی کلاینت‌ها و ابزارها پیچیده باشه.


6️⃣ روش Metadata in Responses
توی این روش، به جای ارسال اطلاعات صفحه‌بندی در هدر، کل متادیتا (مثل تعداد کل رکوردها، cursor بعدی، و وضعیت وجود صفحه‌ی بعدی) رو توی بدنه‌ی پاسخ JSON می‌گنجونیم. این کار باعث می‌شه کلاینت به راحتی اطلاعات لازم رو از یک جا دریافت کنه.

{
"data": [...],
"pagination": {
"total": 1000,
"next_cursor": "def456",
"has_more": true
}
}

اینجا کلاینت علاوه بر داده‌های اصلی، اطلاعات کاملی از وضعیت صفحه‌بندی دریافت می‌کنه. خوبیش اینه که همه‌ی اطلاعات مورد نیاز برای صفحه‌بندی توی یک JSON مشخص هستن و خوانایی بالایی هم داره چون ساختار JSON معمولاً برای توسعه‌دهنده‌ها آشنا و راحته. ولی از اون سمت اضافه کردن متادیتا ممکنه حجم پاسخ رو کمی بیشتر کنه. همچنین با استانداردهای هدر HTTP در تضاده؛ یعنی برخی استانداردهای REST ترجیح می‌دن اطلاعات مربوط به ناوبری در هدر قرار بگیره، اگرچه این موضوع بیشتر یک نکته سبک‌سازیه تا یک مشکل جدی.

💬 نظر؟ بریم سراغ موضوع دیگه: 🤓
یا روی API Design ادامه بدیم: ⚙️

اگر روی API Design بمونیم:
- موضوع API Documentation و Discoverability
- استراتژی‌های مدیریت نسخه‌بندی API در طول زمان (API Evolution)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥1
تو به jack S3 فکر میکنی و من به S3 Storage ، ما مثل هم نیستیم 😁
👎1