Afgelopen keer schreef ik over het ontstaan van de wildgroei aan Magento 2 extensies met daarin een grote diversiteit aan kwaliteit. Tussen de regels door ervaar je dat extensie bouwers naast hun vaste ervaren ontwikkelaars ook juneoren en stagiairs op productontwikkeling zetten. Niks mis mee, zolang er constructief en functioneel meegedacht wordt door ervaren developers. Ervaring leert dat dit laatste mijns inziens te wensen over laat.
Een behoorlijk kritische noot zoals je misschien hebt ervaren. Ik blijf van mening dat het niveau momenteel achterwege blijft. Zoals ik in mijn vorige blog opmerkte, gaat kwantiteit in vele gevallen nog steeds voor kwaliteit. Gelukkig merken we hierin ook een tegenwicht waarin extensie leveranciers steeds vaker contact opnemen voor een stuk advies waarna we in vele gevallen de eerste code reviews mogen uitvoeren. Een groot voordeel als Magento partner is dat we over de mogelijkheid beschikken om extensies te testen op gesplitste databases. We moedigen dit soort samenwerkingen enorm aan en kunnen daardoor, voorafgaand aan officiële releases, de laatste punten op de i zetten en/of hen van passend advies voorzien.
De mogelijkheid tot het opsplitsen van je database is een specifieke Magento 2 Commerce feature. Gezien het opzetten van gesplitste databases relatief eenvoudig is, raad ik aan dit vanaf de opzet van je ontwikkelstraat direct mee te nemen. Mocht dit niet zijn gebeurd, dan wil ik je graag adviseren de tijd te investeren om dit alsnog om te (laten) zetten. Waarom? Het bevordert onder andere de schaalbaarheid voor toekomstig gebruik, het maken van back-ups en deels de snelheid van je gehele Magento instance. Simpel gezegd speel je hiermee dus ook in op de gebruikerservaring van je klanten en is het mede daardoor in mijn ogen een must-have.
Wat er feitelijk achter de schermen gebeurt is het opsplitsen van één enkele master database in drie losse. Hieronder vallen de ‘default’, ‘checkout’ en ‘orders’. Met deze insteek, mits verdeeld over aparte MySQL-gebruikers, heeft Magento de volledige beschikking over de capaciteit van elke database en wordt het niet belemmerd door overige SQL processen. Hiervoor geldt een andere, zeer minimale insteek. Precies dit is hetgeen waar extensie leveranciers nog te weinig rekening mee houden en merken we dat dit deels door het onbekende terrein komt.
Gelukkig weten we goed hoe dit op te lossen, alleen is dit niet de gewenste manier en loopt een code-review hier nog te vaak op stuk. De flexibiliteit van Magento is groot, waardoor je tot bijna elk onderdeel de controle kan overnemen zonder hiervoor de core van de module aan te hoeven passen. Exact dit is de bottleneck aangezien Magento, indien een goed geschreven module, automatisch de juiste afhandeling van het lezen en schrijven voor je ontzorgt maar het installatie- en/of update-proces de plek is waarin dit specifiek aangegeven moet worden.
Dit kan op verschillende manieren worden opgelost. Je kan bijvoorbeeld een around plugin of een preference schrijven. Een tweede optie is de module te forken en de aanpassingen in een eigen versie te verwerken. Het effect hiervan is dat je separaat versiebeheer moet voeren en niet kunt bouwen op de originele code. In beide gevallen bevind je jezelf op glad ijs en moet er extra code worden geschreven die je volgens mij juist in de core mag verwachten. Onze collega’s van Firebear Studio hebben hierover een goed blog geschreven, waarin dit proces nauwkeurig wordt beschreven.
Mocht je omtrent dit onderwerp meer informatie willen of wil je onze expertise benutten om vooraf vast te stellen of jouw module voldoet aan dit cruciale eisenpakket. Neem dan gerust contact op.