Why deprecated?

[fidelix]

The plugin could instead make the endpoint configurable, so it would still be very much relevant.

Is there a reason this repo will be deprecated when people can still self-host mercury?

Thanks,

[HenryQW]

Hi @fidelix , there will definitely be an option to do what you have described.

I'm currently working on integrating a dockerized mercury API into my all-in-one TTRSS solution here.

[fidelix]

Okay, so where will the plugin code reside?

Do you plan on making it configurable for custom endpoints?

[jamespo]

@fidelix I forked and put basic custom endpoint support in https://github.com/jamespo/mercury_fulltext

Seems to work for me. Can open pull request to merge back in if desired.

[HenryQW]

@jamespo thanks for the input. However, this might break the existing setup for many users, there should be a fallback option until Mercury API is fully deprecated in 59 days.

[HenryQW]

Also, exposing self-hosted API without authentication seems to be a bad idea to me. My plan is to make the API a dockerized service and only accepts requests from localhost.

[jamespo]

The default binding for the Mercury API server is localhost:3000 so you'd have to wilfully expose it, at least.

[HenryQW]

Not really if it's dockerized (I've got one image here) and you let Docker do the discovery:

version: "3"  
services:
    database.postgres:
      image: sameersbn/postgresql:latest
      expose:
        - 5432
      networks:
        - rss-cluster

    service.mercury:
      image: wangqiru/mercury-parser-api
      expose:
        - 3000 # in fact, this is not even required. I put this down as a reminder of the actual port used. 
      networks:
        - rss-cluster

    service.rss:
      image: wangqiru/ttrss:latest
      ports:
        - 8888:80
      networks:
        - rss-cluster
      environment: 
        - DB_HOST=database.postgres

networks:
  rss-cluster:

Your endpoint would then be service.mercury:3000 and it's only accessible within rss-cluster network.

Another option would be adding authentication to Mercury API but I'd prefer the above way.

[fidelix]

I thank you for the good work, but I have no intention of using docker composer.
There are many scenarios where that is not an available option or may not be desired at all, so having something that is self-contained would be optimal for me and some others.

That is why I asked whether this repository would still be maintained, because the repository makes perfect sense by itself and is working well for me - save the configurable endpoint.

Also, exposing self-hosted API without authentication seems to be a bad idea to me.

Naturally, it depends who you are exposing to.
If it's only to a closed network then it's perfectly acceptable, and I think it should not be the responsibility of an API client to enforce the deployment strategy of its API server.

[jamespo]

I'm running tt-rss (and now mercury) on a 768mb OpenVZ 6 VPS so docker isn't really an option. Mercury is bound to localhost, but if I was opening it up I'd prefer nginx or another webserver to handle the auth.

However for other platforms docker will of course make things much easier.

[HenryQW]

@fidelix @jamespo Thank you both for your input, really appreciate! The master branch now hosts the configurable endpoint version.