# Proposal: Engine V1 REST API Transition

**URL:** <https://forums.mobyproject.org/t/proposal-engine-v1-rest-api-transition/49>\
**Category:** Architecture\
**Created:** [May 18, 2017, 4:06pm UTC](https://forums.mobyproject.org/t/proposal-engine-v1-rest-api-transition/49 "2017-05-18T16:06:14Z")\
**Posts on this page:** 3\
**Page:** 3

<div class="post-metadata">

**Author:** ![shykes2](https://avatars.discourse-cdn.com/v4/letter/s/e95f7d/32.png) [@shykes2](https://forums.mobyproject.org/u/shykes2)\
**Post date:** [June 8, 2017, 4:53pm UTC](https://forums.mobyproject.org/t/proposal-engine-v1-rest-api-transition/49/42 "2017-06-08T16:53:04Z")

</div>

> dnephin [https://forums.mobyproject.org/u/dnephin](https://forums.mobyproject.org/u/dnephin)  
> June 8
> 
> shykes2:
> 
> grpc allows multi-plexing multiple services into a single transport…  
> The aggregation is done automatically by grpc.
> 
> gRPC allows you to configure multiple “gRPC services” _within the same  
> process_ to a single transport. I think it’s important to mention that a  
> “gRPC service” is just a code construct. It’s not a “component”. This isn’t  
> much different from any REST API where you can configure multiple routes at  
> different urls on the same transport.
> 
> If you want to run different processes on the same transport you need  
> another proxy process which handles that multiplexing.
> 
> Does this match your understanding? Our working definition of “component”  
> has been “separate binary” (so a separate process). This means we would not  
> be running multiple components on the same socket/port. But a proxy can be  
> used to support that design.

Yes this does match my understanding. I think we have 2 viable options for  
multiplexing:

1. a proxy as you describe. Note, we can develop a proxy that supports  
dynamic registration of components on a single address (ie all components  
connect to the proxy instead if the other way around).

2. a directory with a bunch of unix sockets, one per service.

---

<div class="post-metadata">

**Author:** ![duglin](https://yyz1.discourse-cdn.com/flex031/user_avatar/forums.mobyproject.org/duglin/32/28_2.png) [@duglin](https://forums.mobyproject.org/u/duglin)\
**Post date:** [June 8, 2017, 9:30pm UTC](https://forums.mobyproject.org/t/proposal-engine-v1-rest-api-transition/49/43 "2017-06-08T21:30:40Z")

</div>

Option 1 is what I’ve been thinking and it would be part of the monolith to  
make it easier to manage.

thanks  
-Doug

---

<div class="post-metadata">

**Author:** ![stevvooe](https://yyz1.discourse-cdn.com/flex031/user_avatar/forums.mobyproject.org/stevvooe/32/54_2.png) [@stevvooe](https://forums.mobyproject.org/u/stevvooe)\
**Post date:** [June 9, 2017, 12:00am UTC](https://forums.mobyproject.org/t/proposal-engine-v1-rest-api-transition/49/44 "2017-06-09T00:00:07Z")

</div>

> [@shykes2](#):
>
> a proxy as you describe. Note, we can develop a proxy that supports  
> dynamic registration of components on a single address (ie all components  
> connect to the proxy instead if the other way around).

We are considering this approach in containerd and I think it is very viable. I think there is also the possibility to register services that are unknown at compile time, making the base of a very interesting plugin framework.

[Previous page](https://forums.mobyproject.org/t/proposal-engine-v1-rest-api-transition/49.md?page=2)