On Wednesday, October 19, 2016 at 9:54:44 AM UTC+1, Peter Damoc wrote: > > *The problem * > > I know how to implement a REST API and interrogate that API from Elm but > that *seams very low level. * > > I was curious about a language abstraction that would isolate my Elm > program from the actual database strategy. > > How do you approach dealing with the databases? What is your strategy? > What options are there? > Do you have any pointers to interesting perspective/approaches? >
Interesting that you jump straight from 'REST API' to 'database'. You can map database CRUD operations straight onto REST POST, GET, UPDATE, DELETE operations, it is true. Many APIs even if they do not expose all of CRUD through REST in this way, often have a trace of it in the API since the mapping is an obvious one. However, there is more to APIs than CRUD, and in many situations CRUD is not what you want for an API at all. Here are some examples to illustrate. Suppose I have an API that lets a user create a profile, modify their profile as they see fit, use their profile to access some applications, and if they choose to, delete their profile permanently. This fits naturally to a CRUD mapping of the profile. Suppose I have an API for a bank account. The user cannot simply make changes to their account, they must always do so by requesting balancing transactions. So take some money from my account, and put it in another account. This does not map to CRUD on accounts at all, the API will describe a carefully chosen set of transactions that the user can fill in and request to have processed. CRUD on single tables does not necessarily make a good API, as tables can be too small a fragment to deal with at the API level. Suppose in my profile example, that the profile has a list of email addresses in it, one of which is marked 'active'. There will be at least 1 profile table with a 1-to-many to the email addresses table. When I fetch the profile, I likely also want to fetch all the emails at the same time. The profile is what I call a 'slice' of data and it corresponds to a little document model. You could equally well store this document model in a non-relational database as json, say on MongoDB for example. This is often how I think when designing APIs - what are the slices that the consumer needs to be able to work with to get the level of abstraction right. Having designed a data model and considered its slicing, I produce a CRUD API (+ finders) but at the level of abstraction of the slices. Later on, I then tidy this up by removing operations that should not be exposed in the API, say I don't want the delete operation for example. Or sometimes I remove the whole CRUD API for a certain class of entities, like the bank accoutn example, as a more transactional style API will be used instead. 'graphql' looks very interesting. I had a wee look after the recend post about an Elm client for it. Remember you will need a graphql implementation on the server though. And that for some situations, graphql might not be appropriate. As in the bank account example, you don't necessarily want the consumer to be able to freely navigate the whole graph of your data model, certain parts might require more restricted access. Actually, I was thinking I'd like to look into graphql more deeply at some point. It essentially provides a way for the consumer of an API to dynamically specify the 'slice' that they want. It could also be used purely on the server side as a way of defining slices but exposing them as particular end points for a particular slice. Like: GET /api/profile/<id>/summary - Gets just some of the profile data. GET /api/profile/<id> - Get the full profile Would be easy to do, if my server code let me set up these end points by writing them as graphql queries and automatically map that onto whatever underlying database technology I am using. I have no idea where we are at for good server side libraries for doing this... -- 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.
