TeamNewPipe / web-api

REST API providing external data feeds for the NewPipe website. Written as a micro service. In Python.
MIT License
22 stars 9 forks source link

Information for download section #1

Open TobiGr opened 6 years ago

TobiGr commented 6 years ago

For the new download section I suggested in TeamNewPipe/website#50 we need to gather some more information. First we need the current stable and beta release. Since we can't get the latest beta release via the GitHub API without going through all releases, my idea is to use F-Droid's release data: https://gitlab.com/fdroid/fdroiddata/raw/master/metadata/org.schabi.newpipe.txt. One big advantage is that we'd only promote new releases which are already available on F-Droid. I think that's necessary since I use the download icon as link to NewPipe's F-Droid release page.

It shouldn't be that hard to find the line that contains the current version , the matching build / tag and version code. With additional information from the changelogs dir (which we should use btw to tell people in the F-Droid app directly what changed), we can display some more details about the releases.

I'd suggest following structure for that: api/[stable|beta]/current/[version/changelog].

I don't like the idea of doing it with JS, but since we are going to need that information for the "What's New" dialog too, we should implement it in this or a similar way.

Another idea is to write a .YML file in _data with a shell or python script. This data could be easily used by Jekyll in the site generation process and wouldn't require JS scripts. With this data it would also be possible to provide the api for the app as long as we don't need to much information. A small disadvantage is that we'd need to re-generate the site twice a week or so.

What do you think @TheAssassin. Should we try to do it with a shell script?

TheAssassin commented 6 years ago

Since this is dynamic data, it can't go into the website repository without having a service or cron job make a commit whenever data changes. Therefore, we should do it here in the API.

If you design a JSON format containing the data you need, I can code the necessary parts in the API required to fetch and convert the upstream data.

TobiGr commented 6 years ago

I'd suggest something like this. If you have any alternative, please tell me.

api {
    "stable": {
        "version": "1.0.0",
        "changelog": "something HTML escaped"
    }, 
    "beta": {
        "version": "1.0.0beta",
        "changelog": "something_"
    },
    "githubStats": {
        "stars": 3030,
        "contributors": 180,
        "commits": 1800,
        "languages": 43 /* WebLate */
    }
}

If necessary, we could prefix or group the stable and beta with app. This might me helpful when the Android TV version is available. But I guess TeamNewPipe/NewPipe#939 needs some more time until this separate APK gets released.

TobiGr commented 6 years ago

Can you also provide the data in JS format like this:

var api = {
  "stable": ...
  ...
};

It would be extremely helpful for me because I could include it much easier in the website. And contributors, commits and languages are not that important. When you do not have time to get this data, it is not a problem for now.

TheAssassin commented 6 years ago

Your first example isn't valid JSON anyway.

I suggest something slightly more generic:

{
    "flavors": {
        "stable": {...},
        "beta": {...},
    },
    "stats": {
        "github": {...}
    }
}

I'd work out the final layout while writing the API, if that's okay for you.

TheAssassin commented 6 years ago

I rewrote the HTTP fetching code to make all requests in parallel, the API runs in about the same time as before. It fetches the stargazers count from GitHub, stable and beta versions, etc., and assembles a single JSON object containing all the information:

{
    "flavors": {
        "beta": {
            "version": "v0.12.0-beta"
        },
        "stable": {
            "version": "v0.11.6"
        }
    },
    "stats": {
        "stargazers": 3051
    }
}

We can easily extend this, with further requests, or other data from the ones already performed.

I'll commit the current state soon. I won't deploy it until you adjusted the website's code.

TheAssassin commented 6 years ago

Current state:

{
    "flavors": {
        "beta": {
            "version": "v0.12.0-beta"
        },
        "stable": {
            "version": "v0.11.6"
        }
    },
    "stats": {
        "contributors": 30,
        "forks": 467,
        "stargazers": 3051,
        "translations": 43,
        "watchers": 3051
    }
}
TobiGr commented 6 years ago

Thanks!

TobiGr commented 6 years ago

With additional information from the changelogs dir (which we should use btw to tell people in the F-Droid app directly what changed), we can display some more details about the releases.

@TheAssassin 2nd paragraph of my first post :)

@theScrabi Can you please add changelogs for the next releases? I'll need that for the website and the What's New dialog in the app. See the F-Droid docs for more info. Thanks!

TheAssassin commented 6 years ago

@TheAssassin 2nd paragraph of my first post :)

I built the API after the data model you provided. I'll work on it maybe on Thursday.

TobiGr commented 6 years ago

Thanks