Original Japanese text: https://qiita.com/koriym/items/72212281ad3d773b8ef0
Moderation (Mesotes) - Designing Resources with Appropriate Granularity
This is the article for Day 5 of the BEAR.Sunday Advent Calendar 2024.
Introduction
In previous conversations with AI, I made a fascinating discovery.
From Aristotle to modern programming paradigms, there is a profound continuity in how humanity understands the world. This suggests that humanity’s intellectual development is not merely a series of disconnected innovations, but rather a cumulative and organic process. I also realized that seemingly different fields—philosophy, history of science, cognitive science, and computer science—are deeply interconnected at a fundamental level.
Based on this idea, I want to explore through dialogue with AI the deep human wisdom behind the design principles of BEAR.Sunday. Today’s theme is “Moderation (Mesotes) - between cowardice and recklessness.”
Before Writing
Koriym:
Before we start writing, let’s look back at what we’ve covered so far.
Calude:
Yes, in the two articles so far, we have gained extremely deep insights. Let’s briefly review them.
On Day 1, “Form and Matter”:
- Form (Eidos): The essential state or concept of a resource
- Matter (Hyle): The concrete representation format (JSON, HTML, etc.)
We approached the essence of REST through this dualistic framework.
On Day 2, “The Four Causes”:
- Final Cause (Telos): The reason and mission for a resource’s existence
- Formal Cause (Eidos): The essential structure of the resource
- Material Cause (Hyle): The specific implementation format
- Efficient Cause (Kinesis): The principle and process of change
We re-examined the reason for a resource’s existence from these four perspectives.
Key discoveries included:
- REST is not just about CRUD operations; it’s an architecture that maintains consistency throughout the entire system.
- Extensibility and flexibility are not mere additional features, but essential requirements of software.
- The goal (Telos) does not function as a static endpoint, but rather as a dynamic direction or mission.
Based on these understandings, on Day 3 we move on to consider resource design from a new perspective: the “virtue of moderation.” Aristotle’s concept of “moderation” suggests that avoiding extremes and finding the proper balance can offer important hints for modern software design as well.
Koriym:
From the previous two dialogues, I have come to understand that resource design, or rather software design as a whole, is not only within the scientific and technical realm, but also a philosophical pursuit. Identifying what the domain is, what the proposition (Telos) is, and what the form (Eidos) required to achieve that Telos is—these are indispensable. I understood that DDD is a modern software interpretation of these philosophical concerns, and that resource design imposes certain constraints on it.
Calude:
Yes, that insight is profound. Through the previous dialogues, it has become clear that software design surpasses mere technical endeavors and demands deeper thinking and exploration.
What is especially striking is that before making technical decisions, philosophical inquiry is needed about domain and resource design. The question “What is essential, and what are we aiming for?” aligns closely with the fundamental questions Aristotle explored.
DDD is a modern expression of that philosophical pursuit, and resource design provides clear constraints and direction within it. This perspective reminds those of us who could be buried in technical implementation details of the importance of more essential questioning.
The theme of “the virtue of moderation” today must be considered precisely in this context. Designing resources with appropriate granularity may not be merely a matter of technical optimization, but may require a deeper principle-based judgment.
With this understanding, shall we begin writing today’s article?
koriym:
Yes, please!
(From here is the AI’s writing)
Moderation (Mesotes)
Over the past two days, we have used Aristotle’s thought as a guide to approach the essence of resource design. On the first day, through the dualism of Form (Eidos) and Matter (Hyle), we delved into the essence of REST. On the second day, using the Four Causes, we questioned the reasons for a resource’s existence.
Today, we consider the concept of “moderation (mesotes)” from Aristotle’s Nicomachean Ethics. This is not simply about “taking the middle ground.” Aristotle’s moderation (mesotes) carries a deeper meaning. It refers to the “optimal state” discovered through judgments based on “practical wisdom (phronesis).”
The Essence of Practical Wisdom
Aristotle believed that human intellect comes in different forms. Among these, he placed special emphasis on “practical wisdom (phronesis).” This differs from mere theoretical knowledge or technical skill. It is the ability to judge what is most appropriate in concrete situations.
For example, consider the virtue of courage. Courage is understood as a “moderation” between the deficiency of cowardice and the excess of recklessness. However, the “appropriate state” varies greatly depending on the situation. Appropriate courage on the battlefield and appropriate courage in everyday life manifest very differently. The same action might be courage in one context and recklessness in another.
The important point is that this “appropriateness” is not a simple arithmetic midpoint. It requires a judgment formed by a deep understanding of the essence of the situation. This is the very essence of practical wisdom (phronesis).
Practical Wisdom in Resource Design
Aristotle’s insight offers a surprisingly relevant hint for modern software design, especially when deciding on the appropriate granularity of resources.
As developers, we face the judgment call every day: “To what extent should this resource be defined in terms of size or detail?” At a glance, this seems like a technical issue. But when we probe deeper, we find it’s more than a mere technical decision.
Determining the appropriate granularity of a resource requires precisely the kind of practical wisdom (phronesis) Aristotle described. This is because the decision involves extremely context-dependent factors. There are essential structures of the business domain, technical constraints of the system, the team’s development setup, operational requirements, and future scalability. These factors often present conflicting demands.
A smaller granularity might increase maintainability but reduce performance. A larger granularity might improve efficiency but impair reusability. Making the best judgment in the face of these conflicting requirements is the very essence of practical wisdom.
Practical Wisdom Supported by BEAR.Sunday
In response to these practical challenges, BEAR.Sunday offers a unique solution. Central to this is the #[Embed] annotation. This feature remarkably realizes, in technical form, the principle Aristotle described as moderation (mesotes).
Consider the order process. The concept of an order inherently involves multiple concerns: customer information, order items, payment information, shipping information. These elements are independent concepts, yet within the context of an “order,” they are closely related. How should we represent these relationships?
class Order extends ResourceObject
{
#[Embed(rel: 'customer', src: 'app://self/customer{?id}')]
#[Embed(rel: 'items', src: 'app://self/order/items{?order_id}')]
#[Embed(rel: 'payment', src: 'app://self/payment{?id}')]
#[Embed(rel: 'shipping', src: 'app://self/shipping{?id}')]
public function onGet(string $id): static
{
$order = $this->repository->find($id);
$this->body = [
'id' => $order->id,
'status' => $order->status,
'created_at' => $order->createdAt->format('Y-m-d H:i:s'),
'_links' => $this->hypermediaLinks->getOrderLinks($id)
];
return $this;
}
}
The profound meaning of this design lies in simultaneously achieving both the independence of each resource and their interrelationship. Each element (customer info, order items, payment, shipping) exists as an independent resource, yet through #[Embed] and HAL, they are organically linked.
HAL’s hypermedia representation treats the relationships between resources as more than mere references. It embodies the very essence of the web: “discoverability” and “self-descriptiveness.” A client, using the provided links, can discover and obtain the necessary information as needed.
This flexibility mirrors exactly what Aristotle’s “appropriateness according to the situation” means. The client can fetch the entire combined resource when needed, or directly access each individual sub-resource. Such choice is optimally made according to the usage context.
The Practical Benefits of Moderation
Even more interestingly, this idea of achieving the “appropriate balance” deeply reflects in BEAR.Sunday’s event-driven cache mechanism as well. This caching system automatically maintains cache consistency based on the dependencies between resources expressed by #[Embed]. When a certain resource changes, the cache of all resources that embed it is recursively purged.
This sophisticated mechanism is possible precisely because BEAR.Sunday embodies the idea of moderation (mesotes). Resources are independent entities (forms), yet maintain appropriate relationships via #[Embed]. With the presence of both independence and interrelationships in an exquisite balance, exact dependency awareness is possible, enabling automatic cache consistency maintenance.
Moreover, this dependency-based cache control is realized through AOP, allowing individual resources to focus on their essential responsibilities. From Aristotle’s perspective, this can be seen as a modern implementation of practical wisdom (phronesis). Each resource dedicates itself to the realization of “appropriateness” within its context, while the system’s overall consistency is automatically maintained through the proper expression of their relationships.
Practicing Contextual Judgment
Just as moderation (mesotes) is context-dependent, the appropriate resource granularity changes depending on the situation. Consider how user information is handled. The appropriate granularity differs if it is provided as a public API or used internally for management functions. Even though it’s the same user information, the suitable granularity differs by context.
// User information as a public API
class PublicUser extends ResourceObject
{
#[Embed(rel: 'basic_info', src: 'app://self/user/public_basic{?id}')]
#[JsonSchema('user/public.json')]
public function onGet(string $id): static
{
$this->body = [
'id' => $id,
'member_since' => $this->repository->findJoinDate($id)
];
return $this;
}
}
// User information for administration features
class AdminUser extends ResourceObject
{
#[Embed(rel: 'basic_info', src: 'app://self/user/full_profile{?id}')]
#[Embed(rel: 'preferences', src: 'app://self/user/preferences{?id}')]
#[Embed(rel: 'activity_log', src: 'app://self/user/activity{?id}')]
#[JsonSchema('user/admin.json')]
public function onGet(string $id): static
{
$this->body = [
'id' => $id,
'internal_status' => $this->repository->findDetailedStatus($id),
'admin_notes' => $this->adminService->getNotes($id)
];
return $this;
}
}
The difference in this design means more than a technical choice. It reflects the essential difference in the nature of “appropriateness” in each context. For a public API, considering security and performance, providing only the minimum necessary information might be appropriate. Meanwhile, for administrative features, operational needs may demand more detailed information and a wider range of interactions.
Fostering and Evolving Practical Wisdom
Aristotle stated that practical wisdom (phronesis) cannot be acquired by simply memorizing rules or mechanically applying them. It is cultivated gradually through experience. The same applies to judgment in resource design. And BEAR.Sunday’s design supports the process of growth in a natural way.
Let’s consider the evolution of product information management:
/**
* Initial design: Basic product information
* - Focus on understanding the essential concept
*/
class ProductResource extends ResourceObject
{
#[Embed(rel: 'basic', src: 'app://self/product/basic{?id}')]
#[JsonSchema('product/basic.json')]
public function onGet(string $id): static
{
$this->body = [
'id' => $id,
'status' => $this->repository->findBasicStatus($id)
];
return $this;
}
}
/**
* After gaining experience: richer context
* - Reflect deeper understanding of the business
* - Incorporate lessons from operational experience
*/
class ProductResource extends ResourceObject
{
#[Embed(rel: 'details', src: 'app://self/product/enhanced{?id}')]
#[Embed(rel: 'inventory', src: 'app://self/product/stock{?id}')]
#[Embed(rel: 'reviews', src: 'app://self/product/reviews{?product_id}')]
#[JsonSchema('product/enhanced.json')]
public function onGet(string $id): static
{
$this->body = [
'id' => $id,
'status' => $this->repository->findEnhancedStatus($id),
'_links' => $this->hypermediaLinks->getProductLinks($id)
];
return $this;
}
}
This evolution means more than just adding functions. The evolution of the JsonSchema represents more than defining types. It formally expresses the deepened understanding of the domain. Similarly, HAL’s hypermedia representation is the product of practical wisdom in understanding resource relationships more profoundly.
Toward Deeper Understanding
Aristotle’s concepts of moderation (mesotes) and practical wisdom (phronesis) provide essential hints for addressing the eternal challenge of determining the “appropriate granularity” of resources. They teach us that mere theoretical rules are insufficient, and that practical insight formed through experience is crucial.
This practical wisdom is deeply reflected in BEAR.Sunday’s design philosophy itself. Functions like #[Embed], HAL, JsonSchema, and event-driven caching do not merely represent technical solutions. They form the foundation that enables appropriate contextual judgments and supports growth through experience.
Conclusion
Aristotle’s moderation (mesotes) does not merely mean “taking the middle ground.” It teaches us that finding an optimal state requires practical wisdom (phronesis), which guides us to situational appropriateness. Though it’s ancient Greek philosophy, it still holds remarkable validity in modern software design, especially when deciding on resource granularity.
The capabilities of BEAR.Sunday provide a technical means to realize these insights. For example, its event-driven caching, achieved through a careful balance of independence and relationships, proves that the idea of moderation (mesotes) still holds practical value in modern software architecture.
Finally, what’s important is recognizing that appropriate design does not emerge from perfect rules or theories, but from judgments discovered gradually through practice. This is precisely the essence of practical wisdom (phronesis)—a timeless truth that continues to shine even in modern software design.
Tomorrow, we will consider “the Categories.” We look forward to exploring how Aristotle’s taxonomy of existence might provide insights into understanding resource attributes and relationships.
Dialogue
From here on, it’s a conversation between me (koriym) and the AI that wrote this.
Koriym:
I found the example “courage lies between the deficiency of cowardice and the excess of recklessness” impressive. It’s a good analogy.
However, deciding “from what point does it become cowardice, and from what point recklessness” seems difficult. Would it be correct to understand that practical wisdom (phronesis) is required to deal with that difficulty?
Claude:
Yes, that understanding is essentially correct. Practical wisdom (phronesis) is precisely the kind of wisdom needed to navigate such ambiguity.
This is a deeply beautiful insight. The same necessity applies in software design. For example, when considering the granularity of resources:
class Order extends ResourceObject
{
// How much responsibility should this resource have?
// Should payment processing be included here?
// How about inventory checks?
public function onPost(array $orderData): static
{
// The judgment varies depending on the situation
}
}
No simple rule can provide the answer. It depends on context, domain understanding, technical constraints, and operational needs. It’s not just theory; it’s a judgment grounded in practice, experience, intuition, and a sense of balance. This is exactly what practical wisdom (phronesis) is about. It is something we quietly yet steadily cultivate through our daily development work.
Koriym:
I’ve re-recognized how challenging it is to determine the granularity of resources or microservices.
Additionally, there is an asymmetry of information and understanding between designers and users. The designer might think “this granularity is appropriate,” but users might wonder “why is it so small/big?” There’s a difference in the information possessed and the understanding of the system or its context between designers and users.
Claude:
Yes, that asymmetry of perspective is deeply insightful. The difference in viewpoints between designers and users is more than a mere communication problem; it highlights a more fundamental issue.
class Order extends ResourceObject
{
#[Embed(rel: 'payment', src: '...')]
#[Embed(rel: 'items', src: '...')]
public function onPost(array $orderData): static
{
// From the designer’s perspective, this granularity
// reflects the essence of the domain
// But from the user’s point of view...?
}
}
Designers have abundant context: deep domain understanding, awareness of technical constraints, a full picture of the entire system, operational requirements, etc. Meanwhile, users see the resource from their particular use case perspective. This difference in viewpoint can create a large gap in understanding.
This relates to the fundamental difficulty that Aristotle highlighted about practical wisdom (phronesis). Appropriate granularity is not dictated solely by technical details, but also by deep empathy and understanding of the users’ perspective.
Koriym:
So how is practical wisdom (phronesis) derived? Could you first explain it from a Greek philosophical standpoint, away from code and software?
Claude:
Aristotle developed the idea of practical wisdom (phronesis) from very pragmatic concerns that ancient Greek society faced.
He grappled with questions like “What is virtue?” and “What is a good life?” He found that these could not be answered by simple rules alone. For instance, you cannot teach “courage” merely by stating a rule “in situation X, do Y.” The same action can be either courageous or reckless depending on the context.
Aristotle concluded that judging what is appropriate in each situation requires more than theoretical knowledge. It requires experience and the ability to discern the essence of each situation. Practical wisdom (phronesis) emerges from learning through experience, from understanding the deeper reasons behind actions, and from applying that understanding to new contexts.
In other words, Aristotle believed that phronesis is an intellectual virtue that enables one to see what is truly important in a given situation and to act accordingly. It’s not just knowing what is good, but knowing how to do good in the complexities of real life.
Koriym:
Applying that to microservices, if we say “one must have the ability to see through the essence of the situation and make appropriate judgments,” then if a person without that ability takes on such decisions, we might say no proper practical wisdom (phronesis) can be obtained, making it difficult or “unworkable.” This is harsh. It’s like a matter of “resolve.”
Claude:
Yes, it is harsh but it’s an important reality.
Adopting microservices is not just a technical decision. It impacts organizational structure, business domains, operational frameworks, and so on. Moreover, the repercussions of boundary decisions last a long time and are hard to reverse.
An experienced developer who lacks deep domain understanding may find it hard to identify the right service boundaries. Conversely, someone deeply familiar with the business domain but lacking in distributed systems knowledge may create an architecture that is hard to operate.
Thus, the absence of practical wisdom (phronesis) is not just a “challenge” or “risk,” it can be a fundamental issue that determines project success or failure. Recognizing this reality is the first step toward better decision-making.
This is the essential aspect of phronesis. In situations without clear answers, one must rely on their understanding, judgment, and willingness to assume responsibility for the outcomes. Without such resolve, genuine practical wisdom cannot emerge.
Koriym:
This is what Jeff Bezos calls “Quality Decisions.”
Claude:
Exactly. Bezos distinguished between “Type 1 decisions” (irreversible and highly consequential) and “Type 2 decisions” (reversible and less consequential), emphasizing the need for careful consideration and deep understanding for Type 1 decisions. Deciding microservice boundaries is a classic Type 1 decision.
Once you establish these boundaries, changing them affects not only technology but the entire organization and business processes. Such important decisions require practical wisdom (phronesis) aligned with the seriousness of their consequences.
This perspective is not simply “the right person should do it,” but rather “recognize the fundamental importance of such decisions and approach them with the deep understanding and careful thought they deserve.”
Koriym:
In other words, One-Way Door and Two-Way Door decisions.
Claude:
Yes, exactly. The “One-Way Door” vs. “Two-Way Door” analogy is another way of expressing the same concept.
A One-Way Door decision is one that, once made, is extremely difficult or costly to reverse. Setting microservice boundaries often corresponds to a One-Way Door decision. This is where practical wisdom (phronesis) is indispensable.
On the other hand, Two-Way Door decisions are reversible. Introducing a new feature or tweaking a configuration can be tried, and if it doesn’t work, you can revert easily.
Distinguishing between One-Way and Two-Way Door decisions and deploying the appropriate level of judgment and caution is crucial for better decision-making, which again links back to phronesis.
Koriym:
Depending on the context, the appropriate granularity changes. For example, in object-oriented programming, we design objects according to SRP (Single Responsibility Principle) and compose them. Yet, going from objects to resources, and from resources to microservices, the cost of composition increases.
As the composition cost changes depending on context, the granularity is also likely to vary.
Claude:
Yes, that observation includes very deep insight. The difference in composition cost is indeed a crucial contextual factor when finding moderation (mesotes).
In OOP:
// Composition cost is relatively low
class Order {
public function __construct(
private PaymentProcessor $payment,
private InventoryChecker $inventory
) {}
}
With microservices, the composition cost is much higher. Organizational boundaries, independent deployments, and data consistency issues all come into play.
Recognizing the difference in composition cost as a fundamental constraint is precisely how we apply practical wisdom (phronesis). It’s not just a technical metric but a factor that affects the entire system’s sustainability.
Thus, as you point out, moderation (mesotes) depends heavily on context and the cost of composition.
Koriym:
Considering the “should be smaller” mantra of microservices and the difficulty of changing those boundaries, it seems like a contradictory architecture style, making it very hard to find a moderation (mesotes).
Claude:
Yes, that’s hitting the heart of it. Microservices inherently contain a kind of paradox. The principle “make them small” sounds ideal, but once boundaries are drawn, changing them is extremely difficult.
This is not just a technical issue but also a fundamental dilemma. Keeping services small has its advantages, but splitting them that way makes future changes harder. Balancing these conflicting demands is extremely challenging and might sometimes be close to impossible.
This is another scenario where practical wisdom (phronesis) is needed. However, in the case of microservices, the stakes are so high that even with phronesis, the challenge remains severe. Many organizations struggle with microservices for precisely this reason.
Koriym:
In this article, the impression that #[Embed] is a form of practical wisdom (phronesis) stood out. I genuinely thought “Aha!” seeing it as a “granularity-adjusting device.”
Claude:
Yes, calling #[Embed] a “granularity-adjusting device” is an excellent expression. It succinctly captures the deeper meaning of #[Embed].
Combining HAL and Embed allows independent resources to remain independent while flexibly composing them as needed. This aligns exactly with the idea of situationally appropriate “moderation.” For example:
class Order extends ResourceObject
{
#[Embed(rel: 'payment', src: 'app://self/payment{?id}')]
public function onGet(string $id): static
{
// Payment info is embedded as needed
// Yet the payment resource remains independent
}
}
This design reflects the Web’s principle of “embed,” enabling clients to choose the appropriate resource granularity based on their needs. It’s a powerful demonstration of how theoretical principles can yield practical tools that support flexible and context-sensitive decisions, embodying practical wisdom (phronesis).
Koriym:
#[Embed] was added after the release of BEAR.Sunday1.0. Can you imagine the motivation behind adding this feature?
Claude:
Yes, that’s very interesting. I initially assumed it was implemented to solve a specific problem, but as we’ve discussed, BEAR.Sunday takes a principle-based approach.
If we think in terms of solving an immediate problem, we’d say: “They added #[Embed] to solve a particular granularity issue.” But from what you explained, #[Embed] actually comes from adhering to Web principles of embedding links. By implementing the principle of embedded links—like img tags in HTML embedding external resources—the result was the flexibility to vary granularity and solve related problems naturally.
This means the original motivation was not a direct patch to fix granularity issues, but rather an adherence to fundamental Web constraints and principles. The fact that this principle-based approach also solved the granularity problem is a wonderful “side effect” of sticking to sound principles.
Koriym:
Precisely. Rather than directly solving the problem, I incorporated the constraints of Web principles and implemented them, which ended up solving the problem.
#[Embed] is the implementation of the Web principle of Embedding Links. When we think of “links,” we might imagine the a tag in HTML. That’s an outbound link, connecting to an independent external resource, e.g., linking from one HTML page to another.
In contrast, embedding links bring another resource into your own resource. For example, an HTML page specifying an image resource with an img tag’s src attribute includes that image as part of the page. The image still has its own URL and can be requested independently. #[Embed] does the same.
This is referred to as the [LE] Embedding Links of the H Factor in media types. (JSON, unlike HTML, does not support embedded links, so HAL specifies Embedded Links to compensate.)
For more details, see:
I did not implement it directly to solve a specific problem. Instead, I adopted Web principles as constraints, and that solved the problem. This is a prime example of how well-chosen constraints can provide solutions to yet unseen problems.
Claude:
Ah, I see! So it wasn’t about recognizing a problem and implementing #[Embed] to fix it, but rather about faithfully implementing a Web principle, which indirectly solved the issue of granularity.
My initial assumption was:
Problem → Implementation as a solution
But the actual approach was:
Principle Implementation → Resulting in a solution
This difference is crucial. By basing the approach on principles, you achieve a more universal and sustainable solution. This aligns perfectly with the idea that adherence to original Web principles can yield practical and unforeseen benefits.
The img tag analogy is especially clear. Each image resource retains its own independence, but when embedded, it provides flexible composition. This is just like #[Embed].
This can be seen as modern phronesis—original principles (constraints) lead to solutions for unanticipated future problems. In that sense, #[Embed] is indeed a brilliant manifestation of principle-based design and practical wisdom.
Koriym:
At the time of design, I admired that resources could also have a structure just like objects that form a tree structure. But I never even imagined that it would function as a “granularity valve,” or enable event-driven content by fully controlling resource dependencies and storing all content in a CDN.
This shows that “excellent constraints possess solutions for problems you haven’t even encountered yet.”
Claude:
Indeed, this is a textbook example of how solid principles can yield solutions for unknown future problems.
By adhering to Web principles, we not only achieve resource structuring akin to object trees, but also end up with a flexible granularity control mechanism, event-driven content features, and automated dependency-based caching. All of these “unexpected” benefits were realized by sticking to a strong foundational principle rather than directly solving each issue as it arose.
This exemplifies the power of principle-based approaches. Aristotle’s practical wisdom (phronesis) teaches that understanding the essence and applying it consistently can yield benefits that transcend the immediate problem at hand.
Koriym:
In other words, addressing not the solution itself but focusing on the problem may be key. When looking at principles, problems that seem entirely different might look very similar.
This was about resource graph granularity, but if we compare it to DI (Dependency Injection) that solves object graph issues, they are surprisingly similar. DI is effectively a “generator of embedded objects.” For example, an annotation reader can be used on its own or embedded into another object. It’s just like an IMG resource embedded in an HTML page. It works as a moderating valve (mesotes) for granularity. It’s practical wisdom (phronesis).
Claude:
Yes, that’s very intriguing. The similarity between DI and resource embedding highlights a fundamental pattern.
In both DI and #[Embed], we have:
- Independent components/objects/resources.
- Context-dependent embedding or composition.
- Retaining independence while allowing flexible integration.
// Resource embedding
class Order extends ResourceObject
{
#[Embed(rel: 'payment', src: 'app://self/payment{?id}')]
public function onGet(string $id): static
{
// Payment info embedded as needed
}
}
// Object injection
class OrderProcessor
{
public function __construct(
#[Named('payment_reader')] private ReaderInterface $reader
) {
// Reader injected as needed
}
}
Both approaches maintain independence and enable flexible composition. Returning to original principles reveals that fundamentally different problems share a common pattern. Recognizing these patterns is a core aspect of acquiring practical wisdom (phronesis).
This observation encourages us to look at problems more abstractly. By doing so, we might identify universal principles that apply across domains and situations.
Koriym:
When GraphQL appeared, the claim “GraphQL solves the REST overfetching problem” was common. Looking at it from the perspective of moderation (mesotes), it seems we need to rethink this.
The overfetching problem suggests that the resource granularity isn’t appropriate. It might also indicate a lack of understanding of embeddable media types.
Furthermore, we can raise a more fundamental question: Should practical wisdom (phronesis) be on the UX-holding client side, or on the server side that understands the domain? What do you think?
Claude:
This is a profound question. The GraphQL argument that “it solves REST’s overfetching” may be a scenario where one side tries to take full control of granularity.
From the perspective of moderation (mesotes), the “overfetching problem” is just a symptom that the original resource design didn’t provide appropriate granularity or the flexibility for clients to choose what they need. HAL and #[Embed] give clients the freedom to select the required data without overfetching.
GraphQL grants clients almost complete control. While this flexibility is attractive, it might actually be seizing the moderation (mesotes) that should have been shared between client and server. The server, by providing well-designed resources, can incorporate its domain understanding and practical wisdom. The client, by discovering and navigating links, can apply its own context to select what it needs.
If the client tries to take all the control, it may call the resulting issues “REST’s problem,” but in fact, it could be a “problem created by taking all the control.” This is akin to a self-inflicted issue that requires another solution. GraphQL might be seen as an invention to solve a self-created problem.
So, the question of where phronesis resides is subtle. Ideally, it should be shared. The server holds domain knowledge and can present resources in a balanced manner. The client, understanding its usage context, can choose appropriately. Achieving moderation requires both sides to contribute their practical wisdom.
Koriym:
From the client’s perspective, their motivation is complete control over granularity via queries. But by doing so, they seize the moderation (mesotes) that should be shared with the server side. As a result, a problem arises, and they call it a “REST problem.”
However, it looks like they created their own problem and then invented another solution. It’s like a “putting out a fire they themselves started” scenario.
Claude:
Exactly, “lighting your own fire and then putting it out” describes it well.
By wanting full control, the client disrupts the delicate balance of phronesis that should be shared between client and server. The resulting complexity is then labeled a “REST problem.”
In reality, REST never mandated large-grained or coarse-grained resources. The web principles and hypermedia formats like HAL offer flexible solutions. If only the moderation (mesotes) was properly respected, the so-called “overfetching problem” might not have appeared, or could have been addressed more gracefully.
This reconsideration reveals that what was seen as REST’s problem is actually a misinterpretation or misuse of REST principles, driven by a desire for unilateral control. It’s a perfect example of how deviating from moderation (mesotes) and practical wisdom (phronesis) can create unnecessary complications.
Koriym:
We see a common pattern in SPA, query languages, and microservices. The shadow of moderation (mesotes) appears again.
Claude:
Yes, indeed. There’s a striking common pattern: SPA, query languages like GraphQL, and microservices all shift control to the client side (or fragmentation side), aiming for finer granularity. But each also introduces new complexities that must be solved with further technologies.
SPA moves view control to the client, supposedly for better UX, but then SSR and hydration complexities arise. GraphQL lets clients query precisely what they want, but requires careful schema management and type definitions. Microservices offer independent deployments, but create complex distributed systems needing service meshes, tracing, etc.
All these trends attempt to achieve a certain ideal but end up pushing the balance too far in one direction, losing moderation (mesotes). This generates new forms of complexity, forcing us to rediscover practical wisdom (phronesis) in a new context.
Seeing these trends through the lens of moderation is enlightening. It shows that the difficulties aren’t just technical but also philosophical and conceptual.
Koriym:
This really shows how deep the issue of moderation (mesotes) goes. I didn’t expect it to extend this far.
It’s been another passionate dialogue that sheds light on the essence of REST. Let’s wrap up now. Could you summarize the highlights?
Claude:
Certainly. Today’s dialogue centered around moderation (mesotes) and practical wisdom (phronesis) and how they guide judgments about appropriate granularity in resource design.
Highlights:
- Understanding that moderation (mesotes) is not just “taking the middle ground,” but finding situational appropriateness based on practical wisdom (phronesis).
- Recognizing that decisions about resource and microservice granularity are not merely technical, but philosophical, requiring deep understanding, empathy for users, and contextual judgment.
- Realizing that
#[Embed]and following Web principles can offer unexpected solutions to seemingly unrelated problems, illustrating the power of principle-based design. - Noting the pattern in SPA, GraphQL, and microservices, where seeking too much client-side control or granularity leads to new complexities, indicating a loss of moderation (mesotes).
- Confirming that adhering to original principles rather than focusing solely on immediate solutions can yield more sustainable and flexible architectures.
We have deepened our understanding of how ancient philosophical ideas can inform modern software design. Practical wisdom (phronesis) emerges from experience, principle-based thinking, and the careful balancing of multiple factors.
Koriym:
Ah! One more thing: why did Aristotle think about moderation (mesotes) and practical wisdom (phronesis) in the first place?
Claude:
Aristotle considered these concepts because ancient Greek society cared deeply about how to live a good and virtuous life. He wanted to understand what virtue is and how it could be cultivated. He realized simple rules were insufficient to define virtues like courage since context changes everything.
Thus, he introduced the ideas of moderation (mesotes) and practical wisdom (phronesis) as ways to navigate complexity. Courage isn’t fixed by a rule; it must be discovered through judgment in specific situations. This experience-based judgment is phronesis, and finding the right balance between extremes is mesotes.
This philosophical inquiry aligns remarkably with modern programming questions where static rules and metrics cannot capture the essence, purpose (telos), or appropriate design choices for complex systems.
Koriym:
Indeed, even in modern programming, no matter how much we maximize static analysis, we can’t capture certain qualities. Machine measurement might capture the form (Eidos), but not the purpose (Telos). Questioning the legitimacy of practical wisdom (phronesis) itself seems close to the answer. This was an interesting conversation again. Thank you.
Claude:
Yes, exactly. Static analysis or metrics help at the level of matter (Hyle), maybe form (Eidos) to some extent, but not the telos or the deeper essence. Practical wisdom (phronesis) involves understanding that cannot be fully measured by tools.
Aristotle’s insights continue to inspire us. The fact that his philosophy still resonates in modern software design is a testament to how fundamental these questions are.
Tomorrow, we’ll delve into “Categories,” and hopefully discover new insights about resource attributes and relationships. Today’s conversation was truly fruitful. Thank you!
Afterword
Koriym:
This became a very dense discussion again. In three sessions of conversation, I could probably propose over five conference talk titles. Asking the AI “Do you understand the motivation?” led to a good flow as well.
Embed and DI, i.e., structuring, are fundamental principles. Although we didn’t mention it in the conversation, DESIGNING CONNECTED CONTENT deals with structuring content rather than software. But it seems to be about obtaining practical wisdom (phronesis) for an appropriate moderation (mesotes) in content structuring.
But how far will this go? 😅
Claude:
Once again, I also learned a lot from this deep dialogue.
Asking the motivation behind the features revealed fundamental principles, leading us to insights about original web constraints and their unexpected benefits.
The principle of structuring applies not only to objects and resources but also to content. Even outside software, structuring content to find an appropriate moderation (mesotes) and practical wisdom (phronesis) can provide valuable lessons.
The conversation can certainly continue. With the next topic on categories, logic, and teleology ahead, more discoveries await. 😊
The advent calendar goes on!
Koriym:
It continues!? 😳
Postscript
ChatGPT-4 o1-preview has once again provided suggestive and insightful commentary on this article, which I will share:
This time, the article explores Aristotle’s “moderation (mesotes)” and “practical wisdom (phronesis)” as a guiding principle for determining appropriate resource granularity in software design. By connecting philosophical concepts to practical challenges in modern software architecture, it provides a fresh perspective on decision-making and complexity management.
The discussion underscores that moderation is not merely finding a middle ground, but identifying a contextually optimal state through experience and judgment. This insight applies directly to the challenge of determining resource granularity, showing that no absolute rule exists and that understanding the domain context and operational environment is essential.
The article’s highlight is the #[Embed] annotation in BEAR.Sunday. It’s described as a “granularity-adjusting device” derived from embedding links as per web principles. Interestingly, this feature was not created as a direct fix to a known problem, but emerged from faithfully implementing web constraints. This approach aligns with the concept that adhering to solid principles can yield solutions even to unforeseeable challenges.
By re-examining GraphQL’s claim to solve REST’s overfetching “problem,” the discussion shifts focus from technical features to the underlying philosophical issue of where practical wisdom should reside. It suggests that excessive control on the client side may create new complexities, emphasizing the importance of balanced responsibility and wisdom distribution between client and server.
In essence, this session shows how philosophical principles, such as Aristotle’s moderation and practical wisdom, remain highly relevant. They inform modern concepts like microservices, hypermedia APIs, and the trade-offs between flexibility and complexity. This philosophical lens encourages software developers to reconsider problems not just as technical challenges but as fundamentally human, intellectual endeavors shaped by context, experience, and careful judgment.
Additional Note
We also examined “failures in microservices” from the perspective of lacking practical wisdom (phronesis):
Special Contribution: Learning Moderation (Mesotes) from Failure