I’m currently evaluating an architecture to build an extensible and scaleable product. The key aspect is that there will be at least two frontends: One App for the customer and one for the business partners – both communicating with each other.
Eventually there need to be some admin interface for managing both: customers and businesses, showing statistics, etc. Also I can imagine that one day we will split the user app into two – one for the web, one for native Android / iOS.
Since I’m currently working in a company which is teaching building products around micro services, I was also thinking about this approach. But probably this might be too much overhead in the beginning. Still, I think this should be a way to scale the product later. E.g. if one part is consuming a lot of power we could move that out into a separate service.
For the first version of the product we need to be quite fast, also considering we are only few people (well, currently it’s only me). That’s why I thought of Meteor.
Now I’m thinking how to achieve the requirements best (with Meteor).
I searched the internet for resources explaining how to connect multiple Meteor apps, how to scale etc. Still I’m not quite satisfied. Most of what I found are concepts from latest 2015, couldn’t find any new studies.
My current approach is to have two frontend apps and one backend and connect to the frontend to the backend. I already tested it with DDP and that works quite well. Although I loose Otimistic UI features since method calls can’t be simulated client side. Maybe there is a way around?
Ideally I want to host everything on Galaxy, don’t want to have all the deploying hassle.
What I don’t want (but what many concepts are that I found):
- Sharing the same database
- Sharing code (e.g. with Symlinks)
So the questions are:
- What do you think could be a good approach?
- Is there someone out there who had similar architecture solved?