Why we use Redux design pattern across all platforms

Oursky produces apps that run on multiple platforms, but before adopting Redux, there was no common pattern to adhere to. Every project could have a different philosophy in how the data flow was implemented. Being the lead engineer at Oursky, one of my responsibilities is thinking about engineering management to minimise the mental overhead needed for developers to contribute to an existing project. Below, I will discuss why our company adopted the Redux design pattern across all platforms as a standard to cap the cost and complexity of projects.

Don’t repeat yourself
Though every project is different, the principles for good quality code are the same. Projects can follow a certain kind of principle so that a project can be kick started quickly. If we are working on many different platforms, there needs to be a method for syncing the expectation of a project’s code to reduce the cost of context switching. The Redux design pattern is versatile enough to apply to various platforms. Having a lower mental overhead allows other developers to just jump in and contribute, devoting their time to improving the code when rotating between projects.

Consistency
Without a standard, each person will come up with a different design pattern for a new project. It is not to say that Redux is the best design pattern, but rather that Redux is simple enough to understand and enforcing the use of Redux allows capped complexity in components. Redux as a design pattern frames each project enough so that engineers who work together on the same Redux Store (the single source of truth) and have the code merged cleanly. You can refer to this piece as a simple explanation of the Redux Store, Action, and Dispatch.

Recycling Resources
With the Redux design pattern, apps in different platforms have the same data flow, which means the requirements for APIs are the same. No platform specific API is needed. Improvement in one platform can be migrated to another platform, but it also allows for specific platform handling.

Leverages the power of a team
Once we expanded beyond our first hires to about 10-20 developers, we were taking on more projects and some with bigger scopes. One of the arguments for not expanding a company is that sometimes the additional effort on admin and processes isn’t worth the trouble. But having more team members also means we can take on more interesting projects together and share from a greater pool of knowledge. Adopting a standard allows team members to learn from each other because there is a common ground to approach a problem.

Drawbacks of Redux
Of course, Redux also has its drawbacks. For example, it can result in a lot of boilerplate code as a trade off with allowing collaborations among developers. In addition, there is no recommendation on how normalized data should be in the Redux Store. For example, a person’s name maybe broken into many parts: first name, last name, nickname. Should the Redux Store store the parts or the full name? If storing the parts, the UI needs to be smart enough to assemble a full name. If the Store stores the full name, the UI will not be able to show the first name only without data redundancy in the store. Finally, the Redux design pattern does not have a set way to solve the singleton problem.

Other design patterns that we have tried in the past and other developers can consider trying are VIPER in iOS, Model-View-ViewModel in Android and MVC in JS. If you have learnings and suggestions for us to try, please leave a comment and let me know!

If you found this piece helpful, give us some claps or follow the Oursky Publication for more startup/entrepreneurship/project management/app dev/design hacks! 👏

😻 At Oursky we’re all about helping brands and entrepreneurs make their ideas happen. Get in touch if you’re looking for a partner to help build your next digital product.