Å bygge vår nettsides robotsøkemotor: en titt inn i Weglot teknologi

Mange Weglot Brukere liker å sørge for at alle URL-ene til nettstedet deres er nøyaktig oversatt ( etter det første laget med maskinoversettelse levert av Weglot ). For mange, hvis du eier et stort nettsted, oversatt til mange språk, kan det være tidkrevende.

Vi har også fått tilbakemeldinger fra brukerne våre om at noen av dem var litt forvirret når de startet sitt første oversettelsesprosjekt. De lurte ofte på hvorfor de bare kunne se URL-en til hjemmesiden i oversettelseslisten og ikke alle de andre sidene, eller hvordan de skulle generere oversettelsene av innholdet.

Så vi visste at det var rom for forbedringer på dette området. Vi kunne hjelpe brukerne våre med å komme lettere om bord og administrere prosjektene deres raskere og mer effektivt, men vi hadde bare ikke noen løsning ennå.

Som du kanskje allerede har gjettet ... førte dette til lanseringen av funksjonen Administrer URL-er, som lar brukeren skanne URL-ene til nettstedet sitt og generere oversatt innhold fra den. Weglot Dashbord, raskt og effektivt.

Denne funksjonen har nylig blitt flyttet fra oversettelseslisten til den nye siden for håndtering av oversettelser etter URL-adresse, der den har blitt enda mer fleksibel og kraftfull, så vi tenkte det var på høy tid å fortelle deg hvordan denne funksjonen ble realisert.

Golang til unnsetning

I begynnelsen av 2020 ga nedstengningen på grunn av pandemien meg endelig muligheten til å ta fatt på å lære meg programmeringsspråket Golang, som jeg måtte utsette på grunn av mangel på tid.

Golang (eller Go) er et språk laget av Google som har fått mye oppmerksomhet de siste årene.

Det er et statisk kompilert programmeringsspråk som er utviklet for å hjelpe utviklere med å skrive rask, robust og samtidig kode. Enkelheten gjør det mulig å skrive og vedlikeholde store og komplekse programmer uten at det går på bekostning av ytelsen: Golang kan ses på som Pythons og C's uventede barn: (ganske) enkelt å skrive og raskt å utføre.

Etter min mening er den beste måten å lære et nytt programmeringsspråk (eller et nytt rammeverk eller hva det måtte være) på å finne et godt prosjekt der du kan bruke det du lærer i praksis. Det er ikke den enkleste oppgaven: Hvis utviklere leser dette, vet de hvor vanskelig det kan være. 

Et godt sideprosjekt må oppfylle noen spesifikasjoner:

• Omfanget må være stort nok til at utvikleren kan lære nok av teknologien han lærer mens han bygger programmet: Å skrive ut "Hello world" i konsollen er sjelden nok til å få en forståelse av et nytt språk.
• Omfanget må ikke være så stort at utvikleren sannsynligvis vil gi opp før prosjektet er fullført (vi har alle vært der).
• Sist, men ikke minst, det må være morsomt å gjøre! Å programmere en huskeliste for 200. gang kommer ikke til å være særlig underholdende, og sjansen er stor for at du gir opp så snart du har tenkt ut hvordan du skal få det til å fungere. 
• Bonuspoeng: sideprosjektet bør ideelt sett løse et problem fra den virkelige verden, noe som bidrar til å holde fokus på oppgaven.

Så hvorfor nevner jeg dette? Da jeg tenkte på hva som kunne være et flott sideprosjekt for å begynne å lære Golang, slo det meg at en webcrawler kunne passe perfekt til beskrivelsen ovenfor og også kunne løse noen av problemene vi ønsket å fikse. Weglot brukere.

En webcrawler (ofte kalt "bot") er i sin enkleste form et program som er laget for å besøke et nettsted og hente ut informasjon.

Et typisk bruksområde for en webcrawler kan være å oppdage og besøke hver eneste side på et nettsted og deretter generere et nettstedskart. Eller å indeksere innholdet, som for eksempel Googles roboter.

I vårt tilfelle trengte vi noe brukerne våre kunne bruke til å skanne nettstedet sitt og importere tilbake alle nettadressene på nettstedet. 

Vi lette også etter en ny måte å generere oversettelser på. Merknad for de som ikke er kjent med Weglot …«generering av oversettelser» betyr at nettadressene dine (og innholdet i dem) vises i Weglot oversettelseslisten, slik at du kan gjøre manuelle redigeringer i oversettelsene.

Da måtte brukerne besøke nettstedet deres på et oversatt språk for å generere dem. Det fungerer veldig bra når nettstedet ditt bare har noen få sider og du ikke har mange oversatte språk, men det kan fort bli en overveldende oppgave hvis du eier et veldig stort nettsted med tusenvis av sider.

Ideen om å bruke en webcrawler til å automatisere denne oppgaven begynte raskt å se ut som en ideell løsning, og det ville være et perfekt bruksområde for Golangs samtidige programmeringsfunksjoner!

Så i januar 2020 begynte jeg å prototype en webcrawler mens jeg lærte det grunnleggende om Golang, og snart hadde jeg noe jeg kunne vise til Rémy, Weglot s tekniske direktør. 

Det var ikke mye, et enkelt program som tok en URL som input og begynte å gjennomsøke nettstedet og besøke alle lenker med samme domene som det fant, men det var raskt og effektivt.

Etter en rask demonstrasjon var Rémy begeistret for løsningen, og han var villig til å bruke den tiden som trengtes til forskning og utvikling for å ferdigstille POC (proof of concept) og deretter tenke på hvordan vi kunne legge løsningen til rette for fremtidig produksjonsbruk.

Som programvareingeniør føles det veldig bra når du jobber med noe på egen hånd og deretter får innvilget tid til å utvikle produktet ditt fullt ut. Det er en fantastisk følelse av anerkjennelse, og det motiverte meg hele veien til vi hadde et produksjonsklart produkt (noe som fortsatt var en lang vei å gå).

Problemet med hosting

Ved siden av å ferdigstille boten, som fortsatt trengte en funksjon for å generere innhold og litt ekstra arbeid for å ta hensyn til forskjeller mellom ulike CMS og integrasjoner, begynte jeg å tenke på hvordan vi kunne hoste og eksponere boten for brukerne våre.

Min første tanke var å bruke den klassiske og velprøvde løsningen: å spinne en databehandlingsinstans på AWS og eksponere boten bak en webserver. Det virket som en god idé, men jo mer jeg tenkte på det, desto mer bekymret ble jeg for flere problemer.

For det første hadde jeg ingen anelse om hvor mye serveren måtte belastes, og hvor mange brukere som ville bruke funksjonen samtidig. Hva om den tildelte kapasiteten er nok, men du plutselig har mange brukere som gjennomsøker forskjellige veldig store nettsteder samtidig?

Siden jeg ikke hadde noen tidligere erfaring med å hoste et Go-program, var det vanskelig å avgjøre hvilke ressurser (CPU, RAM ...) som ville være nok til å gi en god brukeropplevelse.

I tillegg følte jeg at den klassiske "alltid oppe"-webserveren ikke var den mest effektive løsningen. Folk ville ikke gjennomsøke nettstedet deres hele tiden: Når du først har importert nettadressene dine og generert innholdet ditt, er det ikke meningen at du skal bruke boten daglig, selv om du ofte publiserer nytt/oppdatert innhold.

Da jeg tenkte på det, begynte det å se ut som et perfekt bruksområde for serverløs hosting.

For de som gikk glipp av den serverløse trenden for noen år siden, vil jeg raskt oppsummere hvordan den fungerer:

• Til tross for navnet serverless kjører koden fortsatt på en server
• I motsetning til en server, som alltid kjører og lytter etter tilkoblinger, kjører serverløs kode på forespørsel. Når serverløs kode utløses, vil skyleverandøren klargjøre og tildele noen ressurser slik at koden kan kjøre.

Denne hostingmodellen har umiddelbart to hovedfordeler:

• Utviklerne trenger ikke å administrere infrastrukturen, alt dette gjøres av leverandøren. Det betyr at du ikke trenger å bekymre deg for serversikkerhet eller konfigurasjon.
• Og viktigst av alt: Den er skalerbar! 

Husker du da jeg sa at det var vanskelig å forutse hvilke ressurser en server ville trenge for å kjøre boten? Vel, du trenger ikke å bry deg med dette nå, for hver forespørsel opprettes en ny statsløs isolert container for å kjøre koden din inni den, det er ingen risiko for å overskride serverens kapasitet, hver forespørsel får sin egen container å kjøre i.

Så alt er til det beste i den beste av alle mulige verdener? Ja, nesten!

I 2020 var serverless computing begrenset til 5 minutter (i hvert fall for AWS, jeg har ingen erfaring med serverless hosting på Google Cloud Platform eller Microsoft Azure). Det gir god mening, ettersom denne hostingmodellen ble utviklet for korte oppgaver som å generere en pdf-fil eller beskjære bilder, for eksempel. 

I vårt tilfelle var imidlertid varigheten på 5 minutter et vanskelig problem. Selv om det er mer enn nok til å gjennomsøke et lite nettsted med rask respons, ville det helt sikkert nådd grensen før oppgaven var fullført for store netthandelsnettsteder som lett kan ha titusenvis av sider og noen ganger er litt trege til å svare.

Jeg var i ferd med å gi opp serverless da AWS kom med en kunngjøring tidlig i 2020 - de ville øke grensen på 5 minutter til 15 minutter! 

Dessverre, som det ofte er tilfelle med AWS, gir de ikke mye innsikt i nye funksjoner når de kunngjør dem, tidsfristen ble forlenget, men det var ingen forklaringer på hvordan du får den.

Jeg skal spare deg for de mange prøving og feilingene og undersøkelsene jeg gjorde for å finne ut hvordan jeg kunne utvide grensen til 15 minutter, men la meg forsikre deg om at det ikke var lett 🙂 🙂 .

Grensen på 5 minutter var faktisk en grense som ble håndhevet på infrastrukturnivå, AWS vil ikke opprettholde en HTTP-forbindelse mer enn 5 minutter mellom de forskjellige tjenestene, løsningen var ganske enkelt å ikke utløse den serverløse koden med et HTTP-anrop, det er mange andre måter, i vårt tilfelle satte vi opp for en utløsning med SQS: AWS meldingskø-tjenesten.

Formidling av resultatene

Da hostingproblemet var løst, var det én oppgave igjen før vi kunne avslutte for i dag. 

Så langt hadde vi en fungerende bot, hostet på en skalerbar og kostnadseffektiv måte, og det siste vi trengte var å sende dataene som ble produsert av boten, tilbake til brukerne.

Siden jeg ønsket at funksjonen skulle være så interaktiv som mulig, valgte jeg sanntidskommunikasjon mellom boten og Weglot dashbord.

Sanntid er ikke obligatorisk for denne typen funksjoner, man kan alltids nøye seg med en enklere løsning som lang polling, men jeg ville være sikker på at brukerne våre ville få tilbakemelding så snart crawleren hadde startet jobben sin, og la oss være ærlige, det var også en måte å la boten skinne og vise potensialet sitt på 🙂 .

Siden vi ikke hadde noe som kunne håndtere sanntidskommunikasjon på den tiden (vi hadde ikke bruk for det), bestemte vi oss for å gå for en velprøvd løsning. Vi skrev en enkel websocket-server i nodejs og hostet den på en EC2 AWS-forekomst.

Etter litt arbeid med boten for å implementere kommunikasjonen med websocket-serveren og automatisere distribusjonen, var vi endelig klare til å gå videre til testing før vi satte den i produksjon.

Det som startet som et sideprosjekt, ble etter hvert en del av dashbordet. 

Jeg hadde det veldig gøy da jeg skrev crawleren og løste de mange problemene jeg støtte på. Til slutt lærte jeg også mye: et nytt programmeringsspråk og nye ferdigheter i AWS-økosystemet.

Go er definitivt et språk jeg kommer til å bruke igjen, det er virkelig godt egnet for nettverksoppgaver og kooperativ programmering. Det er også et veldig godt språk å kombinere med serverless computing på grunn av det lave minneavtrykket sammenlignet med språk som Js, PHP eller Python.

Boten har åpnet nye perspektiver for oss, og vi har noen planer for fremtiden. Vi planlegger å skrive om ordtellingsverktøyet vårt for å gjøre det mer effektivt og ytelsessterkt, og vi kan også bruke det til å varme opp hurtigbufferen (fylle den med data).

Jeg håper du likte dette innblikket Weglot Selv om jeg likte å skrive denne artikkelen, er det bare å prøve boten selv!