Sylius — interní analýza pro výběr platformy¶

Pozice Syliusu na trhu¶

Sylius sedí přesně mezi dvěma světy:

Příliš velký na Shopify / WooCommerce — ty nestačí na katalog tohoto rozsahu
Příliš malý na enterprise řešení (SAP Commerce, Commercetools) — ta jsou zbytečně drahá a těžká

Pro PHP firmu se Symfony zázemím je Sylius přirozená volba. Onboarding je téměř nulový.

Co Sylius přinese hotové¶

Produktový katalog, košík, checkout, objednávky
Platby a dopravy jako rozšiřitelný model
Admin
State machine pro checkout/order flow

Kde Sylius nelze ohýbat — a co to znamená¶

Sylius má pevný model světa. Lze ho rozšiřovat, ale nelze přepisovat jeho základní koncepty bez toho, aby se projekt stal "přepisujeme Sylius".

Konkrétní příklady z tohoto projektu:

Cenotvorba — Sylius má ChannelPricing: jedna cena na kanál, hotovo. Současný systém má pipeline 5+ vrstev: Pohoda pošle cenu → přepíše ji dodavatelský import → přepíše ji skript výjimek výrobců → přepíše ji logika skladu Zlatnická → přepočítá SQL trigger. Tohle v Syliusu neexistuje jako koncept. Celá pipeline musí žít mimo Sylius a do ChannelPricing přijde už finální číslo.

Flag neprepsat — v současném systému existuje příznak na produktu: "import nesmí přepsat ručně upravená data". Používá ho všech 14 importů. Sylius nic takového nativně nemá. Musí být custom atribut + logika v importní vrstvě.

Varianty a barvy jako oddělené entity — v současném systému jsou barvy (eshop_produkty_barvy) a varianty (eshop_produkty_varianty) dvě různé věci, obě bez vlastní ceny a skladu. Sylius řeší oboje přes ProductOption → ProductVariant. Mapování je proveditelné, ale vyžaduje jasné rozhodnutí při návrhu.

Překlady inline v tabulce — eshop_produkty má 80+ sloupců, překlady 6 jazyků přímo v řádku (nazev_en, nazev_de...). Sylius používá Doctrine extensions pro překlady (samostatné tabulky). Import musí tuto transformaci zvládnout.

Skrývání produktů podle marže — business pravidlo "skryj produkt pokud nízká marže a není skladem" běží jako cron. V Syliusu to musí být event listener na import, nebo součást importní pipeline.

Klíčová myšlenka: Sylius ušetří práci, pokud se mu přizpůsobíme. Sylius přidá práci, pokud ho budeme ohýbat podle starého systému.

Importní vrstva — co bude třeba postavit mimo Sylius¶

Toto je největší část projektu. Současný kód je spletenec PHP skriptů bez rozhraní, transakcí ani testů. Nelze migrovat — musí se přepsat.

Co importní vrstva musí umět:

Stáhnout a parsovat data od 14 dodavatelů (každý jiný formát)
Zpracovat Pohoda XML (diff i full import)
Spustit cenovou pipeline a vyproduktovat finální cenu před zápisem do Syliusu
Respektovat flag "nepřepisovat ručně upravená data"
Zapsat do Syliusu přes jeho API nebo command bus — nikdy přímý SQL
Logovat průběh a chyby
Zvládnout výpadek bez ztráty dat (žádný TRUNCATE bez transakce)

Riziková mapa:

Oblast	Riziko	Konkrétní důvod
Importní pipeline (14 zdrojů)	🔴 Vysoké	Každý dodavatel jiný formát, roky akumulovaných výjimek v kódu
Pohoda integrace	🔴 Vysoké	Obousměrná vazba, vlastní číselné řady, diff i full import
Cenová pipeline	🔴 Vysoké	5+ vrstev přepisů, magické konstanty, výjimky výrobců a skladů
Flag neprepsat	🟡 Střední	Musí být reimplementován v importní vrstvě
Produktový model / překlady	🟡 Střední	80+ sloupců → Sylius Translation model
Varianty + barvy	🟡 Střední	Mapování na ProductOption je čisté, ale vyžaduje návrh
Sylius samotný	🟢 Nízké	Standardní e-commerce, žádné exotické požadavky

Editace produktů — dvojí pravda¶

Toto je největší provozní otázka. Aktuálně existuje flag neprepsat — admin může ručně upravit popis/fotky a import to nepřepíše.

V Syliusu budou dvě možnosti:

Varianta A — Sylius admin jako editor Produkty se editují v Sylius adminu. Importní vrstva ví, která pole jsou "uzamčena" a nepřepisuje je. - ✅ Jeden systém pro editory - ⚠️ Importní vrstva musí být velmi přesná v tom, co přepisuje a co ne

Varianta B — vše řeší importy, Sylius admin jen pro objednávky Produktová data žijí mimo Sylius (importní vrstva / mezistupeň). Sylius dostává vždy kompletní data. - ✅ Sylius zůstane čistý, žádné custom pole neprepsat - ⚠️ Editoři musí upravovat data mimo Sylius admin — potřebuje vlastní UI nebo PIM

Bez rozhodnutí o tomto bodu nelze zpřesnit odhad. Varianta A je provozně přirozenější, Varianta B je architektonicky čistší.

Odhad rozsahu¶

Oblast	Hodiny
Analýza a technický návrh	80–150 h
PoC — import, Pohoda, cenová pipeline	40–100 h
Importní vrstva (14 dodavatelů)	150–400 h
Pohoda integrace	100–250 h
Sylius — katalog, checkout, objednávky	250–500 h
Migrace dat, testování, výkon	100–300 h

Varianta	Hodiny
Čistý projekt	700–1 000 h
Realisticky	1 000–1 500 h
Se skrytými výjimkami v importech	1 500–2 000 h

Vyhledávání — Sylius + Meilisearch¶

Vyhledávání je na frontendu klíčové a v současném systému je to jedno z největších technických dluhů.

Současný stav: vyhledávání běží přes sérii složených SQL dotazů, které mixují podmínky na kategorie, parametry, dodavatele, dostupnost a text. Dotazy jsou pomalé, špatně udržovatelné a neexistuje jeden autoritativní zdroj pravdy — logika je roztroušená v PHP a SQL.

Cílový stav — Sylius + Meilisearch:

Sylius má oficiální bundle pro Meilisearch (monsieurbiz/sylius-search-plugin nebo sylius-search ekosystém). Meilisearch je open-source full-text search engine s nízkou latencí a bohatou filtrací (facety).

Co Meilisearch vyřeší: - Full-text vyhledávání s typosopy a relevancí (současný LIKE %term% to neumí) - Facetové filtrování (výrobce, cena, dostupnost, parametry) bez složitých JOIN dotazů - Okamžitá odezva — index v paměti, <10 ms na dotaz - Jeden zdroj pravdy pro frontend — Sylius plní index, frontend čte z Meilisearch

Co to znamená pro virtuální kategorie: Část virtuálních kategorií vznikla právě proto, že parametrické filtrování neexistovalo. Po nasazení Meilisearch s facety bude možné tyto průřezy nahradit uloženými filtry nebo dynamickými URL — bez nutnosti ručně spravovat produkty v kategoriích.

Riziková mapa:

Oblast	Riziko	Důvod
Indexování 150K produktů	🟡 Střední	Meilisearch zvládá, ale indexační pipeline musí být správně navržená (inkrementální update po každém importu)
Facety a přeložené atributy	🟡 Střední	6 jazyků × N parametrů — nutno navrhnout schéma indexu
Synchronizace po importu	🟡 Střední	Import mění produkty dávkově, Meilisearch musí dostat delta nebo full-resync
Nahrazení virtuálních kategorií	🟢 Nízké	Závisí na rozhodnutí — lze provést postupně

Rozhodnutí k zodpovězení: Bude Meilisearch součástí první fáze migrace, nebo se nasadí až po spuštění? Bez Meilisearch bude frontend vyhledávání buď pomalé (SQL) nebo nebude.

Doporučený postup¶

Fáze 1 — placená analýza a PoC (80–120 h) - Návrh importní vrstvy a cenové pipeline - PoC jednoho dodavatele end-to-end do Syliusu - PoC Pohoda integrace - Rozhodnutí: Varianta A nebo B pro editaci produktů - Výstup: architektura, zpřesněný odhad, seznam rizik

Bez Fáze 1 není možné závazně nacenit realizaci.