Architecture is the foundation, the skeleton, that sets your project up for success. It's the stuff that we wish we got right from the start because making drastic architectural changes, later on, can be challenging and time-consuming.
Today, we React developers have tools like Context, Hooks, Redux, and xState. We write code that deals with four or five different kinds of state. And we continuously debate ways to design your app to handle things like auth, state management, networking, app logic, and subscriptions.
Since there aren't a lot of "widely accepted standards for building React apps consistently, coherently, and with minimal risks to [developers'] professional reputations and livelihoods", we're often left to figure things out as we go (Joel Hooks, June 17th, 2020).
In this article, we'll discuss some client-side architecture basics. We'll very clearly establish the concerns we need to address at each layer of the architecture, which types of state we need to handle, and the role that Apollo Client plays.
<aside> đź’ˇ Disclaimer: While there are other ways to think about designing your application, working with state, and separating concerns, this is a conceptual model that we think works for most people. Even if it doesn't work for you, I hope it helps you guide conversations towards something that makes more sense for your team and your project.
As always, I'm always happy to chat about this stuff and answer questions on Twitter.
</aside>
When it's time to decide on tools and approaches we take to build apps, we use a mixture of logic and emotion.
Logically, we try to choose the best tool for the job. What's going to work? What won't?
Emotionally, what tools and approaches are going to make us feel good?
Humans tend to prefer tools that can not only accomplish the task, but that give us feelings of control, mastery, satisfaction, and even pride (from “The Design of Everyday Things" by Don Norman).
These are the kinds of tools that have great developer experience.
If we're forced to use something with a steep learning curve, rules, or seemingly unnecessary complexity and structure, it doesn't usually make us feel good. A lot of times, it can actually induce some pretty negative emotions.
This might be why some developer prefer React.js with its minimal learning curve, slim API, and feeling of freedom vs. one like Angular, with a steeper learning curve but a lot more guidance around how to structure your app.
Both tools are great. And you can accomplish the same things with both. Though one could say React affords a better developer experience and Angular yields more towards structure for enterprise applications. Both of these properties— structure and developer experience, are essential. Yet, they seem to conflict with each other.
Software design = structure vs. developer experience