I’ve recently launched a Meteor/React-Native app called Badger and I would love to get feedback on what you love/hate about it!
Badger is an app that is used to send delayed reminders to your friends and family. Common use cases are to take out the trash (weekly), pay the rent (monthly), and to send someone a delayed message in the morning. Currently all reminders are being pushed out with SMS via Twilio.
Currently only the iOS app is live and an Android version will be coming in the future. It’s also currently limited to US users on the App Store, but we’re looking to expand globally in the future.
The backend is using 3 Meteor micro services to handle the API, Scheduler, and Notifications (SMS, APNs, GCM).
The front-end is using vanilla React-Native and is using Redux and REST calls via AJAX. The app really doesn’t need realtime but having a realtime feed could be implemented easily with the Node DDP adapter or the React Native Meteor DDP wrapper.
Just a question about why you would use Meteor for this type of app?
You build an app using react native, which I am guessing you needed to build in isolation?
I am just assuming that wouldn’t have been built with the normal Meteor tool set.
Also since you’re not using DDP, what benefits do you get from using Meteor over just running a node service to just respond to the REST API calls? All the other stuff would just be NPM packages I am guessing (twillio and stuff).
Is there still a client output to your Meteor app, or does it only work via the iOS app?
edit: I am not in the US so sadly I can’t try it out Australia always missing out
Mainly because I wanted to build it fast and I was already using Node and MongoDB. Using fibers on the server is really nice!
DDP was also really nice to tie the microservices together by using Meteor.call to pass data around the services.
If there’s a V2 of the API i’ll prob. use GraphQL/Apollo to expose a newer API while keeping the V1 REST intact.
Also since you’re not using DDP, what benefits do you get from using Meteor over just running a node service to just respond to the REST API calls?
For the clientside there isn’t much of an advantage as you’re just using REST calls at the end of the day. However, this is far more scalable than using publications to deliver data. Even in regular Meteor apps I only use a subscription if I have to (to get realtime), otherwise i’ll use a Meteor method and a local mongo collection to render data.
Is there still a client output to your Meteor app, or does it only work via the iOS app?
For now just an iOS app. However, in the future we will prob. make a web based client (this will likely be a React Meteor app with Apollo).
its pretty cool to see how versatile meteor can be.
You’re not using a large part of what I would have thought was the core feature set of meteor, but it still sounds like you get a lot out of the platform.
Awesome Adam! Is there a specific reason you don’t launch on Android right away? I’m starting to look into React-Native, but I’m still a bit reluctant because of the possible need of a split code base for iOS and Android.
The main reason was the app was built before the RN for Android was released. We’ve had the app soft launched for a few months to work on ironing out any UX issues.
The app was built with the NavigatorIOS router which as you may have guessed, only works on iOS. At the time it was unknown on how to integrate Android, and the Navigator (JS based) router was
The new router that i’m using for Android is JS based and can be shared with the iOS. Instead of making two code bases I just have to re-factor some of the code to work with both. This includes fidgeting with animations (although the defaults are quite good!). The new router i’m using is a flux based router on top of Navigator to give it a more declarative API.
Code re-use (once refactored) will be around 90%. The main differences will be in the scheduling view where you have the time date picker and weekly/daily/etc… buttons. This is good though because we want these to be native not generic.
Also i’m thinking about writing a blog post soon to go into more depth if this is interesting to anyone?
Wait, so you expose a REST api from your Meteor backend? I thought the only way to hook into a Meteor db was establish a DDP collection and then Meteor.call? Would be very curious as to how you could have a Meteor / Mongo db that you could do an ordinary GET/POST/PUT, etc…
Sure, so underneath the Meteor layer is a normal Node app. The main difference is that you can’t use callbacks without wrapping with Fibers. The connect app is also a bit hidden from plain sight but any middlewares can be added.
The easiest way to add a JSON API is to use the simple:json package:
You can just query for data and return a response as needed. There is also simple:rest that offers more to expose publications and such but was too much for my use case. I also made my own router Restful but it wasn’t popular enough to maintain it (though it’s based off of Badger’s routing, just cleaned up). It was also based on functional principals which is not the norm in JS.
The main bit of glue to use connect is here:
which ultimately is just binding a callback (controller) to the route path that matches:
The Restful package was more of a fun side project so it’s not being kept up to date. However, using simple:json is a great base for REST routes (as opposed to Picker/Iron Router which need more glue for easier responses).
So I would need to create a whole different router to handle incoming API calls, right? Currently using react-router, so not sure how that factors in. Would be great to have a good blog post on this, so looking forward to it!
You would need a serverside only router for API calls. If you’re already using IronRouter you could use the server part of it or another one like Picker or simple:json. Basically if someone hits /foo.com/api/posts you send down all the posts in JSON.
Would be great to have a good blog post on this, so looking forward to it!
Great! If anyone else has ideas of what to include in the post that would be great.
Australia always missing out 