معرفی PostGraphile V5 (قسمت 1): جایگزینی پایه ها

Benjie نگهدارنده مجموعه Graphile با بودجه جامعه است – مجموعه ای از ابزارهای توسعه دهنده Node.js دارای مجوز MIT برای GraphQL و/یا PostgreSQL. یک پروژه کلیدی در این مجموعه، PostGraphile است، یک تولیدکننده طرحواره GraphQL با کارایی بالا، قابل تنظیم و توسعه‌پذیر برای APIهایی که عمدتاً (اما نه منحصراً!) توسط PostgreSQL پشتیبانی می‌شوند.

در این پست Benjie داستان خود را از آوردن یک الگوی جدید به PostGraphile می‌گوید تا آن را قادر می‌سازد تا قوی‌تر و کارآمدتر از همیشه شود – این سیستم جدید در نسخه 5 PostGraphile در دسترس است، در حال حاضر برای همه حامیان مالی Graphile در دسترس است. اطلاعات بیشتر در postgraphile.org

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

من می‌خواستم PostGraphile V5 از تمام ویژگی‌های جدید GraphQL پشتیبانی کند، اما حتی وصله‌کردن ویژگی‌های تثبیت‌شده مانند چندشکلی در سیستم نگاه پیش‌رو غیرقابل حل به نظر می‌رسید – با این در ذهن ساخته نشده بود. این به سختی تعجب آور بود، سیستم اصلی تنها در 2 هفته با هم هک شد! من به راه حل بهتری نیاز داشتم…

فوریه 2020 بود. من از کنفرانس FOSDEM در بروکسل برگشته بودم و در رختخواب با تب دراز کشیده بودم. (سرکوب‌کننده‌های ایمنی و کنفرانس‌ها ترکیب برنده‌ای نیستند.) وقتی تب‌ها را داخل و خارج می‌کردم، فکری به ذهنم خطور کرد… چه می شود اگر به جای نوشتن کدی که اجرا می شود، آن کد را می نوشتیم شرح داده شده اعدام. GraphQL اعلانی است، اما حل‌کننده‌ها رویه‌ای هستند… چه می‌شود اگر در عوض، ما حل‌کننده‌های اعلامی بسازیم؟

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

معلوم شد که این یک فرآیند طولانی با بسیاری از شروع های اشتباه است. در طول 3 سالی که روی این پروژه کار کردم (روشن و خاموش، بین کار مشتری و مسئولیت های منبع باز، چند ساعت وقت گذاشتن اینجا و آنجا برای دور زدن آن) موتور را 5 بار بازنویسی کردم. هر بار به چیزی رسیدم که کار می کرد، اکثراً، اما در نقطه ای نزدیک به پایان به دلیل نظارت جزئی با شکست مواجه می شدم و هر بار مجبورم می کردم دوباره به تابلوی نقاشی مراجعه کنم.

در طول این بازنویسی‌ها، کد «تحلیل‌کننده طرح» که کاربران می‌نوشتند (یا PostGraphile برای شما ایجاد می‌کرد) به سختی تغییر می‌کرد – این فقط موتوری بود که باید تکامل یابد. «تحلیل‌کننده‌های طرح» با حل‌کننده‌های سنتی GraphQL تفاوت دارند زیرا به‌جای فراخوانی کد برای انجام کار واکشی داده‌های لازم برای انجام درخواست (همانطور که حل‌کننده‌های سنتی انجام می‌دهند)، در خدمت ایجاد «طرح میدانی» هستند که اقدامات مورد نیاز را توصیف می‌کند. (یا “گام ها”). سپس سیستم تمام این طرح‌های میدانی را در یک «برنامه عملیاتی» ترکیب می‌کند و می‌تواند مراحل این طرح – ادغام، جایگزینی، سازمان‌دهی مجدد و بهینه‌سازی – را دستکاری کند که در نهایت منجر به یک طرح بسیار بهینه‌شده می‌شود که کارهایی را که سرویس‌های پشتیبان نیاز دارند به حداقل می‌رساند. انجام دادن.

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

و آن را بساز، من انجام دادم! (در نهایت…)

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

بنابراین، به جای ادامه فشار دادن یک سیستم اجرای کل نگر اعلامی در داخل یک سیستم اجرای خطی، تصمیم گرفتم موتور اجرای GraphQL خود را بنویسم. در نهایت، این منجر به Gra شدسریع، نسل بعدی موتور برنامه ریزی و اجرای GraphQL! در این ویدیو می‌توانید اطلاعات بیشتری در مورد این موضوع و چیزهایی که آن را بسیار هیجان‌انگیز می‌کند، نه فقط برای PostGraphile بلکه برای کل اکوسیستم GraphQL بیابید:

Graسریع تمام مشکلات من را با نگاه به آینده حل کرد و همچنین قدرتمندتر و انعطاف پذیرتر بود! کار کردن با آن لذت بخش بود و همچنان خواهد بود. Graسریع بهتر از نگاه کردن به آینده است: از هر نظر که به آن اهمیت می‌دادم: نوشتن و نگهداری برنامه‌ها ساده‌تر است، خواندن آسان‌تر، سریع‌تر اجرا می‌شوند، توانایی بیشتری دارند – مدیریت چندشکلی و تحویل تدریجی و همه این چیزهای سرگرم‌کننده دیگری که GraphQL به ما دسترسی می‌دهد. به — و پرس و جوهای SQL که سیستم برای V5 ساخته شده بود بسیار ساده تر و آسانتر برای خواندن (و سریعتر برای اجرا!) از موارد در V4 بودند.

ولی!

مشکلی بود.

یک مشکل بزرگ.

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

بنابراین من تصمیم گرفتم کاری را انجام دهم که همیشه به ما گفته می شود انجام ندهیم: همه چیز را بازسازی کردم. از ابتدا.

و از آنجایی که به هر حال داشتم همه چیز را بازسازی می‌کردم، می‌توانستم چند مشکل دیگر را که آزارم می‌داد حل کنم… 🤔

هفته آینده برای قسمت 2 دوباره بررسی کنید: پلاگین ها و تنظیمات از پیش تنظیم شده. و به یاد داشته باشید: برای دریافت نسخه پیش از انتشار PostGraphile V5، تنها کاری که باید انجام دهید این است که از Graphile در هر سطحی حمایت کنید و سپس یک ایمیل یا DM برای ما ارسال کنید! در graphile.org/sponsor اطلاعات بیشتری کسب کنید