{"id":55106,"date":"2022-07-01T13:57:13","date_gmt":"2022-07-01T08:27:13","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=55106"},"modified":"2022-07-06T11:33:13","modified_gmt":"2022-07-06T06:03:13","slug":"networking-layer-with-combine","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/networking-layer-with-combine\/","title":{"rendered":"Networking layer with Combine"},"content":{"rendered":"

What is Combine?<\/b><\/p>\n

The Combine<\/b> Framework – A framework rolled back in 2019 that works on the fundament of Functional Reactive Programming (FRP) paradigm similar to RxSwift and ReactiveSwift. It is developed by Apple and can be seen as a 1st party alternative to RxSwift and ReactiveSwift.<\/p>\n

Let\u2019s read from the documentation:<\/p>\n

Customize handling of asynchronous events by combining event-processing operators.<\/i><\/a><\/p>\n

This article takes liberty assuming that we have the basic understanding of the three key moving pieces in Combine which are publishers<\/b>, operators<\/b>,\u00a0subscribers,\u00a0<\/b>and how we can create a Combine Pipeline<\/b>.<\/p>\n

\"Example<\/a>Example of Combine Pipeline<\/a><\/p>\n

In this post, we\u2019ll talk about the implementation of the networking layer using Combine. <\/b>While in the implementation we will touch on some topics like Protocols<\/b>, Generics, Associative Protocols,\u00a0<\/b>and Of Course Combine\u2019s flavor of URLSession<\/b><\/p>\n

Before we jump into writing the Networking Layer using Combine, <\/b>let’s revisit the \u201cCall back\u201d<\/b> type network layer we generally have been implementing in our code.<\/p>\n

In this networking layer, we have defined a few protocols that define our API abstraction. To highlight the Combine\u2019s way of networking layer<\/b>, It will be more related if we refactor the \u201cCall back\u201d<\/b> (closure) type network layer. On a refactoring adventure like this, it’s a good idea to start by changing the protocols first and update the implementations later.<\/p>\n

Link to CallBack Type Request Protocol<\/a><\/p>\n

Before we update the protocol let\u2019s spend some time understanding these Protocols and their purpose. As mentioned we\u2019ll brush up on a few advanced swift topics like Protocols<\/b>, Generics, and Associative Protocols.<\/b><\/p>\n

As we see in the code above there are many protocols, so do we really need them?? Well honestly no we don\u2019t but we should if we want our app and the API to be decoupled, which in turn will allow us to mock it easily for testing.<\/p>\n

Let me say it loud: Protocols <\/b>are AWESOME.<\/b><\/p>\n

Now let\u2019s analyze the protocols in detail:<\/p>\n

Request<\/b> :<\/p>\n

\/\/ An AssociatedType Protocol: Request type to be implemented by Concrete Requests<\/b><\/p>\n

\"\"<\/a><\/p>\n

Link to CallBack Type Request Protocol<\/span><\/a><\/p>\n

This Request type is an associated Type Generic Protocol that defines two associated types to operate on.<\/p>\n

    \n
  1. Response type <\/b>constrained to be decodable<\/li>\n
  2. ResponseParser<\/b> is constrained to be of ResponseParserType<\/b> where ResponseParserType is another ATP over Response type. Also, We type constrain ResponseParser to be able to guarantee that Parser is for the correct Response type.<\/li>\n
  3. We have defined a few required properties for the request.<\/li>\n
  4. Next, we have an errorParser of ErrorParserType <\/b>Protocol Type that allows the Implementing Request type to use a custom error parser over the default one.<\/li>\n<\/ol>\n

    That very much describes the Request Protocol<\/b> that will be used by our app code to declare every request type.<\/p>\n

    But, this protocol remains as-in. It doesn\u2019t use the callback so we don\u2019t have to convert this to use combine.<\/p>\n

    Next, RequestExecutor :<\/b><\/p>\n

    This protocol declares the abstraction for the request executor implementation. This will help us to switch over the API (Framework) making requests.<\/p>\n

    \"\"<\/a>

    Link to CallBack Type Request Protocol<\/span><\/a><\/p><\/div>\n

    Mark the use of generic type but let me make this clear that it is just a Protocol with a function that accepts generic requests. It is an implementation of type erasure<\/b> concept that allows the use of the Generic Protocol as type.<\/p>\n

    And This is not an ATP (associated type Protocol)<\/b><\/p>\n

    That will pretty much make our Networking API. Let\u2019s just see the implementation of RequestExecutor.<\/strong><\/p>\n

    \"\"<\/a>

    Link to RequestExecutor Implementation<\/span><\/a><\/p><\/div>\n

    The code is self-explanatory as it just implements the RequestExecutor<\/b> protocol.<\/p>\n

    The function executeRequest<\/b> is where all the magic happens. It takes the request type and converts it to URLRequest through RequestConvertible<\/b> to use it with the newly created dataTask. You will notice how conveniently the validations of using the right parser and response type are kept with Request type<\/b> and the only job of the request executor is to make network calls.<\/p>\n

    And that is what a scalable network layer will take to work.<\/p>\n

    But wait, where is Combine ?<\/b><\/p>\n

    Yes, It is the time to start over and Combine.<\/b><\/p>\n

    We\u2019ll start by refactoring the RequestExecutor<\/b> protocol, As it was the only protocol in our API abstraction that makes use of Call back <\/b>(closures).<\/b><\/p>\n

    \"\"<\/a>

    Link to Combine’s Network layer Protocols<\/span><\/a><\/p><\/div>\n

    Link to Combine’s Network layer Protocols<\/a><\/p>\n

    This is what RequestExecutor<\/b> refactor is all it takes to be used for Combine.\u00a0<\/b><\/p>\n

    The changes:<\/p>\n

      \n
    1. We removed the call back parameter instead there is a return type of AnyPublisher<\/b> Generic over Request\u2019s response and Error.<\/li>\n
    2. Refactoring also saw use of Generic where clause<\/b> for constraining R<\/b> type with RequestConvertable<\/b>. but it’s just a syntactic change induced to brush up the use of where clause.<\/b><\/li>\n<\/ol>\n

      Note that there is use of AnyPublisher<\/b> which is common in Combine with its own benefits. But Why not use the Publisher specifically available URLSession.DataTaskPublisher<T, Error><\/b> over DataTask. The reason for not using DataTaskPublisher or any other specific publisher is to not make our executeRequest <\/b>function tightly coupled with the implementation. We\u2019ll talk more on AnyPublisher<\/b> in a while.<\/p>\n

      That is all with the refactoring part of Protocols, The next step is to refactor the actual implementation of these abstractions.<\/p>\n

      Let\u2019s now see the simple use of URLSession.DataTaskPublisher <\/b>for making Web api requests and then we\u2019ll add it to our Refactoring.<\/p>\n

      Data task with Combine:<\/b><\/p>\n

      \"\"

      Data task in Combine<\/p><\/div>\n

      This pipeline defines the urlSessionPublisher<\/b> and subscribe it using sink <\/b>subscriber. <\/b>That is the most basic form of combine\u2019s pipeline for DataTask.<\/p>\n

      This does the job of making requests over the network and fetching us the data, url response objects. But using it in our implementation is still a long way.<\/p>\n

      Let\u2019s evolve the current pipeline using some awesome operators.<\/b><\/p>\n

      \"\"<\/a>

      Link to Network Subscription Stream with operators<\/span><\/a><\/p><\/div>\n

      This is much evolved now, let\u2019s talk about these updates to our pipeline.<\/p>\n

        \n
      1. We are using map operator to transform the output (data: Data, response: URLResponse) <\/b>of urlSessionPublisher to data ignoring the response.<\/li>\n
      2. decode<\/b> is used to load the data and attempt to parse it. Decode<\/b> can throw an error itself if the decode fails. If it succeeds, the object passed down the pipeline will be the struct from the JSON data.<\/li>\n
      3. In case of any error we handle it here using replaceError<\/b>, as we don\u2019t want our pipeline (Subscription) to finish with failure.\u00a0 We may also use the catch <\/b>operator instead of using replaceError. But it is to mind that even with replaceError<\/b> or catch<\/b> operator if there is an error in the stream, it will end up by finishing the pipeline.<\/li>\n
      4. Using eraseToAnyPublisher()<\/b> to expose an instance of AnyPublisher<\/b> to the downstream subscriber, rather than this publisher\u2019s actual type. This form of type erasure<\/i><\/b> preserves abstraction across API boundaries, such as different modules. When you expose your publishers as the AnyPublisher type, you can change the underlying implementation over time without affecting existing clients.<\/li>\n
      5. As we handled the error using replaceError<\/b> on step 3, this closure will get invoked with an Array of Posts data or an empty array in case of error.<\/li>\n
      6. It shows how we can cancel a subscription. (Comment it if testing the code)<\/li>\n<\/ol>\n

        This is much better. But what about if we don\u2019t want to replace the error with empty data. Let\u2019s fix that.<\/p>\n

        Raising Error and Stricter Network request processing stream:<\/b><\/p>\n

        Here we are going to update the above-created combine network pipeline to raise errors and normalize them to errors that our Application will understand.<\/p>\n

        Combine has a family of try-prefixed operators, which accept an error-throwing closure and return a new publisher<\/i>. The publisher terminates with a failure in case an error is thrown inside a closure. Here are some of such methods: tryMap(_:), tryFilter(_:), tryScan(_:_:)<\/p>\n

         <\/p>\n

        \"\"<\/a>

        Custom Error to be used for Networking Layer<\/p><\/div>\n

        \"\"<\/a>

        Network Subscription Stream with Error Handling<\/span><\/a><\/p><\/div>\n

        Use of tryMap<\/b> over map and use of mapError<\/b> blocks are the main update to our network request processing pipeline.<\/p>\n

          \n
        1. With the tryMap operator, the response from dataTaskPublisher<\/b> is immediately inspected and we throw an error of desire if the response code is not in range.<\/li>\n
        2. Same as the above pattern we decode the response, but there is a commented part, we may use the tryMap closure with normal Decoding and throwing error of our choice if any.<\/li>\n
        3. With mapError<\/b> we convert any raised error types down into a common Failure type of APIError<\/b> or ParseError<\/b><\/li>\n<\/ol>\n

          With the above changes to our pipeline, we achieved the expected error handling.<\/p>\n

          Wooo!<\/p>\n

          That was a lot on Combine\u2019s network data processing pipeline.<\/p>\n

          With all that knowledge we gain in the last part it’s time to move back on our Network layer Refactoring and apply these.<\/p>\n

          We\u2019ll go back to our WebApiClient<\/b> class and implement the refactored RequestExecutor <\/b>protocol.<\/p>\n

          As I have already explained the basic single-shot pipeline using DataTaskPublisher, tryMap, mapError. <\/b>Our refactored WebApiClient will end up as below.<\/p>\n

          \"\"<\/p>\n

           <\/p>\n

          Link to Combine’s RequestExecutor Implementation<\/a><\/p>\n

          The above code is just a combination of all that we learned in Error handling and using Error Mapping. But before I go on to explain the whole Network layer Pipeline, let me remind you of my promise to explain the use of AnyPublisher<\/b> type over DataTaskPublisher<\/b> while refactoring RequestExecutor<\/b> protocol, Here it is !!<\/p>\n

            \n
          1. Used a Fail<\/b> publisher that immediately terminates with the specified error. And I erase it to any publisher. This is used in case try? request.asURLRequest() fails to create the request and ends up throwing an error. By using AnyPublisher we are able to return any type of publisher even before we create our DataTaskPublisher\u2019s instance.<\/li>\n
          2. Just shows that we may also use the CurrentValueSubject publisher to emit an error.<\/li>\n
          3. After we have the right request instance we need to create a publisher that actually makes the request call. We do so by creating the DataTaskPublisher instance.<\/li>\n
          4. We may have used a map operator, but the mapping operation can throw an error, so we use tryMap instead. Making use of the tryMap<\/b> operator allows us to check the response code and if anything goes wrong we throw an error.<\/li>\n
          5. Here again,\u00a0tryMap<\/b> is used for using our old parsers that may also end up throwing errors. Provides us with the flexibility to use our custom parser instead of using the Decode<\/b> operator we saw earlier.<\/li>\n
          6. There may be many types of error we may encounter, So to make them one type that our calling code can easily handle we use mapError<\/b> as explained above.<\/li>\n
          7. A scheduler that allows us to switch back to the main queue.<\/li>\n
          8. Finally, we erase the publisher to any type.<\/li>\n<\/ol>\n

            This brings us to the end of the article but feel free to check out the demo project<\/a> to learn more about how we end up using this network layer.<\/p>\n

            Don\u2019t forget to add your api key in WebApiConstants class. Get one from here<\/a>.<\/p>\n

            Also check the use of Generics<\/b>, Protocols<\/b> and Dependency Injection<\/b>.<\/p>\n

            <\/div>","protected":false},"excerpt":{"rendered":"

            What is Combine? The Combine Framework – A framework rolled back in 2019 that works on the fundament of Functional Reactive Programming (FRP) paradigm similar to RxSwift and ReactiveSwift. It is developed by Apple and can be seen as a 1st party alternative to RxSwift and ReactiveSwift. Let\u2019s read from the documentation: Customize handling of […]<\/p>\n","protected":false},"author":1138,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":51},"categories":[1400],"tags":[4987,4988,4989],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/55106"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1138"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=55106"}],"version-history":[{"count":8,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/55106\/revisions"}],"predecessor-version":[{"id":55174,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/55106\/revisions\/55174"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=55106"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=55106"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=55106"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}