Vad är en server? En enkel guide för appbyggare

En server är en dator, eller ett program som körs på en dator, som väntar på förfrågningar och svarar på dem. När du öppnar en webbplats skickar din webbläsare (klienten) en förfrågan över internet, och en server någonstans skickar tillbaka sidan, bilderna eller datan. Varje app du använder, från e-post till nätbank, bygger på att servrar gör detta miljontals gånger om dagen.

Varför servrar spelar roll när du bygger med AI

När en AI-byggare gör en app åt dig körs en del av koden i besökarens webbläsare och en del oftast på en server. Serverdelen gör de saker som webbläsaren inte kan lita på eller inte kan göra ensam:

• Spara och ladda data från en databas.
• Hålla hemligheter, som nycklar till betal- eller AI-leverantörer, som aldrig får nå webbläsaren.
• Kontrollera behörigheter, så att en användare bara kan se och ändra sina egna poster.
• Prata med andra tjänster: debitera ett kort, skicka ett mejl, anropa en AI-modell.

Att veta vad servern gör hjälper dig förstå var din apps regler egentligen bor, varför vissa ändringar kräver en ny publicering och vad du betalar för när du hostar en app. För uppdelningen mellan de två halvorna, se frontend kontra backend.

En vardaglig jämförelse

En server är som kundtjänsten på ett postkontor. De letar inte efter kunder; de väntar. En kund (klienten) går fram med en förfrågan, ”skicka det här paketet” eller ”har ni post till mig?”, och expediten hanterar den och lämnar tillbaka ett resultat. En expedit kan betjäna många kunder efter varandra, och ett upptaget postkontor öppnar fler luckor.

Postkontoret har också regler som kunden inte kan åsidosätta: du måste visa legitimation för att hämta ett paket. Det är serverns uppgift i en app också. Webbläsaren kan be om vad som helst, men servern bestämmer vad den får.

Hur en förfrågan når en server

När någon besöker https://bookings.example.com/schedule:

1. DNS-uppslag. Webbläsaren frågar domännamnssystemet vilken IP-adress bookings.example.com pekar på. Se hur domäner och DNS fungerar.
2. Anslutning. Webbläsaren ansluter till den adressen, på port 443 för HTTPS, och sätter upp en krypterad förbindelse. Se vad HTTPS är.
3. Förfrågan. Den skickar en HTTP-förfrågan: GET /schedule.
4. Arbete. Servern kör koden som hanterar /schedule, kanske genom att slå upp dagens bokningar i databasen.
5. Svar. Den skickar tillbaka en statuskod (200 OK) och innehållet: en HTML-sida, eller JSON-data som sidan visar.

All detta tar vanligtvis en bråkdel av en sekund.

Vilka sorters servrar du hör talas om

Observera att ”server” betyder både maskinen och programmet. ”Servern kraschade” kan betyda båda.

Ett genomgånget exempel: en bokningsapp för en frisersalong

Här är vad servern gör i en liten bokningsapp för en salong:

• En besökare öppnar sidan. Servern (eller ett CDN framför den) skickar sidfilerna.
• Sidan frågar servern GET /api/slots?date=2026-10-03. Servern frågar databasen efter lediga tider och returnerar dem som JSON.
• Besökaren bokar 14:00. Sidan skickar POST /api/bookings. Servern kontrollerar att tiden fortfarande är ledig, eftersom den inte litar på webbläsarens påstående, sparar bokningen och returnerar 201 Created.
• Servern anropar en e-posttjänst med en hemlig nyckel, lagrad på servern, för att skicka en bekräftelse.

Om du stängde av servern kunde sidan fortfarande laddas från ett CDN, men den kunde inte visa lediga tider eller spara bokningar.

Vad en server behöver för att fungera bra

• Minne (RAM) och CPU. För lite minne och appen kraschar under belastning; för lite CPU och den blir långsam.
• Att vara igång. En server som är avstängd kan inte svara. Vissa plattformar sätter inaktiva appar i viloläge och väcker dem vid nästa besök, vilket sparar pengar men kan göra den första förfrågan långsammare.
• Konfiguration och hemligheter, tillhandahållna som miljövariabler.
• Loggar, serverns protokoll över vad som hänt, vilket är första stället du tittar när något går sönder.
• Uppdateringar och säkerhetspatchar, som hanterad hosting sköter åt dig.

Vanliga missuppfattningar

• ”Molnet betyder att det inte finns några servrar.” Molnet är andra företags servrar, hyrda per timme eller efter användning.
• ”En server är en stor speciell dator.” Vilken dator som helst kan fungera som server. Din laptop kör en när du öppnar localhost under utveckling.
• ”Om knappen är dold kan användarna inte göra det.” Vem som helst kan skicka förfrågningar direkt till din server. Behörighetskontroller måste ske på servern, inte bara i sidan.
• ”Fler servrar löser långsamhet.” Ofta är den verkliga orsaken en långsam databasfråga eller ett externt API. Hitta flaskhalsen först.
• ”Jag måste sköta en server för att ha en app.” Hanterade plattformar kör servrarna åt dig; du distribuerar koden och de sköter maskinerna.

Vad du ska fråga din AI-byggare

• ”Vilka delar av den här appen körs på servern, och vilka körs i webbläsaren?”
• ”Håll alla API-nycklar på servern och läs dem från miljövariabler.”
• ”Kontrollera behörigheter på servern för varje förfrågan som läser eller ändrar data.”
• ”Var hittar jag serverloggarna, och vad säger de om det här felet?”
• ”Behöver den här appen en server alls, eller kan den vara en statisk sida?”
• ”Vad händer med den första förfrågan efter att appen varit inaktiv?”

Servrar i Mythex

På Mythex hanterar du inte några servrar. Medan du bygger körs din app i en privat molnsandlåda för live-förhandsvisningen. När du publicerar distribuerar Mythex den: statiska frontends som statiska sajter och backends (Node, Python, C#, Java och andra) som containrar byggda från en Dockerfile, utan någon hosting att konfigurera själv. Mythex väljer maskinstorlek vid distributionen: som standard 1 CPU och 512 MB minne, med mer tillgängligt på begäran (upp till 1 GB på Free, och upp till 2 CPU:er, 4 GB och 3 maskiner på Pro). Publicerade appar somnar när de är inaktiva och vaknar vid nästa besök, och en sovande app kostar ingen beräkningstid. Detaljerna finns i dokumentationen om API-backends och hostinggränser, och vår guide till webbhosting täcker helheten.

Frågor