funql presentatoinV2.md

**
**

فهرست مطالب

دریافت به اندازه اطلاعات 2

مشکلات GraphQl 4

ساختار ارتباطی منطبق با درک انسان 9

پایگاه داده های غیر رابطه ای 11

تاریخچه پایگاه های ارتباطی (RDBMS) و NoSQL 12

ساختار داده ها 12

مقیاس گذاری 13

مدل توسعه 13

SSG and SSR static site generation and server side rendering 14

مقیاس پذیری 16

مقیاس پذیری داده های پویا 18

مقیاس پذیری داده های ایستا 19

کوئری کیو (Query queue) یا QQ 19

Playground 20

سهولت توسعه (هم برای بک‌اند - هم برای فرونت‌اند) 21

داکیومنت شدن ورودی و خروجی‌های کدنویسی شده 21

واحد تست E2E گرافیکی 21

Issue Driven Development 23

دریافت به اندازه اطلاعات

بسیاری از ساختار های فعلی تعامل با برنامه های سمت سرور به گونه ای بود که برای دریافت مجموعه از اطلاعات مرتبط با هم، نیاز به ارسال چندین درخواست به برنامه سرور دارند.

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

مشکل اول تحت عنوان under fetching شناخته می شود یعنی اطلاعات دریافتی نسبت به اندازه که نیاز است کمتر بوده و نیاز به ارسال درخواست مجدد به سرور است. این کار موجب میشود تعداد درخواست های قابل پاسخ سرور در واحد زمان به شدت کم تر شود و بار پردازشی بیشتری را به سرور تحمیل نماید.

مشکل دوم تحت عنوان over fetching شناخته می شود یعنی کلاینت فقط بخشی خاص از اطلاعات را نیاز دارد ولی برنامه سرور بدون توجه به نیاز کلاینت کلیه داده ها برای او ارسال میکند. این مشکل سبب اشغال پهنای باند توسط سرور میشود و زمان تبادل داده ها را نیز افزایش میدهد.

شرکت فیسبوک برای رفع این مشکل مفهومی تحت عنوان graphql را معرفی نمود که توانست مشکلات بالا را حل کند ولی خود آن نیز مشکلاتی را جهت پیاده سازی اضافه نمود.

مشکلات GraphQl

1. با توجه به اینکه graphql یک مشخصه و زبان توصیف مدل داده ها و نحوه درخواست آنها است، علاوه بر پیاده سازی معمول برنامه سرور نیاز به پیاده سازی مختص به graphql نیز می باشد که این مورد، یکی از اصل های اساسی برنامه نویسی که "عدم تکرار" است را نقض می نماید و توسعه دهندگان را مجبور به یادگیری زبان توصیفی منحصر به graphql یعنی gql می کند.

2. پس از اینکه توصیف مدل داده ها را به زبان graphql انجام میشود، به ازای ارسال هر درخواست به سمت سرور نیاز به تجزیه و تحلیل متون توصیفی است که این فرآیند نیز، دارای سربار پردازشی میباشد.

1. یکی از موارد که در graphql مدیریت میشد، ارسال داده ها به همراه روابطشان است اما مشکل مهمی که در این قسمت به وجود می آید، عدم کنترل عمق و نوع روابطی است که کلاینت می تواند درخواست نماید. این عامل سبب تولید درخواست های غیر بهینه توسط کلاینت میشود.

1. در graphql برای درخواست یک داده باید نام آن به طور کامل ذکر شود بنابراین در حالتی که نیاز به همه یا اکثریت داده های یک موجودیت داریم باید تمامی اسامی داده ها ذکر شود که همین موجب اشغال پهنای باند شبکه و کاهش سرعت ارسال درخواست به سرور میشود.

2. graphql یک زبان توصیفی با رویکرد کلی است و برای پایگاه داده خاصی بهینه نشده است. در واقع این ابزار هیچ دیدی نسبت به اینکه در ساختارهای دیگر چه پیاده سازی انجام شده است، ندارد و قاعدتا بهینه سازی خاصی نیز روی آن اتفاق نیفتاده است.

3. ارسال درخواست در graphql در قالب فرمت های متداول رایج مانند json نبوده و همین عامل سبب میشود تا ارسال درخواست با بسیاری از ابزار های فعلی، امری پیچیده تلقی شود.

جهت حل مشکلات بالا ما funql را با توجه به امکانات و ابزار های موجود در زبان توسعه طراحی نمودیم.

عدم نیاز به تعریف مجدد موجودیت ها یا توابع در funql باعث میشود که توسعه برنامه سرور سریع تر انجام پذیرد و منابع کمتری نیز صرف شود همچنین این کار باعث یکپارچگی بیشتر در برنامه سرور میشود به عنوان مثال مغایرت نوع داده های تعریف شده در مشخصه های graphql با نوع داده های تعریف شده در زبان توسعه، موجب عدم یکپارچگی برنامه سرور می‌شود. بعلاوه این کار باعث میشود توسعه دهنده برنامه سرور نیازی به یادگیری مجدد مواردی که قبلا و به شکل دیگر فراگرفته است، نداشته باشد.

افزودن منطق جدید دریافت اطلاعات، انعطاف بیشتر در گزینش اطلاعات دریافتی را به ارمغان می آورد. این کار سبب میشود تا کلاینت بتواند بر اساس دو منطق 0 و 1 مشخص نماید چه داده هایی را نیاز دارد و یا ندارد. اضافه شدن منطق 0 سبب کاهش اسراف پهنای باند در درخواست همه یا اکثریت داده های یک موجودیت میشود. همچنین بر خلاف graphql فرمت ارسال داده ها بر اساس استاندارد های موجود یعنی json طراحی شده است.

ارائه راهکاری جهت محدود کردن عمق و داده هایی که کلاینت می تواند درخواست کند نیز، سبب حل شدن مشکل درخواست های غیر بهینه از سمت کلاینت می شود. این کار هماهنگی کاملی بین منطق درخواست داده ها و نحوه مدل و ذخیره سازی داده ها در پایگاه داده را به ارمغان می آورد.

Graphql برای جلوگیری از over-fetching و under-fetching روش Rest ایجاد شد اما در کنار مزیت یاد شده دو ایراد مهم در آن وجود دارد:

۱. برای توصیف درخواست front-end از back-end از زبانی استفاده می شود که متداول

نیست و فهم آن هم برای ماشین و هم برای انسان مشکل ساز است

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

۲. در gql ما با یک رشته کار می کنیم که تمامی متغیر های درخواست را در خود جای داده است و type safety را از بین برده است که در نتیجه آن امکان validation first را نداریم

type safety به معنی آن است که مقداری که به یک متغیر تخصیص داده می شود از همان نوعی باشد که برنامه نویس تعریف کرده است و انتظار دارد

هم چنین validation first به مفهوم این است که اولین کاری که در هنگام دریافت درخواست انجام می شود بررسی مطابقت نوع متغیرهای دریافتی با نوع های تعریف شده است

در راه حل ما از فرمت json استفاده می شود که علاوه بر شناخته شده بودن برای انسان و ماشین ،درهنگام ارسال درخواست قابلیت validation first با استفاده از کتابخانه های موجود مانند fastest validator را فراهم می کند.

بسیاری از نفوذها و تهدیدات امنیتی در اثر ارسال داده های مخرب به سرور ایجاد می شود و با این روش ، امکان بروز تعداد قابل توجهی از تهدیدات یادشده وجود نخواهد داشت

از طرف دیگر امکان بروز خطا در هنگام اجرای برنامه کاهش چشمگیری خواهد داشت. اهمیت این موضوع زمانی آشکار می شود که بدانیم گروهی از پژوهشگران دانشگاه MIT زبان Elm را برای همین منظور توسعه داده اند. پس از صحت سنجی نوع داده ها ، بر اساس درخواست کاربر تابع مورد نظر فراخوانی می شود

از آن جا که این توابع به روش functional programming پیاده سازی می شونددارای سه ویژگی هستند :

• reference : immutable داده ها تغییر داده نمی شود و پایدار هستند

• pure function : به ازای ورودی مشخص خروجی مشخص داریم

• no side effect : تابع از خارج خودش تاثیر پذیر نیست چرا که مقدار هیچ متغیری در خارج از تابع تعیین نمی شود.

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

این موضوع علاوه بر آن که در مرحله حاضر TDD یا Test Driven Development را ممکن می کند به ما امکان حرکت در جهت IDD یا Issue Driven Development را می دهد . به این ترتیب که حل مسائل بزرگ آینده را با استفاده از راه حل های چند صد هزار مسئله کوچک قبلی فراهم کنیم و کدنویسی هوشمند توسط ماشین را محقق کنیم.

ساختار ارتباطی منطبق با درک انسان

**
**

یکی از موضوعاتی همواره در بحث طراحی برنامه های سمت سرور مطرح می گردد نحوه ی ارتباط آن با کلاینت بوده است.

ساختار های ارتباطی فعلی از قواعد خاصی پیروی نمی کنند به عنوان مثال در مفهوم restful api صرفا پیشنهاد میشود به جهت درک بهتر برنامه نویسان از method های پروتکل http استفاده گردد یا در graphql فراخوانی برنامه سرور شبیه به فراخوانی یک تابع است.

مدل پیشنهادی در funql به زبان انسان بسیار شبیه تر از مدل های بالا می باشد. این بیان در ارسال درخواست به برنامه سرور شبیه به ادای یک جمله است.

من می خواهم روی<model> عمل <doit> را با جزئیات <details> انجام دهم.

که جزئیات انجام تغییرات <set> و دریافت اطلاعات <get >است.

Model : موجودیتی که می خواهیم رو آن کاری انجام دهیم.

Doit: عملی می خواهیم روی آن موجودیت انجام دهیم.

Details: جزئیات انجام آن عمل می باشد که شامل دو ساختار set و get است.

Set : کلیه تغییراتی که می خواهیم روی موجودیت انجام شود.

Get: اطلاعاتی که می خواهیم به ما نمایش داده شود.

زبان ارتباطی معرفی شده نسبت به سایر روش های ارتباطی بسیار گویا تر بوده و تعامل با آن حتی برای کاربرانی که تجربه برنامه نویسی ندارند نیز بسیار آسان است.

پایگاه داده های غیر رابطه ای

دو نوع اصلی از پایگاه داده های مدرن برای انتخاب ، رابطه ای و غیر رابطه ای هستند که با نام های SQL یا NoSQL نیز شناخته می شوند.

پایگاه های داده SQL به عنوان پایگاه داده های رابطه ای شناخته می شوند و دارای یک ساختار داده ای مبتنی بر جدول هستند و یک طرح دقیق و از پیش تعریف شده مورد نیاز است. پایگاه داده های NoSQL یا پایگاه های داده غیر رابطه ای می توانند بر اساس اسناد ، پایگاه داده های گرافی ، جفت کلید-مقدار یا ذخیره wide-column باشند. پایگاه های داده NoSQL به هیچ اسکیما از پیش تعیین شده ای نیاز ندارند ، به شما این امکان را می دهد تا با "داده های بدون ساختار" آزادتر کار کنید. پایگاه های داده رابطه ای به صورت عمودی مقیاس پذیر هستند ، اما معمولاً گران ترند ، در حالی که ماهیت مقیاس پذیری افقی پایگاه داده های NoSQL مقرون به صرفه تر است.

تاریخچه پایگاه های ارتباطی (RDBMS) و NoSQL

بیش از 40 سال است که پایگاه داده های رابطه ای (RDBMS) وجود دارد. از نظر تاریخی ، آنها به خوبی کار کرده اند ، برای زمانی که ساختار داده ها بسیار ساده تر و ساکن تر بوده اند. با این حال ، همزمان با پیشرفت فناوری و برنامه های کلان داده ، پایگاه داده رابطه ای سنتی مبتنی بر SQL برای کنترل حجم داده های در حال گسترش سریع و پیچیدگی های در حال رشد ساختار داده ها ، کمتر مجهز بود. در دهه گذشته ، پایگاه های داده غیر رابطه ای NoSQL برای ارائه انعطاف پذیرتر ، مقیاس پذیرتر ، مقرون به صرفه و جایگزین برای پایگاه های داده رابطه ای سنتی مبتنی بر SQL ، محبوبیت بیشتری پیدا کردند.

ساختار داده ها

پایگاه های داده رابطه ای مبتنی بر جدول هستند. پایگاه داده های NoSQL می توانند بر اساس اسناد ، پایگاه داده های گرافی ، جفت کلید-مقدار یا ذخیره wide-column باشند. پایگاه داده های رابطه ای در زمانی ساخته شده اند که داده ها عمدتاً ساختار یافته و به طور واضح توسط روابط آنها تعریف شده است. امروز ، ما می دانیم که داده های امروز بسیار پیچیده تر هستند. پایگاه داده های NoSQL برای رسیدگی به داده های پیچیده تر و بدون ساختار (مانند متن ها ، پست های رسانه های اجتماعی ، عکس ها ، فیلم ها ، ایمیل) طراحی شده اند که به طور فزاینده بسیاری از داده های موجود را تشکیل می دهند.

مقیاس گذاری

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

مدل توسعه

پایگاه های داده NoSQL بیشتر عضوی از جامعه منبع باز هستند. بانک های اطلاعاتی رابطه ای معمولاً با هزینه های صدور مجوز برای استفاده از نرم افزارهایشان منبع بسته هستند.

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

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

SSG and SSR static site generation and server side rendering

**
**

یکی از مورد توجه ترین فناوری های مورد استفاده در توسعه برنامه های سمت کاربر تلاش در جهت تولید محتوای ایستا و پردازش صفحات سمت کاربر در برنامه سرور می باشد

این امر موجب تولید محتوای قابل فهم موتور های جست و جو می شود. بسیاری از روش های توسعه برنامه های سمت کاربر به گونه ای بوده که محتوای آنها به طور کامل توسط موتور ها جست و جو نمایه نشده و در تاثیر نامناسبی در رتبه بندی این برنامه ها توسط موتور جست و جو می گذارد.

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

همین عوامل سبب شد تا بسیاری از توسعه دهندگان و کتابخانه های برنامه های سمت کاربر به سمت تولید این نوع محتوا کوچ کنند در حالی که توسعه دهندگان برنامه های سمت سرور دید خاصی در رابطه با این راهکار نداشته و محتوای های غیر بهینه ای را در اختیار برنامه های سمت کاربر قرار می دادند و روند تولید و توسعه این محتوا را کند و سخت می کردند به طور مثال چارچوب های مطرح این روش توسعه برای به روز آوری محتوای خود اقدام به باز تولید صفحات خود در بازه های زمانی کرده که روش غیر بهینه ای بوده و توجه ای به سازوکار بروز رسانی اطلاعات در سرور نداشته و حتی سبب تولید محتوای غیر معتبر می شود.

بستر funql به گونه ای توسعه یافته تا بتواند محتوای مناسب پیاده سازی این روش را در اختیار توسعه دهندگان سمت کاربر قرار دهد و این فرآیند را تسهیل ببخشد.

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

نکته ی دیگر قابل ذکر این است که حتی در صورتی که توسعه دهنده سمت کاربر علاقه ای به تولید محتوای ایستا نداشته باشند به دلیل گزینش اطلاعات بر اساس تحلیل و رابطه کاربری و نیز ذخیره سازی داده های در ram هزینه درخواست اطلاعات از سرور کمتر از حالت معمول است

مقیاس پذیری

**
**

یکی از نیاز های روز افزون توسعه نرم افزار های سمت سرور توجه به راهکارهای مقیاس پذیری آنها می باشد. اهمیت این موضوع زمانی بیشتر نمایان میشود که برنامه توسعه داده شده نیاز دارد که تعداد زیادی پردازش را مدیریت کرده و این مهم باید با بهینه سازی های لازم در ابعاد فنی و اقتصادی انجام شود. همین عوامل سبب گشته که این موضوع در توسعه نرم افزار به امری مهم مبدل گردد به طوری که بسیاری از فناوری های کنونی با تمرکز بر پاسخ به این مسئله توسعه یافته اند.

مقیاس پذیری یعنی توانایی یک سیستم به منظور مدیریت افزایش کاربران.

روش های مقیاس پذیری یا Scaling به دو دسته اصلی تقسیم می شوند:

• مقیاس پذیری افقی (Horizontal Scaling)

• مقیاس پذیری عمودی (Vertical Scaling)

پایگاه های داده ارتباطی، به دلیل روشی که ساختاردهی شده اند، معمولا به صورت عمودی ساختاردهی می شوند؛ که در این صورت، یک سِرور باید تمامی پایگاه داده را میزبانی کند تا از پایایی و تداوم دسترسی به داده ها، اطمینان حاصل شود. این امر موجب افزایش سریع هزینه ها، محدودیت مکان در مقیاس های بالاتر و ایجاد نقاط شکست نسبتاً کوچک برای زیرساخت پایگاه داده می شود. راه حل، ساختاردهی به صورت افقی است، یعنی افزودن سِرور به جای تمرکز بر افزایش ظرفیت یک سِرور یکتا.

از این طریق می توان به جای استفاده از یک پایگاه داده، بخش های مختلف داده را روی پایگاه های داده مختلف نگهداری کرد و در زمان فراخوانی یک داده، اسناد مرتبط را که ممکن است بر روی پایگاه های داده مختلف ذخیره شده باشند، در یک زمان فراخوانی کرد. پایگاه های داده NoSQL به صورت خودکار، می توانند داده ها را میان چندین سِرور توزیع و بازخوانی کنند. مقیاس پذیری افقی؛ به این معنی که برای افزایش ظرفیت، یک راهبر پایگاه داده به راحتی می تواند سِرور و یا مواردی همچون فضای ابری را اضافه نماید. پایگاه داده، در صورت لزوم به طور خودکار داده را در میان سرور توزیع می کند.

مقیاس پذیری عمودی یکی از مهم ترین راهکار های ارائه شده در این رابطه می باشد بدین صورت که می توان با صرف منابع کمتر نسبت به سایر روش ها به توزیع بار پردازشی پرداخت. در این نگاه به جای مقیاس پذیری یک سرور به صورت افقی یعنی با اضافه کردن منابع بیشتر به یک سرور، از چندین سرور به صورت موازی بهره گرفته میشود. همچنین با توجه به این ساختار امکان مقیاس پذیری به صورت نامحدود نیز فراهم میشود.

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

بسیاری از پایگاه داده هایی که امروزه مورد توجه سازمان های بزرگ قرار گرفته اند و نیز معماری های جدید نرم افزاری مانند معماری میکروسرویس ها با توجه ویژه به مبحث مقیاس پذیری عمودی توسعه یافته اند.

با توجه به مسائل ذکر شده funql از دو راه حل جهت مقیاس پذیری بهره می برد.

مقیاس پذیری داده های پویا

یکی از مسائل پیش رو در مقیاس پذیری عمودی تعامل برنامه های سرور ها با یک دیگر می باشد. برخی استاندارد های موجود مانند GRPC به دلیل معرفی زبان توصیف منحصر به خود که باید به صورت جداگانه توسعه بیابند، دارای مشکلاتی برای تیم توسعه دهنده بوده و سبب اتلاف زمانی می شوند.

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

این نوع مقیاس پذیری سبب افزایش بازده در مواجه با حجم بالای داده ها و پردازش ها میشود.

همچنین به دلیل استفاده از پایگاه داده mongodb در funql و تفاوت مدلسازی این نوع پایگاه داده با پایگاه داده های رابطه ای امکان تعریف پایگاه داده به صورت مستقل برای هر برنامه سرور به سهولت وجود دارد.

مقیاس پذیری داده های ایستا

نحوه مقیاس پذیری ساختار خواندن اطلاعات به دلیل توجه funql به تولید محتوای ایستا متفاوت است. در حالت کلی هزینه نگهداری داده های ایستا نسبت به پویا بسیار کمتر بوده و به همین ترتیب مقیاس پذیری و توزیع محتوای ایستا بر روی شبکه های توزیع اطلاعات بسیار سهل و کم هزینه میباشد.

همچنین در پیاده سازی این روش به تدابیری جهت یافتن مکان داده های توزیع شده و نیز ذخیره سازی و دسترسی به داده های خصوصی اندیشه شده است.

کوئری کیو (Query queue) یا QQ

مفهوم صف‌بندی کوئری‌ها در بستر توسعه funql برای مدیریت بروزرسانی تغییرات در روابط داده‌ها ایجاد شده است.

بستر توسعه فان‌کیوال بر مبنای دیتابیس‌های nosql بنا شده و در تعریف هر schema از تعاریف و استاندارهای خود پیروی می‌کند، یکی از این استاندارها جداسازی رابطه‌های داخلی و خارجی هر schema از یکدیگر و از فیلدهای خالص است که در انتها تمام رابطه‌های داخلی و خارجی به هر شکل و تعداد به صورت embedded در خود آن schema به این شکل که اگر داده از تعداد مشخص شده‌ای کمتر باشد به صورت کامل و اگر بیشتر باشد paginate اول آن ذخیره می‌شود. داده‌های embed (جاگذاری شده) در داخل یک schema اگر نیاز به بروزرسانی داشته باشد و این بروزرسانی bulk بسیار بزرگ و زمان‌بری باشد آن را به bulkهای کوچک‌تر تقسیم می‌کنیم و در داخل یک فایل JSON کوئری قابل execute را به شکل uplog ذخیره می‌کنیم. معادل اطلاعات این JSON فایل را در ISDB که یک in-memory دیتابیس است هم ذخیره می‌کنیم. QQ بر اساس یک زمانبندی و تنظیمات دستی و هوش‌مصنوعی مدیریت اجرا کردن این uplog را با دریافت اطلاعات از ISDB انجام می‌دهد. علاوه بر این QQ مدیریت بروزرسانی Replica setها در Horizontal scaling مختص خود Funql را هم برعهده خواهد داشت.

Playground

به سه دلیل به سمت طراحی محیطی برای آزمایش ورودی و خروجی‌های درخواست‌های ارسالی به آدرس /funql (آدرس هدف بستر توسعه فانکیوال رفتیم).

سهولت توسعه (هم برای بک‌اند - هم برای فرونت‌اند)

در هنگام توسعه بارها نیاز به تست خروجی کد نوشته شده پیدا می‌کنیم و اگر بتوانیم یک رابط کاربری زیبا با ux و dx خوب برای تست خروجی کد، طراحی کنیم در زمان و هزینه توسعه‌ي بک‌اند کار صرفه جویی قابل توجه‌ای ایجاد کرده‌ایم.

از طرفی کدنویسی هم که می‌خواهد در سمت مشتری خروجی‌ها را به نرم‌افزار متصل کند نیاز مکرر به آزمایش داده‌های سرور دارد و با این رابط کار او بسیار ساده‌تر خواهد بود.

داکیومنت شدن ورودی و خروجی‌های کدنویسی شده

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

بستر توسعه فان‌کیوال علاوه بر ارسال پیغام‌های کاربردی خطا در خروجی‌های به خاطر validation-first بودن کدهای نوشته شده، به صورت کامل و گرافیکی در playground برای تک تک درخواست‌ها و هر کدام از فیلد‌های هر درخواست توضیحات کاملی ارائه می‌کند.

در نهایت به همراه داکیومنتی که برای هر درخواست در playground وجود دارد به خاطر type-safty طبیعی و وابسته به پلتفرم موجود در این بستر، تمامی تکه کدهای نوشته شده دارای توضیحات بروز و قابل فهم در این رابط کاربری هستند

واحد تست E2E گرافیکی

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

Issue Driven Development

**
**

با توجه به پیشرفت‌های چشمگیر هوش مصنوعی در چند سال اخیر و کاربردهای آن در اکثر حوزه‌های اجتماعی، سیاسی، افتصادی، فناوری و ... می‌توان این ادعا را داشت که دنیای آینده، دنیای هوش مصنوعی است. در افق بلند مدت هم با توجه به پیشرفت‌های سریع در حوزه هوش مصنوعی و پیش بینی های افراد معتبر و متخصص در این حوزه و وجود پروژه‌هاي مثل Bayou که اسپانسر آن دارپا و گوگل هستند در بیست سال آینده همه وجوه تمدنی بشر از جمله اقتصاد، فرهنگ، سیاست، صنعت و ... تحت لواي هوش مصنوعی مدیریت خواهند شد. در نتیجه جهت جلوگیری از غافلگیری های تکنولوژیک باید پایه‌های این حوزه در کشور تقویت شوند.

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

در IDD یا همان Issue Driven Development بستری فراهم می‌شود تا مسائل بزرگ توسعه نرم‌افزار به کوچکترین فانکشن ممکن به نام issue تقسیم گردد. سپس از طریق resolve شدن آن‌ها به جمع کردن دیتاست برای هدف مورد نظر پرداخته می‌شود.

با استفاده از هوش مصنوعی و شبکه‌های عصبی عمیق یادگیری حل مسائل بزرگ برنامه‌نویسی با استفاده از دیتاست جمع‌آوری شده انجام می‌شود.

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