React Native + Meteor Backend

help
1

I’ve been working with Meteor for a long time, and I hate to say that Cordova is a fundamentally bounded technology. It simply won’t suffice for our mobile app. That said, Meteor’s backend has been wonderful.

For those of you that have been working with React Native and Meteor for a while (ping @SkinnyGeek1010, @jitterbop, @spencercarli) , it’s been quite a while since some of the older discussions. Are there any must-have packages that are needed to make connecting a RN app to a Meteor server much easier? What are some common pitfalls to avoid? I would rather not write my own DDP client, or my own client-side react database.

https://www.npmjs.com/package/react-native-meteor


Are you using any of these packages, and how was the integration like? Did you end up using Redux as a reactive store instead of something like a minimongo cache? These packages seem to adhere to the pub/sub mongo collection paradigm as opposed to something like GraphQL. Have you dropped these packages because of this? Regarding performance, are there notable improvements to using RN+MeteorBackend instead of full stack Meteor?

Thanks, looking forward to all responses.

2 Likes
2

If other ppl want more info, this post helped point me in the right direction: Support for React Native bundle with Meteor

3

None that I can think of that you have to have. One might be using the fetch API that is going to be the new standard for AJAX requests. This is built into new browsers and also RN. This isn’t a Meteor type of package but a new one that’s popped up. It also ties in with my suggestion for simple-rest below. Also using promises (and promise based NPM packages) in RN will make life easier, this is something new to Meteor users.

What are some common pitfalls to avoid?

Unless you really have to move quickly I would think twice about heavily coupling your RN to a Meteor backend. Not only are you tied to Meteor’s pub/sub system but the maintainers of any libraries you’re using.

Using tightly coupled tools can also lead you to having an unscalable app for no reason. For example in Meteor land it’s quite common to use a subscription for everything, whether it needs to reactively update or not… but this is a very inefficient way to do this (mostly because Meteor makes it hard to get non-reactive data). However, with RN and something like fetch or request, you can just make a normal REST API request to the Meteor server and have the API route return a Meteor method result or whatever a publication would have normally have returned. simple-rest can also handle login by providing you with the meteor login token.

It also depends on how much of your content is reactive. If you only have one thing that’s reactive and the rest can be updated manually I would use some of the simple-rest packages to use AJAX to fetch things the “normal” way and then use the Meteor specific subscriptions (with react-native-meteor or ddp-client) to setup a subscription as needed.

If you’re using a React app, Redux works really well for sharing state across components:

But i can totally understand if this is overkill or overloading the learning curve. There’s also GitHub - petehunt/minimongo-cache for a minimongo experience. If you haven’t learned redux yet and it seems daunting, mobx has had good reviews (I have’t tried it… happy with redux) MobX

Are you using any of these packages, and how was the integration like? Did you end up using Redux as a reactive store instead of something like a minimongo cache?

Started out with the first version of node-ddp-client and it was overkill for what I needed. I opted for long polling to get it out the door (reliably). I’ve tried minimongo cache and found that I created spaghetti and was hard to track data flow. I’m using redux with only the logger middleware, no dev tools. I like to keep it simple and prevent yak shaving.

Regarding performance, are there notable improvements to using RN+MeteorBackend instead of full stack Meteor?

Things are easier to maintain IMHO. I don’t like implicit magic as it’s caused more problems for maintainability (even though it makes the first weeks faster). Animation performance compared to Cordova is night and day. Things just work, unlike Cordova’s flaky API. No one has asked me if it’s a web/react-native app… while on Cordova several people would ask if it was a hybrid app.

Good luck :thumbsup:

1 Like
4

I don’t know if I can add much more to @SkinnyGeek1010’s answer! I’m on pretty much the same page as him.

However I would say the react-native-meteor is a must, even if it’s just for the easy integration with the accounts system. It makes it incredibly easy.

We’re also using Redux for a client side store in RN - though it does have a learning curve. The only thing different that we’re doing is using Meteor Methods directly from the RN app (via the API exposed in react-native-meteor) to fetch data rather than using fetch and server routes.

Here are a few blog posts that touch on my experience/thought on RN + Meteor

There are also other posts on my Medium profile that may be on interest to you :slight_smile:

4 Likes
5

Thanks for the great responses. I would try to adhere to Meteor methods / subs as much as possible without using a new API. I think react-native-meteor is the way I’m gonna go. The minimongo cache by Pete Hunt looks to be NRFP as stated in the readme. Redux looks interesting, but I think it might be overkill for now.

Edit: It looks like react-native-meteor uses minimongo-cache under the hood…

1 Like
6

It seems like you ditched the ddp client? How do you handle Auth to Meteor server? Manual implementation of resume tokens, with RN’s persistent storage?

1 Like
7

How do you handle Auth to Meteor server? Manual implementation of resume tokens, with RN’s persistent storage?

simple-rest has an accounts package that allows you to do this pretty easily. However, OAuth is not currently implemented so that could be a hassle if needed. You can POST /users/login with ajax, passing in the username/email and password and then you get back a response:

{
  token: "string",
  tokenExpires: "ISO encoded date string",
  id: "user id"
}

Then you can store this token on disk and then use it for future requests:

// call a meteor method you already have setup

HTTP.post("/methods/getPost", {data: "1234"}, {
  headers: { Authorization: "Bearer " + token }
}, function (err, res) {
  // update state with new data
  console.log(res.data); // {title: "Hello World"}
});

more info:

The part I really like is that i’m not as tied to Meteor accounts since the login token can be swapped out with a JWT and the app could authenticate with any API. The example above is calling the methods endpoint (via simple-rest) but you could also use a RESTful route and a router (but that makes it harder to use with a vanilla Meteor app).

FWIW the main reason I don’t want to be heavily coupled to publish/subscribe and Meteor methods is because Meteor’s data layer is churning some (for the better I believe) and I would rather do a bit of work now than a lot of work to change it later.

2 Likes
8

I’m bumping this, see the other bump below.

I’ve finished writing this library, which uses DDP. GitHub - Streemo/react-ddp: ddp client with subs, methods, minimongo supported without much work (see readme), will not make minimongo a dep.

After the Meteor Camp at NYC a couple of weeks ago, it seems like the Meteor community is going to be ditching DDP in a year or two (according to Arunoda’s ‘predictions’). I am almost certain that (for RN at least) this will be the stack to use:

React-Native + Apollo (Redux) + GraphQL + Meteor Server for mobile. I am unsure of how the Browser + Meteor Server will evolve… Will DDP be thrown away in web-apps as well? Right now, it’s the default data transport layer. With RN + Meteor, DDP isn’t even the default, so it makes more sense for it to get tossed out of the equation there. Nevertheless, I spent some time implementing a very simple DDP library built on top of mondora’s DDP client. It assumes user accounts, and that’s it. No assumptions are made about data storage (Redux, Minimongo-cache, etc.)

For more information on the library, see:

2 Likes