Dutchlabelshop.

Dutchlabelshop

In het tijdperk van e-commerce en platforms zoals Etsy krijgen creatieve makers meer kansen dan ooit om hun passie om te zetten in iets tastbaars. Boutique-eigenaren kunnen hun handgemaakte collecties laten uitgroeien tot een professioneel en winstgevend merk.

Dutchlabelshop helpt deze makers daarbij door producten te bieden waarmee zij hun werk duidelijk en trots als hun eigen merk kunnen presenteren. Het bedrijf biedt vier soorten hoogwaardige, gepersonaliseerde labels: merklabels, maatlabels, waslabels en hangtags al verkrijgbaar vanaf oplages van slechts 30 stuks.

De uitdaging

Dutchlabelshop benaderde ons voor een herbouw van hun IT-infrastructuur. Hun vorige webshop (ook door ons ontwikkeld) draaide op Magento 1, dat richting het einde van de levensduur ging in juni 2020.

Een groot deel van de bestaande codebase was gericht op het verwerken van bestellingen na plaatsing, ter ondersteuning van het productieproces. We grepen deze kans aan om de codebase opnieuw te ontwerpen, met als doel het systeem robuuster, flexibeler en toekomstbestendiger te maken.

We werkten in sprints van twee weken en de klant was één dag per week bij ons op kantoor aanwezig. Zo konden we een korte feedbackloop garanderen en snel schakelen tijdens het proces.

Migratie van Magento 1 to 2

In de Magento 1-installatie hadden we door de jaren heen veel maatwerk opgebouwd, wat uiteindelijk resulteerde in 75 op maat gemaakte extensies.

Onze eerste stap was om samen met het team van de klant alle extensies uit de Magento 1-shop door te nemen. Per extensie beoordeelden we of we deze konden laten vervallen, moesten overzetten naar Magento 2, of dat er een alternatief beschikbaar was voor de nieuwe omgeving.

Servicegerichte architectuur

Het project bestaat uit veel verschillende, maar onderling verbonden onderdelen. In de Magento 1-webshop hadden we alles binnen Magento ondergebracht, wat uiteindelijk niet de beste oplossing bleek. Magento is sterk in waar het voor bedoeld is, maar door het systeem verantwoordelijkheden te geven waarvoor het niet ontworpen is, kwamen we soms in lastige situaties terecht.

Daarom kozen we voor een servicegerichte architectuur (SOA). Hierbij hebben we de verschillende, maar samenhangende onderdelen van de codebase opgesplitst in systemen die elk doen waar ze het beste in zijn. Deze systemen vormen samen één geheel binnen het Magento-ecosysteem.

Dit betekende dat we het systeem hebben opgesplitst in verschillende onderdelen:

• Contentmanagement
• Productdesigners & uploadtools
• Productbibliotheek
• Pricingbibliotheek
• Diverse microservices voor kleinere taken
• Een middlewarelaag voor de productiefaciliteit

In deze case study lichten we elk onderdeel verder toe, zodat duidelijk wordt hoe een moderne Magento 2-stack kan functioneren.

Hyvä Frontend

Voor dit project kozen we voor het Hyvä-thema: een frontend die standaard razendsnel is en eenvoudig uit te breiden met de maatwerkfunctionaliteiten die Dutchlabelshop nodig heeft. Voor deze klant hebben we uiteindelijk ongeveer 30 modules geschikt gemaakt voor Hyvä, waarvan we er ook een aantal hebben gedeeld met de Hyvä-community.

Met het oude Luma-thema is het lastig om mee te gaan met de steeds hogere verwachtingen van eindgebruikers op het gebied van snelheid en gebruikerservaring (UX). Met Hyvä als basis voor de frontend wordt dit een stuk eenvoudiger en beter beheersbaar.

Content management

Naast de Magento 1-webshop had de klant een WordPress-site draaien voor alle blogcontent. Het samenbrengen van de blogcontent met andere sitecontent was een grote wens van het contentteam van de klant. Daarom waren we op zoek naar een contentmanagementsysteem dat ons in staat stelde om:

• Flexibel contenttypes te creëren (zoals blogs, landingspagina’s, FAQ’s, etc.)
• Gedetailleerde controle te hebben over gebruikers en rechten
• Content te previewen in het daadwerkelijke design
• De geschiedenis van wijzigingen in content te zien (versioning)
• Elk contentitem in meerdere talen te beheren
• Alle content op te halen via een REST (of GraphQL) endpoint

Deze vereisten brachten de lijst terug tot een aantal systemen:

• Contentful
• Cockpit
• Butter CMS
• Prismic.io
• DatoCMS

We hebben met elk van deze partijen meerdere gesprekken gevoerd en hun demo’s grondig beoordeeld samen met het contentteam van de klant om te bepalen welk systeem het beste aansloot bij onze wensen en voorkeuren. Uiteindelijk hebben we besloten om voor Prismic.io te kiezen.

Helaas was er geen Magento 2-extensie beschikbaar om Prismic met Magento 2 te koppelen en zo een naadloze ervaring voor het contentteam te creëren. Omdat we zo enthousiast waren (en nog steeds zijn!) over Prismic, hebben we besloten om de extensie zelf te bouwen. We hebben deze ook open source gemaakt — je kunt deze vinden op onze Github repo elgentos/magento2-prismicio.

Je kunt meer lezen over onze Prismic- en Magento-integratie hier.

Product designers & uploaders

De kern van het verkoopproces voor Dutchlabelshop is natuurlijk het product. Dutchlabelshop heeft een aantal labels op voorraad, zoals de Made in-labels. De overige producten moeten door de klant zelf worden ontworpen met wat wij configurators noemen. We kunnen deze configurators onderverdelen in twee categorieën: een uploader waarbij je een afbeelding uploadt en op basis daarvan een label maakt en een designer waarbij je een label ontwerpt aan de hand van vooraf ingestelde opties.

We hebben veel geleerd van deze types in het Magento 1-project. Het belangrijkste inzicht was dat we geen server-side rendering wilden gebruiken voor het genereren van label previews. De belangrijkste reden hiervoor is dat server-side rendering te traag is, vooral door netwerkvertraging. Een client-side rendering aanpak geeft de klant direct resultaat wanneer er wijzigingen worden gemaakt in de configurator. Met client-side rendering hoeven we ons ook geen zorgen te maken over schaalbaarheidsproblemen zoals bij server-side rendering.

We kozen voor React om de configurators te bouwen. Voor de preview kozen we Fabric.js als extra objectmodel bovenop het HTML canvas-element.

Voor oudere browsers die client-side rendering niet goed ondersteunen, vallen we terug op een server-side rendering client.

De basis van elke configurator is een JSON-bestand dat bij het laden van de pagina wordt gedownload en alle productdata bevat. Met deze JSON rendert de React-applicatie de invoervelden voor de gebruiker. Bij elke wijziging wordt er een nieuwe preview gegenereerd.

Productbibliotheek

In Magento 1 was Magento zelf de bron voor productdata. Toen we besloten over te stappen naar een servicegerichte architectuur, hadden we een centrale plek nodig waar productdata vandaan komt. De productbibliotheek is die plek; deze bevat alle producttypes en opties. Alle mogelijke opties en waarden voor producten van Dutchlabelshop zijn opgenomen in de productbibliotheek.

We gebruiken de productbibliotheek in verschillende onderdelen van het technische landschap van Dutchlabelshop, zoals Magento 2, het Order Management System en de designers & uploaders. De productbibliotheek maakt gebruik van een zelfgebouwde command line tool om een statische JSON te genereren, die is opgebouwd uit meerdere inputbestanden. Dit maakt onderhoud en overzicht een stuk eenvoudiger.

Pricingbibliotheek

De pricingbibliotheek is vergelijkbaar met de productbibliotheek, met als verschil dat deze bibliotheek alle kost- en verkoopprijzen bevat. De prijsinput wordt gegenereerd op basis van een complexe berekening, waarbij rekening wordt gehouden met een groot aantal variabelen zoals labelgrootte, denier, symbool ja/nee, kader ja/nee, glanskleur ja/nee, enzovoort.

Microservices

Color Extractor

In de Magento 1-shop moesten klanten zelf de kleuren kiezen die op het label aanwezig waren. Voor de nieuwe shop wilde de klant dit proces automatiseren. Met behulp van machine learning worden de kleuren automatisch uit de afbeelding gehaald. Deze kleurinformatie wordt vervolgens opgeslagen in Magento en gebruikt tijdens het productieproces.

Vertalingen

Omdat de shop beschikbaar is in 16 talen, hadden we een manier nodig om ervoor te zorgen dat alle teksten in alle talen beschikbaar zijn. We hebben een vertaal-microservice ontwikkeld die alle templatebestanden doorzoekt op vertaalbare tekst. Vervolgens controleren we per tekst of er een vertaling beschikbaar is in alle 16 talen. We hebben deze microservice gekoppeld aan ons deploymentproces, dat een waarschuwing geeft (of faalt boven een bepaalde drempel) wanneer er vertalingen ontbreken.

Bedrijfsprocessen

De belangrijkste verantwoordelijkheid van de middleware is het volgen van de productie van orders. Omdat deze processen in de Magento 1-shop waren ingebouwd, moesten we ze overzetten naar de middleware. Dit gaf ons een mooie kans om de processen opnieuw te bekijken.

Allereerst moesten we inzicht krijgen in hoe het huidige proces eruitzag. Gelukkig waren deze processen al gedocumenteerd door Dutchlabelshop, omdat zij als volledig remote organisatie werken.

In dit geval hielp goede documentatie niet alleen om nieuwe medewerkers snel in te werken, maar ook om ons inzicht te geven in de bestaande processen.

Vervolgens hebben we bepaald hoe het nieuwe proces eruit moest zien. Hiervoor hebben we meerdere sessies met de klant gehouden om de volledige workflow te visualiseren. We maakten een flowchart in Lucidchart. Het grote voordeel van Lucidchart is de samenwerkingsfunctie, waardoor we tegelijkertijd met de klant aan dezelfde diagrammen konden werken.

Om goed inzicht te krijgen in de bedrijfsprocessen rondom de productie van labels, hebben Peter Jaap en Jeroen de productielocatie van Dutchlabelshop bezocht.

Power loom

Color spools

Lasercutter

Ons testproduct – Elgentos-logo labels

Middleware

In het hart van de nieuwe shop staat de custom middleware: het Order Management System, oftewel OMS. We hebben het OMS gebouwd op Laravel, het PHP-framework.

Na het maken van de flowchart en het bezoeken van de productiefaciliteit hadden we een duidelijk beeld van hoe het volledige productieproces door de applicatie moest verlopen. Met dit in gedachten konden we beginnen met het bouwen van de basis van de applicatie. Hiervoor hebben we de applicatie opgedeeld in het kleinste onderdeel: het scherm.

Schermen

Het productieproces bestaat uit een aantal stappen. In sommige stappen werken één of meerdere mensen. Deze mensen hoeven alleen de informatie te zien die op dat moment relevant voor hen is. Hiervoor hebben we schermen gemaakt. Een scherm is een overzichtspagina met alle orders die zich in die stap van de workflow bevinden. Een scherm kan meerdere acties bevatten, die per context verschillen. Een fabrieksmedewerker kan de orders in zijn stap bekijken en zich alleen daarop focussen. Orders kunnen vervolgens naar de volgende stap in de workflow worden gestuurd of terug worden gezet, bijvoorbeeld wanneer er iets mis is gegaan tijdens de productie.

• Order detail scherm
• QA design proces workflow
• Upload Photo Proof workflow
• Cutting preparation workflow

Rechten

Een van de belangrijkste onderdelen van het OMS is het rechten­systeem. In het productieproces is een medewerker verantwoordelijk voor één of meerdere stappen. Met het rechten­systeem kunnen we ervoor zorgen dat een medewerker alleen de schermen ziet die nodig zijn voor zijn taak. Binnen de workflow zijn rechten gekoppeld aan elke stap.

Als extra beveiliging worden de rechten per order ook door de workflow bepaald. Wanneer een order naar de volgende stap gaat, controleert de workflow automatisch welke rechten bij die stap horen. Deze rechten worden vervolgens aan de order gekoppeld, zodat de juiste medewerker deze ziet.

Naast het tonen of verbergen van complete orders, kunnen we ook specifieke informatie verbergen. Zo ziet een fabrieksmedewerker bijvoorbeeld geen klant- of financiële gegevens, maar alleen de informatie die relevant is voor zijn taak.

Notification Manager

Wanneer een order door het volledige productieproces gaat, moet Magento continu worden bijgewerkt. Hiervoor hebben we de notification manager ontwikkeld. Aan de OMS-kant triggert elke (goedgekeurde) actie een notificatie naar Magento. Op basis daarvan bepaalt Magento of er een actie moet worden uitgevoerd.

Een voorbeeld: het is mogelijk om een product te bestellen met een photoproof. Wanneer een order deze stap in het productieproces bereikt, stuurt het OMS een notificatie naar Magento. Deze notificatie bevat alle benodigde data om een e-mail naar de klant te sturen met de photoproof.

De notification manager wordt ook gebruikt voor verzendnotificaties. Het OMS is verantwoordelijk voor het aanmaken van zendingen en het doorsturen daarvan naar de fulfillment services. Deze services sturen de trackinginformatie terug naar het OMS. Vervolgens verwerkt het OMS deze informatie, verplaatst de order binnen de workflow en stuurt de trackinggegevens via de notification manager naar Magento. Magento zorgt er daarna voor dat de klant via e-mail op de hoogte blijft van de verzending totdat het pakket is geleverd.

Deployments

We moesten ervoor zorgen dat al deze bewegende onderdelen goed op elkaar aansluiten zoals bedoeld. Daarnaast hadden we een manier nodig om de codekwaliteit op peil te houden en ons te waarschuwen wanneer er iets niet klopt. Om dit te bereiken hebben we een CI/CD-pipeline in GitLab geïmplementeerd, waarmee we verschillende checks en buildprocessen automatiseren.

CI/CD-pipeline

Deze pipeline genereert een kleine website met documentatie over codekwaliteit, codecomplexiteit, security checks, vertaalchecks, enzovoort, zodat onze developers deze periodiek kunnen beoordelen.