Imagine some fellow wants to query a pizza server for the list of pizzas. This individual would do simply
GET /pizzas
;=> ["cheese", "extra cheese", "broccoli"]
With pedestal-app's data model and messages, I am not sure how to design client-server communication. Here are the possibilities some minutes of hammocking brought:
- An effect-consumer that
- transforms a message into an HTTP request
- transforms back the results (to e.g.
[{:type :add :topic [:pizzas] :value "cheese"} ...]
) - puts the messages in the queue
- A dedicated resource on the server (e.g. "/edn") that
- accepts pedestal messages
- dispatches to the right function
- responds with the raw data (i.e. ["cheese", "extra cheese", "broccoli"])
- has the effect-consumer transform back the results to messages
- A dedicated resource that uses the routes. Just like #2, but
- altering the request
- forwarding it to another entry in route table
- Messages on both sides, with
- the server transforming messages into function calls
- the server transforming results back into messages
- the client just adding these messages to the queue
It seems to me that with approaches #2 and #4, I'd bypass and lose all the benefit of the interceptors. With approach #2, I'd need to redouble the routing logic. With approach #4, I'd also need to generate a lot of code to accommodate the pedestal client.
Options #1 and #3 seem better, but #3 smells hacky and #1, misdirected.
How are you guys doing it?
Thanks!