کلوژر برای micro service

درود
دوستان من یه اپ دارم که میخوام بحث سفارشاتش رو جدا کنم تو قالب یک مایکرو سرویس برای اینکار میخوام از کلوژر استفاده کنم حالا سوال اینجاست که چه چالش هایی ممکنه سر راهم قرار بگیره و اینکه آیا کلوژر برای اینکار زبان مناسبی هست یا خیر؟

خود کلوژر، که روی JVM ران میشه پس استارت‌آپ کندی داره. از طرف دیگه، کلوژر، هسته‌ی بزرگی داره یعنی clojure.core خیلی بزرگه و featureهای خیلی زیادی توش هست. این باعث میشه که استارت‌آپ، از یه نرم‌افزار جاوای معمولی خیلی بیشتر بشه. درحد ۲-۳ ثانیه!!
همین مسائل، باعث میشه رم زیادی هم مصرف کنه.
پس برای میکروسرویس مناسب نیست.

حالا کلوژر رو (مثل هر چیز دیگه‌ای که به java bytecode کامپایل بشه) میشه با GraaVM کامپایل کرد و باهاش Native Image گرفت که این باعث میشه مصرف رم به شدت پایین بیاد و سرعت باز شدن اپلیکیشن هم خیلی، خیلی بیشتر بشه. واقعا چیز خفنیه!
فقط بدیش اینه که یه سری لایبرریهایی که با جاوا نوشته شدن (حتی اونایی که خیلی پرطرفدار هستن مثل Jetty) یه سری مشکلاتی دارن و اصولی ساخته نشدن. این باعث میشه که GraalVM نتونه اینا رو به صورت Native Image کامپایل کنه. این مساله درحدی فراگیره بین لایبرریهای جاوا، که من کلا بیخیالش شدم! ولی درمورد میکروسرویس، از اونجایی‌که اصولا هیچوقت از لایبرری‌های بزرگ استفاده نمیکنیم (و شاید اصلا از لایبرری استفاده نکنیم و همه‌چیز توی کد‌های خودمون نوشته بشه) این مشکل رو ندارید و میتونید به Native Image کامپایلش کنید.
ولی اینم چیزیه که از همون اول پروژه باید بهش فکر کنید و از همون اول باهاش پیش برید.

این از «کلوژر»


درمورد کلوژراسکریپت:
همه‌چیزش همون کلوژره ولی به جاوا‌اسکریپت کامپایل میشه و میشه توی بروزر (یا توی nodejs) اجراش کرد.
سرعت اجرای اولیش بالاتره، رم کمتری مصرف میکنه و… تنها فرقش هم اینه که لایبرریهای جاوا در دسترستون نیست و به جاش از لایبرریهای جاوا‌اسکریپت استفاده میکنید.
این میتونه گزینه‌ی مناسبی باشه. البته بازم برای میکروسرویس نمیدونم چقدر مناسبه چون به هر‌حال سایز خروجیش بزرگتر از کدی میشه که با خود جاوااسکریپت (و بدون اضافه کردن پکیجهای npm) نوشته باشید. (به خاطر همون که گفتم core بزرگی داره)


من نمیدونم از چه پلتفرمی استفاده میکنید ولی مثلا اگه با آمازون کار میکنید، بهترین راندمان رو توی پایتون خواهید داشت! حتی سریعتر از C!
به خاطر اینکه حتی C هم یه زمانی میبره برای warm up ولی پایتون (و جاوا اسکریپت) رو طوری پیاده کردن توی آمازون، که همیشه یه interpreter آماده‌ی ران کردن کدهای شما هست و دیگه اون تایم warmupش کمتر میشه. (دقیقا نمیدونم قضیه از چه قراره ولی اینو توی یه سری سرچی که خیلیوقت پیش زده بودم دیدم)

5 پسندیده

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

2 پسندیده

مثلا من بیام با کلوژر سیستم authentication رو پیاده کنم

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

بازم میریم سر همون حرف ربط نداشتن زبان برنامه نویسی به‌ موضوع اما در مورد کلوژر واقعا مشکل خاصی برای این نمیبینم مگر اینکه چیزی باشه که من ندونم.

1 پسندیده

زمان پیاده سازی و هزینه سخت افزاری نسبت به ریلز یا جنگو

جان؟ خیلی رمزی گفتی نگرفتم چی شد!

اگر منظورت مقایسه کلوژر با جنگو و ریلز باشه که راستش نمیدونم چطور میشه یک زبان برنامه نویسی رو با دوتا فریمورک مقایسه کرد اصلا. داری یکم برای خودت سختش میکنی

5 پسندیده

هیچ مشکلی وجود نداره، یه نگاهی به ktor هم بندازی بد نیست

3 پسندیده