Hi there,
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?
This is not the approach Meteor takes, but one of the guiding principles of scalable architecture is to make your app servers stateless - that way they can scale horizontally vs vertically (which is much more expensive and not feasible without limit).
Microservices are a good fit and are possible with Meteor, actually very nicely since everything can use DDP and method calls.
The problems will come with data access and scaling pub/sub once traffic increases - that’s why there are solutions like Redis Oplog etc.
Not sure why you don’t want to share the database - DB are designed to be used my multiple users and if there is too much load on the database, they are designed to be sharded (NoSql ones like Mongo especially). And if that is still not enough you add a cache layer on top like Redis.
1 Like
I also think that DDP is not a bad choice for microservices. Though I think some advantages of Meteor won’t take effect when designing a microservice architecture. Anyway, in a current project I’m working on, write actions are done via REST and Meteor still is a help.
Scaling would be also an issue when having only one full-stack app. So there you need to find a way to work around. And your hint to Redis Oplog seems to be a good option.
The point why I don’t want to share the database is that I think it makes scaling hard because:
- You need to scale the whole DB at once, not just the one that needs more power.
- You need some kind of code sharing. Imho at least database schemas should be shared.
- Shared responsibility.
- Since there is no separation I think it will be hard to separate out parts later on if necessary.
In the first step I would start with those three apps I mentioned. My hope on this approach is that it makes it easier to build microservices later if needed. I’m pretty convinced that microservices absolutely make sense, but when building a complete microservice architecture from the start will massively slow down the development speed and brings lot of complexity into hosting and deployment.
I try to find a good balance to starting fast and being maximal flexible to extend the system later.