Frontend Edge Funkcijų Geografinis Maršrutizavimas: Vietove Grįsto Užklausų Paskirstymo Vadovas

Šiuolaikiniame tarpusavyje susijusiame pasaulyje programų kūrimas pasaulinei auditorijai nebėra pasirinkimas – tai būtinybė. Tačiau pasaulinė vartotojų bazė kelia unikalių iššūkių: Kaip pristatyti turinį su minimalia delsa vartotojui Tokijuje ir kitam Berlyne? Kaip laikytis regioninių duomenų privatumo įstatymų, tokių kaip BDAR Europoje? Kaip pateikti lokalizuotą turinį, pavyzdžiui, valiutą ir kalbą, kuris kiekvienam vartotojui atrodytų natūralus? Atsakymas slypi tinklo pakraštyje (edge).

Sveiki atvykę į Frontend Edge Funkcijų Geografinio Maršrutizavimo pasaulį. Ši galinga paradigma sujungia mažos delsos edge funkcijų vykdymą su vietove pagrįstos logikos intelektu, siekiant sukurti greitesnes, labiau reikalavimus atitinkančias ir itin personalizuotas vartotojų patirtis. Perimdami užklausas tinklo pakraštyje – fiziškai arčiau vartotojo – kūrėjai gali priimti dinamiškus maršrutizavimo sprendimus dar prieš užklausai pasiekiant centralizuotą pagrindinį serverį (origin server).

Šis išsamus vadovas jus supažindins su viskuo, ką reikia žinoti apie geografinį maršrutizavimą tinklo pakraštyje. Išnagrinėsime, kas tai yra, kodėl tai keičia žaidimo taisykles šiuolaikinėje svetainių kūrimo srityje ir kaip galite tai įgyvendinti. Nesvarbu, ar esate architektas, projektuojantis pasaulinę sistemą, programuotojas, optimizuojantis našumą, ar produkto vadovas, siekiantis geresnio personalizavimo, šis straipsnis suteiks jums įžvalgų ir praktinių žinių, kaip įvaldyti vietove grįstą užklausų paskirstymą.

Kas yra Geografinis Maršrutizavimas?

Savo esme, Geografinis Maršrutizavimas (arba geo-maršrutizavimas) yra praktika, kai tinklo srautas nukreipiamas į skirtingas paskirties vietas, atsižvelgiant į užklausą siunčiančio vartotojo geografinę vietą. Tai tarsi išmanusis interneto eismo reguliuotojas, užtikrinantis, kad kiekvieno vartotojo užklausa būtų nusiųsta į tinkamiausią serverį ar tarnybą, kad ją įvykdytų.

Tradiciniai Metodai Prieš Edge Revoliuciją

Istoriškai geo-maršrutizavimas daugiausia buvo valdomas DNS lygmeniu. Technika, vadinama GeoDNS, domenų vardą išverčia į skirtingus IP adresus, priklausomai nuo to, iš kur kilo DNS užklausa. Pavyzdžiui, vartotojas Azijoje gautų serverio Singapūre IP adresą, o vartotojas Europoje būtų nukreiptas į serverį Frankfurte.

Nors DNS pagrįstas maršrutizavimas yra efektyvus nukreipiant srautą į skirtingus regioninius duomenų centrus, jis turi apribojimų:

• Detalumo trūkumas: DNS veikia aukštu lygmeniu. Jis negali tikrinti individualių užklausų antraščių ar priimti sprendimų remdamasis kuo nors kitu, išskyrus DNS užklausos šaltinį.
• Talpyklos (cache) vėlavimai: DNS įrašai yra intensyviai saugomi talpyklose visame internete. Pakeitimai gali užtrukti minutes ar net valandas, kol paplis visame pasaulyje, todėl tai netinka dinamiškam, realaus laiko maršrutizavimui.
• Netikslumas: Vieta nustatoma pagal vartotojo DNS serverį (resolver), kuris gali netiksliai atspindėti tikrąją vartotojo vietą (pvz., naudojant viešą DNS, kaip Google 8.8.8.8).

Edge funkcijos revoliucionizuoja šį procesą. Vietoj maršrutizavimo DNS lygmeniu, logika yra vykdoma kiekvienai HTTP užklausai Turinio Pristatymo Tinklo (CDN) Buvimo Taške (PoP). Tai suteikia daug galingesnį ir lankstesnį požiūrį, leidžiantį priimti realaus laiko sprendimus kiekvienai užklausai, remiantis tiksliais, tiekėjo pateiktais vietos duomenimis.

Edge Galia: Kodėl Edge Funkcijos yra Idealus Įrankis

Norint suprasti, kodėl edge funkcijos yra tokios efektyvios, pirmiausia reikia suprasti, kas yra „edge“. Edge yra pasaulinis serverių tinklas, strategiškai išdėstytas duomenų centruose visame pasaulyje. Kai vartotojas apsilanko jūsų svetainėje, jo užklausą apdoroja fiziškai arčiausiai jo esantis serveris, o ne tolimas, centralizuotas serveris.

Edge funkcijos yra mažos, be serverio veikiančios kodo dalys (dažnai JavaScript/TypeScript), kurios veikia šiame tinkle. Štai kodėl jos yra idealus įrankis geografiniam maršrutizavimui:

1. Itin Maža Uždelsa

Fizika yra pagrindinė kliūtis interneto našumui. Laikas, per kurį duomenys keliauja tarp žemynų, yra reikšmingas. Vykdant maršrutizavimo logiką artimiausiame edge mazge, sprendimas priimamas per milisekundes. Tai reiškia, kad galite nukreipti vartotoją, perrašyti užklausą į regioninį backend'ą ar pateikti lokalizuotą turinį beveik akimirksniu, be papildomos delsos, kuri atsirastų keliaujant į pagrindinį serverį.

2. Detalus, Kiekvienos Užklausos Valdymas

Skirtingai nuo DNS, edge funkcija gali patikrinti visą gaunamą HTTP užklausą. Tai apima antraštes, slapukus, užklausos parametrus ir kt. Šiuolaikinės edge platformos taip pat įterpia patikimus geografinius duomenis į užklausą, tokius kaip vartotojo šalis, regionas ir miestas. Tai leidžia sukurti neįtikėtinai smulkias taisykles, pavyzdžiui, nukreipti vartotojus iš konkretaus miesto į beta funkciją arba blokuoti srautą iš sankcionuoto regiono.

3. Sumažinta Pradinio Serverio Apkrova ir Kaina

Valdydami maršrutizavimo logiką edge tinkle, jūs sumažinate didelę dalį darbo savo pagrindiniams programų serveriams. Jei užklausa gali būti aptarnauta tiesiai iš edge talpyklos, nukreipta ar užblokuota edge tinkle, jai niekada nereikia naudoti jūsų brangių pagrindinio serverio skaičiavimo resursų. Tai lemia atsparesnę, labiau mastelį keičiančią ir ekonomiškesnę architektūrą.

4. Sklandi Integracija su Šiuolaikinėmis Karkasais

Platformos, tokios kaip Vercel, Netlify ir Cloudflare, glaudžiai integravo edge funkcijas į savo kūrimo procesus. Su karkasais, kaip Next.js, Nuxt ar SvelteKit, edge logikos įgyvendinimas gali būti toks pat paprastas, kaip pridėti `middleware.ts` failą į savo projektą, todėl tai tampa prieinama frontend kūrėjams be gilių DevOps žinių.

Kaip Veikia Geografinis Maršrutizavimas su Edge Funkcijomis: Žingsnis po Žingsnio

Atsekime vartotojo užklausos kelionę, kad suprastume edge pagrįsto geografinio maršrutizavimo mechaniką.

1. Vartotojas Inicijuoja Užklausą: Vartotojas Londone, JK, įveda jūsų svetainės URL į savo naršyklę.
2. Užklausa Pasiekia Artimiausią Edge Mazgą: Užklausa nekeliauja iki pat serverio JAV. Vietoj to, ją perima artimiausias Buvimo Taškas (PoP), greičiausiai Londone.
3. Iškviečiama Edge Funkcija: Edge platforma aptinka, kad turite sukonfigūravę edge funkciją šiam keliui. Funkcijos kodas įvykdomas akimirksniu.
4. Gaunami Vietos Duomenys: Platforma automatiškai pateikia funkcijai vartotojo vietos duomenis, paprastai per specialias užklausos antraštes (pvz., `x-vercel-ip-country: 'GB'`, `cf-ipcountry: 'GB'`) arba `request.geo` objektą.
5. Taikoma Maršrutizavimo Logika: Jūsų kodas dabar vykdo savo logiką. Jis patikrina šalies kodą. Pavyzdžiui:

               if (country === 'GB') { ... }
               
   
                 
                   Copy
                 
               
             

6. Imamasi Veiksmų: Remdamasi logika, funkcija gali atlikti kelis veiksmus:
   • Perrašymas į Regioninį Backend'ą: Funkcija gali tyliai persiųsti užklausą į kitą serverį, pavyzdžiui, `https://api.eu.your-service.com`, nekeisdama URL vartotojo naršyklėje. Tai puikiai tinka duomenų rezidencijos reikalavimams.
   • Nukreipimas į Lokalizuotą URL: Funkcija gali grąžinti 307 (Laikinasis nukreipimas) arba 308 (Nuolatinis nukreipimas) atsakymą, nusiųsdama vartotoją į lokalizuotą svetainės versiją, pavyzdžiui, `https://your-site.co.uk`.
   • Atsakymo Modifikavimas: Funkcija gali gauti originalų turinį iš pagrindinio serverio, bet tada jį modifikuoti realiu laiku, įterpdama lokalizuotą turinį, kainas ar kalbos eilutes prieš siųsdama jį vartotojui.
   • Užklausos Blokavimas: Jei vartotojas yra iš apriboto regiono, funkcija gali grąžinti 403 (Uždrausta) atsakymą, visiškai užkirsdama kelią prieigai.
   • Pateikimas iš Talpyklos: Jei lokalizuota puslapio versija jau yra edge talpykloje, ji gali būti pateikta tiesiogiai, suteikiant greičiausią įmanomą atsakymą.

Visas šis procesas vyksta skaidriai vartotojui ir per sekundės dalį, sukuriant sklandžią ir optimizuotą patirtį.

Praktiniai Panaudojimo Atvejai ir Tarptautiniai Pavyzdžiai

Tikroji geografinio maršrutizavimo galia atsiskleidžia realaus pasaulio pritaikymuose. Panagrinėkime keletą labiausiai paplitusių ir paveikiausių panaudojimo atvejų pasauliniams verslams.

1 Atvejo Analizė: Elektroninės Komercijos Lokalizacija

Iššūkis: Pasaulinis internetinės prekybos mažmenininkas nori suteikti lokalizuotą apsipirkimo patirtį. Tai apima kainų rodymą vietine valiuta, atitinkamų produktų rodymą ir teisingos kalbos naudojimą.

Edge Sprendimas:

1. Edge funkcija patikrina gaunamos užklausos `geo.country` savybę.
2. Jei šalis yra 'JP' (Japonija), ji nukreipia vartotoją iš `mystore.com` į `mystore.com/jp`.
3. `/jp` puslapis yra sugeneruojamas serveryje su kainomis JPY (¥) ir turiniu japonų kalba.
4. Jei šalis yra 'DE' (Vokietija), funkcija perrašo užklausą į puslapio versiją, kuri gauna produktų duomenis iš Europos inventoriaus duomenų bazės ir rodo kainas EUR (€). Tai įvyksta be matomo URL pasikeitimo, užtikrinant sklandžią patirtį.

Rezultatas: Didesni konversijų rodikliai, padidėjęs vartotojų pasitikėjimas ir profesionalesnis pasaulinis įvaizdis.

2 Atvejo Analizė: Duomenų Suverenitetas ir BDAR Atitiktis

Iššūkis: SaaS įmonė teikia paslaugas visame pasaulyje, bet turi laikytis ES Bendrojo duomenų apsaugos reglamento (BDAR), kuris turi griežtas taisykles dėl to, kur saugomi ir tvarkomi ES piliečių duomenys.

Edge Sprendimas:

1. Edge funkcija patikrina kiekvienos API užklausos `geo.country`.
2. Yra palaikomas ES šalių sąrašas: `['FR', 'DE', 'ES', 'IE', ...]`.
3. Jei vartotojo šalis yra ES sąraše, funkcija viduje perrašo užklausos URL iš `api.mysaas.com` į `api.eu.mysaas.com`.
4. `api.eu.mysaas.com` galinis taškas (endpoint) yra talpinamas serveriuose, fiziškai esančiuose Europos Sąjungoje (pvz., Frankfurte ar Dubline).
5. Užklausos iš visų kitų regionų (pvz., 'US', 'CA', 'AU') yra nukreipiamos į bendrosios paskirties backend'ą, talpinamą JAV.

Rezultatas: Įmonė pasiekia teisinę atitiktį, išvengia didelių baudų ir kuria pasitikėjimą su savo Europos klientais, demonstruodama įsipareigojimą duomenų privatumui.

3 Atvejo Analizė: Našumo Optimizavimas Internetiniams Žaidimams

Iššūkis: Daugelio žaidėjų internetinio žaidimo kūrėjas turi prijungti žaidėjus prie žaidimo serverio su kuo mažesne delsa (ping), kad užtikrintų sąžiningą ir jautrų žaidimo procesą.

Edge Sprendimas:

1. Kai žaidimo klientas paleidžiamas, jis siunčia „piršlybų“ (matchmaking) užklausą į pasaulinį API galinį tašką.
2. Edge funkcija perima šią užklausą. Ji identifikuoja vartotojo vietą (`geo.country` ir `geo.region`).
3. Funkcija palaiko geografinių regionų atitikmenų artimiausių žaidimų serverių IP adresams žemėlapį: `{'us-east': '1.2.3.4', 'eu-west': '5.6.7.8', 'ap-southeast': '9.10.11.12'}`.
4. Funkcija atsako į API užklausą su optimalaus žaidimo serverio IP adresu.
5. Žaidimo klientas tada jungiasi tiesiogiai prie to serverio.

Rezultatas: Žymiai pagerėjusi žaidėjų patirtis su mažesniu vėlavimu, lemianti didesnį žaidėjų išlaikymą ir pasitenkinimą.

4 Atvejo Analizė: Etapiniai Įdiegimai ir A/B Testavimas

Iššūkis: Technologijų įmonė nori išleisti svarbią naują funkciją, bet prieš pasaulinį išleidimą nori ją išbandyti su mažesne auditorija, kad sumažintų riziką.

Edge Sprendimas:

1. Nauja funkcija įdiegiama už funkcijos vėliavėlės (feature flag).
2. Edge funkcija tikrina ir slapuką (norėdama pamatyti, ar vartotojas sutiko dalyvauti), IR vartotojo vietą.
3. Logika nustatyta taip, kad funkcija būtų įjungta visiems vartotojams konkrečioje, mažesnės rizikos rinkoje, pavyzdžiui, Naujojoje Zelandijoje ('NZ'). `if (geo.country === 'NZ') { enableFeature(); }`
4. Vartotojams už Naujosios Zelandijos ribų pateikiama senoji svetainės versija.
5. Didėjant pasitikėjimui funkcija, į leidžiamų šalių sąrašą edge funkcijoje pridedama daugiau šalių, leidžiant kontroliuojamą, laipsnišką įdiegimą.

Rezultatas: Sumažinta pasaulinių sutrikimų rizika dėl klaidingos funkcijos, vertingas grįžtamasis ryšys iš realaus vartotojų segmento ir sklandesnis pasaulinis paleidimas.

Įgyvendinimo Vadovas: Kodo Lygmens Pavyzdys

Teorija yra puiku, bet pažiūrėkime, kaip tai atrodo praktikoje. Naudosime Next.js Middleware sintaksę, kuri veikia Vercel Edge Functions, nes tai yra labai populiarus įgyvendinimas. Koncepcijos lengvai perkeliamos į kitus tiekėjus, tokius kaip Cloudflare Workers ar Netlify Edge Functions.

Scenarijus: Norime sukurti maršrutizavimo sistemą, kuri:

1. Nukreipia Kanados vartotojus (`/`) į specialią Kanados svetainės versiją (`/ca`).
2. Tyliai nukreipia visus vartotojus iš Vokietijos ir Prancūzijos į europietišką backend'ą API iškvietimams į `/api/*`.
3. Blokuoja prieigą vartotojams iš hipotetinės šalies su kodu 'XX'.

Savo Next.js projekte sukurtumėte failą pavadinimu `middleware.ts` pagrindiniame kataloge (arba `src/` viduje).

// src/middleware.ts
import { NextRequest, NextResponse } from 'next/server';

// Šis sąrašas galėtų būti valdomas atskirame konfigūracijos faile arba edge duomenų bazėje
const EU_COUNTRIES = ['DE', 'FR'];

export const config = {
  // „matcher“ nurodo, kuriuose keliuose ši tarpinė programinė įranga (middleware) veiks.
  matcher: ['/', '/about', '/api/:path*'],
};

export function middleware(request: NextRequest) {
  // 1. Išgauname geografinius duomenis iš užklausos.
  // `geo` objektą automatiškai užpildo Vercel Edge Network.
  const { geo } = request;
  const country = geo?.country || 'US'; // Jei vieta nežinoma, numatytoji reikšmė yra 'US'
  const pathname = request.nextUrl.pathname;

  // 2. LOGIKA: Blokuoti prieigą iš konkrečios šalies
  if (country === 'XX') {
    // Grąžiname 403 Forbidden atsakymą.
    return new NextResponse(null, { status: 403, statusText: "Forbidden" });
  }

  // 3. LOGIKA: Nukreipti Kanados vartotojus į /ca sub-kelią
  // Patikriname, ar jau nesame /ca kelyje, kad išvengtume nukreipimo ciklo.
  if (country === 'CA' && !pathname.startsWith('/ca')) {
    const url = request.nextUrl.clone();
    url.pathname = `/ca${pathname}`;
    // Grąžiname 307 Laikinojo nukreipimo atsakymą.
    return NextResponse.redirect(url);
  }

  // 4. LOGIKA: Perrašyti API užklausas ES vartotojams į regioninį backend'ą
  if (pathname.startsWith('/api') && EU_COUNTRIES.includes(country)) {
    const url = new URL(request.url);
    // Pakeičiame pagrindinio kompiuterio vardą (hostname), kad jis rodytų į ES skirtą pradinį serverį.
    url.hostname = 'api.eu.your-service.com';
    console.log(`Perrašoma API užklausa vartotojui iš ${country} į ${url.hostname}`);
    // Grąžiname perrašymą. Vartotojo naršyklės URL lieka nepakitęs.
    return NextResponse.rewrite(url);
  }

  // 5. Jei neatitinka jokia taisyklė, leidžiame užklausai tęsti į puslapį ar API maršrutą.
  return NextResponse.next();
}

Kodo Analizė:

• `config.matcher`: Tai esminis optimizavimas. Jis nurodo edge tinklui kviesti šią funkciją tik konkretiems keliams, taip taupant vykdymo išlaidas resursams, tokiems kaip paveikslėliai ar CSS failai.
• `request.geo`: Šis objektas yra platformos pateiktų vietos duomenų šaltinis. Gauname `country` kodą ir nustatome protingą numatytąją reikšmę.
• Blokavimo Logika: Tiesiog grąžiname `NextResponse` su `403` būsena, kad užblokuotume užklausą tiesiog edge tinkle. Pagrindinis serveris niekada nepasiekiamas.
• Nukreipimo Logika: Naudojame `NextResponse.redirect()`. Tai siunčia 307 atsakymą atgal į naršyklę, nurodydama jai prašyti naujo URL (`/ca`). Tai matoma vartotojui.
• Perrašymo Logika: Naudojame `NextResponse.rewrite()`. Tai galingiausias veiksmas. Jis nurodo edge tinklui gauti turinį iš kito URL (`api.eu.your-service.com`), bet pateikti jį po originaliu URL (`/api/...`). Tai visiškai skaidru galutiniam vartotojui.

Iššūkiai ir Svarstymai

Nors geografinis maršrutizavimas edge tinkle yra galingas, jo įgyvendinimas nėra be sudėtingumų. Štai keletas svarbių veiksnių, į kuriuos reikia atsižvelgti:

1. GeoIP Duomenų Bazių Tikslumas

Vietos duomenys gaunami iš vartotojo IP adreso, susiejant jį su GeoIP duomenų baze. Šios duomenų bazės yra labai tikslios, bet ne neklystančios. Vartotojai, naudojantys VPN, mobiliuosius tinklus ar tam tikrus įmonių tinklus, gali būti neteisingai identifikuoti. Todėl visada turėtumėte suteikti vartotojams galimybę rankiniu būdu pakeisti nustatytą vietą (pvz., šalies pasirinkimo meniu svetainės poraštėje).

2. Talpyklos (Caching) Sudėtingumas

Jei tam pačiam URL pateikiate skirtingą turinį skirtingiems regionams, kyla rizika, kad vienos šalies vartotojas pamatys kitai šaliai skirtą talpykloje esantį turinį. Norėdami to išvengti, turite nurodyti CDN saugoti skirtingas puslapio versijas. Paprastai tai daroma siunčiant `Vary` antraštę atsakyme. Pavyzdžiui, `Vary: x-vercel-ip-country` nurodo CDN sukurti atskirą talpyklos įrašą kiekvienai šaliai.

3. Testavimas ir Derinimas

Kaip patikrinti, ar jūsų Vokietijai skirta maršrutizavimo logika veikia teisingai, nenuskridus į Vokietiją? Tai gali būti iššūkis. Metodai apima:

• VPN: VPN naudojimas, norint nukreipti savo srautą per serverį tikslinėje šalyje, yra įprastas metodas.
• Platformos Emuliacija: Kai kurios platformos, pavyzdžiui, Vercel, leidžia lokaliai pakeisti `request.geo` duomenis kūrimo metu testavimo tikslais.
• Naršyklės Kūrėjo Įrankiai: Kai kurie naršyklės kūrėjo įrankiai turi vietos klastojimo funkcijas, nors tai ne visada gali paveikti IP pagrįstą aptikimą edge tinkle.

4. Konkretaus Tiekėjo Įgyvendinimai

Pagrindinė edge maršrutizavimo koncepcija yra universali, tačiau įgyvendinimo detalės skiriasi tarp tiekėjų. Vercel naudoja `request.geo`, Cloudflare naudoja `request.cf` objekto savybes ir t. t. Nors logikos perkėlimas yra įmanomas, atminkite, kad tai nėra paprastas kopijavimo ir įklijavimo veiksmas, ir egzistuoja tam tikras priklausomumas nuo tiekėjo.

Edge Ateitis yra Geografinė

Geografinis maršrutizavimas su edge funkcijomis yra daugiau nei tik protinga technika; tai fundamentalus pokytis, kaip kuriame pasaulines programas. Kadangi edge platformos tampa vis galingesnės, galime tikėtis dar sudėtingesnių galimybių:

• Edge Duomenų Bazės: Su produktais, tokiais kaip Cloudflare D1 ir Vercel KV, patys duomenys gali gyventi edge tinkle. Tai leidžia nukreipti vartotojo užklausą į artimiausią edge funkciją, kuri tada gali skaityti ir rašyti duomenis iš duomenų bazės toje pačioje fizinėje vietoje, pasiekiant vienženklį milisekundžių duomenų bazės užklausų laiką.
• Gilesnės Integracijos: Tikėkitės dar glaudesnio ryšio tarp frontend karkasų ir edge galimybių, abstrahuojant dar daugiau sudėtingumo ir paverčiant „global-first“ kūrimą numatytuoju.
• Patobulintas Personalizavimas: Be šalies, maršrutizavimo sprendimai bus priimami remiantis daugiau veiksnių, prieinamų edge tinkle, tokių kaip įrenginio tipas, ryšio greitis ir net dienos laikas, siekiant pateikti hiper-personalizuotas patirtis.

Išvada: Kurkite Pasauliui, iš Edge Tinklo

Frontend edge funkcijų geografinis maršrutizavimas suteikia programuotojams galių spręsti sudėtingiausius iššūkius, kylančius kuriant programas pasaulinei auditorijai. Perkeldami vietove pagrįstą logiką iš centralizuotų serverių į paskirstytą tinklo pakraštį, galime kurti programas, kurios yra ne tik greitesnės, bet ir labiau atitinkančios reikalavimus, atsparesnės ir giliai personalizuotos.

Gebėjimas perrašyti, nukreipti ir modifikuoti užklausas remiantis vartotojo vieta, visa tai su minimalia delsa, atveria naują vartotojo patirties lygį. Nuo duomenų suvereniteto gerbimo su išmaniuoju duomenų maršrutizavimu iki vartotojų džiuginimo lokalizuotu turiniu – galimybės yra didžiulės. Projektuodami savo kitą programą, negalvokite tik apie tai, kur talpinti savo serverį; pagalvokite, kaip galite išnaudoti pasaulinį tinklo pakraštį, kad pasitiktumėte savo vartotojus ten, kur jie yra.