Thank you, Kevin, for your questions. Here are my answers...
Rails is actually working very well for me. I don't want to get rid of rails. But the app grew bigger and bigger, because I added new features in the UI and always used a quick way (short-term) for the implementation. So I was afraid of architectural changes for too long.
The Android UI targets different users (a different business role) than the SPA. There's not much overlap in the objects these 2 APIs handle, so I think splitting the DB for the 2 APIs into separate DBs would be rather easy.
Great question! It all started with data separation between the customers (a requirement from one of the first customers), but it turned out to be invalid. So there's no need anymore to run a copy of the complete stack for each customer. However running a copy of the complete stack provides a great feature that I don't want to lose: I can upgrade the apps for some customers only (i.e. one customer is a beta tester) while the others stay on an old version.
Uhm... not quite, at least not in the way I currently use these products. Redis is currently only a (temporary) key-value store and each instance has its own namespace. There's no communication between the instances in Redis. I came up with messaging systems, because I see the opportunity to optimize some parts of the whole system with the help of a pub/sub message bus. And I think the full potential of said message bus will unfold after splitting up my monolith.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you, Kevin, for your questions. Here are my answers...
Rails is actually working very well for me. I don't want to get rid of rails. But the app grew bigger and bigger, because I added new features in the UI and always used a quick way (short-term) for the implementation. So I was afraid of architectural changes for too long.
The Android UI targets different users (a different business role) than the SPA. There's not much overlap in the objects these 2 APIs handle, so I think splitting the DB for the 2 APIs into separate DBs would be rather easy.
Great question! It all started with data separation between the customers (a requirement from one of the first customers), but it turned out to be invalid. So there's no need anymore to run a copy of the complete stack for each customer. However running a copy of the complete stack provides a great feature that I don't want to lose: I can upgrade the apps for some customers only (i.e. one customer is a beta tester) while the others stay on an old version.
Uhm... not quite, at least not in the way I currently use these products. Redis is currently only a (temporary) key-value store and each instance has its own namespace. There's no communication between the instances in Redis. I came up with messaging systems, because I see the opportunity to optimize some parts of the whole system with the help of a pub/sub message bus. And I think the full potential of said message bus will unfold after splitting up my monolith.