Take an English-only Optimizely SaaS CMS + Next.js App Router site and add Arabic – real per-language content, /en/… and /ar/… URLs, right-to-left layout – without breaking the English site or losing a single field of the ~250-item corpus. Simple enough on paper. In practice, five things bit hard enough to be worth writing down.
Optimizely Graph ships with semantic search built in. No vector database, no embedding pipeline, no second index to keep in sync – you add one argument to a GraphQL query and you get vector search over your CMS content.
That’s a genuinely big deal, and it’s why I didn’t reach for pgvector one of the demo project. So I built site /search page that understands what people mean, is 100% server-rendered, URL-driven, and ships zero client JavaScript.
The good news: it works, and it’s about four lines of GraphQL. The interesting news: my first three attempts at verifying it worked were all measuring the wrong thing, and the fix for the biggest problem isn’t in any documentation I could find.
Read MoreWe recently worked on an Angular-based project where the front-end team was developing in a micro-front-end architecture—completely isolated from the back-end and with no exposure to Optimizely CMS. Their world revolved around Angular development and independently deployed micro-front-end applications.
Our challenge was to introduce Optimizely as the CMS backbone for content authoring and to manage the content tree structure. We needed a foundational architecture that allowed both front-end and back-end teams to work productively and in parallel across sprints—without stepping on each other’s toes.
