First take a step back and consider what your thinking about this holistically. My immediate questions I am going to ask you?
Why is rails not working for you ?
Why are the Android and SPA apis so different? You can support multiple auth endpoints. Long term your adding technical debt by having two api stacks.
Your already running a copy of the stack for each customer. What are your pain points that’s require this? How could you address these?
You already have redis which will handle most use cases you have for Rabbit, Kafka or NATS. Look at he the thing you know before jumping into something new. (Also don’t use rabbitmq rpc calls please)
If this is a hobby project make sure what your doing is actually achievable or your going to feel like you failed.
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.
First take a step back and consider what your thinking about this holistically. My immediate questions I am going to ask you?
Why is rails not working for you ?
Why are the Android and SPA apis so different? You can support multiple auth endpoints. Long term your adding technical debt by having two api stacks.
Your already running a copy of the stack for each customer. What are your pain points that’s require this? How could you address these?
You already have redis which will handle most use cases you have for Rabbit, Kafka or NATS. Look at he the thing you know before jumping into something new. (Also don’t use rabbitmq rpc calls please)
If this is a hobby project make sure what your doing is actually achievable or your going to feel like you failed.
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.