# Component architecture

**URL:** https://forums.mobyproject.org/t/component-architecture/115
**Category:** Architecture
**Created:** [July 28, 2017, 2:27pm UTC](https://forums.mobyproject.org/t/component-architecture/115 "2017-07-28T14:27:10Z")
**Posts on this page:** 1
**Showing post:** 6

<div class="post-metadata">

### Author: ![dnephin](https://yyz1.discourse-cdn.com/flex031/user_avatar/forums.mobyproject.org/dnephin/32/32_2.png) [@dnephin](https://forums.mobyproject.org/u/dnephin)
#### Post date: [July 28, 2017, 6:37pm UTC](https://forums.mobyproject.org/t/component-architecture/115/6 "2017-07-28T18:37:42Z")

</div>

> [@justin](#):
>
> [What are the (if any) existing natural separations in moby-core today that would be low-hanging fruit for componentization?]  
> logging

What do you mean by logging? container logging? or logging from each component? Wouldn’t container logging just be part of containerd?

> [@justin](#):
>
> The REST API

There were 2 mentions of this, but I don’t think the REST API qualifies as “low-hanging fruit for componentization”. To provide the REST API we need a gRPC interface for every other component. That means we have to complete all other component work before we can actually provide the REST API as a component. This was discussed in [https://forums.mobyproject.org/t/proposal-engine-v1-rest-api-transition](https://forums.mobyproject.org/t/proposal-engine-v1-rest-api-transition)

* * *

> [@cpuguy83](#):
>
> What are the (if any) existing natural separations in moby-core today that would be low-hanging fruit for componentization?

Another option is “events”. Events will be generated from every component, and they will most likely need to be aggregated and provided from a single API endpoint.

An “events” component could be implemented using kafka (or an existing message queue implementation), so that the client can consumer events as a stream.

---

_[View the full topic](https://forums.mobyproject.org/t/component-architecture/115)._