Learning to think differently using Firebase and Ionic

I thought I’d briefly share some observations from my learning and using Ionic2 with AngularFire and Firebase over the last few weeks. I’ve managed to build what I consider a fairly sophisticated app with great ease. Compared to the Android apps I’ve built I’ve been fantastically impressed with the speed at which new ideas can be explored with this platform. I had used Appcelerator several years ago and this seems so much easier. I recognize there are differences in approaches, but the current-day toolchain is proving very attractive.

Now my quick observation…

Getting used to an always-available, asynchronously maintained database source with Firebase has been interesting. I’ve literally had to change my whole approach to working with external data. Decades of working with transactional-oriented on-request solutions with traditional SQL-oriented sources has made it a bit challenging, but I’m adapting - and changing my coding styles in the process.

When I first started with Ionic and Firebase (through AngularFire2) I kept trying to force Firebase into behaving like a more traditional source - not so much the data itself - but the manner in which I accessed it. I’d build elaborate wrappers to follow the chain of asynchronous events with promises and callbacks and it became, well, quite challenging.

My new approach is to place watchers (observable handles returned through “subscribe”) into a global provider module. I start them up when my app starts and let them collect and maintain data autonomously.

The modules/pages that need to access data now just request copies of those data from the globals module or employ methods in the globals module to perform in-memory scans of said data.

Basically, I’m using Firebase to capture my data and treat them like always-available arrays and dictionaries of data that my app can peek at whenever and wherever it’s needed. Individual modules no long make requests on their own to find data. They now assume the data is there and available, all the time.

This way of working seems to work very well for data sets measured in megabytes (or less) vs. extremely large data sets (that couldn’t possibly be handled in the same manner).

Frustrations of working with a new platform and set of tools is slowly melting and become great admiration. And, I look forward to Ionic2’s final releases and continued development.

4 Likes

That is fantastic! Much simpler than having event handling all over the place, tied to your controllers or UI components or whatever.

And you know what, if you do it in this manner then it’s probably also feasible to make it work offline too, you can persist your in-memory “store” using whatever means (I believe Ionic 2 favors SQLite as a local storage mechanism).

Then (if it makes sense for your use case) the user can use the functionality (or part of it) offline too.

Another cool thing with this approach is that you’re not polluting all of your app’s source code with Firebase stuff, it’s isolated. So you could probably swap out Firebase quite easily for something else (your own backend, RethinkDB, websockets, GraphQL, whatever) without changing one line in your app’s “business logic”.

(I suppose the in-memory store should/could still have a mechanism in place to fire events in order to notify the app’s controllers or components or whatever that new data is available, but that’s fairly trivial)

Great concept. Does it make sense for you to open-source your approach on Github? I’m interested in using it and/or collaborating on it.

Very interesting. I’ve only built one app with Firebase and it wasn’t too bad, but I think I’m still doing things the old way / fighting the framework somewhat and making things overly complex. Any example apps or blog posts demonstrating this would be super helpful!

you should look in to ngRX… sounds like it does exactly what you just spent time creating :slight_smile:

1 Like

Aaron - I really didn’t create anything reusable - just how I accessed my data. But, thank you. I’ll definitely take a look.

Right! That’s what I thought already, the concept is cool but we might be reinventing the wheel.

I remember Flux and Redux from React, is this something similar? Especially the “store” (https://github.com/ngrx/store) sounds alike.

And ngrx is built on top of RxJS which Angular2 already uses.

I’ve also seen people who advocate building Angular2 apps with Redux. Now the final piece of the puzzle is that, apparently, ngrx is an implementation of Redux: http://onehungrymind.com/build-better-angular-2-application-redux-ngrx/

Still I would be eager to see a little example of David’s approach if only to compare and contrast it with the full-blown Redux approach.