What is Dashwave?
Dashwave is an Android cloud-integrated platform that accelerates builds and provides instant, pre-built, pre-cached emulation and code environments. It enables rapid feature/code/SDK previews, and quick bug resolution, connecting with Git, CI/CD, your local IDE, and as an API.
It runs on a state of the art build engine enough to reduce time spent on building APKs by 20X, seamlessly integrates with our collaborative emulators (yes you can share emulations, embed them as a link anywhere) all packaged with one click, instant dev environments for rapid code reviewing and bug squashing.
Our Journey - Optimising Builds by 20X ⚡️
12 months ago, when we started our only objective was to make android development faster owing to the fact that how slow build times and feedback loops are and why would a general purpose build engine would not suffice.
We spoke with over 200 engineering leaders from companies like OCBC , Gojek , PhonePe , Swiggy , redBus , Booking.com , Microsoft , Powerplay , Curefit - house of cult , The Zulip Open Source Project , Freecharge , Uber , Reddit, Inc. and many-many more. We learnt how productivity metrics differ in Android development compared to backend or frontend, and how they monitor developer productivity to enhance their developer experience.
Android devs work very closely with product teams, and simply creating builds on a cloud engine is not enough. Building APKs without the functionality to test or preview is akin to writing code without understanding the purpose behind it.
We had a vision to bring entire development on cloud but we knew, until we don’t optimise for the core performance bottlenecks (which is builds and emulation) there is no sense in building just another cloud dev environment 🤷♂️.
Hence we decided to develop a cloud build engine with cloud emulation in our first product iteration.
The elephant in the room
The number one frustration today for an android developer is wasting hours on simply waiting for their builds to complete 😓. This approach not only slows down developers, kills innovation and creativity but the testers as well who rely on builds for further testing.
Companies often not realise the impact of how much they are loosing right under their nose because their developers are not productive. Think of it, just reducing build times by a mere 50% on a team size of 10 can save you atleast 3 years worth of engineering cost and productivity, keep aside the time saved on debugging, innovation and testing.
Feeling fishy? How about you check for yourself? Here are some top studies done on developer productivity:
- Embrace 2024 Mobile Developer Pain Points
- What's New with GitHub for ISVs: June 2023 EditionSurvey reveals AI’s impact on the developer experience - The GitHub Blog
- Original Research on Develocity | TechValidate
- Ask Programming: What do you waste too much time on as a developer? : r/programming (reddit.com)
- Developers Kept Away From Coding, Estimated £10.4bn a Year Wasted - IT Security Guru
- Keep Code Review from Wasting Everyone’s Time | Code Climate
- Developer Productivity for Humans, Part 4: Build Latency, Predictability, and Developer Productivity (computer.org)
- Continuous Integration (martinfowler.com)
Back to building Dashwave
Over the past 12 months, we read over more than
- 100 research articles, papers, documentations
- Experimented our build engine over 250+ open source Github repositories to deliver support at scale, with an engine optimised for both cost and performance.
- Monitored support for the top three stacks, i.e., Java/Kotlin, React Native and Flutter.
- With an early success rate of mere 10% we experimented the engine for more than 25000 builds on 900+ projects and today Dashwave supports almost 95% of code architectures in above mentioned stacks.
- Besides, it took us almost 930 projects and 450 emulation sessions spanning over 100K+ minutes of emulation to reach latency below a threshold of 20ms so that we can deliver a seamless emulation experience.
Today another reason why android development is slow because of
lack of suites to collaborate and debug feedbacks faster. We made our emulations entirely collaborative, just one click, you can share emulation as a link and comment your feedbacks there itself.
A small glimpse into our journey, our challenges and learnings while we navigate through building the tech
- Builds on cloud can be made fast, but not just with heavy duty compute but how wisely you can use ‘Distributed Cache’. It allows developers to use cache across the entire team that everyone can benefit from it. We started with a branch based cache model, in the meantime we realised it wasn’t enough. There used to pile up 100GBs of cache and maintaining this was hard. Hence we shifted to a more granular approach of task based caching model which enabled us to trim down GBs of cache to just a few MBs of cache by saving hash keys of tasks rather than complete artefacts.
- While doing this, we have to rewrite 😅 the entire caching architecture more than 5 times unlocking potential of dependency and configuration caching besides distributed caching.
- We were sure, relying on only one compute provider would slow us down hence we integrated over more than 9 services and 7 micro-services written in Go and Distributed Cache on a multi-cloud (AWS and Azure) infrastructure orchestrated using Nomad.
- Our key goals were scalability, serviceability, performance and cost optimisation. We wrote our own Autoscaler that would scale not on the basis of CPU or memory requirements but on the basis of build jobs to be scheduled. Not only this, we made the Autoscaler entirely regional so as to optimise for network latencies that might occur for global teams who are function remotely.
- Our entire build workflow is modular meaning you can hook as many custom steps in the build workflow like Custom Scripts, SonarQube, Appium. We run builds in a stateless manner to fully utilise our cloud resources.
- Another bottleneck for us was code security. From day zero we were very concerned about the code security that lies in our hands. We decided whatever be the case, even if it slows us down we need to make sure to we deliver an experience that can be trusted. The result? We recently did our VAPT and we were just awestruck to hear that our VAPT had only 5 vulnerabilities of which 2 were medium and 3 were low 🥳.
Fastest Android Dev Workspaces - What actually makes developers productive!
With an infrastructure stack optimised for cost, performance, region, scale, serviceability, security and what not we finally made a move to go back to our actual mission
Build a platform ecosystem that makes android developer faster and smarter at development
That's → Android development straight in the browser
Having a common browser based environment makes it enormously easy to operate when it comes to
- Rapid PR Reviewing
- Rapid Bug Squashing
- SDK Sandboxing for Documentations and Libraries
- and, Collaborative Coding
Android development has consistently shown higher numbers in certain developer metrics, indicating challenges in areas such as
- MTTR (Mean time to Recover)
- MTTM (Mean time to Merge)
- MTTD (Mean time to Debug)
Hear me out 👂...
A developer wastes as much as 30-40 minutes for every context switch that they make while reviewing or rapid bug resolution. Time is lost in setting up a different environment, cache invalidation, context setting. Generally developers of all kinds go through a minimum of 5 cycles of context switching /week which estimates an equivalent of 2-3 hours lost /week just on context switching.
Our challenge in deploying instant android developer environments was to hook all three top of the line services of Build Runners, Emulation and Code Environment in one window that it would boot up in a matter of seconds.
Just as I mentioned, given our modular approach to development we were able to trim down the boot speed to as low as 10 seconds.
- We broadly have 3 kind of Nomad jobs, Android Studio, Emulator and Build Runner.
- We maintain a pool of each kind of job (region-wise), with a buffered number of jobs maintained by our own engineered Autoscaler .
- Now, each component utilises a combination of these jobs, for example a workspace is combination of an Android Studio job and a Build Runner.
- Our resource or job manager would take out a job from Android Studio and Build Runner pool in real-time as we are ensured by Autoscaler that we have enough buffer.
- These are connected via NFS protocol so as to use same volume and run builds.
- Hence we manage to boot-up time under seconds for a user.
Attaching Plugins, Debuggers to Android Studio and VSCode
Earlier when we started, we took an approach to fire builds via CLI in the terminal and that too during the local development. Local because, it’s the local development which degrades the developer productivity, however today we serve both local and automated builds.
Coming back to firing builds, to be honest, it looked pretty straightforward to us. The mental model of android developers to fire a build is as simple as clicking the build button in Android Studio toolbar. Our conceptual model which was CLI was way different from how they expected a cloud build engine to function. We soon realised that there is a significant UX gap and that can only filled by a ‘Plugin’. Hence, we developed a plugin that would install in your local IDE while it communicates and syncs you code with Dashwave’s build engine on the cloud.
Here's a link to the plugin: Dashwave Cloud Build Plugin
With plugin in picture it solved many challenges for us
- Setup was hard with a CLI. Configuring CLI for different OS is a hefty task on its own, then we have to rely on third party installers like Brew. The time it took to setup a CLI was way more than setting up a plugin. Just a click of install button and you’re already ready to fire builds on the cloud.
- CLI has limited functionalities. With a plugin we could now provide support on Android Studio, VSCode across all OS. This also means the features of logging, build configurations, custom build environments, and even connect your own device with the cloud build engine via ADB.
- Connecting debuggers and real devices via ADB. With plugins on both VSCode and Android Studio it became obvious to how can we build a system to support attaching Kotlin debugger, Dart debugger and Flipper (React Native debugger) with real devices attached via ADB.
Journey Ahead
Long way to go, our vision ahead lies in
Enabling and inspiring mobile app developers to foster a more joyful and creative developer experience
Being faster is just part of it, but being smarter makes development more creative and joyful and that’s we believe in.
We’re continuously working towards making the end user developer experience more seamless, faster, smarter. In the coming few months we’re going to launch several key features that would make debugging a breeze.
Thanks to the stellar and amazing team for making all of this come true Supratik Das , Aviral Jain , Nupur Agrawal , Rahul Patil , Rohan Hemantkumar Patel , Alwin T Varghese Abhishek Edla
And yeah not to mention...our own Chief Happiness Officer
Looking forward to it.
Signing off
Yash Khandelwal
Founder, CEO, Dashwave