یو نوی فرنټنډ هیک د غوره لپاره د API فعالیت بدلوي

په تیرو کې، ما ډیری وختونه یو عام چلند لیدلی چیرې چې پراختیا کونکي (د ما په شمول) په هره قضیه کې د لوستلو او لیکلو لپاره ورته API کارولی. حتی نور هم، موږ ډیری وختونه د ورته معلوماتو سرچینې، لکه MySQL/PostgreSQL، د دواړو عملیاتو اداره کولو لپاره تکیه کوله.

دا پدې مانا ده چې ورته کالمونو ته لیکل او له دوی څخه لوستل، ډیری وختونه په هغو ساحو کې د شاخصونو د اصلاح کولو سره د مبارزې المل کیږي چې په پراخه کچه پوښتل شوي.

نو د مثال په توګه، موږ به په مکرر ډول د نوي فلټرونو ځای په ځای کولو یا د پوښتنو فعالیت ښه کولو لپاره شاخصونه ټیک کوو ، او د LIKE په څیر آپریټرونو سره کارول شوي ساحې په فعالیت باندې د دوی اغیزې له امله ځانګړي ننګونې رامینځته کوي.

دا بدلونونه اکثرا د پس منظر لپاره د نورو سمونونو لامل کیږي، په شمول د APIs تعدیل ترڅو د تازه فعالیت افشا کولو لپاره، اندازه شوي وختونه د اضافي شمولیت له امله او داسې نور ...

په API کې د نوي فلټرونو او توکو اضافه کولو په اړه ننګونې ته د رسیدو لپاره، د Apicalypse او البته، GraphQL په څیر د وسایلو او معیارونو په کارولو سره د پروسې د ښه کولو هڅې وې.

د دې حلونو هدف د API پوښتنو تولید ساده کول او د نوي فلټرونو او فعالیتونو پلي کولو لپاره اړین لارښود هڅې کمول دي ، د ډیټا لاسرسي اداره کولو لپاره خورا متحرک چلند وړاندیز کوي ، مګر دوی د لوړې زده کړې وکر درلود.

د CQRS (د قوماندې پوښتنې مسؤلیت جلا کول) په ډیریدو سره ، یوه نوې تګلاره رامینځته شوه. دې ذهنیت د لیکلو او لوستلو لپاره د جلا سرچینو کارول هڅول. لیکنې کولی شي پیښې رامینځته کړي ، او لوستل کولی شي په وقف ځایونو کې د دې پیښو څخه لیدونه رامینځته کړي. حتی که لوستل او لیکنې په ورته ډیټابیس کې اداره شوي وي (مګر مختلف جدولونه)، دې جلا کول د پام وړ ګټې راوړي، او البته، د دویمې ننګونې څخه د خلاصون توان درلود - د ډومین ماډلونو کې د شمولیت او لټون پوښتنې، لکه څنګه چې لوستل شوي ماډلونه دي. عموما د غیر معمولي JSONs په بڼه.

په هرصورت، دا یوه بله ستونزه راپورته کړه. د لوستلو سره، موږ باید لیکنې اندازه کړو، پدې معنی چې یوازینی دلیل چې موږ یې د X څخه تر Y پورې زموږ د غوښتنلیک مثالونه اندازه کول د لوستلو له امله وو. دا مسله د کیچ کولو سره یو څه کم کیدی شي ، او د مایکرو خدماتو نړۍ کې ، موږ کولی شو د لوستلو لپاره مایکرو خدمتونه وقف کړو.

خو...

بیا هم، دا د نورو معمارۍ سټایلونو لپاره مثالی حل نه و لکه ماډلر مونولیت، چیرې چې دا ډول جلا کول ممکن د سیسټم ډیزاین فلسفې سره سم نه وي. بله خبره دا وه، کله چې API ښکته و، ټول محصول ښکته و، او په پام کې نیولو سره، چې ډیری محصولات د لیکلو په پرتله په ډیرو لوستلو تکیه کوي، دا کولی شي په سوداګرۍ غیر ضروري اغیزه وکړي (البته د API څخه اپارتمان؛))

نو، څه شی که موږ کولی شو هغه "نظرونه" وپوښتو، چې د لوستلو موډلونو په نوم هم پیژندل کیږي، په مستقیم ډول د API شاملولو او د بارونو سمبالولو پرته؟ دا هغه ځای دی چې حلونه لکه Meilisearch ، AppSearch او نور په لوبې کې راځي، د "ویلټ کیلي" په نوم یوه نمونه کاروي. د دې نمونې په کارولو سره، فرنټ اینډونه کولی شي په مستقیم ډول د لوستلو مطلوب ماډلونو ته لاسرسی ومومي، د بیک انډ APIs پورې تړاو کموي. البته، فرنټ اینډ لاهم باید د "ویلټ کیلي" لپاره API "پوښتنه" وکړي، مګر فرنټ انډ کولی شي کیچونه خوندي کړي، نو حتی کله چې API ښکته وي، فرنټ انډ کولی شي بیا هم اړیکه ونیسي او مینځپانګه ښکاره کړي.

د دې طریقې سره، موږ کولی شو د لوستلو ډیټابیس تمرکز وکړو او زموږ په API کې د لوستلو لپاره د ټرافیک اداره کولو په اړه اندیښنه ونلرئ. زموږ د API له لارې فرنټ اینډ ته چمتو شوي "ویلټ کیلي" په داسې طریقه خوندي شوې چې فرنټ اینډ نشي کولی دا بدل کړي. پدې کې دمخه ټاکل شوي فلټرونه او شاخصونه شامل دي.

که فرنټ اینډ اضافي وړتیاو ته اړتیا ولري، دا کولی شي د API له لارې غوښتنه وکړي، چیرته چې API کولی شي تایید کړي چې ایا دوی ته اجازه ورکړي. دا اوس هم لږ زنګونه دي.

ځینې مسلکونه چې زه یې لیدلی شم دا دي:

• د API بار کم شوی : د API څخه د لوستلو ټرافیک اپلوډ کوي، دا اجازه ورکوي چې په اصلي عملیاتو تمرکز وکړي.
• د توزیع وړتیا : د لوستلو ډیټابیسونه یا د لټون خدمتونه د لوړ ترافیک اداره کولو لپاره غوره شوي ، د غوښتنلیک پس منظر اندازه کولو اړتیا کموي.
• انعطاف : SaaS یا د ځان کوربه توب اختیارونه ټیمونو ته اجازه ورکوي چې د دوی زیربنا لپاره غوره فټ غوره کړي.
• امنیت : مخکینۍ تعریف شوي فلټرونه او شاخصونه ډاډ ترلاسه کوي چې فرنټ انډ یوازې اجازه ورکړل شوي ډیټا ته لاسرسی کولی شي ، خطرونه کموي. کیلي د API لخوا باطل کیدی شي.
• د پراختیا کونکي وړتیا : د نوي فلټرونو یا لټون وړتیاو لپاره د دوامداره API تازه معلوماتو اړتیا کموي.
• ښه شوی فعالیت : د لوستلو مطلوب ماډلونو ته مستقیم لاسرسی د کاروونکو لپاره د پوښتنو ګړندي ځوابونه چمتو کوي.

مګر، تل نیمګړتیاوې شتون لري:

• د پیښې مطابقت : ډاټا ممکن د لوستلو موډلونو کې د حتمي تسلسل طبیعت له امله یو څه وروسته څرګند شي.
• اضافي ساتنه: یوه اضافي برخه معرفي کوي چې نظارت او مدیریت ته اړتیا لري.
• د سکیما پیچلتیا : سکیما باید په کوډ یا یو عام ځای کې زیرمه شي، ځکه چې د مختلفو شرایطو څخه مختلف ټیمونه ممکن ورته سند ډکولو ته اړتیا ولري (د بیلګې په توګه، د بریښنالیک سره کارمند، مګر د شته کریډیټ او کوپنونو سره هم). پداسې حال کې چې په مستقیم ډول د دې نمونې سره تړاو نلري، دا پیچلتیا زیاتوي.
• د SaaS نسخه یا د ځان کوربه شوي ساتنې لګښت

نو، دا طریقه د سپینو زرو ګولۍ نه ده او د خپلو ننګونو سیټ معرفي کوي، مګر که تاسو د یوې موافقې سره سم یاست، نو په مخکینۍ برخه کې یو کوچنی بدلون به د بیک انډ ټیم شاملولو، د پراختیا پروسې منظمولو او ښه کولو ته اړتیا ونلري. په ټولیز ډول چټکتیا، او البته، اندازه کول باید اسانه وي.