When my company was a lot younger with a less mature team, I remember having the best time with Meteor because I could write Isomorphic code and everything just worked. I didn’t think about performance, nor was I concerned about clean code, I was trying to build features as quickly as possible. It wasn’t until we hired some really experienced people, from companies that have scaled applications to millions, that we started to evaluate the complexity of isomorphic code. There is so much state that exists in modern applications these days. As our designs and UX ambitions increase, the state of our client side applications increase. As data and analytics become more important, the state from our domain/database/server increases. As full-stack developers, how do we manage this complexity? I think there exists a fine line between the Client and Server. After some horror stories with client/server performance in isomorphic states, our solution was to separate these states and provide clean public APIs to manage both of them independently.
But what is STATE?
The truth is, there isn’t just one “State” in an application. State comes in different types and it’s best we clear up these types so we can manage efficient web applications.
Domain State is the state of the server side of your application. It is the state of the application given the domain it is written for. Let’s say I am writing a web application for a Grocery Store, we could expect to find typical states in the application: authentication, validations, error states, but we would also expect to find state/data specific to the industry of Supermarkets. This is called Domain Specific Business Logic, which applies to business logic…