[erlang-questions] Re: Interfaces between distributed OTP applications

Garrett Smith g@REDACTED
Fri Jan 29 17:57:13 CET 2010

On Fri, Jan 29, 2010 at 10:27 AM, ZZZZZZZZZZZZZZZZ
<zvi.avraham@REDACTED> wrote:
> I hate to repost, but maybe somebody can answer?
> thanks in advance

FWIW, when I first saw your post, I casually interpreted your all-caps
name as spam that got through the filter. You might want to tweak your
mail client.

> Zvi
> On Jan 26, 10:36 am, ZZZZZZZZZZZZZZZZ <zvi.avra...@REDACTED> wrote:
>> Hi,
>> the OTP Design Principles states, that OTP Applications are set of
>> loosely-coupled components, while modules inside single application
>> are tightly coupled.
>> Let's say I have two distributed OTP applications:  "client" and
>> "server", both running on different Erlang nodes/hosts.
>> Let's say "server" application uses gen_server, which exposes public
>> function API.
>> The "client" applications calling functions in public API of
>> gen_server in "server" application.
>> What's the proper way to express this in OTP?
>> 1. For simplicity, just add dependency on "server" application in
>> "client" application's .app file. Start both on "server" node.

Yes, though I'm not sure why the client would need to run on the
server node. The server would typically be registered globally and
then accessed from the client through a public API in the server
module (or an application level module).

>> 2. Don't use public API functions in "server". Send messages directly
>> to "server" using gen_server:call / cast.

No. Look over the API docs for other gen_server implementations in OTP
-- there's always a public API that wraps the call/cast to the server.

>> 3. Add third application: "server_api" or "server_if" with single
>> module defining public API wrappers around gen_server messages
>> protocol. Then "client" application will be depended on "server_api"
>> application, and not the "server" itself.

It's common to provide an application level module that provides all
public APIs. E.g. look over the mnesia application.

That said, you still want to provide an API per gen_server, even if
it's only used within your app.

>> 4. Any other ideas?

For learning OTP principles, there's no substitute for reading and
understanding the way existing OTP apps are implemented. I'd recommend
spending some time looking over apps (source, .app file, directory
structure, etc.) like inets and mnesia. I do this all the time to get
ideas for structuring my Erlang code.


More information about the erlang-questions mailing list