IV. Conclusion

Last updated Jun 24th, 2020

This is page four of a guide on Client-Side Architecture basics. Start at page one.

The work isn't over

I know this article expressed a lot of new ideas. To be completely honest, I spent about three months thinking about this off and on, and I'm likely going to spend some time revising it and trying these ideas out with real-world projects.

Stay tuned for updates on this. If you subscribe to the newsletter, I'll let you know when I publish major updates.

Let's look at what we've covered.

A new client-side development philosophy

Zooming out, we started with this:

img/blog/client-side-architecture/Untitled.png

And then zooming in, we landed on this:

img/blog/client-side-architecture/Client-side_architecture_basics_(5).png

Let's recap the statements I've made.

Model-View-Presenter isn't good enough for our needs anymore

The problems we're solving on the client-side are much more complex than they were 20 years ago. Because of that, the starting point for an architecture probably can't be MVP.

Design principles have persisted for a long time to help us write better software

I honestly think that reading books and learning from the past is one of the best ways to avoid future mistakes. Design principles are great. You don't need to always follow them, but know the rules before deciding whether you want to break 'em.

There are no silver bullets

There really aren't. With this advanced client-side architecture, what we introduce in structural quality, we lose in developer experience based on the potential learning curve involved. But ask yourself this question: is the complexity related to nature of the problem itself, or is it just related to the way we're solving it?

This is for developers where "use what works for you" is daunting, and would like a good conceptual starting point for an air tight React architecture

I'm really excited about these ideas. I've been milling around with this for a couple of months now but I think it's really important today. If you're a developer that has been told to use "what works for you", that's still incredibly good advice. But if you run into any of the pain-points in your React project like suddenly facing issues adding features, changing code, and feeling like things have turned to mush, this might help.

Next steps

We shouldn't stop here. Here are a few thoughts to chew on. Feel free to ask questions and leave suggestions on ways I can make this guide more helpful.

Choosing a stack: Given this philosophy, what factors into deciding upon a stack? Compatibility? Developer experience? Maintainer(s) activity?

Organizing code: How do you organize code within a React project? What principles are at play?

Dealing with prop drilling: If we have these clear-cut layers, doesn't that mean we'll have to do a lot of prop drilling?

Test-Driven Development: Can we discuss testing in more detail? What does a test-driven approach to client-side application development look like in 2020? Should we write BDD-style acceptance tests with React Testing Library and Jest? Or should invest into testing for functional correctness using E2E tools like Cypress.io?

Real-life project: What does this look like in practice?



Discussion

Liked this? Sing it loud and proud πŸ‘¨β€πŸŽ€.


5 Comments

Submit
Wataru
a year ago

Hi, this series of posts are really great. I have been thinking how to change our code base to be testable/maintainable. Sadly it’s not React but your posts inspired me a lot.

I will make some proposals and share with the team shortly.

thank you so much!

Jonathan Celio
10 months ago

Awesome posts!

I wonder how could be a real life app using this architecture.

Javier
7 months ago

Hi Khalil, the past months I've been struggling and squeezing my head around how to apply a clean architecture to the front-end, I really want to say THANK YOU, you are definitely connecting all the dots of my mental graph, not only with this serie, with your whole blog.

Nick Z.
4 months ago

Wonderful. Here goes another piece of internet gold.

Juan Villegas
3 months ago

Solid advice here, keep these coming!


Stay in touch!



About the author

Khalil Stemmler,
Developer Advocate @ Apollo GraphQL ⚑

Khalil is a software developer, writer, and musician. He frequently publishes articles about Domain-Driven Design, software design and Advanced TypeScript & Node.js best practices for large-scale applications.



View more in Client-Side Architecture



You may also enjoy...

A few more related articles

Client-Side Architecture Basics [Guide]
Though the tools we use to build client-side web apps have changed substantially over the years, the fundamental principles behind...
How to Test Code Coupled to APIs or Databases
In the real-world, there's more to test than pure functions and React components. We have entire bodies of code that rely on datab...
How to Mock without Providing an Implementation in TypeScript
Having to provide an implementation everytime you create a test double leads to brittle tests. In this post, we learn how to creat...
When to Use Mocks: Use Case Tests
Mocking gets a pretty bad rap. However, if you're building an application using object-oriented programming and you're making use ...

Want to be notified when new content comes out?

Join 10000+ other developers learning about Domain-Driven Design and Enterprise Node.js.

I won't spam ya. πŸ–– Unsubscribe anytime.

Get updates