Thanks everybody. It seems like we've converged on a similar approach.
Do you guys keep your domain models all in repos at the root of your
Also, right now my api call ends with a (Cmd ModelUponSuccess), with that
ModelUponSuccess belonging to the child page that uses the model returned
(where it is also stored, for now, though I was thinking about refactoring
them out into top level repos; hence the question above. But I need to also
issue a (Cmd AndBumpThatAuthToken) upon a successful api call. Do I Cmd.map
the ModelUponSuccess message from the caller to a message type in the api
itself, so that it can issue a Cmd.batch list of commands that are all of
the message type of the api module itself?
[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
Getting a little late here, so hopefully that's still coherent. Thanks
again everybody. I'm pretty new to the language and really appreciate the
On Wednesday, October 12, 2016 at 10:48:18 PM UTC+9, Peter Damoc wrote:
> > 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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.