apollo-ios VS RxSwift

GraphQL queries are just HTTP POST queries with a JSON body. They're supported everywhere.

If you want specialized tooling for them, Kotlin and Swift both have great strongly-typed GraphQL libraries.

Apollo publishes libraries for both:

- https://www.apollographql.com/docs/kotlin/

- https://www.apollographql.com/docs/ios/

apollo-ios - A strongly-typed, caching GraphQL client. Language: Swift.

RFC: apollo-ios/CodegenProposal.md at release/1.0-alpha-incubating · apollographql/apollo-ios · GitHub Example Generated Output: apollo-ios/Tests/ApolloCodegenTests/AnimalKingdomAPI/ExpectedGeneratedOutput at release/1.0-alpha-incubating · apollographql/apollo-ios · GitHub PR for discussion is here: [RFC] In Progress - Release 1.0 - Swift Codegen by calvincestari · Pull Request #1876 · apollographql/apollo-ios · GitHub

Apollo iOS, on the other hand, generates Swift types from queries in our "queries.graphql" files and supports caching out of the box. Generating types from the SDL is not per se a problem, but it becomes cumbersome and error-prone with large nested queries. Apollo iOS also strongly-binds the generated structures to your queries, making it almost impossible to translate fetched data into an internal state.

Apollo Client does have a good integration with these frameworks including React, iOS and Android — so, you might want to check that out

I use RxSwift/RxCocoa and The Binder Architecture. That way View Controllers always show the most recent data from the service.

RxSwift - Reactive Programming in Swift. Language: Swift.

I do this with RxSwift and my CLE library. Using those you can do something like this:

I've tried going to RxSwift's source and copying the RxSwift folder into my playground file's Source folder but no dice, it complains about a source file not being found. I tried flattening all the files into one folder and had the same problem.

We have defined what async code is, and two basic issues we could have when working with it: running tasks serially and in parallel. For running tasks in parallel we saw that DispatchGroup can be a simple solution for that. I will recommend using a library for this though. What I taught you here is basic async knowledge, but in real world scenarios, this won't be this straightforward, so using a battle tested library is always an advantage when working in production. I personally recommend using Apple's Combine if you can (it is supported in iOS 13 and above) or using RxSwift otherwise Finally, I can't finish this article without mentioning async-await. With async-await, probably all of this discussion will be a thing of the past. It lets us write async code that can be written like sync code. You can see the proposal (already implemented and that will be released in the next version of swift) here, and even try it in your code following a tutorial like this one.

I think this is the most important thing to understand with all your heart. All subjects, relays and operators might seem scary, especially with Rx-hermetic jargon. But simplifying it in your head to a simple collection will help you to understand all concepts easily. For me it was a sudden click. If you want to learn more, official docs are great source and emphasize this concept: https://github.com/ReactiveX/RxSwift/blob/main/Documentation/GettingStarted.md#observables-aka-sequences