An Arabic answer engine

The problem

The product answers questions in Arabic, in English, and in the mix of both that people actually type. Its central interaction is not a page load. An answer arrives progressively, over seconds, and changes the layout the entire time it is arriving.

The existing frontend had grown without clear seams. Interface, business logic and data access reached into each other freely, which is survivable in a normal application and not survivable in one where the document is being rewritten while someone reads it.

What our engineers built

A complete rewrite with real boundaries between those three layers.

Tokens arrive faster than a person reads and faster than the interface needs to repaint. Rendering naively turns a stream into a render storm, which on a mid-range phone is the difference between an answer that feels alive and one that feels broken. One place decides how often the interface is allowed to catch up with the stream, instead of that decision being scattered across components.

An answer is Markdown that is only partly present at any moment. A table is a table from the first pipe character and not valid until the last row lands, so structured content renders progressively and settles, rather than flickering between broken and correct.

Layout carried more than usual. Content grows while it is being read, the composer stays pinned while the answer expands behind it, and scroll has to follow the stream without yanking a reader who has scrolled up. Arabic and English mix inside single sentences, so direction, alignment and spacing hold in both directions in the same document.

Where the shape of the stream made the client’s job harder than it needed to be, the fix was the API contract rather than another workaround in a component.

The result

The rewrite shipped and the product is live in beta. New answer types inherit correct behaviour instead of needing their own special cases — which is the difference between a product that can grow and one that can’t.