Bouwen voor iedereen: app opnieuw bouwen met React Native
Door DeHub Team — 2021-07-02
In het derde kwartaal van 2021 zijn we begonnen met het opnieuw opbouwen van de DeHub-app vanuit het niets in React Native.
Beslissen om een werkende applicatie te herschrijven is geen beslissing die iemand leuk vindt. De bèta was live, er waren gebruikers en elke week die aan de herbouw werd besteed, werd een week niet besteed aan functies waar die gebruikers om vroegen. We hebben het toch gedaan en het is een van de weinige grote gesprekken uit die periode die we nooit meer hebben bezocht.
Wat er mis was met de eerste app
De bèta is gebouwd om een vraag te beantwoorden — zullen mensen dit überhaupt gebruiken — en het heeft het beantwoord. Wat het niet kon, was groeien. Verzending naar twee platforms betekende het onderhouden van twee codebases, wat in de praktijk betekende dat één platform stilletjes achterop raakte en elke functie ongeveer het dubbele kostte van wat het zou moeten kosten.
Voor een team van onze omvang is dat geen technisch ongemak. Het is een limiet voor hoe snel het product ooit kan bewegen.
Waarom React Native
De eerlijke reden is de invloed van het team. React Native liet een kleine groep vanuit één codebase naar iOS en Android verzenden zonder twee keer volledig native te gaan, en zonder de compromissen van een ingepakte webweergave — wat voor een app gebouwd rond video en live content fataal zou zijn geweest.
Het betekende ook dat de mobiele app en de web-app een mentaal model, een componentwoordenschat en in veel gevallen echte logica konden delen. Vier jaar later draait DeHub een React-webapp en een React Native mobiele app die parallel worden onderhouden, en beschikt over een kruising tussen hen in een tempo dat niet mogelijk zou zijn geweest als het antwoord in 2021 twee native herschrijvingen was geweest.
De delen die moeilijker waren dan verwacht
Niemand mag dit lezen als een wrijvingsloze keuze:
- Video is waar de abstractie lekt. Afspelen, achtergrondaudio en livestreaming zijn precies de gebieden waar je in native modules terechtkomt, ongeacht de beloften van het framework.
- Wallet-integratie was de lopende belasting. Mobiele portemonnee-verbinding is vaker opnieuw opgelost dan enig ander deel van de app en blijft de meest voorkomende plek waar nieuwe gebruikers stallen.
- Herschrijven duurt altijd langer. De lijst met dingen die de oude app deed die niemand had geschreven dons wordt alleen ontdekt door ze te verwijderen.
Waarom het nog steeds juist was
De herbouw is de reden dat de app alles heeft overleefd wat daarna kwam. Toen de arcade gelanceerd in Q1 2022, toen de stream app arriveerde die zomer, toen het hele ecosysteem in 2023 in een enkele d'app werd getrokken — geen van deze was een geval van bolting op de beta. Ze landden op een fundering die opzettelijk was gebouwd om gewicht te dragen.
De les die we eruit hebben getrokken is niet "vroeg herschrijven". Het is dat op het moment dat je het specifieke plafond kunt noemen dat je architectuur op het team legt, je al betaalt voor het herschrijven, of je er nu mee bent begonnen of niet.
Hoe je één overleeft
Twee dingen zorgden ervoor dat deze herschrijfafwerking in plaats van kraam eindigde, en beide zijn de moeite waard om te vermelden, omdat de meeste herschrijvingen wel kraam zijn.
De oude app bleef draaien. We stopten niet met het leveren aan bestaande gebruikers terwijl de vervanging werd gebouwd. Dat verlengt de tijdlijn en het verwijdert de druk die een gehaast overschakelen veroorzaakt, waar herschrijvingen meestal sterven.
De scope was de architectuur, niet het product. Elk verzoek om ook een functie te verbeteren tijdens het opnieuw opbouwen, is afgewezen. Een herschrijving die tegelijkertijd een herontwerp is, heeft twee manieren om te falen en geen manier om te vertellen welke er gebeurt. Het interfacewerk wachtte tot 2024, toen het goed werd verzonden als een volledige revisie naast een 200% backend verbetering.