سلام،
ممنون از شما آقای جوانبخت. در ارتباط با این جمله که می‌گه « این کار باعث ارسال درخواست های زیادی به سرور خواهد شد. اما آیا این امکان وجود دارد تا تنها با استفاده از یک درخواست به این مهم دست پیدا کنیم؟» شاید به این صورت بشه اصلاحش کرد که الزاما این طور نیست!!! زیرا می‌تونیم سمت سرور به هر تعداد که بخواهیم JOIN بزنیم و یک جیسون تر و تمیز داشته باشیم که حاوی کلیه اطلاعات کاربر هست که تنها با یک ریکوئست دریافت شده. در واقع، از این بعد REST هیچ کمبودی نسبت به GraphQL نداره.
سلام،
ممنون از شما آقای جوانبخت. در ارتباط با این جمله که می‌گه « این کار باعث ارسال درخواست های زیادی به سرور خواهد شد. اما آیا این امکان وجود دارد تا تنها با استفاده از یک درخواست به این مهم دست پیدا کنیم؟» شاید به این صورت بشه اصلاحش کرد که الزاما این طور نیست!!! زیرا می‌تونیم سمت سرور به هر تعداد که بخواهیم JOIN بزنیم و یک جیسون تر و تمیز داشته باشیم که حاوی کلیه اطلاعات کاربر هست که تنها با یک ریکوئست دریافت شده. در واقع، از این بعد REST هیچ کمبودی نسبت به GraphQL نداره.
سلام،
ممنون از شما آقای جوانبخت. در ارتباط با این جمله که می‌گه « این کار باعث ارسال درخواست های زیادی به سرور خواهد شد. اما آیا این امکان وجود دارد تا تنها با استفاده از یک درخواست به این مهم دست پیدا کنیم؟» شاید به این صورت بشه اصلاحش کرد که الزاما این طور نیست!!! زیرا می‌تونیم سمت سرور به هر تعداد که بخواهیم JOIN بزنیم و یک جیسون تر و تمیز داشته باشیم که حاوی کلیه اطلاعات کاربر هست که تنها با یک ریکوئست دریافت شده. در واقع، از این بعد REST هیچ کمبودی نسبت به GraphQL نداره.
سلام. ممنونم از نظر خوبتون. در اینجا یک مثال آوردیم و بله در این مثال خاص یک join ممکنه نیاز ما رو برآورده کنه (مشروط بر اینکه معماری دیتابیس طوری باشه که بشه join زد). اما چند نکته هست. اول اینکه ممکنه به دلیل جدا بودن سرویس ها از هم دیگه join زدن در لایه دیتابیس قابل انجام نباشه (یا بهینه نباشه). دوم ممکنه در صفحات مختلف رفتار اپلیکیشن ما تفاوت داشته باشه و در هر صفحه فیلدهای خاصی از داده رو لازم داشته باشیم. در این صورت با معماری REST نیاز به چند API مختلف داریم. و سوم ممکنه join های تو در توی زیادی داشته باشیم که در لایه دیتابیس استفاده از اون بهینه نیست. اینو در نظر بگیریم که معماری REST یا GraphQL بر هم برتری ندارن و هر کدوم در جای خودشون میتونن بهترین باشن. موفق و سربلند باشید 🌹🙏
سلام. ممنونم از نظر خوبتون. در اینجا یک مثال آوردیم و بله در این مثال خاص یک join ممکنه نیاز ما رو برآورده کنه (مشروط بر اینکه معماری دیتابیس طوری باشه که بشه join زد). اما چند نکته هست. اول اینکه ممکنه به دلیل جدا بودن سرویس ها از هم دیگه join زدن در لایه دیتابیس قابل انجام نباشه (یا بهینه نباشه). دوم ممکنه در صفحات مختلف رفتار اپلیکیشن ما تفاوت داشته باشه و در هر صفحه فیلدهای خاصی از داده رو لازم داشته باشیم. در این صورت با معماری REST نیاز به چند API مختلف داریم. و سوم ممکنه join های تو در توی زیادی داشته باشیم که در لایه دیتابیس استفاده از اون بهینه نیست. اینو در نظر بگیریم که معماری REST یا GraphQL بر هم برتری ندارن و هر کدوم در جای خودشون میتونن بهترین باشن. موفق و سربلند باشید 🌹🙏
کاش این دوره بصورت تصویری هم وجود داشت و می شد دید بهتری داشت ممنون
سلام، ممنون از شما آقای جوانبخت. در ارتباط با این جمله که می‌گه « این کار باعث ارسال درخواست های زیادی به سرور خواهد شد. اما آیا این امکان وجود دارد تا تنها با استفاده از یک درخواست به این مهم دست پیدا کنیم؟» شاید به این صورت بشه اصلاحش کرد که الزاما این طور نیست!!! زیرا می‌تونیم سمت سرور به هر تعداد که بخواهیم JOIN بزنیم و یک جیسون تر و تمیز داشته باشیم که حاوی کلیه اطلاعات کاربر هست که تنها با یک ریکوئست دریافت شده. در واقع، از این بعد REST هیچ کمبودی نسبت به GraphQL نداره.
سلام. ممنونم از نظر خوبتون. در اینجا یک مثال آوردیم و بله در این مثال خاص یک join ممکنه نیاز ما رو برآورده کنه (مشروط بر اینکه معماری دیتابیس طوری باشه که بشه join زد). اما چند نکته هست. اول اینکه ممکنه به دلیل جدا بودن سرویس ها از هم دیگه join زدن در لایه دیتابیس قابل انجام نباشه (یا بهینه نباشه). دوم ممکنه در صفحات مختلف رفتار اپلیکیشن ما تفاوت داشته باشه و در هر صفحه فیلدهای خاصی از داده رو لازم داشته باشیم. در این صورت با معماری REST نیاز به چند API مختلف داریم. و سوم ممکنه join های تو در توی زیادی داشته باشیم که در لایه دیتابیس استفاده از اون بهینه نیست. اینو در نظر بگیریم که معماری REST یا GraphQL بر هم برتری ندارن و هر کدوم در جای خودشون میتونن بهترین باشن. موفق و سربلند باشید 🌹🙏