Nick Skriabin

Initially, we were running our infra on an OpsWorks as we had some (very little, to be honest) experience with it. Unfortunately, it's really hard to scale OpsWorks without good knowledge of Chef, so we moved to EB. Everything was ok with it unless we faced an unexpected downtime one day and we were unable to identify the problem. Access to logs was locked and instances were severe/degraded and stuck in this state, deploys didn't work and the whole service was down and frozen. At this point we decided, that its a great time to move to Docker and EKS. Luckily, at current scale it took not so much time to containerize server app and launch it on EKS – we migrated to EKS within 2.5 full days.

Wrapping up: lack of good knowledge of Chef and poor reliability and accessibility of AWS EB forced us to move to EKS which works perfectly fine now and covers all our needs, plus it is much more flexible and reliable in terms of scalability and management. We now can track everything that happens with infra with no pain, integrate any additional logging solutions and be sure, that even if something go wrong, we'll be able at least identify the problem and fix it ASAP instead of trying to fight with the service itself.

We built the first version of our app with RN and it turned out a mess in a while. A lot of bugs along with poor performance out of the box for a fairly large app. Many things, that native platform has, cannot be done with existing solutions for RN. For instance, large titles on iOS are not fully implemented in any of existing navigations libraries. Also there's painfully slow JSON bridge and many other small, yet annoying things. On the other hand Flutter became a really powerful and easy-to-use tool. A bit of a learning curve, of course, because of Dart, but it worth learning. Flutter offers TONS of built-in features, no JSON-bridge, AOT compilation for iOS.