Hello,
I’ve build an app that is getting larger and larger everyday.
We are starting to build mini-games with phaser.js : I don’t want to put everything in the same app for numerous reasons :
- The bundle is getting really heavy
- Build time are very long
- It makes it harder to work on it with several developers.
So I want to have 2 meteor apps, with their own repo for each :
Let’s name them app & games.
Most of the code would live inside app, including the landing page
But when going on the url baseUrl/games/:gameID, I want you to end up on games, but every other baseUrl/X would be on app.
Questions :
- Database will be shared, and is hosted on compose.io, is there any pitfall I must be aware of ?
- How would you manage routing for this kind of separation ?
- Does this architecture makes sense to you ?
- How would you manage communication between apps ? (I am thinking about wrapping DDP.connect(url) to match my
needs)
Thank you !
This will be your single point of failure and your first scaling pain point. As long as you know the writes per second are low enough, you should be ok.
You could probably use nginx to detect the different url paths and pass the requests to one app or another, using multiple location blocks and proxy setup. E.g.
location / {
proxy_pass http://main_app
}
location /games {
proxy_pass http://game_app
}
This would allow you things like emails, ROOT_URL, etc are all consistent across both apps, domain-wise.
Maybe, but you should know things will likely change with apollo getting more code every day. It might make a lot more sense to look at Apollo for this type of concern. Sharing a db is actually an anti-pattern for microservices, but the issue is there is no good way to share authentication across DDP connections unless you share the DB or make your own API token system.
Again, once you need authentication for data across DDP.connect calls, your life will get a little more painful and you will need something like @ianserlin DDP token library.
3 Likes
The lib Josh was referring to is here: https://github.com/usefulio/api-base However, while you might use it as inspiration, I would suggest doing a JWT exchange over the wire instead of an api key. You could have a central auth authority service for your ecosystem as well if you didn’t want to share databases between your microservices.
3 Likes
Thank you for your answer !
Thank you for your answer Josh !
1 Like
This is very much how feathers.js is doing things. Have you tried using a JWT setup with Meteor yet, @ianserlin?