I've been using absinthe on the server side and I am able to control access permissions quite well for GraphQL hosting, though I am using a custom permission library that ties to our local LDAP server so that code would not be generically useful to release.
But yes, I am a fan of GraphQL. I just expose 'functionality', not raw tables. Many of my GraphQL calls do not map to a database table but rather potentially multiple (or even none in some cases). On Wednesday, October 19, 2016 at 5:29:08 AM UTC-6, Rupert Smith wrote: > > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
