1

I've been playing around with Clean Architecture and VIPER.

Yesterday a friend asked me why not put the Interactor logic on the server and just sync the processed data to the iOS client, instead of sending raw data and processing on the Interactor. This would have a lot of benefits, as being able to change the logic at will, less code to replicate on multiple clients (iOS and Android, for example), etc.

For an example, say we have a list of Profiles and a list of Posts. Each post has an image and a profileID.

And let's say we wanted a screen showing a table view with all the posts' images and when the user taps on a post, we show the respective profile on a separate screen. In the profile, we would show the name and all the images posted by that profile.

If we leave the logic on the client, we'd be syncing data like this:

{
    profiles: [
        {
            id: "...",
            name: "..."
        },
        ...
    ],
    posts: [
        {
            profileID: "...",
            imageURL: "..."
        }
    ]
}

Then we'd have a ShowPostsInteractor that would just return the data for all posts and a ShowProfileInteractor, which would filter the posts' data to grab just the posts from that profile, then it would return some data to the view like:

{
    name: "...",
    imageURLs: ["...", ...]
}

The second alternative is to leave this logic on the server, in which case the synced data would be:

{
    profiles: [
        {
            id: "...",
            name: "...",
            imageURLs: ["...", ...]
        },
        ...
    ],
    posts: [
        {
            profileID: "...",
            imageURL: "..."
        }
    ]
}

(note the addition of imageURLs in profiles)

And the ShowProfileInteractor would just pass the profile data as it is to the view, since it wouldn't need to filter the posts anymore (this was done by the server).

Sure, the second approach duplicates some data, but since it's just strings, this wouldn't be very relevant.

I've seen the first approach done more often. So my question is, why would I not do the second approach (leave as much logic as possible on the server) and maybe removing all the interactors from the client, letting the controller access gateways directly, since there would be no processing of the data?

Rodrigo Ruiz
  • 4,248
  • 6
  • 43
  • 75

1 Answers1

1

I might be wrong, but I don't think Clean Architecture was designed with mobile or SPA apps in mind. I've always seen it as a good old fashioned web application centered thing with the interactor on the server side.

The rationale is that the architecture should be

Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules

Pushing the interactors to the client side defeats that goal, IMO.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
  • So you'd implement the second example I gave? Also, as for Clean Architecture for mobile, look at VIPER (https://www.objc.io/issues/13-architecture/viper/) – Rodrigo Ruiz Jul 28 '16 at 17:56
  • OK, so it seems like they're treating the server as just another data store. It kind of makes sense. I'm still not 100% convinced that Clean Architecture is a good fit for mobile. `The same Interactor could be used in an iOS app or a console application`, as described in VIPER, is not exactly the same as `replacing a UI with another`. Generally speaking, there's a lot less benefit to being able to defer architectural decisions in mobile than in a web application, IMO. – guillaume31 Jul 29 '16 at 05:18
  • Regarding your question, I would say yes, especially if you're planning on adding more mobile platforms. Writing the interactor in multiple client languages makes it less maintainable. But how much processing you're willing to do on the server vs client is also an important part of the equation. And I don't know if VIPER lends itself well to moving the interactor to the server side. – guillaume31 Jul 29 '16 at 05:28