Preskočiť na obsah

Z Bubble na React a Supabase: návod na migráciu

Návod na migráciu z Bubble na React a Supabase

Prechod z Bubble na React a Supabase zahŕňa prestavbu aplikácie, presun dát a overenie, že nová verzia funguje podľa očakávaní. Tento návod pomôže posúdiť, či sa táto práca oplatí a ako ju naplánovať.

Pre koho je tento návod

Návod je určený pre:

  • zakladateľov, ktorým z MVP v Bubble vyrástol skutočný produkt
  • product ownerov, ktorí plánujú prestavbu
  • tímy, ktoré chcú mať väčšiu kontrolu nad architektúrou frontendu a backendu
  • agentúry alebo technických lídrov, ktorí pripravujú migráciu z Bubble

Ak je vaša aplikácia v Bubble stabilná, roadmapa je krátka a produkt je už „dosť dobrý“, migráciu možno vôbec nepotrebujete.

Kedy migrácia z Bubble dáva zmysel

Samotný tlak investorov alebo uprednostňovanie kódu nemusí byť dostatočný dôvod na prestavbu. Migráciu zvážte, keď platí viacero z týchto bodov:

1. Produkt plánujete rozvíjať ešte roky

Ak plánujete aplikáciu rozširovať ešte roky, na architektúre záleží viac. Už nejde len o to, ako rýchlo spustíte. Ide o ďalšie funkcie, integrácie, nových ľudí v tíme a požiadavky zákazníkov.

2. Logika aplikácie je čoraz zložitejšia

Bubble zvládne veľa, ale zložitosť niečo stojí. Možno už váš produkt má pokročilé oprávnenia, náročné workflowy, nezvyčajné interakcie v UI, veľa podmienených stavov alebo množstvo integrácií. Ak áno, námaha spojená s rozširovaním aplikácie v Bubble môže rásť rýchlejšie než samotný produkt.

3. Ťažká údržba sa stáva problémom pre biznis

Často je to skutočný dôvod migrácie. Každá zmena je riskantná, hľadanie chýb trvá priveľmi dlho, logika je roztrúsená po stránkach a workflowoch alebo je zaúčanie nových ľudí trápenie. Ak platí niečo z toho, problém už nie je len technický. Brzdí celú firmu.

4. Potrebujete väčšiu kontrolu nad backendom

Supabase vám dá PostgreSQL, SQL, row-level security, edge functions, úložisko súborov a prehľadnejší model backendu, než ponúka vstavaná databáza a workflow engine v Bubble. Ak je pre vás flexibilita backendu čoraz dôležitejšia, z pohodlia Bubble sa môže stať obmedzenie.

5. Máte tím, ktorému kód naozaj pomôže

React a Supabase nie sú automaticky lepšie než Bubble. Lepšie sú len vtedy, ak to tím, ktorý aplikáciu prestavia a bude ju udržiavať, naozaj ovláda. Musí vedieť prehľadne usporiadať frontendový kód, modelovať dáta, nastaviť pravidlá prístupu, testovať produkt a správne prevádzkovať celý stack.

Kedy s migráciou radšej ešte počkať

Niekedy je najrozumnejšie zostať na Bubble.

Zvyčajne to platí, keď:

  • aplikácia už dnes firme dobre slúži
  • na roadmape sú hlavne drobné vylepšenia
  • potrebujete už len pár funkcií
  • výkon vo vašej fáze stačí
  • prestavba by odsunula dôležitejšiu prácu
  • za migráciou je skôr nepohodlie než obchodný prínos

Ak softvér už robí to, čo potrebujete, prestavba môže odložiť užitočnejšiu prácu.

Prečo tímy často prechádzajú práve na React a Supabase

Po Bubble neexistuje jediný správny cieľový stack. React a Supabase sú však častá kombinácia, pretože pokrývajú dve hlavné časti, ktoré mal Bubble v jednom balíku:

  • vývoj frontendovej aplikácie
  • backend, databázu, autentifikáciu, úložisko a API

Prečo React

React je dobrá voľba, keď chcete:

  • plnú kontrolu nad UI a architektúrou komponentov
  • veľký ekosystém knižníc a vývojárskych nástrojov
  • jednoduchšiu spoluprácu s frontendovými vývojármi
  • predvídateľnú prácu so stavom a opakované použitie komponentov
  • lepšie možnosti pri testovaní, ladení výkonu a dizajn systémoch

Už nie ste viazaní na editor stránok a workflowy v Bubble. Môžete postaviť čistejšiu štruktúru komponentov a logiku UI, v ktorej sa ľahšie vyznáte.

Prečo Supabase

Supabase často nahrádza Bubble na strane backendu, pretože ponúka:

  • PostgreSQL namiesto proprietárnej databázovej vrstvy
  • SQL na reporty, joiny, obmedzenia (constraints) a čistenie dát
  • row-level security na riadenie prístupu
  • vstavanú autentifikáciu
  • úložisko pre nahrané súbory
  • logiku na strane servera cez edge functions a databázové funkcie
  • spravovanú platformu, ktorá má pritom oveľa bližšie ku klasickému vývoju softvéru

Dostanete väčšiu kontrolu a nemusíte stavať každú časť backendu od nuly.

Prečo táto dvojica spolu dobre funguje

Bubble spája UI, workflowy, autentifikáciu, databázu a nasadenie do jedného systému. Keď od neho tímy odchádzajú, často chcú stack, v ktorom sa dá stále stavať rýchlo, ale ktorý ich už nezamkne v jednom proprietárnom prostredí.

Kombinácia Reactu a Supabase býva rozumnou strednou cestou:

  • je flexibilnejšia ako Bubble
  • produktívni v nej budete rýchlejšie, než keby ste všetko stavali na holej infraštruktúre
  • ľahšie na ňu nájdete vývojárov ako na úzko špecializované no-code riešenie

Čo sa z Bubble nedá jednoducho preniesť

Bubble neexportuje zdrojový kód, ktorý by sa dal priamo previesť na aplikáciu v Reacte. Produkt staviate nanovo podľa existujúcej aplikácie. V praxi:

  • dáta sa zvyčajne dajú exportovať
  • grafiku a médiá môžete použiť znova
  • správanie produktu sa dá zdokumentovať
  • workflowy, stránky, podmienky, privacy rules a logiku pluginov treba aj tak postaviť znova

Migrácia je zvyčajne sčasti reverse engineering a sčasti upratovanie produktu.

Čo sa zvyčajne dá použiť znova

  • grafika značky, texty a mediálne súbory
  • exporty dát z Bubble
  • API kontrakty s externými službami
  • poznatky o produkte od skutočných používateľov
  • funkčná mapa toho, čo aplikácia už dnes robí

Čo zvyčajne treba postaviť nanovo

  • štruktúru stránok a strom komponentov
  • prácu so stavom na frontende
  • workflowy a logiku automatizácií
  • pravidlá súkromia a model oprávnení
  • väzby a obmedzenia v databáze
  • validačné pravidlá
  • funkcie, ktoré stoja na pluginoch
  • procesy prihlasovania a registrácie

Preto migrácia nie je len technické preklopenie kódu. Je to architektonický projekt.

Ako k migrácii pristúpiť

Postupujte v týchto krokoch:

  1. pochopiť, čo aplikácia v Bubble naozaj robí
  2. rozhodnúť, čo migrovať, čo prerobiť a čo vyhodiť
  3. postaviť produkt znova v jasne oddelených vrstvách
  4. pred prepnutím overiť novú aplikáciu oproti starej

Nižšie nájdete praktický postup krok za krokom.

Fáza 1: audit súčasnej aplikácie v Bubble

Skôr než začnete písať kód, zdokumentujte súčasnú aplikáciu.

Audit by mal pokryť minimálne:

  • všetky stránky a používateľské toky
  • používateľské roly a rozdiely v ich oprávneniach
  • databázové entity a väzby medzi nimi
  • externé integrácie
  • nahrávanie súborov a prácu s nimi
  • naplánované workflowy a automatizácie
  • privacy rules
  • pluginy
  • známe problémy produktu a obchádzky

Táto fáza často odhalí niečo dôležité. Aplikácia v Bubble zvyčajne obsahuje funkcie, na ktoré si už nikto nepamätá, duplicitnú logiku, staré experimenty alebo obchádzky, ktoré by ste nemali brať so sebou.

Podľa auditu rozhodnite, ktoré z týchto funkcií ponechať.

Výstup auditu

Výsledkom auditu by mal byť zoznam funkcií rozdelený do kategórií, napríklad:

  • ponechať bez zmeny
  • prerobiť počas migrácie
  • odložiť až po spustení
  • úplne odstrániť

Bez tohto kroku sa rozsah a rozpočet odhadujú ťažšie.

Fáza 2: nový návrh dátového modelu pre PostgreSQL

Dátové modely v Bubble často odrážajú to, ako sa aplikácia postupne skladala, nie to, ako by sa mala doména ideálne modelovať. Pri prechode na Supabase odolajte pokušeniu kopírovať štruktúru z Bubble pole po poli.

Namiesto toho navrhnite schému pre PostgreSQL nanovo.

Zvyčajne to znamená:

  • vytvoriť relačné tabuľky
  • jasne definovať primárne a cudzie kľúče
  • normalizovať opakujúce sa alebo preťažené polia
  • pridať obmedzenia tam, kde záleží na konzistencii dát
  • rozhodnúť, ktoré odvodené hodnoty sa majú počítať, a nie ukladať
  • zjednotiť konvencie pomenovania

Prečo na tomto kroku záleží

V Bubble sa dá postupovať rýchlo, no táto rýchlosť často zakrýva slabé rozhodnutia o štruktúre dát:

  • duplicitné záznamy
  • voľné odkazy medzi záznamami
  • preťažené textové polia
  • nejasné väzby M:N
  • logika vo workflowoch, ktorá patrí do dátového modelu

Tieto problémy vyriešte pri návrhu schémy v PostgreSQL.

Tipy na migráciu dát

Pri presune dát z Bubble do Supabase:

  • exportujte a preskúmajte dáta čo najskôr
  • pred importom nájdite rozbité odkazy
  • starostlivo zmapujte vzťahy medzi objektmi v Bubble
  • napíšte importné skripty, nerobte všetko ručne
  • testovacie importy spúšťajte najprv na kópii databázy
  • po každom importe skontrolujte počty záznamov a najdôležitejšie väzby

Často sa ukáže, že skutočným problémom migrácie nie je kód frontendu. Je ním kvalita dát.

Fáza 3: autentifikácia a autorizácia nanovo

Bubble má autentifikáciu, súkromie a správanie aplikácie často úzko poprepájané. Pri prechode na React a Supabase musíte tieto oblasti jasnejšie oddeliť.

Supabase Auth dokáže nahradiť základné procesy prihlasovania, napríklad:

  • registráciu
  • prihlásenie
  • obnovu hesla
  • správu relácií
  • prihlásenie cez sociálne siete, ak ho potrebujete

Autentifikácia je však len časť práce.

Musíte definovať aj autorizáciu:

  • kto čo môže čítať
  • kto čo môže upravovať
  • čo môžu robiť administrátori
  • čo sa nikdy nesmie dostať ku klientovi

Privacy rules z Bubble prenášajte do RLS v Supabase opatrne

Tu sa nikdy neponáhľajte.

Privacy rules a podmienky na stránkach v Bubble sa nedajú preniesť 1 : 1 do politík row-level security v Supabase. Prístupový model musíte zadefinovať znova, tentoraz z pohľadu backendu.

Osvedčený postup je zdokumentovať každú rolu a odpovedať na otázky:

  • ktoré tabuľky môže táto rola čítať
  • ktoré riadky môže táto rola čítať
  • ktoré stĺpce sú citlivé
  • aké zápisy sú povolené
  • ktoré akcie majú bežať len na serveri

Ak aplikácia v Bubble používala API tokeny, administrátorské obchádzky alebo nekonzistentné nastavenia súkromia, migrácia je správny čas tento model sprísniť.

Fáza 4: workflowy ako backendová logika a frontendové toky

Workflowy v Bubble často miešajú správanie UI, biznis logiku, validáciu a vedľajšie efekty v jednej vizuálnej reťazi.

V Reacte a Supabase by ste tieto zodpovednosti mali rozdeliť jasnejšie.

Pri migrácii sa osvedčuje tento vzor:

  • správanie UI zostáva na frontende
  • dáta sa podľa potreby validujú na klientovi aj na serveri
  • biznis pravidlá patria do backendových funkcií, SQL alebo kódu na serveri
  • úlohy na pozadí a vedľajšie efekty riešite explicitne

Bežné typy workflowov, ktoré treba premapovať

  • odoslanie a validácia formulárov
  • schvaľovacie procesy
  • notifikácie
  • naplánované úlohy
  • transformácie dát
  • akcie podľa rolí
  • spúšťače webhookov
  • udalosti súvisiace s platbami

Ľahšie tak nájdete a otestujete kód, ktorý zodpovedá za konkrétne správanie.

Fáza 5: nový frontend v Reacte

Najväčšia chyba tu je snažiť sa príliš doslovne napodobniť štruktúru stránok z Bubble.

Lepšie je brať staré UI ako predlohu a postaviť ho znova s:

  • zdieľanými základnými prvkami layoutu
  • znovupoužiteľnými komponentmi formulárov
  • jednotnými komponentmi pre tabuľky a zoznamy
  • explicitným routingom
  • jasnými hranicami stavu
  • dizajn systémom alebo knižnicou komponentov

Čo si ujasniť hneď na začiatku

Skôr než začnete stavať veľa obrazoviek, rozhodnite:

  • ako budete riešiť routing
  • ako budete spravovať stav
  • ako budete pracovať s formulármi
  • akým spôsobom budete načítavať dáta
  • akú štruktúru priečinkov budú mať komponenty
  • akú UI knižnicu alebo dizajn systém použijete
  • ako budete riešiť chyby a prázdne stavy

Ak tieto rozhodnutia preskočíte, aplikácia v Reacte môže skončiť v rovnakom neporiadku ako tá v Bubble, z ktorej odchádzate.

Výber frameworku pre React

Niektoré tímy hovoria „React“, aj keď v skutočnosti myslia framework postavený na Reacte, napríklad Next.js. Pri produkčných aplikáciách je to často dobrý nápad. Dostanete viac štruktúry pre routing, funkcie na strane servera a nasadenie.

Vyberte frontend, ktorý váš tím dokáže udržiavať.

Fáza 6: integrácie, súbory a okrajové prípady

Väčšina plánov migrácie túto oblasť podceňuje.

Aplikácie v Bubble mávajú množstvo drobných detailov, napríklad:

  • e-mailové procesy
  • generovanie PDF
  • platby
  • nahrávanie súborov
  • dashboardy pre jednotlivé roly
  • ako funguje vyhľadávanie a filtrovanie
  • funkcie, ktoré stoja na pluginoch
  • analytické udalosti
  • akcie len pre administrátorov

Práve v týchto oblastiach sa nová aplikácia môže začať od starej líšiť, ak ich dobre nezdokumentujete.

Pre každú netriviálnu funkciu si spravte checklist a potvrďte:

  • pôvodné správanie
  • požadované nové správanie
  • či správanie kopírujete, alebo ho zámerne vylepšujete

Fáza 7: testovanie oproti aplikácii v Bubble

S otázkou, či sa nová aplikácia správa rovnako ako stará, nečakajte do konca.

Overovať treba počas celého projektu.

Aplikáciu v Bubble použite ako predlohu očakávaného správania.

Testovanie by preto malo porovnávať nový produkt so starým v oblastiach ako:

  • prístup podľa rolí
  • CRUD toky
  • filtrovanie a triedenie
  • výpočty
  • notifikácie
  • integrácie
  • práca so súbormi
  • okrajové prípady

Tu migračným projektom často pomôžu veľmi konkrétne testovacie scenáre alebo checklisty funkcií. Pri väčších projektoch dokáže porovnávacie testovanie v prehliadači ušetriť veľa času na QA.

Fáza 8: plán prechodu

Posledná fáza je prechod do produkcie.

Musíte rozhodnúť, ako sa používatelia a dáta presunú z aplikácie v Bubble na nový stack.

Bežné možnosti prechodu:

Prechod naraz

Zmrazíte úpravy v Bubble, zmigrujete posledné dáta a všetkých naraz prepnete na novú aplikáciu.

Koncepčne je to jednoduchšie, no riskantnejšie, ak je produkt veľký alebo kritický pre biznis.

Postupný prechod

Konkrétne workflowy, skupiny používateľov alebo moduly presúvate postupne.

Riziko je nižšie, ale dočasne pribudne zložitosť, najmä ak musia oba systémy fungovať súčasne.

Paralelná prevádzka

Oba systémy necháte krátko bežať súčasne. Počas tohto overovacieho obdobia porovnávate výstupy aj správanie používateľov.

Je to bežné pri rizikovejších aplikáciách, najmä pri interných nástrojoch a produktoch, na ktorých stojí prevádzka firmy.

Časté chyby pri migrácii z Bubble na React a Supabase

Prestavba všetkých funkcií bez otázok

Pred prestavbou posúďte staré obchádzky, experimenty a málo používané funkcie.

Priame kopírovanie dátového modelu z Bubble

Je to jeden z najrýchlejších spôsobov, ako presunúť technický dlh z jedného stacku do druhého.

Projekt vnímaný len ako vizuálny redizajn

Najťažšie zvyčajne nie je UI. Sú to oprávnenia, workflowy, kvalita dát a biznis logika.

Podcenená náhrada pluginov

Pluginy v Bubble môžu skrývať veľa funkcionality. Pri každom dôležitom plugine sa rozhodnite pre jednu z možností:

  • natívna implementácia v novom stacku
  • napojenie na externú službu
  • odstránenie

Slabý návrh riadenia prístupu

Ak oprávnenia a RLS dôkladne nenavrhnete znova, nová aplikácia môže skončiť menej bezpečná než stará.

Príliš skorá migrácia

Ak sa produkt vo fáze overovania nápadu ešte výrazne mení, prestavba vás pri hľadaní toho, čo funguje, skôr spomalí, než by pomohla.

Viera, že AI migráciu úplne zautomatizuje

AI nástroje veľa pomôžu pri generovaní kódu, audite, písaní testov aj QA checklistoch. Nenahradia však rozhodnutia o architektúre, nový návrh dát, premýšľanie o bezpečnosti ani produktový úsudok.

Čo najviac ovplyvňuje cenu a harmonogram

Univerzálny odhad neexistuje, ale najväčší vplyv majú tieto faktory:

  • aký neporiadok je v súčasnej aplikácii v Bubble
  • ako dobre je súčasná aplikácia zdokumentovaná
  • koľko biznis logiky je schovanej vo workflowoch
  • kvalita dát a zložitosť väzieb
  • počet používateľských rolí
  • počet integrácií
  • potreba zopakovať UI do posledného pixelu
  • či tím počas migrácie zároveň prerába produkt
  • či musia oba systémy bežať paralelne

Projekt zvyčajne ide oveľa rýchlejšie, keď je tím ochotný:

  • zjednodušiť staré workflowy
  • odstrániť nepoužívané funkcie
  • vylepšiť schému namiesto toho, aby ju kopíroval
  • prijať, že niektoré obrazovky treba pre nový stack navrhnúť inak

Praktický checklist na rozhodnutie

Skôr než sa do migrácie pustíte, položte si tieto otázky:

  1. Je produkt dlhodobo dosť dôležitý na to, aby sa prestavba oplatila?
  2. Riešime skutočný obchodný problém, alebo len reagujeme na technologické obavy?
  3. Spomaľuje už teraz ťažká údržba vývoj nových vecí?
  4. Potrebujeme na backende niečo, čo sa v Bubble robí len veľmi ťažko?
  5. Sme pripravení dátový model navrhnúť znova, a nie ho kopírovať?
  6. Máme správny tím, ktorý aplikáciu v Reacte a Supabase dobre postaví a bude ju udržiavať?
  7. Vieme jasne určiť, čo migrovať, čo vylepšiť a čo odstrániť?
  8. Máme realistický plán na migráciu dát, testovanie a prechod?

Ak sú odpovede väčšinou slabé alebo nejasné, pred prestavbou pravdepodobne potrebujete viac analýzy.

Odporúčané výstupy migrácie

Ak si na migráciu najímate tím, pred začiatkom samotného vývoja si od neho vypýtajte tieto výstupy:

  • zoznam funkcií a rozsah migrácie
  • prehľad cieľovej architektúry
  • návrh schémy v PostgreSQL
  • model autentifikácie a autorizácie
  • zoznam obrazoviek a tokov
  • plán náhrady pluginov
  • QA checklist podľa správania súčasnej aplikácie
  • plán migrácie dát
  • plán prechodu

Tieto dokumenty znižujú nejasnosti a zvyčajne ušetria oveľa viac času, než koľko stoja.

Pred rozhodnutím o prestavbe

Pokračujte v Bubble, ak je aplikácia stabilná a plánované zmeny sú malé. React a Supabase zvážte, ak vás údržba spomaľuje, logika je zložitejšia a potrebujete väčšiu kontrolu nad backendom.

Počítajte s prestavbou produktu aj jeho architektúry vrátane dát, oprávnení, workflowov a testovania.

Ďalšie články.

  1. Ako zaviesť generatívnu AI vo firme: plán na 90 dní

    Praktický plán na 90 dní: prvý proces, zodpovední ľudia, výber nástrojov, pilot s kontrolou, riziká a dôvody, prečo sa zavádzanie AI zasekne.

  2. Čo je AI agent? Zrozumiteľne a bez žargónu pre firmy

    Čo je AI agent, čím sa líši od chatbota a AI workflowu, z čoho sa skladá a kde sa ho v bežnej firme oplatí použiť.

  3. Čo je MCP? Model Context Protocol vysvetlený pre firmy

    Čo je Model Context Protocol, ako prepojí AI aplikácie s vaším CRM, súbormi a databázami, kedy ho potrebujete a čo zabezpečiť ako prvé.

Všetky články

Chcete sa poradiť o svojom projekte?

Dohodnite si hovor a spolu prejdeme vaše možnosti.

JurajCEO, QikBuild

Z hovoru si odnesiete

  • Návrh, čo by sme postavili ako prvé
  • Orientačnú cenu
  • Odpoveď, či sa vám oplatí softvér na mieru
Dohodnúť 30-minútový hovor

Alebo napíšte na hello@qikbuild.com