Loading…
How OVO determined the right technology stack for their web-based projects
GrabGeorge Matthew Limongan
Summary
OVO faced maintainability issues caused by fragmented web technology stacks, including PHP, Vue, React, Nuxt, and Go, alongside outdated documentation. This fragmentation resulted in severe context-switching costs during code reviews and prolonged onboarding times for new engineers. To establish a single primary front-end stack, the team compared React and Vue against maintainability principles encompassing operability, simplicity, and evolvability. Vue was selected because its standardized framework structure and documentation minimized architectural variations across projects. Implementation entailed creating a standardized Vue boilerplate, updating the internal UI library, and scheduling periodic upgrades for legacy React services rather than migrating them entirely.
Context
OVO maintained multiple front-end technologies with incomplete documentation, causing heavy context switching during code reviews and slow onboarding for new engineers.
Approach / What changed
Evaluated React and Vue against a maintainability north star metric, selected Vue as the single primary stack for future projects, established a standardized project boilerplate, and updated the shared UI library.
Takeaways
- Standardizing on a single framework allows applying security patches once across all projects rather than creating distinct patches per stack.
- Vue was chosen over React because its framework structure and standardized documentation provide consistent patterns that reduce complexity across teams.
- OVO elected not to migrate existing legacy services to Vue, opting instead to enforce the standard on future projects while performing periodic upgrades on legacy code.
Related reading
Grab ·
The journey of building a comprehensive attribution platform
Grab needed to modernize its marketing analytics from manual ad hoc queries and high data latency to a platform supporting real-time attribution for pricing models like cost per order. The engineering team initially deployed a pure stream-processing engine using Kappa architecture, Kafka, ScyllaDB, and Redis, which reduced latency from days to minutes and merged ads and promo touchpoints. However, stream-only processing faced high costs, out-of-order event issues, and difficulties running multi-touch models across longer historical windows. Grab transitioned to a Lambda architecture pairing Coban stream processing with Spark-based batch ETL and Amazon S3. This hybrid design separated real-time operational metrics from historical batch reporting, cutting real-time processing costs by approximately 25% while maintaining under 1% data discrepancy.
Kang HuangGrab ·
Bringing Grab’s Live Activity to Android: Enhancing user experience through custom notifications
Grab designed an equivalent to iOS Live Activities for Android to provide real-time order tracking outside the app. Because Android lacks Apple's native ActivityKit push token system, the team substituted push tokens with placeholder values to maintain technical consistency across platforms and preserve backend push targeting via their Hedwig service. For the user interface, engineering selected custom notifications over floating views because custom notifications avoid intrusive screen usage and do not require the 'Draw over other apps' permission. The client implementation separates responsibilities across dedicated classes: LiveActivityIntegrationManager handles token registration across business verticals, LiveActivityAttributes encapsulates UI configuration, and LiveActivityManager maps payloads to Android NotificationManager instances. The solution launched for Food, Mart, Express, and Transport verticals.
Jessica SeanGrab ·
Managing dynamic marketplace content at scale: Grab's approach to content moderation
Grab manages content moderation across GrabFood and GrabMart, where merchants update over 100,000 item listings daily across eight countries. The platform must adhere to internal rules, local government regulations, and external platform guidelines across these markets. To handle scale and regional nuance, Grab uses an in-house automated system powered by algorithms and machine learning to scan daily listings for violations. Items flagged as requiring subjective judgment or cultural awareness are routed to human moderators for manual review. Additionally, Grab collaborates with Google to maintain compliance with Play Store policies.
Poonam GambhireGrab ·
Stepping up marketing for advertisers: Scalable lookalike audience
Grab's legacy lookalike audience generation platform suffered from long creation SLAs of two working days, high costs, and low weekly update frequencies. To resolve these bottlenecks, the engineering team designed an embedding-based platform powered by an in-memory retrieval service and automated update pipelines. The system creates audience representations by averaging constituent passenger embeddings, determining user membership through real-time cosine score thresholds. To eliminate feature store latency while fitting all embeddings into memory, a hash-based compression method cuts passenger embedding storage needs by roughly 90%. Consequently, audience availability dropped to within 15 minutes of campaign creation, audience generation costs fell by 98%, and ad impressions and clicks doubled.
William Wu