Intro to PostGraphile V5 (بخش 3): درون نگری و انتزاع

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

این قسمت سوم از سری “معرفی PostGraphile V5” است که با قسمت 1 شروع شد: جایگزینی پایه ها. این هفته، Benjie در مورد سیستم جدید درون نگری و تولید طرحواره خود، و اینکه چگونه منجر به بهبود ایمنی نوع، مستندات و سازگاری بهتر می شود صحبت می کند. این سیستم جدید در نسخه 5 PostGraphile در دسترس است، در حال حاضر برای همه حامیان مالی Graphile در دسترس است، در postgraphile.org اطلاعات بیشتری کسب کنید.

برای اینکه PostGraphile بتواند یک API بر اساس پایگاه داده PostgreSQL شما بسازد، باید بداند پایگاه داده شما شامل چه چیزی است: طرحواره ها، جداول، ستون ها، فهرست ها، محدودیت ها، توابع، نماها، کمک ها و غیره. از تکنیکی به نام “درون نگری” استفاده می کند: SQL را صادر می کند SELECT عباراتی علیه “کاتالوگ سیستم”، که به طور موثر پایگاه داده خود را توصیف می کند. PostGraphile (و قبلاً PostGraphQL) این کار را از همان ابتدای پروژه انجام داده است.

PostGraphile V4 پرس و جوی درون نگری خود را از PostGraphQL v3، v3 از v2 و v2 از v1 به ارث برده است. هر نسخه ترفندهایی را اضافه می کرد، پشتیبانی از موجودیت های مختلف را بهبود می بخشید، یا سازگاری با نسخه های جدیدتر PostgreSQL را بهبود می بخشید، اما ساختار در کل مشابه باقی ماند. نتیجه یک جستجوی درون نگری بسیار خاص PostGraphile بود، با نیازهای مستندات و تایپ خاص خود، تطبیق‌های زیادی برای نسخه‌های مختلف PostgreSQL، و سازگاری بسیار ضعیف با پایگاه‌های داده مشابه PostgreSQL، مانند Cockroach DB.

در ضمن طی مشاوره…

در حین بررسی پروژه های مختلف مشتری مبتنی بر PostGraphile، متوجه تعدادی از مسائل بسیار رایجی شدم که افراد در طرحواره های پایگاه داده خود دارند. مواردی مانند فراموش کردن فعال کردن امنیت سطح ردیف روی یک جدول با وجود ایجاد خط مشی برای آن (یک مشکل امنیتی مهم!)، فراموش کردن ایجاد نمایه در محدودیت های کلید خارجی (بررسی معکوس اغلب به اسکن جدول نیاز دارد – یک مشکل اصلی عملکرد) و موارد دیگر از این قبیل. . من به تعداد زیادی قانون رسیدم و سیستمی نوشتم که می توانست این مشکلات را شناسایی کند که می توانید از آن در https://pgrita.com استفاده کنید. اطراف لبه‌ها کمی خشن است (PostGraphile V5 اخیراً تمام توجه من را به خود جلب کرده است)، اما به دلیل قیمت دسترسی زودهنگام آن که فقط 25 دلار در ماه است، ارزش زیادی دارد. حتی یک طرح رایگان وجود دارد!

در حین ساختن pgRITA، من نیاز به پشتیبانی از بسیاری از نسخه‌های مختلف PostgreSQL داشتم، و به یک راه آسان برای مقابله با نتایج درون‌نگری از آن‌ها نیاز داشتم – مهم‌تر اینکه مطمئن شوم اشتباه تایپی نکرده‌ام و بدانم چه فیلدهایی مانند attinhcount حتی به معنای بنابراین من چیزی ساختم که مستندات PostgreSQL را تجزیه و آن را به انواع TypeScript تبدیل کرد، با مستندات ساخته شده از طریق TSDoc. لذت بخش بود و نوشتن قوانین pgRITA را بسیار آسان تر کرد. حتی می‌دانست که کدام ویژگی‌ها برای همه نسخه‌های مختلف PostgreSQL مشترک هستند، در مقابل کدام یک ممکن است فقط در نسخه‌های قبلی یا بعدی باشند و آنها را به‌عنوان اختیاری علامت‌گذاری کند (با استفاده از ?).

قهرمان جدیدی پدید می آید…

زمانی که زمان ساخت Introspection برای PostGraphile V5 فرا رسید، تصمیم گرفتم از جستجوی درون نگری که در 7 سال گذشته به خوبی به ما کمک کرده بود، استفاده مجدد نکنم. من چیز بهتری برای پایه گذاری آن داشتم: سیستم pgRITA. مقداری سفارشی سازی بعد و من با افتخار اعلام می کنم pg-introspection کتابخانه – یک کتابخانه درون نگری کاملاً تایپ شده برای PostgreSQL. در حال حاضر در npm منتشر شده است، و می توانید از آن برای هر پروژه دیگری نیز استفاده کنید! نگران نباشید که چند ماه است که هیچ به روز رسانی نداشته است، اساساً “تمام شده” است و فقط زمانی که نسخه های شکسته PostgreSQL (یا TypeScript) منتشر می شود به به روز رسانی نیاز دارد.

این سیستم جدید مزایای زیادی نسبت به سیستم قبلی دارد:

• همگام سازی با نسخه های جدید PostgreSQL بسیار ساده تر است زیرا از مستندات ایجاد می شود.
• برای نسخه‌های مختلف PostgreSQL به پرس و جوی متفاوتی نیاز ندارد زیرا به ندرت به ستون‌ها مستقیماً ارجاع می‌دهد و در عوض از آن استفاده می‌کند. SELECT * یا تکنیک های مشابه،
• به اسناد زیادی (یا انواع سفارشی تایپ اسکریپت) نیاز ندارد زیرا اینها به صورت خودکار تولید می شوند.
• با Postgres–likes بهتر کار می کند زیرا از بسیاری از ویژگی های پرس و جو فانتزی استفاده نمی کند.
• درک آن به لطف تولید آسانتر است – از بسیاری از الگوهای مشابه استفاده مجدد می کند که ساختار را یکنواخت و سازگار می کند.
• ما آن را با تعدادی کمک کننده افزایش داده ایم تا زندگی را آسان تر کنیم،
• و خیلی بیشتر.

بازبینی انتزاعات

هر چند یک سوال باقی ماند در V4، افزونه ها از نتایج درون نگری مستقیماً برای تولید انواع، فیلدها، آرگ ها و غیره در GraphQL API ما استفاده می کنند. آیا این همان چیزی بود که ما برای V5 می خواستیم؟ یکی از مشکلات رویکرد V4 این است که وقتی تغییرات اساسی ایجاد می‌کنید، هیچ راه آسانی برای «جعل کردن» یک جدول تکراری برای پشتیبانی از الگوهای استفاده منسوخ و در عین حال انتقال همه چیز به روش جدید وجود ندارد.

من به GraphQL اعتقاد زیادی دارم (در واقع، در زمان نوشتن مقاله من در خود مشخصات GraphQL شماره 2 هستم) بنابراین برای من دردناک است که ابزاری که من ساخته ام همیشه راه های آسانی برای دستیابی به طرحواره بدون نسخه ندارد. طراحی که GraphQL هنگام ایجاد تغییرات اساسی در جداول پایگاه داده زیربنایی شما آن را تشویق می کند. (شخصاً، من فکر می کنم شما باید هدف خود را این باشید که طرحواره پایگاه داده خود بدون نسخه باشد، اما همیشه این امکان وجود ندارد.) البته شما می توانید طرحواره PostGraphile خود را به جای جداول بر روی نماها بسازید، اما view ها مشکلات خاص خود را دارند که من نمی خواهم آن را انجام دهم. برو داخل اینجا…

با خودم فکر کردم: «نه، واضح است که رویکرد V4 مشکلاتی داشت. باید یک لایه میانی وجود داشته باشد. و من دارم همه چیز را بازسازی می کنم، پس چرا که نه؟»

معرفی مراحل ساخت

با استفاده از دامنه سیستم پلاگین جدید ما، ساختمان طرحواره را به چهار مرحله تقسیم کردم: inflection (نام گذاری اشیا) gather (انجام درون نگری و کارهای مشابه)، behavior (که هفته آینده به آن نگاه خواهیم کرد) و schema (در واقع ساختن طرحواره، به طور همزمان، بر اساس خروجی های فازهای قبلی).

را inflection فاز تعدادی از توابع “عطف کننده” را ثبت می کند که با نام گذاری شده اند هدف، که توصیف یک را به عنوان ورودی می پذیرد وجود، موجودیت و رشته ای را برگردانید تا به عنوان نام آن موجودیت برای آن هدف استفاده شود (به عنوان مثال هنگام ایجاد (را هدف) یک کاربر (را وجود، موجودیت) ممکن است نام فیلد جهش را بخواهید createUser، یا userCreate، یا حتی create_a_user – با عطف، به شما بستگی دارد). مهمتر از همه، می توان فلکتورها را اضافه کرد، اما آنها را نیز می توان جایگزین کرد. جایگزین به فلکتور قبلی دسترسی دارد که به آن امکان می دهد مقدار قبلی را به آن اضافه کند، افزایش دهد یا به طور کامل جایگزین کند.

بعدی این است gather مرحله ای که در طی آن تمام اطلاعات لازم برای ساخت طرحواره GraphQL با هم جمع می شوند. این شامل مواردی مانند نتایج درون نگری از پایگاه داده PostgreSQL، مقادیر ردیف در جداول enum و هر چیز ضروری دیگری است که باید از یک منبع راه دور واکشی شود. در پایان مرحله جمع آوری یک شیء “ورودی” تولید می شود که آماده تغذیه به فاز بعدی است. این شی در حال حاضر از “منابع”، “کدک ها” و روابط بین آنها تشکیل شده است. منابع مواردی را توصیف می کنند که PostGraphile می تواند داده ها را از آنها استخراج کند: جداول، نماها، توابع و غیره. به) پایگاه داده؛ و نه فقط انواع پایه مانند int، float، text – کدک ها چیزهای پیچیده تری مانند آرایه ها، دامنه ها و انواع ترکیبی (رکوردها) را نیز پوشش می دهند.

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

در نهایت، است schema فاز. فاز طرحواره شی “ورودی” تولید شده توسط gather فاز و – با اعمال تمام تماس های قلاب طرحواره – از آن برای ساخت همزمان طرحواره GraphQL استفاده می کند. توجه به این نکته مهم است که بر خلاف gather فاز، schema فاز می تواند همزمان باشد زیرا هر واکشی داده های ناهمزمان باید قبلاً در آن انجام شده باشد gather فاز.

منابع خود را بیاورید

یکی از ویژگی های جالب این سیستم این است که شما در واقع این کار را نمی کنید نیاز آ gather اصلاً مرحله – شما می توانید جداول، ستون ها و توابع خود را خودتان توصیف کنید و طرحواره را از این توضیحات تولید کنید. یا می‌توانید مرحله جمع‌آوری را با یک مرحله پس از پردازش ترکیب کنید، جایی که منبعی را با چند تغییر و نام متفاوت کپی می‌کنید تا نیازهای سازگاری با عقب را تکمیل کنید. شما همچنین می توانید gather از چندین پایگاه داده مختلف، ایجاد یک طرحواره GraphQL از چندین پایگاه داده PostgreSQL بدون اینکه مصرف کنندگان طرح شما عاقل تر باشند. این یک ویژگی بسیار قدرتمند است!

البته هنگام استفاده از یک طرحواره (بیشتر) تولید خودکار بسیار مهم است که بتوانید شکل آن را به راحتی و به سرعت اصلاح کنید، بنابراین سیستم رفتاری که دفعه بعد در مورد آن صحبت خواهیم کرد…

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