The good things on the front end: EWAs
Credit Karma’s cornerstone mission is to champion financial progress for all. From an engineering perspective, this means ensuring a seamless experience from start to finish. So when we discovered that some of our members were experiencing delays when viewing web content on native platforms, our front-end and native platform infrastructure teams took action, launching a new environment for hybrid Single Page Apps called Embedded Web Apps.
Why the Delay?
For our native apps to load a WebView, a request is sent to our PHP back end to load the contents of the page. If the user has not opened a WebView recently, a single sign-on reauthentication process takes over the initial request, which could lead to significant delays before showing any content.
But what if we cut out the PHP back end’s lengthy reauthentication process and instead take advantage of the authentication that already exists in the native landscape?
Goodbye, Mono, hello, FERS!
Our solution used preexisting infrastructure: Over the past two years, we slowly reduced the front-end responsibilities of our PHP back end with a lean, innovative, front-end hosting platform, Front-End Render Service (FERS). Think of FERS as a tier of web servers that dynamically integrates different applications across dozens of teams at Credit Karma. Not only did decoupling our apps from our PHP back end and handing off authentication to the native platform result in a notable decrease in latency, but also gave us the ability to leverage hybrid applications.
Enter the Hybrid: part native, part web app
First, what is a hybrid app? Fundamentally, hybrid apps are web apps placed into a native app shell. Once they are downloaded from an app store and installed locally, the shell is able to connect to the capabilities the native platform provides through a browser that’s embedded in the application. Specifically, hybrid apps rely on HTML being rendered in a browser that has been embedded within the app, known as the WebView.
The Trifecta: Native, FERS and EWAs
In order for EWA WebViews to be integrated smoothly into Credit Karma’s infrastructure, our native platform engineers implemented the Native Bridge, an entry point into WebViews. The Native Bridge allows for communication between the host app and WebViews, and enables WebViews to delegate work to the host applications.
And remember that lengthy reauthentication process back when there was a PHP-back end dependency? With the integration of the Front-End Render Service, network calls that require authentication are now forwarded to the Native Bridge, which then makes authenticated calls on behalf of our web apps. And finally, the integration of the Native Bridge and FERS enables WebViews to fetch the EWA front-end bundle from FERS.
Pros and Cons of EWAs
- Thanks to our EWAs, any Credit Karma web developer can now contribute to our mobile apps. Plus, our new lightweight EWAs load content quickly and work across multiple native platforms. Yet another perk of EWAs is the ability to bypass the clunky process of native versioning. Now app maintenance is as simple as updating a web page in real time. By maintaining one codebase for all platforms, not only do EWAs decrease the development cycle, but also save time by cutting out the need to code on multiple platforms.
- There’s room for improvement when it comes to testing our hybrid apps in a straightforward way. The insertion of a layer between the web app and API creates more complexity for end-to-end testing. Further, while the benefit of building an EWA is developing one codebase for all platforms, it is worth noting that certain features or designs aren’t supported equally. So, modifications may be required to create a consistent user experience.
The future of EWAs at Credit Karma
What’s on the horizon for EWAs at Credit Karma? Our roadmap includes integrating the features of PWAs and HTTP/2, which will further decrease latency and improve our members’ experience.
- PWAs: Progressive Web Apps
- Progressive Web Apps are reliable and fast, and they provide key engagement features. Specifically, PWAs load instantly and always render content, regardless of network conditions. This reliability is achieved through a service worker that acts as a client-side proxy that can precache crucial resources and eliminate our apps’ dependence on the network. The result is a faster app that responds to user interaction with quick animations and an instant, reliable experience for our members.
- HTTP/2 addresses many performance problems that came with HTTP/1.1, such as concurrent request limits and the lack of header compression. HTTP/2 handles concurrent request limits by streaming binary frames that enable the exchange of multiple, open and independent bidirectional sequences without latency between successive streams. In addition to gracefully handling request limits, HTTP/2 compresses request and response header metadata using the HPACK compression format, ensuring only a few bytes are sent to the server for each request.
Collaboration for the Win!
The successful launch of Credit Karma’s Embedded Web Apps would not have been possible without the collaboration of the native and front-end infrastructure teams. Now, instead of maintaining and writing two separate sets of code for Android and iOS platforms, we can share the EWA codebase. Our new EWA can be deployed across multiple platforms — not only saving Credit Karma engineers valuable development time, but also resulting in an easily scalable codebase that can be reused without rebuilding an entire app from scratch. By doing so, EWAs enable our engineers to build an experience that further empowers our members’ journey to financial progress, exemplifying the good things on the front-end at Credit Karma.