[DISCUSSION] Remove wikimedia android data client

[macgills]

Summary:

The library is out of date and unmaintained (I believe) making it more difficult to integrate with new APIs or model changes. We should move the code into our codebase.

[misaochan]

I was under the impression that we were maintaining a fork of this? @maskaravivek

[sivaraam]

The library is out of date

Given the fact that the library is claimed to be a successor of the mediawiki:api I would say it is far from being outdated. If anything, it must be more up-to-date. "Incomplete" might be appropriate.

... and unmaintained ...

I don't think it is. There have been changes in the upstream as recent as November 2019.

I also have one comment related to @maskaravivek's comment at #3257 (where this discussion originated):

Yes, there's a lot of history behind why the data-client came into picture and honestly I would prefer to have everything in our main codebase rather than maintain a library that too for model classes which keep changing frequently.

IIUC, the library provides a nice model to access the Mediawiki and REST API's response. And I thought the API response would be stable and thus the model would not need to be changed. I don't understand why the model needs to be changed frequently. What am I missing?

[sivaraam]

Having said that, as of now it's interesting to note that the Wikipedia android app (from which the library originated) itself doesn't seem to be using the external library. It seems to be using a version of the library present within its codebase.

[misaochan]

This was the maintainer's (@dbrant 's) recommendation to me in Aug 2019 when we were encountering issues with needing to make a modification to the library:

Therefore, for the time being, I would recommend that you simply take the current source files that you're using from the library and copy them into your project (keep making any modifications you need), and no longer depend on the library. At a later time, when the new endpoints and models are settled, we may revisit publishing a common client library that will factor in the needs of both products, but I'm afraid that doing this today would be prohibitively difficult.

I am personally OK with either option - (1) maintaining the fork as a separate library or (2) putting everything into our main codebase. However, it would be great if we could get an updated recommendation from @dbrant in case anything has changed on WMF's side. :)

[macgills]

I am in favor of 2 as the description says

[maskaravivek]

I am also in favor of 2. To make the transition easier, maybe we could add it as a library module in our codebase.

[misaochan]

To make the transition easier, maybe we could add it as a library module in our codebase.

Sounds good to me. Let's give it a few days in case we get an update from dbrant, if we don't hear anything we can start doing this next week?

[dbrant]

Oh hey 👋
Yes, please do proceed with the option that is most sensible to you.

The problem with the "data-client" library is that it was a little too ambitious in scope, and ended up containing too much business logic that was specific to our product.

For the future, it might be a good idea to have a shared library that contains only the model classes that are returned by the API, and nothing else. (i.e. no network services, no utility functions, etc.)

[misaochan]

Thank you for the update, @dbrant ! I agree that a more simplified shared library would be a better idea in the future. :)

Seems like we are all on board for option 2. Feel free to take this up, anyone!

[macgills]

Library modules often lead to a bit more overhead in the setup, I am fine just copying them to a distinct package inside commons. Modular applications have many benefits but I don't think we get any of them right now and you get a bit of complexity

[maskaravivek]

@macgills I suggested adding it as library module as I thought it might be the easiest way to setup as the project is already setup as an Android library.

I just did it locally and it hardly took me 5 minutes to set it up.

My first focus was to get this as part of our code base as quickly as possible. I am okay moving stuff to the app too but it might be useful to have it modular.