On Wed, Oct 12, 2016 at 4:13 PM, Fa Qing <faqingh...@gmail.com> wrote:

> I'm just curious how everybody approaches their API service layer in
> complex applications.
> Right now, I have a shared API module that I call from various
> elements/pages/components/children... in a pretty flat architecture. That
> module abstracts out the common request composition, etc.

This is also what I had in my app: an API module that exposes a Cmd
producing interface to the rest of the app.

All API callers provide:
1. `success` and  `failure` message constructors
2. the auth_token (if needed)
3. the rest of the data required for the request

The extraction from the header and injection in the header can be
abstracted in some custom `get` and `post` functions.

Right now I have an Api.sendJson call that returns a task

This sounds like a good approach (similar to the custom `post` that I
mentioned earlier) but I would not expose this to the rest of the app.
I would use something like this internally to do the job.

In using my API module, I would always use only functions that produce Cmd
(I avoid using the tasks).
To give you an example. I had a User object that had a list of Companies.
The list is saved a set of IDs and to get the final Elm object I had to
first get the user data and then go through each of the IDs in the
Companies field and request the Company data for that company.
All these details are not the concern of the rest of the program. The rest
of the program just gets the final User with a list of Companies, nicely
wrapped in a message.
Internally to API, there are various functions that help with constructing
the final Task that first fetches the user and then fetches the rest of the
data but these tasks are not exposed outside the module.

If the database storage changes or I decide on another strategy, the rest
of the app is isolated from these changes because it talks in the higher
language of the API not in the lower language of the Http that the API uses
to implement the functionality.

There is NO FATE, we are the creators.
blog: http://damoc.ro/

You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to