Closes: https://github.com/faunadb/sales-engineering/issues/413, https://github.com/faunadb/sales-engineering/issues/273

Major changes:

• Making sure our library doesn't add any method to native types
• Implements the value tree hierarchy
• Refactoring field extractors to make extensive usage of the type system
• Improve error messages, specially for field extractors
• Move from callbacks to future oriented api (with our own QueryResult type)
• Review usage of named parameters
• Increase test coverage
• Adds lint

Not included:

• Support high precision timestamps. https://github.com/faunadb/sales-engineering/issues/414
• API docs: https://github.com/faunadb/sales-engineering/issues/431

Ideally it should not depend on 3rd party dependencies. I think it should be written directly on top of NSURLSession (Foundation) and do not depend on any external networking library. Eventually https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSURLSession.swift will be implemented and this will allow us to run on linux.

Key features:

Configuration:

• baseURL (includes scheme, domain and port).
• requestTimeout.
• observers support.
• authToken
• methods to perform queries...

Am I missing something important? Any other critical feature for the client? @freels @erickpintor

I'm opening this issue so we can discuss how the internal types are being converted to Expr.

Right now there are places where we need to write code like this:

Create(ref: Ref.indexes, params: [
  "name": "spells_by_element",
  "source": Ref("classes/spells"),
  "terms": [["path": "data.element"] as Obj] as Arr, 
  "active": true
])

[["path": "data.element"] as Obj] as Arr

I think as Obj and as Arr requires previous knowledge about the internal Expr class hierarch and exposes that fact that we have internal representations of our own. Therefore, it loses the meaning of having literal conversions.

Ideally, the user doesn't need to know about ArrayV, ObjectV or any other internal type. We should make them transparent to the user.

In Java, we have functions to construct objects, arrays and internal values so the user doesn't need to construct them manually. The user only works with functions at the Expr level:

Create(Ref("indexes"), Obj(
  "name", Value("spells_by_element"),
  "source", Ref("classes/spells"),
  "terms": Arr(Obj("path", Value("data.element"))), 
  "active": Value(true)
)

Since in Scala we have implicit conversions, the user needs to know even less about the internal types:

Create(Ref("indexes"), Obj(
  "name" -> "spells_by_element",
  "source" -> Ref("classes/spells"),
  "terms" -> Arr(Obj("path", "data.element")), 
  "active" -> true
)

I believe that if we follow some ground rules we can make a Swift DSL a bit more fluid. What I would like to see is if we could provide a DSL similar to this:

Create(ref: "indexes", [
  "name": "spells_by_element",
  "source": Ref("classes/spells"),
  "terms": [["path": "data.element"]], 
  "active": true
)

There rules for that syntax are:

• Literals convert to Expr, not subtypes of Value. Perhaps, we don't need to make Value extends `Expr.
• Parameters with type Expr are unnamed. Named parameters are used to infer types. For example Create(ref: "indexes") vs Create(Ref("indexes")).

Those rules are very similar to the Scala implementation at the moment and seems to be the cleanest typed language we got so far.

Let me know you're thoughts.

I think Result verbose and, most of the time, you're more interested on result value rather than knowing it there was an error or not.

We could provide a general error handling that you attach to the client and a version of the query method that only call the call back if the query succeed.

That would make the code more concise and less verbose.

closes #54. I also added the test for each platform. Source and test files are shared among platforms. Only required change was the set up of each dynamic framework and its associated tests.

At the moment we support Int as a Scalar type. I wonder what happens if the user wants to work with values bigger than a Int. In Java and Scala, the DLS works with Long type to guarantee compatibility with all possible number types.

To improve performance, FaunaDB allows http keep-alive connections. The should drivers issue requests with keep-alive header on.

The idle timeout for http connections is 5 seconds on the server, we should set it to a bit less on the client. 4 seconds should be fine.

Closes: https://github.com/faunadb/sales-engineering/issues/444

It seems odd at first but, while developing the Example project I quickly realize that most of the time you're not interested on the actual result but rather to react upon it's completion.

For example:

        Post.save(postToSave).map(at: .main) { [weak self] savedPost in
            self?.post = savedPost
            self?.goBackToPreviousView()
        }

The alternative would be to call await, which blocks the thread preventing the user to cancel the action, if needed.

• [x] observers should be private

query method:

• [x] should always require the callback function
• [x] should never submit an empty NSData
• [x] ~~should not return NSURLSessionDataTask~~

handleQueryErrors method:

• [x] should not throw a NetworkException on cast error
• [x] should not be responsible for parsing the response data
• [x] should not call print

1. Base Xcode project.
2. Dependency manager support. cocoapods and carthage for now.
3. Unit tests target.
4. Example App.
5. Automated UI testing for Example app. (?)
6. Travis .yml file.

These tasks only includes environment support. Driver, testing, example app code are not included in this task.

• Ignoring tests folder
• Testing AtomicInt overflow
• Fix bug on equality operator for ValidationFailure

The rest of the missing branches are either places where the coverage instrumentation can't verify that the branch was called but I manually check that they are being executed, safe guards for unexpected errors, or string representations for data structures.