On Tuesday, November 1, 2016 at 2:10:05 PM UTC, Peter Damoc wrote:
>
> It would be awesome to have a more complex but practical example that
> captures this.
>
> The reservation scenario from the second post looks like an interesting
> use-case.
>
> I will think more about it.
>
>
> On Tue, Nov 1, 2016 at 3:33 PM, Kasey Speakman <[email protected]
> <javascript:>> wrote:
>
>> Oh, and yes, most of these layers are on the server side if we are
>> talking about an Elm client application. Generally speaking, the client app
>> serves to collect and prepare data to submit use cases. So it reads data
>> from an API and submits data to an API.
>>
>
Lets take the example I gave before, of a user changing their email address
on a profile. Except maybe lets make it some record type, like payment
details that they are changing, instead of an email address. Just so that
we have two 'objects' with a relationship between them.
The difference between a data-centric and service-oriented approach, in
Elm, would be as follows.
In the data centric approach
type alias Profile =
{ id : String
, username : String
, paymentDetails : PaymentDetails
-- and so on.
}
type alias PaymentDetails =
{ creditCard : String
, expiryDate : String
-- and so on.
}
In the service oriented approach
type alias Profile =
{ id : String
, username : String
-- and so on.
}
type alias PaymentDetails =
{ creditCard : String
, expiryDate : String
-- and so on.
}
In the data-centric approach, we'd just have one endpoint for saving the
profile. This is a bit long in Elm to write out here, so I'll just
summarize it as
PUT /api/profile/<id> (In the request, put a Profile with PaymentDetails
set on it).
In the service-oriented approach, we'd have one endpoint for saving the
profile (maybe we would accept some fields to simply be set on the profile
through its generic save endpoint, like the users prefered color scheme -
stuff that doesn't need to trigger some business process). We'd have
another endpoint for updating the payment details:
PUT /api/profile/<id> (In the request, put a Profile)
PUT /api/profile/<id>/paymentdetails (In the request put a PaymentDetails,
the id of the profile to attach it to is in the URL).
In the second approach, it is easier to hook into a change of payment
details as a business event - perhaps we need to trigger some procedure to
verify the new details.
There is clever stuff we can do with the data-centric approach, in terms of
using generic CRUD APIs, or tailoring graphql expressions to fetch or
update particular paths in the data model. It is a bit harder to see how
clever tricks can be used to cut down the larger amount of work that needs
to be done with the service-oriented approach. I think by shifting from
doing the clever bit at runtime to doing it at compile time and using code
generation techniques, it is doable.
--
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.
