Is It Possible to Connect a New Front End App to an Existing Meteor Server?

I’m building a React app that I’d like to connect to an existing Meteor server. How would I go about connecting that up?

Been searching for resources online everywhere and there don’t seem to be any examples of doing this, is it even possible without just copying the existing Meteor project and replacing the client code with my project? (I really don’t want to go down that path!).

There are different ways to achieve this all depending on your setup. If you use Apollo, you can just connect to the Apollo endpoint. If you want to use DDP, then you will have to use one of the DDP client libraries. Here are two that I found with a quick search on the forums:

1 Like

This was very helpful, thanks!

I recently published a new version of @socialize/react-native-meteor which includes changes to allow it to be used outside of React Native. It closely mirrors Meteor’s API and includes React Tracker integration.

The following code sandbox demos the package being used to connect to Atmosphere and grab the most recently published packages.

7 Likes

Wow, this is ultimately what I’ve been looking for! Thank you :smiley:

1 Like

This is a good idea.

I have been looking at SimpleDDP, Meteor React Native, and DDP client and they all share very similar code special the core for DDP implementation.

Meteor React Native seems active and we tested so it would and I was also thinking about forking it and adapting it to any React framework.

Yes, they do. @cloudspider is working on https://github.com/chris-visser/ddp which might be of interest, and progress is under way to break React Native Meteor functionality into a set of packages that closely mirror how Meteor is broken into packages. This will allow the Meteor API to be used in basically any JS framework or runtime that supports NPM. That work is going on here: https://github.com/Meteor-Community-Packages/meteor-api-untethered if you want to follow along or contribute.

4 Likes

There are also ways to build your Meteor code in to a bundle that can be used by third party frameworks like React Native, NativeScript or maybe even something like next.js. There was even an idea floated about using Meteor to actually build some of those projects directly, rather than trying to plug the output from Meteor into third party build processes this way, but there doesn’t seem to be enough people with enough knowledge of the build system around to make that happen.

1 Like

Great, I also like the fact that we’ve different initiatives on that front, it allows us to experiment and figure out the best path forward.

I think these projects are very important contribution to the Meteor ecosystem and they would open up the door for hooking up Meteor backend to the list of growing front-end frameworks and extending Meteor even further into the JS ecosystem.

I’ve added monthly sponsorship for this project which I plan to increase as we move along and I’ll try contributing to the repo as well thanks for starting this! I think the Meteor core team might also want to consider supporting these projects, needless to say they will boost Galaxy revenue :+1:.

Thanks for the sponsorship @alawi! :pray:

I agree wholeheartedly. There’s a huge opportunity to introduce Meteor to a much wider developer audience, and making the API available for use across the broader JS ecosystem is half the battle. On top of that it also widens the options available to us as current Meteor developers as well, so that’s a huge win also.

One other thing that I’d like to mention about this effort is that this could also open up the possibility of dual publishing certain meteor packages to both NPM and Atmosphere. Currently I use the @socialize/react-native-meteor fork with a bit of dependency injection to accomplish this with all of the Socialize packages so that they are available on NPM for use in React Native. The Server specific code that must run within a meteor server environment gets loaded only within the Meteor package, and for client code, Meteor, Mongo, etc are all supplied as args to functions that create closures that are executed in their respective environments. I’m not sure how many people find that interesting, but I think it has a lot of potential.

1 Like

How does authentication happen? Can you expand on that? In Meteor, you just import and use MeteorAccountsLink and it handles the logged-in user automatically. What about in the external app?