• Mo Asady

Hybrid or native?


This article is focused towards the development community. I will be briefly discussing the technology platforms that work together to represent the foundation that the Freighton platform is built upon.

Android, iOS and the Web

It is no secret that app development is both time consuming and costly. Back in 2016 when we started designing the platform, we realized that we had a hard decision to make. Namely to develop native application, or to to choose to work with hybrid platform.

In an effort to better understand hybrid development I spent endless nights looking into some of the most used frameworks, I focused most of my research on Ionic and ReactNative. The reason i decided to focus on these two frameworks, was that if we were to go down this path, we want to be confident to use a platform that is backed by a large corporation. Ionic is backed by Google and ReactNative is backed by Facebook.

Hybrid vs. Native

The pros:

* One code base to maintain (for the most part...).

* Using web technologies that we are already familiar with (HTML, CSS and Typescript).

* Not having to learn new development languages and platform specific styling techniques.

* Shorter concept to live product cycle.

* One development team to manage.

The cons:

* Tricky access to native device APIs.

* Relying on third party developers to maintain bug free code base.

* Slower loading times compared to native (seems to be less of a problem with newer versions).

* Dealing with cross browser compatibility issues and different renderings of the same elements (it is a web app in a browser after all...).

After doing multiple prototyping phases in both Ionic and ReactNative, we decided that Ionic was better suited to our user case. It is based on the all mighty Angular platform and simply has an excellent developer resources website. We noticed that those of us who neither worked with Angular nor Ionic had no trouble getting the hang of it and we started coding much faster that any other framework we used before.

The Database

Having researched other tech startups who experienced sudden growth spurts, and the challenges they faced when their database simply could not cope with the ever growing demand from large numbers of users. Parallel scalability was an absolute requirement for this project.

Myself, having worked a couple of decades with Microsoft SQL and Mysql and coming from a relational database background always had the curiosity to experiment with noSQL databases.

The first provider the grab my attention was Google and their newly acquired (at that time) Firebase. The second candidate was a newly launched cloud database (was still in Beta) offered by Mongodb named Stitch. Both being serverless platforms offering very similar features.

We ended up choosing Mongodb's Stitch for one major functionality that Firebase lacked, Geospatial queries. As being able to filter loads based on geographic locations is an absolute core functionality that carriers will expect from the platform.

Firebase was still chosen to be our authentication provider, as they provided us with a much better flow to handle user sessions, user registration, email verification and password recovery. We build a custom integration between the two to handle authentication on Firebase end which flows into Stitch.

Document Storage

Amazon S3 was the most cost effective solution, providing us with two types of storage plans. The first allows users instant access to documents attached to ongoing jobs, and the other to securely archive documents once the load has been marked as complete, while still allowing users access to these documents at any later time if needed.

Live Notifications

Having worked with Pubnub in earlier projects involving IOT and live signaling, it was the obvious choice to seamlessly handle critical notification and events that needed to be synchronized across user devices (a bidding event on a load for example).

The concept of creating "rooms" where specific participants only will get notified about an event simplified the design process.

Let the coding begin

Building the user interface in Ionic was a breeze. Its HTML, and CSS at the end of the day and we had the pleasure of using web components that we are familiar with and a styling script that powers the world wide web.

Typescript was a pleasant addition to our Javascript habits. It is a superset of Javascript which makes todays intensive data dependent dynamic content standardized with the use of promises and observables.

Ionic shines when dealing with well structured object based data, so objects are defined in the application level and created there, mainly because Stitch by definition lacks structure and simple stores JSON documents instead of pre-structured tables. Looping through these sets of data to create lists is the most powerful feature of the Ionic framework.

The folks at Ionic also provide a powerful CLI which speeds up development by providing you with the ability to live reload the web app while changes are being made without needing to recompile to code every time changes are made.

It is not perfect

We had to spend numerous hours debugging errors related to package version conflicts, breaking changes in third party components, and signing certificate challenges with both Android and iOS. But! when things were working as expected they worked as a charm.

Final Thoughts

Hybrid development is indeed a cost effective alternative to native development. It has a much shorter proof of concept cycle and any mid-level developer can easily learn these platforms in a short time. If done correctly, it is very good alternative to native development. Our users have no idea about the technology behind the apps, if it looks like an app, feels like an app and interacts like an app ... it is an app.

16 views0 comments

Recent Posts

See All