(META) API Design

[john-kelly]

I currently believe that all api choices should be as close to sql as possible. PostgREST really is a thin layer over sql and i think that it would be important to reveal this fact in the elm client api. There is definitely a possibility that a more general realization of this library would change api naming, however, this library is not that. Despite this realization, it is important to note that priorities are as follows:

1. Type safety and Preventing Invalid States (queries)
2. API close to SQL

Relevant Issues: https://github.com/john-kelly/elm-postgrest/issues/51 https://github.com/john-kelly/elm-postgrest/issues/50 https://github.com/john-kelly/elm-postgrest/issues/48 https://github.com/john-kelly/elm-postgrest/issues/47 https://github.com/john-kelly/elm-postgrest/issues/53

[john-kelly]

for example, doing something like this would be pretty cool.

    PG.from Schema.school
        { select = selection
        , where_ = condition
        , orderBy = []
        , limit = Nothing
        , offset = 0
        }

An important note to this, is that selection (based on my understanding of sql) is not like the typical sql select... selection itself can contain implicit joins b/c of how nesting works in postgrest AND it can contain orders, limits, offsets, and conditions of its own (for those nested entities) -- this might be important to express in the api.

[john-kelly]

Some POC for the selection api: https://ellie-app.com/3R3GsN6NzxBa1/1

More API POC: https://ellie-app.com/3RWQWTP6MqFa1/0

NOTE:

type Selection attributes a
    = Selection (attributes -> Decode.Decoder a)

vs

type Selection a
    = Selection (Decode.Decoder a)

Some helpful info for direction of infix: http://package.elm-lang.org/packages/krisajenkins/remotedata/4.3.0/RemoteData-Infix http://package.elm-lang.org/packages/krisajenkins/formatting/4.2.0/Formatting http://package.elm-lang.org/packages/evancz/url-parser/2.0.1/UrlParser http://klaftertief.github.io/elm-search/?q=%3E%3E%3E