Hi guys. So in our company we have a php tool with a hostgator server and sql dbs as usual. And I am developing an app with meteor and react. They want the app to be a feature of the above mentioned php too. So as far as I get this brings a lot of issues because of server, hosting, db incompatibilities. So what do you think of this situation? What solutions are there?
One solution that comes to my mind is to put my app in a proper meteor hosting place and then somehow to connect it to the sql db of the php tool, is it possible? Here probably the most important thing is to get user accounts from the sql db. Some googling and research makes me think that it can be done with Apollo but it’s confusing since I never used graphQL.
Or maybe it would be best to start everything from 0 with meteor? (Not sure if the company will accept this but maybe I can convince them)
So what solution would you think of if you were in my situation?
You haven’t mentioned what SQL db you’re using. However, the odds are good that there’s an npm package for it - which means it will work with Meteor (and Apollo/GraphQL). You will need to ensure that there’s suitable network connectivity - either a secured public IP, or a VPN between your DB and Meteor app server.
Getting the accounts won’t be a problem if you can connect. Do you intend using those accounts as Meteor user accounts also? You may have some challenges in that case.
Yes that what I was afraid of. I don’t just need pull users from that db and put them in meteor users db, I need to use those accounts for my app as well.
If you need reactive mysql, that’s a good package - I’ve used it myself and it works well. However, you do need to configure it as a replication slave off your main db - which means that if your db does not currently run in a replicated configuration, you’ve also got to reconfigure that as well.
If you don’t need reactive mysql, there’s plenty of choice on npm, such as this one.
I am not sure if I’m aware of the replicated configuration so probably we’ll need to check that one out.
One more question Rob, if you do not mind of course.
Wouldn’t it better just to go with the Apollo? As far as I get it’s designed for situations like this, isn’t it? And since I can request some learning time, I think it will be more beneficial later on, what do you think?
If you want livedata (out of band database modifications drive UI changes on your app), then you probably don’t want Apollo (yet).
If you want mysql access, either Meteor or Apollo (or GraphQL), or Meteor with Apollo will deliver.
If you want external user accounts which are used by a Meteor application in place of its inbuilt MongoDB accounts, then you can use either, because both will be equally challenging.
If you want to get on the front foot with the future data layer of Meteor, then go with Apollo.