Client-side architecture basics:
🖼️ Presentation components - presents data, creates user events
🤾‍♀️ Interaction layer (hooks) - invoke logic against models
⚙️ Infrastructure layer - manage models in data store(s)
📦 Container/controller layer - glues features together
For Redux users, the Redux store would be a part of the Infrastructure layer. It's essentially the client-side database.

Action creators/thunks are the Interaction layer because it contains the closest thing we have to "business logic" on the client-side (interaction logic).
With Apollo Client- AC is fundamentally the entire Infrastructure layer. Where we would normally need to write the plumbing to fetch and update our data using Redux or another state management library, with AC, much of it is already done for us. https://twitter.com/stemmlerjs/status/1247256046860668929
On a side note, I'm really interested in talking to people who are using Apollo Client on large-scale React apps as well. I'm curious about how you keep productive at scale or if you're having issues. Please DM me!
This "architecture" is essentially just implementing Separation of Concerns. You may ask why this even matters. Your code works.

It's about being able to isolate code so that it can be easily tested. It's hard to test Interaction logic when it's coupled to Infrastructure.
I've found that on very large projects, having a clear understanding of which layer a particular construct, class, or function belongs to, simplifies the conventions as to how it may (or may not be used), as well as what it is allowed (or not allowed) to know about.
I really do believe that this is the common architecture that every large-scale client-side architectural stack ends up building in one way or another- it's just the tooling that's different. If you have doubts, questions, or other ideas, please feel free to poke at it.
You can follow @stemmlerjs.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: