GraphQL is the latest API style on the block. It's a modern way for us to pull data out of your system (queries) and make changes to your system (mutations). I'm finally committing to learning everything GraphQL in 2020. In this article, I'll break down my personal learning roadmap.
Eric Evans' "Domain-Driven Design" and Uncle Bob's "Clean Architecture" are books that have introduced tactical approaches towards building complex enterprise applications. Given the fact that we implement ideas from both, in this article, I'll aim to clear up any confusion between parallel topics introduced from both.
By using TypeScript's static type system, not only can we enforce (typically challenging things like) business rules and error states, but we can create a domain-specific language so well-defined that it becomes virtually impossible for any future code to be written that puts the system in an illegal state.
Features represent the essential complexity of software design. It's the complexity that can't be avoided. Everything else โ the languages, tools, patterns, etc โ are a form of accidental complexity. Therefore, to write the simplest possible code (regardless of which side of the stack we're on), we should take a feature-driven approach. It influences the way we structure our projects, write our tests, and package modules, and design features.
A GraphQL schema is a declarative, self-documenting, organization-wide API. It's pretty important to spend a little bit of time on getting it right. However, unless you're a domain expert, that can be hard to do. In this article, we'll look at an approach to GraphQL schema design that involves both non-technical domain experts and developers.
Mocking gets a pretty bad rap. However, if you're building an application using object-oriented programming and you're making use of a layered architecture, mocking can be a very valuable aspect of a larger testing strategy.