How to architect the network system in my project?

Question

I'm developing a open source application that have a client and server side. The first version only have as client tvOS, and is being written with Swift.

Now, I'm writing the network system for my client. My client need to make requests for the API and manager websocket with the server.

What would the goods practices and technology to organize and create the network system in my application?

My last project is similar and I made something like this:

enter image description here

I have the classes Request, RequestUser, RequestEvent, RequestAnything... The Request is responsible for abstracting the logic to make a request, and the others classes (RequestUser, RequestEvent...) inherit from it. They are singletons.

But, I have some problems, for example: much coupling with the Request and, as my classes are singletons, I have hidden dependencies in my controllers.

Would there be some way better to architect the network in my new project?

Answer 1

Do you need a singleton ?

According to the GoF, the intent of a singleton is:

to ensure that a class has only a single instance and to provide an access point to it.

But is there a reason that justifies that a RequestUser really has to be unique across your application ? Or was it just a design choice because it was convenient to easily find back the active user, assuming that the client would be for a single user ? And if so, can't you imagine a future version of your client that would connect to several information sources and combine them, thus needing several active RequestUsers ?

Don't use a singleton, unless you really have to. The convenience of finding it back is more than outweighed by the many hidden dependencies that it favors.

Is it really inheritance ?

It's not clear to me, if:

1. RequestUser inherits from Request because you have a stateful backend and RequestUser is really a distinct Request,
2. or if you just want RequestUser to inherit from a couple of behaviors, such as for example formatting an URL part that will be combined with other parts to build the real request.

In the first case, the inheritance is fine. In the second, it's not a safe design, and you should favor composition. In both cases though, you create a structural dependency between your client and the back-end logic in terms of sequence of operations and communication scheme.

Alternative design: the mediator

You may decouple your components much more by opting for the mediator pattern.

With this pattern, the user, the event and other request topics would become colleagues, inheriting from a base class that provides the common behavior.

A mediator would then encapsulate the interactions between the colleagues. That object, and that object only, would then have to find the current user objet for the current request and manage these kind of dependencies explicitly.

It may be difficult to change your current frame of thinking. However this pattern is really worth the investment: because once the mediator encapsulate the interactions, you no longer have to care if it's a stateful or a stateless back-end in any other places of your code: the mediator would combine the behaviors as required.

• Macabeus: I made RequestUser inherits from Request for the second reason: Request format the URL, send the package for the server and convert the data to JSON. Well... much responsibility in one single point...
• Macabeus: Thank you very much! Your answer helped me to clarify. I will learning more about this pattern. And, I read this blog post that helped me: medium.com/compileswift/network-layers-in-swift-7fc5628ff789
• Christophe: @Macabeus Interesting article, definitively worth reading !