სად შესრულდეს API-ის ლოგიკა: ბაზაში, middleware-ში თუ აპლიკაციაში

ფუნქციის მონაცემებთან გადატანამ შეიძლება აპლიკაციის სამუშაო შეამციროს, მაგრამ გადაწყვეტილების პასუხისმგებლობაც შეცვალოს. თუ ველის შემოწმება კლიენტის მომსახურების უფლებას წყვეტს, ტექნიკური ოპტიმიზაცია ბიზნესკონტროლად იქცევა.

წესი უნდა განთავსდეს იმის მიხედვით, რა მონაცემები და უფლებები სჭირდება, როგორ მოწმდება და როგორ ბრუნდება უკან. ენის სინტაქსი და ხელსაწყოს მოხერხებულობა შემდეგ მოდის.

მოთხოვნის ოთხი ფენა

Percona-ს 15 ოქტომბრის განხილვა ქსელისა და ფაილების წვდომის გარეშე MySQL-ის JavaScript-ფუნქციებს აღწერს. Supabase-ის 15 ოქტომბრის მასალა Fetch-დამმუშავებლების თანმიმდევრულ კომპოზიციას ეხება.

Cloudflare-ის 14 ოქტომბრის ანალიზი მდგომარეობისა და ქეშის სისწორეს განიხილავს. Postman-ის 9 ოქტომბრის პუბლიკაცია დატვირთვის ღრუბლიდან გაშვებას აღწერს. არცერთი წყარო ნებისმიერი API-ის აჩქარებას არ ადასტურებს.

ჩვენი დასკვნაა, რომ მნიშვნელობის გარდაქმნა, მოთხოვნის დაშვება და ბიზნესგადაწყვეტილება უნდა განვასხვაოთ. ქეშმაც პასუხის აზრი და წვდომის საზღვრები უნდა შეინარჩუნოს. კონკრეტული სტეკი ცალკე შემოწმებას საჭიროებს.

გამოთვლა უფლებამოსილება არ არის

ფუნქციას შეუძლია ტელეფონი ერთ ფორმატში მოიყვანოს და შეცდომები დააბრუნოს. უნდა დავუკავშირდეთ თუ არა კლიენტს, უარვყოთ განაცხადი თუ ოპერატორს ვკითხოთ, პროცესის მდგომარეობასა და კომპანიის წესებზეა დამოკიდებული. ეს მცირე გარდამქმნელი ფუნქციის საქმე აღარ არის.

შესასვლელი ფენა დაუდასტურებელ მოთხოვნას აჩერებს. მოქმედი ტოკენი კონკრეტული განაცხადის დამტკიცების უფლებას ავტომატურად არ იძლევა. საჭიროა ჩანაწერის კუთვნილება, მიმდინარე სტატუსი და ნებადართული გადასვლა.

ყოველი წესისთვის ცალკე მიკროსერვისი საჭირო არ არის. ერთი აპლიკაციის ნაწილებს მკაფიო კონტრაქტი სჭირდება: რა შემოწმდა, რა მნიშვნელობა დაბრუნდა და ვინ წყვეტს შემდეგ ნაბიჯს. წინააღმდეგ შემთხვევაში საერთო ფუნქციის ხელახალი გამოყენება მის უფლებამოსილებას ჩუმად აფართოებს.

უკან დაბრუნებაც საზღვარს აჩენს. ნორმალიზაციის ძველი წესის აღდგენამ შეჯერება შეიძლება შეცვალოს. დამტკიცების პოლიტიკის დაბრუნება უკვე პროდუქტის გადაწყვეტილებაა. ორივეს ჩვეულებრივ დამხმარე განახლებად მიჩნევა განხილვას ართულებს.

პირობითი მაგალითი: კონტაქტების იმპორტი

კომპანია პარტნიორების კონტაქტებს სხვადასხვა წყაროდან იღებს. ერთ ნომერში გამოტოვებებია, მეორე სახელი არსებულ კლიენტს ჰგავს, მესამე სხვა ორგანიზაციას ეკუთვნის. ეს პროექტირების მაგალითია და არა დანერგვის შედეგი.

შესასვლელში განისაზღვრება ორგანიზაცია და იმპორტის უფლება. გარდაქმნა ნორმალიზებულ ნომერსა და შეცდომების ნიშნებს ქმნის. აპლიკაცია წყვეტს, შეიძლება თუ არა არსებული კონტაქტის შეცვლა და ვინ განიხილავს კონფლიქტს. მსგავსი სახელი გაერთიანების ნებართვა არ არის.

განმეორებითი იმპორტისთვის წყაროს მწკრივის იდენტობა და შინაარსის ვერსია ინახება. წესის შეცვლისას ოპერატორი მიზეზს ხედავს და არა თითქოს ახალ, დაუკავშირებელ ჩანაწერს. საწყისი მონაცემი ახსნას ეხმარება, თუმცა იმავე დაცვის წესებით უნდა შეინახოს.

ფორმატების საერთო ცნობარისა და პერსონალური კონტაქტების პასუხის ქეშირება სხვადასხვა პოლიტიკაა. მეორე შემთხვევაში საჭიროა უფლებების კონტექსტი, გაუქმების წესი და დასაშვები მოძველების ზღვარი. სწრაფი ეკრანი ქეშის სისწორეს არ ამტკიცებს.

სად გადავიდა დატვირთვა

ბაზაში გამოთვლის გადატანის შემდეგ აპლიკაცია შეიძლება აჩქარდეს, ბაზის სამუშაო კი გაიზარდოს. უნდა შევადაროთ მოთხოვნის მთელი გზა, კავშირებისთვის კონკურენცია, ტრანზაქციის ხანგრძლივობა და შეცდომები. სხვაგვარად ოპტიმიზაცია მხოლოდ რიგის ადგილს შეცვლის.

დატვირთვა მოიცავს სწორ მონაცემს, კონფლიქტსა და უარს. მხოლოდ სუფთა იმპორტი პრობლემური ჩანაწერის ღირებულებას არ აჩვენებს. ღრუბლოვანი გენერატორი ლეპტოპის შეზღუდვას აცალკევებს, მაგრამ ცუდ სცენარს წარმომადგენლობითად ვერ აქცევს.

მიღების სასარგებლო პირობაა: იგივე უფლებები და მონაცემები ცვლილებამდე და შემდეგ იმავე ბიზნესგადაწყვეტილებას იძლევა. განზრახ შეცვლილ გადაწყვეტილებას ცალკე მიღება სჭირდება.

ბიზნესლოგიკა და წესები საზღვრებს აზუსტებს. საკუთარი API-ის პროექტის სქემა დაკავშირებული კონტექსტია. ინტეგრაციების დაგეგმვა ჯერ გადაწყვეტილებებითა და უფლებებით უნდა დაიწყოს.