Designing Around Client Logic & Patterns of Web Applications

Designing around client logic

As a web application begins to act more like a desktop application, the application starts to maintain a lot of state and logic that only pertains to the user interface. It doesn’t always make sense to manage the client-only information and logic on the server, and so JavaScript applications in the browser become more and more complex.

The user interactions managed by JavaScript are not, by and large, effectively modeled as CRUD resources. Single page app JavaScript frameworks have different concerns, and as a result have structured themselves quite differently than server-side Rails applications (you see this in the rise of tools like GraphQL, which is an alternate structure for managing resources).

For example, a primary concern of JavaScript application frameworks is managing the state of the objects and data being interacted with on the client. Frameworks often emphasize having a lot of relatively small constructs that manage the data and logic for a small part of the page. Therefore, a problem in a lot of client-side app frameworks is sharing common state information among otherwise unrelated small components across the page.

On the server-side, sharing common state is not a concern in the same way. A server-side Rails app stores global state in the database and generally doesn’t worry about the mutability ...