Skip to content

Latest commit

 

History

History
181 lines (102 loc) · 5.11 KB

README.md

File metadata and controls

181 lines (102 loc) · 5.11 KB

CERBAS

Cerbas let languages other than elixir call functions written in elixir.

Cerbas uses redis as the "broker".

A client code, for example in python, prepares a json compatible request which stores in redis.

The json is fetched by cerbas server and routed to the configured elixir function.

The returned value from the function is serialized to a json response that is dispatched to the client by means of redis' publish capability.

Client -> json-request -> cerbas driver -> redis -> listen in channel X

Cerbas Server read incoming requests and dispatches to configured elixir functions, publish result to channel X.

To run cerbas install and ...

run redis...

$ redis-server

Open other terminal window and install elixir 1.4

and ...

clone this repo

$ git clone https://github.com/batok/cerbas.git
$ cd cerbas
$ mix deps.get
$ mix run

Open other terminal window and install python's stuff...

$ cd cerbas
$ python3 -m venv py3env
$ source py3env/bin/activate
$ pip install -r requirements.txt

and run the python example...

$ python3 cerbastest.py 

cerbastest.py make some requests to redis, which are routed to elixir functions by CERBAS Server.

the last request "halt" will stop CERBAS Server.

==================================================================

Cerbas can:

  • handle a timeout for executing functions ( default to 5 seconds).

  • compress published responses with msgpack ( optional ).

  • cache values for specific functions.

  • run scheduled functions by means of a CRON compatible file.

Use cases:

  • Scripts or code from any language which at some point need call one or more functions developed with elixir/erlang.

  • CRON like execution of elixir functions

Plus:

Cerbas includes a Plug Web Server which also serve as proxy to other web apps. Four examples are included.

To run the tornado app ...

$ python3 tornadoapp.py

Open any browser and go to localhost:4455/api7/foo

Cerbas' plug server will receive the http request and will route it to tornado web app.

===

The language must communicate with redis and serialize to and from a json like structure. Both are pretty supported in any language. The only caveat is that the redis communication must support "subscribe".

Currently only a python driver for cerbas is included but write an specific driver for any other language is easy if follow these:

Client - Server interaction using CERBAS.

1 - Client prepares a request which is json data containing:

{“func”: “name of an alias name to a real function”, “args”:
json_object_containg_arguments_if_any, “user”: “registered user name”, “source”: “kind of program where the request is generated, i.e. ror which is also registered”}

Example 1:

{“func”: “s3backup”, “args”: {}, “user”: “tom”, “source”: “flask_app”}

Example 2 ( with parameters ):

{“func”: “tablecount”, “args”: {“table”: “users”, “database”, “awesomedb”}, “user”: “peter”, “source”: “ror” }  

Example 3 ( with delay in milliseconds before running the task or function ):

{“func”: “send_a_notification_in_a_minute”, “args”: {}, “user”: “alice”, source:”django_app”, delay= 60000} 

2 - Steps done by any client in any language connected to redis ( db = 1 [dev], db = 8 [prod]).

A - INCR CERBAS_COUNTER

B - GET CERBAS_COUNTER

C - Key name is built this way:

CERBAS-REQ-[Value of CERBAS_COUNTER zero filled right justified to ten digits]

Example:

CERBAS-REQ-0000000001

D - SET Key as in "C" with the value of serialized json request ( see previous examples ).

E - RPUSH CERBAS_QUEUE [ with CERBAS_COUNTER contents, i.e. 1 ]

F - If the request doesn’t expect an answer from CERBAS that was it.

G - Redis pub-sub channel name built this way:

CERBAS-RESPONSE-[Value of number of redis db (1 for dev or 8 for production)]-[Value of CERBAS_COUNTER zero filled right justified to ten digits]

Example:

CERBAS-RESPONSE-1-0000000001

H - Client subscribe to this channel waiting for a response from CERBAS ( Server will publish the response to this channel when finishes processing the request ).

I - Response has the following json structure

{“status”: “ok”, “data”: json_value_or_structure_containing_result} when ok {“status”: “error”, “data”: “error message” } when having errors.

What CERBAS server does is reading values from the queue (LPOP) , (GET) ing the value of the key formed with the popped value, deleting the original request ( DELETE) and routing the request to a real elixir function which must return the possible values:

json value can be any poison serializable content

{:error,error message}

CERBAS will intercept this value an build the appropriate json response that will publish using the right channel in two forms: raw and compressed via msgpack. If the content was msgpacked the channel name used will be prefixed by MSGPACK:.

Due to concurrent goodies of the erlang vm every request is dispatched in its own process without conflicting or waiting for previous requests.