Laravel API Service

#1

سلام دوستان
یک سوالی داشتم .
من میخوام یک فروشگاه اینترنتی بنویسم . همش در این فکر هستم که کلاً سیستم رو API Base کنم یعنی تمام عملیات حذف اضافه ذخیره و … به صورت API باشه و در backend و frontend پروژه از این API ها استفاده کنم . ولی وقتی به ایجکس شدن همه قسمت های سایت فکر میکنم به نظرم جالب در نمیاد . در صورتی هم در پروژه بزرگ معمولاً لیست API ها رو به فرانت کار میدن و فرانت کار با vuejs یا angular سایت رو بالا میاده منم نظرم همین بود ولی وقتی بخوام همه چیو API کنم ، اینجوری مجبور میشم backend هم به این شکل بنویسم که اصلا ضرورتی نداره . ممنون میشم بهترین ، استاندارد ترین روش رو معرفی کنید که باید چیکار کنم در این شرایط که میخوام اجزای پروژه رو جوری تقسیم بندی کنم که اندروید کار بتونه کار خودش رو انجام بده و فرانت کار هم همینطور

ممنون

#2

متوجه منظورتون نمیشم.
وقتی همه‌چیز بخواد توی بک-اند به صورت api باشه، فرانت-اند میتونه با (مثلا) react ساخته بشه و نسخه‌ی موبایل وبسایت هم از همون apiها استفاده کنه.
استفاده از ajax برای ساخت Single Page Application نه تنها جالب نیست، بلکه پر از دردسره. در حالی که ساختنش با react خیلی هم راحته.

مشکلتون با spa چیه دقیقا؟ چرا میگید ضرورتی نداره بک-اند به این صورت باشه؟

استاندارد ترین روش:
اولا که استاندارد خاصی وجود نداره. کلا به دو روش تقسیم میشه:

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

سیستم اول که همه باهاش آشنا هستن. ریکوئستهای get و post که از بروزر به سرور ارسال میشه و صفحه‌ی جدید برای بروزر ارسال میشه.
سیستم دوم میشه مثل همین وبسایت! جدای اینکه امکان لود وبسایت به صورت کلاسیک وجود داره (برای کسانی که js ندارن یا غیر فعالش کردن) صفحه در حقیقت فقط یک بار لود میشه و بعدش فقط بخشهای مورد نیاز ریفرش میشن. احتمالا بهترین ابزار برای ساخت وبسایتهای spa، ری‌اکت باشه.

1 Like
#3

همممم یه چیزایی رو دارین از هم جدا می کنین که منطقی نیست. ajax چیزه خاصی نیست. و از لحاظ تکنیکی با یه پروسه req/res فرقی نداره. حالا قدیما روشی که ازش برای پیاده سازی فرانت اند استفاده می شده جالب نبوده ولی با پیشرفت تکنولژی این فرایند بهتر شده و الان خیلی به این مدل از نرم افزار های فرانت اند می گن SPA. در باطن هنوز یه اتفاق داره می افته.

به نظر من خیلی مهم هست که API رو چه جوری طراحی کنین. در ضمن بک اند شما می تونه همون سرویس API شما باشه. شما یه API مناسب داشته باشید. کلاینت می تونه هرچی باشه. react یا یه اپ موبایل و غیره…

1 Like
#4

بنظرم مشکلی نداره که فرانت و هم بکند بصورت SPA باشند. چه بسا که تجربه کاربری بهتر و سریعتری رو به کاربر میده.

اگر اینطوری دوست ندارید برای فرانت API بسازید و فقط فرانت رو بصورت SPA بسازید و برای بکند همون روش سنتی رو استفاده کنید.

اگر نیاز دارید که اپتون API محور باشه که این مورد بسیار برای ساخت و توسعه اپلیکیشن‌های جانبی (مثل اپ اندرویدی و…) مناسب هست کل سایت (بکند و فرانت) بصورت API طراحی کنید. البته اینکار چالش‌های امنیت هم براتون ایجاد میکنه که باید به اونا هم فکر کنید.

1 Like
#5

:thinking: :thinking: :thinking: :thinking:

SPA یه مفهوم فرانت اند هست و کاری با بک اند نداره

1 Like
#6

صحیح. اما میشه برای بکند هم ازش استفاده کرد.

1 Like
#7

چه جوری ؟

#8

خب شما همون روشی که برای فرانت بکار بردی رو سمت بکندت هم بکار ببر. البته همونطور که گفتم چالش امنیتی داره …

1 Like
#9

هممم متوجه نمی شم. یه مثال بزنین ممنون می شم

#10

:joy:

#11

فکر کنم منظورشون این بود که:
«همه‌چیز در بک-اند به صورت api باشه و چیزی توی بک-اند رندر گرفته نشه»
vs
«بک-اند هم صفحات رو رندر بگیره و هم اینقدری api کامل داشته باشه که بشه فرانت-اند spa ساخت»

2 Likes
#12

چه نوع چالش امنیتی مثلاً ؟

#13

من فکر می کنم منظور ایشون از SPA سمت بک اند server side rendering هست

#14

باید حواسمون به یه سری چیزها باشه. مثلا اینکه کاربر نتونه apiهای سایتمون رو از توی کدها (یا devtools بروزر) بخونه و برداره توی یه سایت دیگه استفاده کنه، یا مثلا کسی نتونه خودشو به جای یه نفر دیگه جا بزنه (مثلا با دزدی توکن)

1 Like