რა არის Full-Stack აპლიკაცია? მარტივი ახსნა

Full-stack აპლიკაცია არის აპლიკაცია, რომელსაც თავისი მუშაობისთვის საჭირო ყველა ფენა აქვს: frontend, რომელსაც ხალხი ხედავს და აწკაპუნებს, backend, რომელიც სერვერზე მუშაობს და წესებს ახორციელებს, და მონაცემთა ბაზა, რომელიც ყველაფერს იმახსოვრებს. ამოცანების სია, რომელიც შენახავს თქვენს საქმეებს, შეგიძლიათ ნებისმიერი მოწყობილობიდან შეხვიდეთ და ვერავინ ნახავს თქვენს სიას, არის full-stack. ერთი გვერდი, რომელიც მხოლოდ სამუშაო საათებს აჩვენებს, არა.

«Stack» (სტეკი) უბრალოდ ნიშნავს ტექნოლოგიების ფენებს, რომლებიც ერთმანეთზეა დაწყობილი. «Full» ნიშნავს, რომ ყველა მათგანი აქ არის.

რატომ არის მნიშვნელოვანი AI-ით აშენებისას

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

ფენების ცოდნა რამდენიმე თვალსაზრისით გეხმარებათ:

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

ყოველდღიური ანალოგია: რესტორანი

წარმოიდგინეთ რესტორანი.

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

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

სამი ფენა დეტალურად

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

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

სამუშაო მაგალითი: იოგას სტუდიის დაჯავშნის აპლიკაცია

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

რას აკეთებს ვიზიტორი: შედის საიტზე, ხედავს ამ კვირის გაკვეთილებს, არჩევს ერთ-ერთს, შედის სისტემაში და ჯავშნის ადგილს.

რა ხდება ქვეშ:

1. Frontend აჩვენებს განრიგს. მის შესავსებად ის backend-ს ეკითხება: «რა გაკვეთილებია ამ კვირაში და რამდენი ადგილი თავისუფალია?»
2. Backend ეკითხება მონაცემთა ბაზას გაკვეთილებს და ითვლის თითოეულზე დაჯავშნებს, შემდეგ პასუხობს.
3. ვიზიტორი აჭერს დაჯავშნა-ს. frontend აგზავნის: «დაჯავშნე გაკვეთილი 42 ამ შესული ადამიანისთვის».
4. Backend ამოწმებს: ნამდვილად შესულია თუ არა ეს ადამიანი? სავსეა თუ არა გაკვეთილი? უკვე დაჯავშნა თუ არა? მხოლოდ მაშინ, თუ ყველაფერი რიგზეა, იწერს ახალ დაჯავშნის ხაზს მონაცემთა ბაზაში.
5. Backend პასუხობს «დაჯავშნილია», და frontend დადასტურებას აჩვენებს.
6. მოგვიანებით სტუდიის მფლობელი შედის სისტემაში და ხედავს გაკვეთილების სიას. backend ამოწმებს, რომ ის ადმინია, სანამ ყველას სახელებს აჩვენებს.

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

მთავარი ტერმინები

• Frontend (კლიენტის მხარე): ის ნაწილი, რომელიც ბრაუზერში მუშაობს.
• Backend (სერვერის მხარე): ის ნაწილი, რომელიც სერვერზე მუშაობს. ასევე უწოდებენ API სერვერს.
• მონაცემთა ბაზა: სადაც მონაცემები ორგანიზებულად ინახება. იხილეთ რა არის მონაცემთა ბაზა.
• API: მოთხოვნების სია, რომლებსაც backend frontend-იდან ან სხვა პროგრამებიდან იღებს.
• ავთენტიფიკაცია (authentication): ვინ ხართ თქვენ (შესვლა). ავტორიზაცია (authorisation): რის გაკეთება შეგიძლიათ.
• დეპლოიმენტი: ყველა ფენის სერვერებზე განთავსება, რომ საზოგადოებამ გამოიყენოს.
• Monolith vs სერვისები: ერთი პროგრამა, რომელიც ყველაფერს აკეთებს, ან რამდენიმე პატარა (მაგალითად ვებსაიტი და ცალკე API). ორივე full-stack-ია.

გავრცელებული შეცდომები და მცდარი წარმოდგენები

• «გამოიყურება დასრულებულად, ამიტომ დასრულებულია.» ნიმუშური მონაცემები და სწორად მოჩანი ღილაკი არ არის შენახული მონაცემები. განაახლეთ გვერდი, გახსენით კერძო ფანჯარაში და შეამოწმეთ, რომ მონაცემები კვლავ იქაა.
• წესების frontend-ში დადება. ღილაკის დამალვა უსაფრთხოება არ არის. თუ backend არ ამოწმებს, ნებისმიერს, ვინც მოთხოვნას იცნობს, შეუძლია იგი პირდაპირ გაგზავნოს.
• საიდუმლო გასაღებების frontend-ში დადება. გადახდის ან AI პროვაიდერის გასაღები ბრაუზერის კოდში ყველა ვიზიტორს შეუძლია წაიკითხოს. გასაღებები backend-ზე უნდა იყოს, გარემოს ცვლადებში. იხილეთ გარემოს ცვლადები და საიდუმლოებები.
• full-stack ნიშნავს რთულს. პატარა full-stack აპლიკაცია შეიძლება იყოს რამდენიმე ეკრანი, რამდენიმე backend მარშრუტი და სამი ცხრილი. ეს ფენების აღწერაა და არა ზომის.
• ფიქრობთ, რომ ყველა ტექნოლოგია თქვენ უნდა აირჩიოთ. პირველი ვერსიისთვის ნებისმიერი გონივრული, ფართოდ გავრცელებული სტეკი გამოდგება. უფრო მნიშვნელოვანია მონაცემებისა და წესების ნათელი აღწერა.

რა ვკითხოთ თქვენს AI შემქმნელს

აღწერეთ აპლიკაცია სამი ფენის თვალსაზრისით, მაშინაც კი, თუ მათ სახელებს არ ასახელებთ:

• მონაცემები: «შეინახე კლასები (სახელი, დრო, ტევადობა) და დაჯავშნები (კლასი, ადამიანი, დაჯავშნის დრო) მონაცემთა ბაზაში.»
• წესები: «კლასში ტევადობაზე მეტი ადამიანი ვერ დაჯავშნის. ადამიანი კლასს მხოლოდ ერთხელ შეძლებს. მხოლოდ ადმინები ნახავენ, ვინ დაჯავშნა.»
• ეკრანები: «ყოველკვირეული განრიგი, დაჯავშნის დადასტურება, ადმინის გვერდი, რომელიც კლასებზე დაჯავშნებს ჩამოთვლის.»
• შემოწმებები: «ამ წესებს სერვერზე აღასრულე და არა მხოლოდ გვერდზე. API გასაღებები სერვერზე დატოვე.»

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

Full-stack აპლიკაციები Mythex-ზე

Mythex ჩატში აღწერილი აღწერიდან აშენებს full-stack ვებ აპლიკაციებს. ახალ აპლიკაციას საწყისად React და TypeScript frontend აქვს. როცა აპლიკაციას მონაცემების შენახვა სჭირდება, Mythex პროექტში გამოყოფილ Postgres მონაცემთა ბაზას ამატებს, და შეგიძლიათ მოითხოვოთ ცალკე API სერვერი (მაგალითად Python, Node, C# ან Java) ვებსაიტის გვერდით. ყველაფერი ერთად მუშაობს ცოცხალ გადახედვაში და იქვე ქვეყნდება საჯარო URL-ზე. დოკუმენტაციის გვერდი მრავალსერვისიანი აპლიკაციების შესახებ აჩვენებს, როგორ გადაიხედება და ქვეყნდება ვებსაიტი და API ერთად, ხოლო full-stack აპლიკაციის ბილდერის გვერდზე საწყისი წერტილებია.

კითხვები