Bygga vår webbplats sökrobot: en titt in i Weglotteknik

Många Weglot vill se till att alla webbadresser på deras webbplats är korrekt översatta(efter det första lagret av maskinöversättning som ges av Weglot). För många, om du äger en stor webbplats, översatt till många språk, kan det vara tidskrävande.

Vi märkte också genom feedback från våra användare att en del av dem var lite förvirrade när de startade sitt första översättningsprojekt för webbplatser. De undrade ofta varför de bara kunde se hemsidans URL i översättningslistan och inte alla andra sidor, eller hur de skulle generera översättningar av sitt innehåll.

Så vi visste att det fanns utrymme för förbättringar på det här området. Vi kunde hjälpa våra användare att lättare komma ombord och hantera sina projekt snabbare och mer effektivt, men det var bara det att vi inte hade någon lösning ännu.

Som du kanske redan har gissat ... ledde detta till lanseringen av funktionen Hantera webbadresser, så att användaren kan skanna webbadresserna på sin webbplats och generera sitt översatta innehåll från Weglot Dashboard, snabbt och effektivt.

Den här funktionen har nyligen flyttats från översättningslistan till den nya sidan för översättningshantering per URL, där den har gjorts ännu mer flexibel och kraftfull. Vi tyckte därför att det var hög tid att berätta hur den här funktionen har tagits fram.

Golang till undsättning

I början av 2020 gav nedstängningen på grund av pandemin mig äntligen möjlighet att ta itu med att lära mig programmeringsspråket Golang som jag var tvungen att skjuta upp på grund av tidsbrist.

Golang (eller Go förkortat) är ett språk som tillverkas av Google och som har fått mycket dragkraft de senaste åren.

Det är ett statiskt kompilerat programmeringsspråk som är utformat för att hjälpa utvecklare att skriva snabb, robust och samtidig kod. Dess enkelhet gör det möjligt att skriva och underhålla stora och komplexa program utan att offra prestanda: Golang kan ses som Pythons och C:s oväntade barn: (ganska) enkelt att skriva och snabbt att utföra.

Enligt min mening är det bästa sättet att lära sig ett nytt programmeringsspråk (eller ett nytt ramverk eller vad det nu kan vara) att hitta ett bra projekt där man kan omsätta det man lärt sig i praktiken. Det är inte den lättaste uppgiften: om utvecklare läser det här vet de hur svårt det kan vara. 

Ett bra sidoprojekt måste uppfylla vissa specifikationer:

• Omfattningen måste vara tillräckligt stor så att utvecklaren kan lära sig tillräckligt mycket av den teknik han lär sig medan han bygger programmet: att skriva ut "Hello world" i konsolen är sällan tillräckligt för att få grepp om ett nytt språk.
• Omfattningen får inte vara så stor att utvecklaren förmodligen kommer att ge upp innan projektet är slutfört (vi har alla varit där).
• Sist men inte minst måste det vara roligt att göra! Att programmera en att-göra-lista för 200:e gången kommer inte att vara särskilt underhållande, och risken är stor att du ger upp så fort du funderar på hur du ska få det att fungera. 
• Bonuspoäng: sidoprojektet ska helst lösa ett verkligt problem, vilket hjälper till att hålla fokus på uppgiften.

Så varför nämner jag detta? När jag tänkte på vad som skulle kunna vara ett bra sidoprojekt för att börja lära mig Golang, slog det mig att en webbsökare perfekt kunde passa ovanstående beskrivning och också kunde lösa några av de problem vi letade efter att fixa för Weglot .

Låt oss tänka på det: en web crawler (ofta kallad "bot") är i sin enklaste form ett program som är skapat för att besöka en webbplats och hämta information.

Ett typiskt användningsfall för en web crawler kan vara att upptäcka och besöka varje sida på en webbplats och sedan generera en webbplatskarta. Eller indexera dess innehåll, som Googles robotar till exempel.

I vårt fall behövde vi något som våra användare kunde använda för att skanna sin webbplats och importera tillbaka alla webbadresser på sin webbplats. 

Vi letade också efter ett nytt sätt att generera översättningar. Sidonot för dem som inte känner till Weglot... "generera översättningar" betyder att dina webbadresser (och innehållet i dem) visas i din Weglot , så att du kan göra manuella redigeringar av översättningarna.

Då var användarna tvungna att besöka deras webbplats på ett översatt språk för att generera dem. Det fungerar riktigt bra när din webbplats bara har ett fåtal sidor och du inte har många översatta språk, men kan snabbt bli en överväldigande uppgift om du äger en mycket stor webbplats med tusentals sidor.

Idén att använda en web crawler för att automatisera denna uppgift började snabbt se ut som en idealisk lösning och det skulle vara ett perfekt användningsfall för Golangs samtidiga programmeringsfunktioner!

Så i januari 2020 började jag prototypa en webbsökare medan jag lärde mig grunderna i Golang och snart nog hade jag något jag kunde visa för Rémy, WeglotCTO. 

Det var inte mycket, ett enkelt program som tog en webbadress som indata och började genomsöka webbplatsen och besöka varje länk med samma domän som den hittade, men det var snabbt och effektivt.

Efter en snabb demonstration var Rémy entusiastisk över lösningen och att ta den tid som krävs för forskning och utveckling för att slutföra POC (proof of concept) och sedan fundera på hur vi skulle kunna vara värd för lösningen för framtida produktionsanvändning.

Som mjukvaruingenjör känns det väldigt bra när man arbetar med något på egen hand och sedan får tid att utveckla produkten fullt ut. Det är en fantastisk känsla av bekräftelse och det motiverade mig hela vägen tills vi hade en produktionsklar produkt(vilket fortfarande var enlång väg att gå).

Problemet med webbhotell

Förutom att färdigställa boten, som fortfarande behövde funktionen för att generera innehåll och en del ytterligare arbete för att ta hänsyn till skillnader mellan olika CMS och integrationer, började jag fundera på hur vi skulle kunna hosta och exponera boten för våra användare.

Min första tanke var att använda den klassiska och väl beprövade lösningen: att snurra en beräkningsinstans på AWS och exponera botten bakom en webbserver. Det verkade vara en bra idé, men ju mer jag tänkte på det, desto mer bekymrad blev jag över flera frågor.

För det första hade jag ingen aning om vilken kostnad servern skulle behöva ta och hur många användare som skulle använda funktionen samtidigt. Vad händer om den avsatta kapaciteten är tillräcklig men du plötsligt har många användare som genomsöker olika mycket stora webbplatser samtidigt?

Eftersom jag inte hade någon tidigare erfarenhet av att vara värd för ett Go-program var det svårt att avgöra vilka resurser (CPU, RAM ...) som skulle räcka för att ge en bra användarupplevelse.

Dessutom kände jag att den klassiska "alltid upp" webbservern inte var den mest effektiva lösningen. Folk skulle inte genomsöka deras webbplats hela tiden: när du väl har importerat dina webbadresser och genererat ditt innehåll är det inte meningen att du ska använda botten dagligen även om du ofta publicerar nytt/uppdaterat innehåll.

När jag tänkte på det började det se ut som ett perfekt användningsfall för serverlös hosting.

För dem som missade den serverlösa trenden för några år sedan ska jag snabbt sammanfatta hur det fungerar:

• Trots namnet serverless körs koden fortfarande på en server
• Till skillnad från en server, som alltid är igång och lyssnar efter anslutningar, körs serverlös kod på begäran. När serverlös kod triggas kommer molnleverantören att tillhandahålla och allokera vissa resurser för att koden ska kunna köras.

Denna värdmodell har omedelbart två huvudfördelar:

• Utvecklare behöver inte hantera infrastrukturen, allt sköts av leverantören. Det innebär att du inte behöver oroa dig för serversäkerhet eller konfiguration.
• Viktigast av allt är att det är skalbart genom design! 

Kommer du ihåg när jag sa att det var svårt att förutse vilka resurser en server skulle behöva för att köra botten? Tja, du behöver inte bry dig om detta nu, för varje begäran skapas en ny statslös isolerad behållare för att köra din kod inuti den, det finns ingen risk att överskrida serverns kapacitet, varje begäran får sin egen behållare att köra i.

Så allt är till det bästa i den bästa av alla möjliga världar? Ja, nästan!

Redan 2020 var serverlös databehandling begränsad till 5 minuter (åtminstone för AWS, jag har ingen erfarenhet av serverlös hosting på Google Cloud Platform eller Microsoft Azure). Det är helt logiskt eftersom den här hostingmodellen utformades för korta uppgifter som att generera en pdf eller beskära bilder till exempel. 

I vårt fall var dock 5-minutersperioden ett tufft problem. Även om det är mer än tillräckligt för att genomsöka en liten webbplats med snabb respons, skulle det med största säkerhet nå gränsen innan uppgiften slutfördes för stora e-handelswebbplatser som lätt kan ha tiotusentals sidor och ibland är lite långsamma att svara.

Jag var precis på väg att ge upp serverless när AWS gjorde ett tillkännagivande i början av 2020 - de skulle öka gränsen på 5 minuter till 15 minuter! 

Tyvärr, som det ofta är fallet med AWS, ger de inte mycket insikt om nya funktioner när de tillkännager dem, tidsfristen förlängdes men det fanns inga förklaringar om hur man får den.

Jag ska bespara dig de många försök och fel och forskning jag gjorde för att hitta hur man förlänger gränsen till 15 minuter men låt mig försäkra dig om att det inte var lätt 🙂 🙂

Gränsen på 5 minuter var faktiskt en gräns som verkställdes på infrastrukturnivå, AWS kommer inte att upprätthålla en HTTP-anslutning mer än 5 minuter mellan sina olika tjänster, lösningen var att helt enkelt inte utlösa den serverlösa koden med ett HTTP-anrop, det finns många andra sätt, i vårt fall ställde vi in för en utlösning med SQS: AWS Message Queuing Service.

Kommunicera resultaten

När hostingproblemet var löst fanns det en uppgift kvar att utföra innan vi kunde avsluta för dagen. 

Så långt hade vi en fungerande bot, hostad på ett skalbart och kostnadseffektivt sätt, och det sista vi behövde var att skicka tillbaka den data som boten producerade till användarna.

Eftersom jag ville att funktionen skulle vara så interaktiv som möjligt valde jag realtidskommunikation mellan botten och Weglot .

Realtid är inte obligatoriskt för den här typen av funktioner, du kan alltid nöja dig med en enklare lösning som lång polling, men jag ville se till att våra användare skulle få feedback så snart crawlern hade påbörjat sitt jobb, och låt oss vara ärliga, det var också ett sätt att låta boten skina och visa sin potential 🙂 .

Eftersom vi inte hade något för att hantera realtidskommunikation då (vi hade ingen användning för det) bestämde vi oss för att välja en beprövad lösning, vi skrev en enkel websocket-server i nodejs och hostade den på en EC2 AWS-instans.

Efter en del arbete med botten för att implementera kommunikationen med websocket-servern och automatisera distributionen var vi äntligen redo att testa innan vi gick över till produktion.

Det som började som ett sidoprojekt tog sig så småningom in i instrumentpanelen. 

Jag hade mycket roligt när jag skrev crawlern och löste de många problem jag stötte på. I slutändan lärde jag mig också en hel del: ett nytt programmeringsspråk och nya färdigheter i AWS-ekosystemet.

Go är definitivt ett språk som jag kommer att använda igen, det är verkligen bra för nätverksuppgifter och kooperativ programmering. Det är också ett mycket bra språk att para ihop med serverlös databehandling på grund av dess låga minnesavtryck jämfört med språk som Js, PHP eller Python.

Eftersom botten öppnade upp nya perspektiv för oss har vi några planer för framtiden. Vi planerar att skriva om vårt ordräkningsverktyg för att göra det mer effektivt och performant, vi skulle också kunna använda det för att värma upp cache (fylla på det med data).

Jag hoppas att du gillade den här inblicken i Weglotteknik lika mycket som jag gillade att skriva den här artikeln, känn dig fri att prova boten själv!