Ano ang Server? Gabay sa Simpleng Wika para sa mga Gumagawa ng App

Ang server ay computer, o programang tumatakbo sa isa, na naghihintay ng mga request at sumasagot dito. Kapag binubuksan mo ang isang website, nagpapadala ang browser mo (ang client) ng request sa internet, at may server sa kung saan man na nagpapadala pabalik ng page, mga imahe, o datos. Bawat app na ginagamit mo, mula sa email hanggang online banking, ay umaasa sa mga server na gumagawa nito nang milyun-milyong beses bawat araw.

Bakit mahalaga ang server kapag gumagawa ka gamit ang AI

Kapag gumawa ng app para sa iyo ang AI builder, may bahagi ng code na tumatakbo sa browser ng bisita at may bahagi na kadalasang tumatakbo sa server. Ginagawa ng bahagi ng server ang mga bagay na hindi mapagkakatiwalaan ng browser, o hindi kayang gawin nang mag-isa:

• Pag-save at pag-load ng datos mula sa database.
• Pagtatago ng mga lihim, gaya ng API keys ng bayad o AI provider, na hindi dapat kailanman umabot sa browser.
• Pagtingin sa mga pahintulot: tinitiyak na ang user ay makakakita at makakapagbago lang ng sarili niyang tala.
• Pakikipag-usap sa ibang serbisyo: pagsingil ng card, pagpapadala ng email, pagtawag sa AI model.

Makakatulong ang pag-alam sa ginagawa ng server para malaman kung saan talaga nakatira ang mga tuntunin ng app mo, bakit may ilang pagbabagong nangangailangan ng republish, at kung ano ang binabayaran mo kapag nag-host ka ng app. Para sa paghahati ng dalawang panig, tingnan ang frontend vs backend.

Isang halimbawa mula sa araw-araw

Ang server ay parang staff sa counter ng post office. Hindi sila lumalabas para humanap ng customer; naghihintay sila. Lalapit ang customer na may request, gaya ng "ipadala ang parsel na ito" o "may sulat ba para sa akin?", at hahawakan ito ng clerk at magbibigay ng resulta. Isang clerk ang puwedeng magserbisyo sa maraming customer nang sunod-sunod, at magbubukas ng dagdag na counter ang abalang post office.

May mga tuntunin din ang post office na hindi maaaring balewalain ng customer: kailangan mong magpakita ng ID para makuha ang parsel. Ganyan din ang trabaho ng server sa app. Puwedeng humingi ng kahit ano ang browser, pero ang server ang nagpapasya kung ano ang ibibigay.

Paano nakakarating ang request sa server

Kapag may bumisita sa https://bookings.example.com/schedule:

1. DNS lookup. Tinatanong ng browser ang domain name system kung aling IP address ang tinuturo ng bookings.example.com. Tingnan ang paano gumagana ang domains at DNS.
2. Koneksyon. Kumokonekta ang browser sa address na iyon, sa port 443 para sa HTTPS, at nagse-set up ng naka-encrypt na koneksyon. Tingnan ang ano ang HTTPS.
3. Request. Nagpapadala ito ng HTTP request: GET /schedule.
4. Trabaho. Pinapatakbo ng server ang code na humahawak sa /schedule, halimbawa ay hinahanap ang mga booking ngayong araw sa database.
5. Sagot. Nagpapadala ito pabalik ng status code (200 OK) at ng nilalaman: isang HTML page, o datos na JSON para ipakita ng page.

Karaniwang nasa maliit na bahagi ng isang segundo ang buong prosesong ito.

Mga uri ng server na maririnig mo

Tandaang ang "server" ay tumutukoy sa makina at sa programa. Ang "bumagsak ang server" ay maaaring tumukoy sa alinman.

Halimbawang gawa: isang booking app para sa salon

Narito ang ginagawa ng server sa isang maliit na booking app para sa salon:

• Binubuksan ng bisita ang site. Ang server (o isang CDN sa harap nito) ang nagpapadala ng mga file ng page.
• Hihingi ang page sa server ng GET /api/slots?date=2026-10-03. Magqu-query ang server sa database para sa mga bakanteng oras at ibabalik ang mga ito bilang JSON.
• Nag-book ang bisita ng 14:00. Magpapadala ang page ng POST /api/bookings. Titingnan ng server kung bakante pa rin ang oras (hindi nito pinagkakatiwalaan ang sinasabi ng browser), sine-save ang booking, at nagbabalik ng 201 Created.
• Tatawag ang server sa email service gamit ang secret key na nakatago sa server para magpadala ng kumpirmasyon.

Kung pinatay mo ang server, maaaring mag-load pa rin ang page mula sa CDN, pero hindi nito maipapakita ang mga bakanteng oras o makapag-save ng booking.

Ano ang kailangan ng server para maayos na tumakbo

• Memory (RAM) at CPU. Kapag kulang ang memory, nag-crash ang app sa maraming bisita; kapag kulang ang CPU, bumabagal ito.
• Dapat tumatakbo. Ang server na naka-off ay hindi makakasagot. May ilang platform na pinatutulog ang mga app na hindi ginagamit at ginigising sa susunod na bisita, na nakakatipid ng pera pero puwedeng magpabagal sa unang request.
• Configuration at secrets, na ibinibigay bilang environment variables.
• Logs: ang talaan ng server ng mga nangyari, na siyang unang tinitingnan kapag may nasira.
• Update at security patch, na inaasikaso para sa iyo ng managed hosting.

Mga karaniwang maling akala

• "Ibig sabihin ng cloud ay walang server." Ang cloud ay mga server ng ibang kompanya, na inuupahan kada oras o ayon sa gamit.
• "Malaki at espesyal na computer ang server." Puwedeng maging server ang kahit anong computer. Ang laptop mo ay nagpapatakbo ng isa kapag binuksan mo ang localhost habang nagde-develop.
• "Kapag nakatago ang button, hindi ito magagawa ng user." Puwedeng magpadala ang sinuman ng request diretso sa server mo. Dapat isagawa ang pagsusuri ng pahintulot sa server, hindi lang sa page.
• "Ang dagdag na server ang lulutas sa pagiging mabagal." Kadalasan, ang tunay na sanhi ay mabagal na database query o external API. Hanapin muna ang bottleneck.
• "Kailangan kong pamahalaan ang server para magkaroon ng app." Ang managed platform ang nagpapatakbo ng mga server para sa iyo; nagde-deploy ka lang ng code at sila na ang bahala sa mga makina.

Ano ang itatanong sa AI builder mo

• "Aling bahagi ng app na ito ang tumatakbo sa server, at alin ang tumatakbo sa browser?"
• "Itago ang lahat ng API key sa server at basahin ang mga ito mula sa environment variables."
• "Suriin ang mga pahintulot sa server para sa bawat request na bumabasa o nagbabago ng datos."
• "Saan ko makikita ang server logs, at ano ang sinasabi nila tungkol sa error na ito?"
• "Kailangan ba talaga ng app na ito ng server, o puwede itong maging static na site?"
• "Ano ang mangyayari sa unang request pagkatapos hindi magamit ang app nang matagal?"

Mga server sa Mythex

Sa Mythex, hindi ka nagse-set up o nagmamanage ng server. Habang gumagawa ka, tumatakbo ang app mo sa pribadong cloud sandbox para sa live na preview. Kapag nag-publish ka, dine-deploy ito ng Mythex: ang mga static front end bilang static site, at ang mga backend (Node, Python, C#, Java at iba pa) bilang mga container na ginawa mula sa Dockerfile, nang walang hosting na ikaw mismo ang kailangang i-configure. Pinipili ng Mythex ang laki ng makina kapag nagde-deploy: bilang default ay 1 CPU at 512 MB na memory, at may mas malalaki kapag hiniling (hanggang 1 GB sa Free, at hanggang 2 CPU, 4 GB at 3 makina sa Pro). Natutulog ang mga na-publish na app kapag hindi ginagamit at gumigising sa susunod na bisita, at ang natutulog na app ay hindi gumagastos sa compute. Nakalagay ang mga detalye sa docs tungkol sa API backends at hosting limits, at sakop ng aming gabay sa web hosting ang mas malawak na larawan.

Mga tanong