I’ve been meaning to write this piece for a long time yet I never got around to it. We’ve heard a lot of praise about our SDK’s design and it’s ease of use. The flux based architecture is a big part of that. The main post is on our docs but I also wanted to talk about a bit of history and the thought process behind it.
History
When I joined 100ms, I was primarily working on infrastructure and backend. I got involved in SDK and our user facing Web Apps as a helping hand to fix a bunch of performance and reliability issues we were facing at the time. The initial version of the SDK was a usual event based architecture and a bit of a mess. I felt that the SDK can have a much better abstraction layer seeing the complexity in the app. It felt like a perfect case for decoupling state and actions.
Ironically enough, I had never really used Redux or anything based on Flux architecture. I had not even used React for a long time, and most of my ideas were based on my recent experience with Angular. We were also already past our planned launch date and I was a bit hesitant to propose any major changes. I started with more research and creating an internal Doc for what I think should be done. I took a serious look at Redux but honestly couldn’t really make sense of it for using in a vanilla JS SDK. So I decided to build my own version of it. I started with writing down the requirements and design goals to keep things simple and focused. Howeever, before I started implementing it, I somehow landed on Zustand. It was exactly what I was looking for. It was simple, easy to use and had a very small footprint. I was sold. I used it with reselect to build a reactive layer on top of our event based core. It was a huge improvement and we ended up launching it as our primary API.