The data layer (an iOS architecture part V)

Old library

The aim of this post is just to explain how to organise the data layer in an architecture. A possible definition of data layer is where the application data is being cooked and served ready for consumption to upper layers.



Data layer is fully responsible of providing data to domain layer, upper layers does not know the origin of the data ( local configuarion, local ddbb, json data, rest api…).

⛔By no means any of the data structures/classes provided by data layer could be transformed by domain or view layer components.

👉Data layer is responsible of notifying any change in the data, in that way views presenting the data affected will be invalidated and forced to fetch the data again.

Components

Data Manager

This component is the outer facade of the data layer, all the domain components will interact always with this component.

👉Data manager is responsible of requesting data to the rest of data layer components and implement all the politics related with data acquisition. Examples of those politics could be:

  • The app configuration is fetched from a rest service, when is not possible to perform such operation, then tries to recover data from persisted data.
  • Persist data remotely via rest service, when not possible data is stored locally. Later on if it is possible, data can be synchronized with the backend.
  • Depending on the criticity of the data could decide whether store data in a persisting securized area or a regular one.
  • Reset all persisted data wether is database, userdefaults or keychain. 💕Very useful if you wanted to reset the app without having to reinstall the app, or just to initialize data layer before executing unit tests.

JSON Manager

This component is the responsible to modelize data persisted in a json file.

Configuration Manager

This component is the responsible of persisting all the app settings.

Security Configuration Manager

This component is the responsible of persisting all the app settings related with the security of the app (e.g. keys, api-keys, information that could identify app user,…). Usually this component is an adaptor of keychain

DB Manager

This component is the responsible of persisting all massive app data. This component could be an adapter of Realm, CoreData or SQLLite.

👉As well as Data Datamanager no other outer component has to know the database technology that wraps.

⛔By no means any internal database entity should have to be exposed to the other components. DB Manager has to convert them to generic ones before providing then to the rest of the components. Following that rule you will get benefits of replacing db technology without major impact in the app.Replace DB technology without any impact on the app.

API Manager

This component is the responsible of fetching or persisting data in the backend via REST api’s. This component is usually an adaptor of URLSession or any other third party library such as Alamofire.

Conclusion

In this post we have reviewed which is the role of Data layer and its components. This post closes all the ones dedicated to this iOS Architecture.

Swifting a Mock Server (with Vapor)

The aim of this post is put up the level of previous post (Testing at the edge of your App with a Mock Server), just by using Vapor (a swift backend framework) and deploying server with Heroku (a cloud platform that lets companies build, deliver, monitor and scale apps).

Setup the environment

Vapor

For installing vapor backend framework just:

For creating a new vapor project, afterwards create a new git repository with the stuff generated and finally open the project:

Up to this point you will have XCode with new project:

stp

Run the project, open your favourite browser and type the url http://localhost:8080

browser

Mock server is working on local ?. Ready for getting to next level? ?

Heroku

If you do not have an account just sign up here. Later on, download Heroku command line tools, for validating installation just type (restart computer if necessary).

….finally after several minutes the mock server is deployed on a remote site, just type https://mock-vapor.herokuapp.com/ in your browser.

browser2

Implementing a dummy service

Our mock server will return .json, first thing to do is setting  content-type.  Just update View.swift extension:

Validate with any rest analyzer:

post

Adding basic fixer answer. This is what our mock servier will answer:

latest_FORCE_BUSINESS_ERROR is just a json template file.

The client App

The client app will be exactly the same presented in previous post, but obviously replacing urls.n In this case we will use three schemas:

  • Local mock server. For debugging with local mock server.
  • Remote mock server. For working with common development mock server.
  • Fixer real server. For working with final service.

Select Local mock server schema and launch the test:

tr

Deploy the mock server

At the moment there is nothing by typing https://mock-vapor.herokuapp.com/latest in the remote server:before

For deploying just push changes:push

This process can take several minutes… ?

push2

But finally we have the remote with latest, at this moment, just type: https://mock-vapor.herokuapp.com/latest. The remote server is ready!

after

Switch mock remote server

Switch oclient Mock Server Schema to lauch the tests on the client, but this time bouncing to a remote mock server.

rs

Conclusion

With this post you have seen how to deploy a remote mock server. You can use this server as a test platform or you could develop your app backend. If you were interested in investigating more you can fetch source code from here.

Useful links