რა არის სერვერი? მარტივი სახელმძღვანელო აპლიკაციების შემქმნელებისთვის

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

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

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

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

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

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

სერვერი ჰგავს საფოსტო განყოფილების მოლარეს. ის არ დადის მომხმარებლების საძებნელად, არამედ ელოდება. მომხმარებელი მოდის მოთხოვნით — «გამომიგზავნეთ ეს ამანათი», «მაქვს რამე მიღებული?» — და მოლარე ამუშავებს მას და შედეგს აბრუნებს. ერთი მოლარე ბევრ მომხმარებელს ემსახურება ერთი მეორის შემდეგ, ხოლო დატვირთულ საფოსტო განყოფილებაში მეტი მოლარე იხსნება.

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

როგორ აღწევს მოთხოვნა სერვერს

როცა ვინმე ეწვევა https://bookings.example.com/schedule:

1. DNS მოძიება. ბრაუზერი დომენის სახელების სისტემას ეკითხება, რომელ IP მისამართზე მიუთითებს bookings.example.com. იხილეთ როგორ მუშაობს დომენები და DNS.
2. კავშირი. ბრაუზერი უკავშირდება ამ მისამართს, HTTPS-ისთვის 443 პორტზე, და ამყარებს დაშიფრულ კავშირს. იხილეთ რა არის HTTPS.
3. მოთხოვნა. იგზავნება HTTP მოთხოვნა: GET /schedule.
4. სამუშაო. სერვერი აწარმოებს კოდს, რომელიც /schedule-ს ამუშავებს, მაგალითად ეძებს დღევანდელ დაჯავშნებს მონაცემთა ბაზაში.
5. პასუხი. სერვერი აბრუნებს სტატუს კოდს (200 OK) და შიგთავსს: HTML გვერდს ან JSON მონაცემებს, რომლებსაც გვერდი აჩვენებს.

ამ ყველაფერს ჩვეულებრივ წამის ნაწილი სჭირდება.

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

გაითვალისწინეთ, რომ «სერვერი» ნიშნავს როგორც მანქანას, ისე პროგრამას. ფრაზა «სერვერი გაითიშა» შეიძლება ნიშნავდეს ორივეს.

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

აი, რას აკეთებს სერვერი პატარა სალონის დაჯავშნის აპლიკაციაში:

• ვიზიტორი ხსნის საიტს. სერვერი (ან მის წინ მდგარი CDN) აგზავნის გვერდის ფაილებს.
• გვერდი სერვერს ეკითხება GET /api/slots?date=2026-10-03. სერვერი მონაცემთა ბაზას თავისუფალ დროებზე ეკითხება და პასუხს JSON-ის სახით უბრუნებს.
• ვიზიტორი ჯავშნის 14:00-ს. გვერდი აგზავნის POST /api/bookings-ს. სერვერი ამოწმებს, რომ დრო ჯერ კიდევ თავისუფალია — ბრაუზერის სიტყვას არ ენდობა — ინახავს დაჯავშნას და პასუხობს 201 Created-ით.
• სერვერი იძახებს ელფოსტის სერვისს საიდუმლო გასაღებით, რომელიც სერვერზეა შენახული, რომ დადასტურება გაგზავნოს.

თუ სერვერს გამორთავთ, გვერდი შეიძლება მაინც ჩაიტვირთოს CDN-იდან, მაგრამ დროებს ვერ აჩვენებს და დაჯავშნებს ვერ შეინახავს.

რა სჭირდება სერვერს კარგად მუშაობისთვის

• მეხსიერება (RAM) და CPU. თუ მეხსიერება ცოტაა, აპლიკაცია დატვირთვისას ავარიულად ითიშება; თუ CPU ცოტაა, ნელდება.
• გაშვებული ყოფნა. გამორთული სერვერი ვერ უპასუხებს. ზოგი პლატფორმა უმოქმედო აპლიკაციებს იძინებს და შემდეგი ვიზიტისას აღვიძებს, რაც ფულს ზოგავს, მაგრამ პირველი მოთხოვნა შეიძლება ნელი იყოს.
• კონფიგურაცია და საიდუმლოებები, რომლებიც გარემოს ცვლადებად გადაეცემა.
• ლოგები — სერვერის ჩანაწერი იმისა, რაც მოხდა, და სწორედ აქ იწყებთ ძიებას, როცა რამე ირღვევა.
• განახლებები და უსაფრთხოების შესწორებები, რომლებსაც მართული ჰოსტინგი თქვენს მაგიერ ასრულებს.

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

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

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

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

სერვერები Mythex-ში

Mythex-ში სერვერებს არ აყენებთ და არ მართავთ. აშენებისას აპლიკაცია ცოცხალი გადახედვისთვის პირადი ღრუბლოვანი სანდბოქსში მუშაობს. გამოქვეყნებისას Mythex აპლიკაციას დეპლოიმენტს უკეთებს: სტატიკური frontend-ები როგორც სტატიკური საიტები, ხოლო backend-ები (Node, Python, C#, Java და სხვა) როგორც კონტეინერები Dockerfile-იდან. არაფერი გაქვთ დასაყენებელი ჰოსტინგში. დეპლოიმენტისას Mythex თავად ირჩევს მანქანის ზომას: საწყისად 1 CPU და 512 MB მეხსიერება, უფრო მეტიც შესაძლებელია მოთხოვნით (Free-ზე 1 GB-მდე, Pro-ზე 2 CPU-მდე, 4 GB-მდე და 3 მანქანამდე). გამოქვეყნებული აპლიკაციები უმოქმედობისას იძინებენ და შემდეგ ვიზიტზე იღვიძებენ, ხოლო მძინარე აპლიკაცია გამოთვლით რესურსზე არაფერს ხარჯავს. დეტალები მოცემულია დოკუმენტაციის გვერდებზე API backend-ები და ჰოსტინგის ლიმიტები, ხოლო ჩვენი ვებ ჰოსტინგის სახელმძღვანელო უფრო ფართო სურათს გვაძლევს.

კითხვები