The ride to get OLA on PhonePe
PhonePe’s open ecosystem approach, enables partners to launch their stores/micro-apps on the app and reach out to over 100M users. This also provides partners another medium beyond their native apps and websites, where PhonePe ensures a seamless login/signup and payment experience for users.
Ola was one of the first partners to come onboard the PhonePe app and their micro-app was completely built by our team. Commute is a high frequency use case and is highly relevant for our user base. What is unique is, with Ola we also launched AutoPay to support our partner’s drive to enable a cash-less commute experience for Indians.
Starting with in-app as a paradigm, we had strong reasons to choose react-native as a platform because:
- It allowed us to iterate and ship faster.
- React native renders native components which bring in an experience similar to native apps.
- We needed to write the code just once for both iOS and Android.
- It aligned with our vision of adding multiple micro apps that come with their own complexities and release cycles.
After Redbus, as our first successful in-app react-native integration, the next integration in the pipeline was OLA and we were optimistically apprehensive about it.
As Uncle Ben says, ‘With great power comes great responsibility’. If we consider OLA which serves a staggering amount of users per day or any other ride hailing service in general, we had to make sure that our UX is at par compared to OLA. The user experiences can range from simple things like the capability to use maps to pinpoint their pickup / drop location to an in-app tracking experience.
This blogpost traces the hurdles we faced and the bridges we crossed to on-board OLA on PhonePe.
The react native community in India is really small and our blog is also an effort to make readers familiar with the journey they might have to take while developing apps on a react native platform.
Chapter I,
The Unsung knights
When we started off with OLA we had to make sure that our codebase ended up like Wakanda and not like Sakaar. It had to be systematic and scalable rather than being a spaghetti code that ended up as garbage.
That’s what this chapter is about, the libraries and the frameworks used, the unsung knights who enabled us to build our micro-app in the time we had.
Redux and Redux-saga
We chose to go along with Redux as our state manager. This decision was primarily driven by the ease of using Redux and the support that is available for it. We won’t go too deep into the benefits of using Redux with react. We would recommend you to checkout their official docs.
To solve the issue of code readability, we decided to have a separation of real estates. The idea was that our components will be functional and dependent on the data stored in the state and all our business logic will sit outside the components.
Now that we were set on the React Redux combination for our view layer and store respectively, the next step was to decide how the logic would flow between the two. What we were missing was a controller layer between the two, and lo and behold, we had the Redux saga to the rescue. The Robin to our Batman.
Redux saga is middleware for Redux that helps in managing the side effects using es6 generator functions. The Side effect could be anything, ranging from api calls, business logic or, any async action that involves the bridge. Redux saga improves upon redux by listening to the same actions, but adding different ways to manage their side effects. It does so by implementing a paradigm similar to threading, with each thread handling separate business logic, dispatching actions and managing stores.
Let’s look at a simple use case of adding debounce to a search component
This is one of the ways to implement debounce using Redux-thunk a popular alternative to Redux-saga to manage side effects
Now this is how we did the same using Redux-saga
Here we are using three APIs provided by Redux saga, namely
put: which is an equivalent of dispatch,
delay: which is similar to wait for those familiar with processes,
takeLatest: it makes sure that if the SOME_ACTION is dispatched again then the previous generator function running can be terminated.
This is a very simple example to illustrate the difference between a traditional implementation and one done via saga. But this is just the tip of the iceberg, if this interests you we would strongly recommend you to visit redux-saga to get the library and the tools it provides. It ranges from something as simple as the ability to cancel api calls to adding custom event emitters which we had used to manage our polls.
Debugging
“Why do we fall? So that we can learn to pick ourselves back up.”
One can always fail in one way or the other. The important thing is the ability to understand the mistake and the capability to rectify it. When we were working on Redbus we faced a lot of issues while debugging, and facing issues while debugging makes the rectification of bugs even harder. To fix that we had integrated with two debugging tools, one being the react-native-debugger which helped us look at the DOM tree and even helped time travel using redux. The other one was reactotron which primarily helps us go through the entire flow of code, and take snapshots of the app, for us to easily return to the point of issue even on refreshing the app.
By this time we had set up the base repository along with the libraries and the tools that we would use.
Wondering what we did next? Wait for the second part in this series where we dig into the base level complications we faced while we started work on the Ola micro-app, and the journey of integrating with Google maps.
Read the second part of the blog post: Chapter 2: Ola begins here.
