Re: [elm-discuss] http "middleware" options

[Fa Qing]

Somehow at that point it seems like we have effectively given up on a clean 
architecture though.

We extracted out our API layer (or at least our transport layer), yet we're 
still having to take both inputs and return values and pass them through 
(every) unrelated entity that calls the API layer. At which point I'm not 
sure I would even want to abstract out the API layer beyond creating a few 
common helper functions. I can shake the feeling that this is a messy 
architecture that doesn't lend itself a clean abstraction with regard to 
these sorts of service modules.

It's a trivial thing, I suppose, to drop down to JS and do this (or as 
Rupert mentioned, use cookies for use cases where cookie restrictions 
aren't too constraining), but I think it would be strongly preferable to 
have a generic  way of doing this directly in Elm.



On Thursday, October 13, 2016 at 1:07:44 AM UTC+9, Peter Damoc wrote:

>
>
> On Wed, Oct 12, 2016 at 6:50 PM, Fa Qing  > wrote:
>
>> Goal
>> [AppRoot] -> [UsersPage] --> ask api for users, and upon success, 
>> 1. send the UsersFetchSuccess message (attaching the users); so far so 
>> good, but then also I need to...
>> 2. replace the token by sending the BumpToken message at the root level 
>> of the app.
>>
>
>  
> I would approach this by making UserFetchSuccess incorporate the token. 
>
> type Msg 
> = UserFetchSuccess Token UserData
>
> and handle the bumping of the token afterwards by maybe extending the 
> update signature with a Maybe Token
>
>
>  
>
> -- 
> 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.

Re: [elm-discuss] http "middleware" options

[Peter Damoc]

On Wed, Oct 12, 2016 at 6:50 PM, Fa Qing  wrote:

> Goal
> [AppRoot] -> [UsersPage] --> ask api for users, and upon success,
> 1. send the UsersFetchSuccess message (attaching the users); so far so
> good, but then also I need to...
> 2. replace the token by sending the BumpToken message at the root level of
> the app.
>


I would approach this by making UserFetchSuccess incorporate the token.

type Msg
= UserFetchSuccess Token UserData

and handle the bumping of the token afterwards by maybe extending the
update signature with a Maybe Token




-- 
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.

Re: [elm-discuss] http "middleware" options

[Wouter In t Velt]

Personally, I like the setup for as it is used in the time tracker SPA 
example (here) 
.

They have a separate file (Util.elm) with the following function:
cmdForRoute : Model -> List (Cmd Msg)

(This function is called inside the update function)
It generates a list of Cmd Msg.

inside cmdForRoute, various API functions are called.

The API is in a separate file, with specific functions for certain read or 
write calls, like: 
fetchProjects : Model -> (Http.Error -> Msg) -> (List Project -> Msg) -> Cmd 
Msg
fetchProjects model errorMsg msg =
get model "/projects" Decoders.projectsDecoder errorMsg msg

Each of those functions calls a more generic "get" or "put" function, which 
does the actual calls to server:
get : Model -> String -> JD.Decoder a -> (Http.Error -> Msg) -> (a -> Msg) 
-> Cmd Msg
get model path decoder errorMsg msg =
 ...


-- 
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.

Re: [elm-discuss] http "middleware" options

[Peter Damoc]

On Wed, Oct 12, 2016 at 4:13 PM, Fa Qing  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.