چرا توسعه دهندگان باید پایگاه داده را در ابتدا قرار دهند

داده ها قلب تجربه کاربر هستند، بنابراین آیا توسعه دهندگان نباید از آنجا شروع کنند؟ SQLite، پایگاه‌های داده NoSQL و انتزاعی‌هایی مانند Neurelo انجام این کار را بسیار آسان‌تر می‌کنند.

توسعه دهندگان در سن خاصی عادت دارند سفر توسعه برنامه خود را با انتخاب یک سیستم عامل آغاز کنند. در مقابل، توسعه دهندگان جوان ممکن است با انتخاب یک ابر شروع کنند. یکی از معتبرترین صداها در فناوری نقطه شروع متفاوتی را پیشنهاد می‌کند، نقطه شروعی که توجه را بر مهمترین مؤلفه پشته برنامه متمرکز می‌کند: پایگاه داده. همانطور که Kelsey Hightower می نویسد، “در اوایل من اشتباه کردم که فقط روی سیستم عامل ها تمرکز کردم و نادیده گرفتم چیزی که من اکنون مهمترین عنصر محاسبات را در نظر می گیرم: داده ها.”

او تنها نیست. بنیانگذار Gatsby.js، کایل متیوز، به نتایج مشابهی رسیده است: “من ۱۰۰٪ به [پایگاه داده” تغییر داده ام ]-اولین بار هنگام نمونه سازی. در دنیایی که داده ها قلب تجربه کاربر هستند، منطقی است که به جای انتخاب چارچوب زبان، به عنوان مثال، و استفاده از هر پایگاه داده ای که همراه آن است، رویکرد اول داده را در پیش بگیریم. با این حال، گفتن این رویکرد ممکن است برای برخی آسان‌تر از انجام آن باشد، که باعث می‌شود پلتفرم‌های API ابری مانند Neurelo به یک برنامه کاربردی خوب تبدیل شوند. رمپ برای توسعه دهندگانی که می خواهند پایگاه داده را در ابتدا قرار دهند اما ممکن است ندانند چگونه.

داده‌ها، داده‌ها، همه جا

خبر مهم از همه تماس‌های اخیر درآمدهای ابری، AI است و اینکه چگونه مصرف خدمات ابری را افزایش می‌دهد. (تمام موارد ذکر شده در مورد هوش مصنوعی را در آخرین تماس درآمدی مایکروسافت.) البته در قلب هوش مصنوعی، داده ها قرار دارند. داده های بسیار و زیادی. از زمانی که آن را “داده بزرگ” نامیدیم، داده ها باعث پذیرش و استفاده از ابر شده است.

این مهم نیست که آن را چه می‌نامیم یا از چه فناوری‌هایی برای ذخیره و پردازش آن استفاده می‌کنیم. همانطور که روندهای O’Reilly اخیر نشان می دهد، حتی به عنوان فناوری هایی مانند < a>Apache Hadoop، Apache Spark، و انبار داده کاهش علاقه را نشان می‌دهند (که فن‌آوری‌های قدیمی هستند)، علاقه به داده‌ها همچنان در حال افزایش است. جالب اینجاست که اوریلی پایگاه‌های اطلاعاتی تخصصی مانند پایگاه‌های اطلاعاتی برداری را به‌عنوان نسبتاً مهم می‌بیند، حتی زمانی که پایگاه‌های اطلاعاتی عمومی‌تر مانند MySQL قابلیت‌های برداری را اضافه کرده و به رشد خود ادامه می‌دهند.

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

برای Hightower، یکی از راه‌های حذف پیچیدگی از تمرکز پایگاه داده شروع ساده با SQLite، به جای پایگاه داده پیچیده تری مانند MySQL. همانطور که او می گوید، ترجیح می دهد “مبانی داده ها و نحوه مدیریت آنها را بیاموزد.” به عبارت دیگر، “من ترجیح می دهم وقت خود را صرف یادگیری SQL کنم، نه نحوه مدیریت سرور پایگاه داده، که یک مهارت مفید است، اما مانع بزرگی برای ورود است.” سهولت SQLite، موافق برنامه‌نویس Simon Willison، این است که «نیازی به اجرای یک سرور و شما نیازی به احراز هویت ندارید.”

این یک رویکرد برای توسعه دهندگانی است که تازه به پایگاه داده می پردازند، اما این تنها رویکرد نیست. به اصطلاح پایگاه داده های NoSQL می توانند برای توسعه دهندگان قابل دسترسی تر باشند. یکی از دلایلی که توسعه‌دهندگان به MongoDB علاقه دارند این است که به‌جای اینکه آنها را مجبور به استفاده از ORM (نقشه‌نگارهای شیء-رابطه‌ای) کند، به برنامه‌نویسی شی‌گرا که توسعه‌دهندگان از قبل می‌دانند، نگاشت می‌شود. داده های خود را به یک مدل رابطه ای هدایت می کنند. (افشا: من برای MongoDB کار می کنم.) گزینه دیگر Supabase است که PostgreSQL مدیریت شده را برای توسعه دهندگان فراهم می کند تا زمان کمتری را برای نگرانی در مورد عملیات پایگاه داده صرف کنند.

اگر نمی خواهید اصلاً یا زیاد به پایگاه داده فکر کنید چه؟ خوب، Neurelo ممکن است پاسخ شما باشد.

مبارزه با “شر ضروری”

Neurelo یک پلت فرم انتزاعی پایگاه داده را ارائه می دهد که به توسعه دهندگان اجازه می دهد بدون نیاز به ساخت پرس و جوهای SQL پیچیده برای ایجاد، بازیابی، به روز رسانی یا حذف رکوردها در پایگاه های داده رابطه ای مانند PostgreSQL یا MySQL یا ساخت پرس و جو با استفاده از MongoDB Query API برای MongoDB. در عوض، Neurelo به طور خودکار API ایجاد می‌کند که هر دو نقطه پایانی REST و GraphQL را مستقیماً از مدل‌ها و طرح‌واره‌های داده توسعه‌دهندگان ایجاد می‌کنند.

همانطور که چیراگ شاه، بنیانگذار و مدیر عامل Neurelo در مصاحبه ای می گوید، این قلب نحوه مبارزه Neurelo با “شرارت ضروری” ORM ها است که توسعه دهندگان فرض کرده اند باید از آن استقبال کنند. او توضیح می دهد: «این یک نبرد سخت است» که با یک ORM کار می کند. “شما باید از یک سری چیزها عبور کنید، و باید آن مهارها را ایجاد کنید، و باید آن را حفظ کنید، زیرا هر زمان که طرح شما تغییر کند یا نیاز شما تغییر کند، باید کل چیز را دوباره تنظیم کنید.”

درد است. اما امیدی وجود دارد.

ORM های سنتی لایه SQL را مبهم می کنند، اما Neurelo به طور کامل به پرس و جو قابل مشاهده است، زیرا شرکت یادداشت ها در سایت خود. توسعه دهندگان می توانند تعاملات پایگاه داده را با افزایش سطح راحتی خود با پایگاه داده بررسی و بهبود بخشند. Neurelo همچنین به حل مشکل “N+1” یک ORM کمک می کند، به موجب آن پایگاه داده پرس و جوها را در یک حلقه ایجاد می کند و تعداد دفعات رفت و برگشت پایگاه داده را به طور غیر ضروری ضرب می کند. Neurelo با استفاده از بارگذاری مشتاق، که داده های مرتبط را در یک پرس و جو با استفاده از اتصالات بازیابی می کند، با این مشکل مقابله می کند. این کار تعداد پرس و جوهایی را که به پایگاه داده برخورد می کنند به حداقل می رساند و عملکرد را بهبود می بخشد. Neurelo همچنین فراتر از عملیات اولیه CRUD عمل می‌کند تا وظایف پیشرفته خواندن/نوشتن پیوستن را ارائه دهد که در چندین نهاد وجود دارد.

به این روش‌ها و روش‌های دیگر، Neurelo به توسعه‌دهندگان اجازه می‌دهد – خواه تازه وارد پایگاه‌های داده باشند و یا با تجربه – زمان کمتری را صرف کشف نحوه کار با پایگاه داده خود و زمان بیشتری برای نوشتن برنامه خود کنند. شاه استدلال می‌کند: «شما عملاً همه چیز را فوراً دریافت می‌کنید، و لازم نیست انگشت خود را بالا ببرید.» به جای ساعت ها یا هفته ها، “شما از صفر به نوشتن کد خود در چند دقیقه می روید.”

این ما را به ارزیابی Hightower برمی‌گرداند که داده‌ها باید اولین نگرانی یک توسعه‌دهنده باشد. اگر او درست می‌گوید، ابزارهایی مانند Neurelo می‌توانند نگرانی اول را کمتر نگران‌کننده کنند، بدون تمام مبادلاتی که ORM ها تحمیل می‌کنند یا سیم‌کشی کدهایی که استفاده از درایور پایگاه داده ممکن است ایجاد کند. این راهی است برای نگه داشتن داده ها در قلب یک برنامه و بسیار قابل دسترس تر برای توسعه دهندگان.