Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Implementation Question: Requests as Class Methods #324
I'm in the early stages of developing an iOS application, which will consume a REST API. While GitHub, Apple docs, tutorials, etc. have been helpful in answering the majority of my questions thus far, I've recently experienced some hiccups while trying to learn more about networking. I haven't found an good, consolidated source of information regarding best practices/design patterns related to building out the networking layer of an application. I recently came across the source code for Artsy and have been reading over it as a guide to building a framework for consuming an API.
I do have a few questions though. Please, forgive me if they sound naive. Why is that the majority of the actual requests are implemented as class methods? What are the advantages of this approach, as opposed to creating some sort of "shared" singleton, which you would use to instantiate/get an instance of ARRouter and then make requests?
Also, there are calls to these ArstyApi class methods spread throughout. However, I don't understand exactly where/how this class is declared globally, allowing it to be recognized across many different class implementations.
Lastly, do you have plans to "Reactify" any portion of the networking layer. From what I've gathered, ReactiveCocoa and the functional programming it enables is a great fit for code that is heavy with callbacks/handlers, etc. A few other articles and iOS source code examples I have come across (SoundCloud and Timehop) have mentioned that if they haven't already done so, they were at least planning to adopt a more "Reactive" style within upcoming iterations of their code, specifically the networking layer.
Thanks for the help!
This is personal, but I've always favoured the look of class methods over
Networking is done in 4 ways at the minute,
They all have different use cases, and came about from different constraints. The network models make it really easy to test code, promise based networking makes it easy to hook a lot of callbacks into the same request, model networking can make it feel like it's just an asychronous call to fetch some data. And accessing the raw api methods is for when we've had time constraints.
There's discussion on our Mobile repo around trying to unify into a single pattern. More on that in your next question.
I'm not entirely sure on how well Moya's enum style can scale for something like eigen, given that for the ~30 routes eidolon uses, it's a 360+ lines of code long API client, even roughly guessing I'd expect eigen to have a hundred plus routes. With a lot more custom messing around. Plus it's swift only, and that's not really production ready for us.
I've explored methods of generating NSURLRequests automatically using documentation so that we can try and concentrate on something that fits similar constraints to what we have for Moya:
I've spent time with ReactiveCocoa now, but I'm not sure I'd want to build more things on it personally. The eigen codebase allows you to work with RAC if you choose, but you can also carry on fine wihtout. I wouldn't want our networking to be purely rac based. I think we could re-thing the promise-based networking into a useful system, which is what we were doing a lot in Eidolon.