This is also why inits are required here, you cannot automatically synthesize a publicly accessible initializer with Swift struct.Why do the data models conform to Hashable?Considering we require Equatible conformance for testing equality within our unit tests, conformance to Hashable will acheve this, as well as providing a hashValue property should we require it for caching.Dealing with Optionality within GraphQL data ????After defining our data model in Swift structs, we should create optional initalizers for these objects from the GraphQL models..This will make actually parsing our data and transforming it into our domain models within our service simple..Apollo makes everything optional ????, so all of our initializers are failable..You might know a better way to remove optionality from GraphQL data, please post a comment if you do.We will rely on flatMap and compactMap when it comes to transforming to deal with optionality.The Swift Networking Service ????Let’s begin by defining a protocol for our Store's interface.Next, let’s define a protocol describing only the functionality from Apollo which we need, called ApolloClientInterface..For now, this is only Queries, as we are not preforming any Mutations..From there, let's ensure the ApolloClient conforms to our protocol.We will use the Result library to handle Success and Failure states for our network calls..This simplifies error handling, and returns Result<Value, Error> within an async completion block.Now that we have our interfaces defined, lets create our actual service class.Network Service Usage ????First, we can add a factory to produce the World.Store objects.At he usage point where we would like to call our service we will create the factory and initialize the store.The result should contain the folowing data when you po result in the LLDB.In part two, we will implement unit tests to gain ~98% test coverage on our store object through mocking Apollo.Originally published at gist.github.com.. More details