Writing a REST Interconnection Library in Swift

www.erlang-solutions.com

SWIFTBA MEETUP

JUNE 8th, 2016@ Inaka's Offices


HELLO!

Pablo Luciano [email protected]

@pablolvillar

www.erlang-solutions.com www.inaka.net

_iOS dev since 2011

_swifter since 2015

mailto:[email protected]


http://www.erlang-solutions.com

http://www.erlang-solutions.com


#warilis


writingarestinterconnectionlibraryinswift_


ROADMAP

1. Motivation

2. Architectural concept

3. Implementation


1.MOTIVATION


Why would we need a REST interconnection library?

Our App

ServerBackend

Give me a list with all the users

200: Success, returns

JSON array with users



Create a user with this info: [...]

200: Success,

user created

Our App

ServerBackend



Update some info for this user:

[...]

200: Success, returns

user updated

Our App

ServerBackend


Delete this user: [...]

200: Success,

user deleted


Our App

ServerBackend



C/R/U/D

Response

Our App

ServerBackend


● NSURLSession

● Alamofire / AFNetworking

● Other libraries

How we usually write networking code:


NSURLSession example: "Give me a list with all the users"

GET /users

How we usually write networking code:


Now, where should that networking code go…?


Premises:

● Find a good place to put our networking code.

● Define a proper way to architecture our REST layer.

● Avoid duplicated code from common CRUD operations.

● Come up with a concise API that we can use across all of our projects.


2.ARCHITECTURALCONCEPT


GOAL: Provide a neat API

that our ViewControllers can interact withwithout having to worry about networking implementation details.


Let's find out common paths...

"Give me a list with all the users" GET /users

"Give me the details for this user" GET /users/:id

"Create a user with this data" POST /users

"Update this user with this data" PUT /users/:id

"Delete this user" DELETE /users/:id



"Give me a list with all the users" GET /users

"Give me the details for this user" GET /users/:id

"Create a user with this data" POST /users

"Update this user with this data" PUT /users/:id

"Delete this user" DELETE /users/:id



"Give me a list with all the posts" GET /posts

"Give me the details for this post" GET /posts/:id

"Create a post with this data" POST /posts

"Update this post with this data" PUT /posts/:id

"Delete this post" DELETE /posts/:id



"Give me a list with all the entities" GET /:name

"Give me the details for this entity" GET /:name/:id

"Create an entity with this data" POST /:name

"Update this entity with this data" PUT /:name/:id

"Delete this entity" DELETE /:name/:id

Let's introduce the entity concept...


"Give me a list with all the entities" GET /:name

"Give me the details for this entity" GET /:name/:id

"Create an entity with this data" POST /:name

"Update this entity with this data" PUT /:name/:id

"Delete this entity" DELETE /:name/:id

Notice that any entity needs an id to work


User Post Comment

id Create?

Read?

Update?

Delete?

Entity


REPOSITORY!

Actually, we need a different place from which we can perform CRUD operations to our entity…

Entity

CreateReadUpdateDelete

And that place is called…


UserRepository

User

findAll() → [User]

findByID(id) → User

create(User)

update(User)

delete(User)


Elemental CRUD operations*

Repository

Entity

findAll() → [Entity]

findByID(id) → Entity

create(Entity)

update(Entity)

delete(Entity)


PostRepository

Post

findAll() → [Post]

findByID(id) → Post

create(Post)

update(Post)

delete(Post)

Customization

findPostsFromUser(User) → [Post]


*


This one has the issue that every repository you create will come with all these basic CRUD methods by default, even if any particular repository doesn't need all of them.

That breaks the YAGNI principle.

But still, it's a very convenient approach for us.

* There are many ways to approach the Repository pattern.


name

Our Repository needs a name to work

Repository

Entity findAll() → [Entity]

findByID(id) → Entity

create(Entity)

update(Entity)

delete(Entity)

GET /:name/

GET /:name/:id

POST /:name

PUT /:name/:id

DELETE /:name/:id


UserRepository

findAll() → [User]

findByID(id) → User

create(User)

update(User)

delete(Entity)

GET /users/

GET /users/:id

POST /users

PUT /users/:id

DELETE /users/:id

This name represents the group of entities that the repository works with

"users"

User


Last, but not least…

We still need to define a place where our networking code will fall into.

Let's introduce the concept of…

BACKEND


Repository Backend

GET/users Networking

code


Repository NSURLSessionBackend

GET/users NSURLSession

code


Repository AlamofireBackend

GET/users Alamofire

code


Repository TestingBackend

GET/users Sample code

(mocks)


Repository Backend

GET/users Networking

code

Raw Data

Parsing??


Raw Data

Parsing

UserRepository

NSURLSessionBackend

GET/users

UsersListViewController .findAll()

Users


3.IMPLEMENTATION


Let's translate all these diagrams into code.

Not just any code, but…

Swift code!


Where to start…?

OK, let's do Repository


✔ Protocol composition

✔ Generics

- Prefer composition over inheritance whenever possible.

- This way, you end up having a more flexible and extendable architecture.

- By using generics, you lead your models to become more adaptive and customizable.

- The final user is going to be happier.


Before proceeding, let's introduce two new friends you should become familiar with...

● Result

● Future


● Result- It's an enum that we're going to use to represent

a result.

- It can be either:

- Success (and hold a relevant result value)

- Failure (and hold a relevant error)


● Result

e. g. [User]

e. g. NSError


● Future- You should definitely check out this talk:

- https://realm.io/news/swift-summit-javier-soto-futures/

- Anyway, roughly speaking, a Future is a struct

that we're going to use to represent the

computation of an asynchronous task.

https://realm.io/news/swift-summit-javier-soto-futures/

https://realm.io/news/swift-summit-javier-soto-futures/


- Here you can see why it's convenient to use Futures:



.map and .andThen are 2 special functions in Futures that allow us to chain asynchronous operations very nicely.


● Future- Let's create a function that returns a Future:

This Future is going to work with a Result<[User], NSError>


- Let's use that Future:

let result:(Result<[User], NSError>)

Type inference

let users: [User]

let error: NSError


✔ Static typing / Type inference

✔ Enums with associated values

- Compiler enforces you to use the types you're expected to use.

- Write less, know more.

- We're getting all the juice from Swift enums by using them with associated values.

- This allows us to define powerful structures to represent discrete values containing relevant information in a proper way.


Now, let's add elemental CRUD functionality to our Repository...


We can add default implementations for those in a protocol extension:


Let's analyze how we would implement one of those…


Let's add a Backend at the Repository level...


Let's define a Backend:Associated type: String

Means that any case will

have a .rawValue of type

String.

"GET" "POST" "PUT" "DELETE"

come by default


Let's (finally) add a Backend at the Repository level...


let future:Future<NSData?, NSError>

Type inference ≠Parsing


=



Now, let's define a concrete Backend that we can actually use...


Now, let's define a concrete Backend that we can actually use...


URL checking We're going to improve this.

Later. Promise.

Serverlinking

Dependency


We need variables to hold these. Also, it would be cool to be able to inject them.


Let's go back a bit to our NSURLSessionBackend definition...

We need to hold state, so we need a class.


Let's define our configuration object


We can use constructor injection in our NSURLSessionBackend...

With default values

Remember: Using dependency injection helps unit-testing.


✔ Dependency Injection

✔ Enums with raw values

- Initializers with default values in their parameters encourage constructor injection.

- Once again, Swift eases unit-testing.

- Enums can be associated to a type so that their cases hold a .rawValue of that type.

- You can define their raw values by your own, or let the compiler do its magic and use the defaults.


Now the question is, why the hell are we still using NSError??


Alright, let's customize!


Let's enhance our error handling...

All of these do not appear as errors in the networking process...We usually get a success response with a status code that WE should interpret as an error, depending on the code (e.g. a 500).


Now, let's talk about parsing...

Do I have time to talk about this?

YES / NO


OK, let's talk about parsing...

User[String: AnyObject]

a.k.a. "Dictionary"

conversion


To the server



create()update()

DictionaryRepresentable




read()

From the server

DictionaryInitializable


From dictionary / To dictionary

In case there's a parsing error (e.g. a missing field).

Remember: You should NEVER initialize an invalid object.


From dictionary, example:


To dictionary, example:


✔ ErrorType

✔ Throws

- Error handling has been enhanced in Swift.

- Now you can define your own errors, which combined with the power of enums and pattern matching allow you to work in a cleaner way.

- Throwable initializers encourage better exceptions handling mechanisms, such as try/catch.

- As we saw, you can make your initializers throw any discrete ErrorType that you define.


https://github.com/inaka/JaymeMeet Jayme

✓ Open Source

✓ Issues are welcome

✓ So are Pull Requests

Jayme is basically what we just built, with some other enhancements that I haven't talked about because of time, for example:

● Pagination support (PagedRepository)● More generalization (Backend is more abstract)

https://github.com/inaka/Jayme



Meet Jayme https://github.com/inaka/Jayme




Meet Jayme https://github.com/inaka/Jayme




THANK YOU!

Any [email protected]

@pablolvillar



Software

Writing a REST Interconnection Library in Swift