On Wed, Oct 12, 2016 at 4:13 PM, Fa Qing <[email protected]> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
