Updating readme to clarify support

[jpvajda]

Hi! At Apollo we've gotten several questions on the maintainers of this repo since this is still in our Github Org, so to clarify I am proposing this change. See our docs for more info on how we are communicating this.

https://www.apollographql.com/docs/react/api/link/apollo-link-rest/

[fbartho]

@jpvajda thanks for the update. I'm happy to merge this with the suggested tweaks, but while I have you here, do you mind giving us an update on: #295 ?

I totally feel comfortable continuing to address normal feature requests, and since there's not a lot of feature changes, any bug requests within the link.

I find myself trapped, however when it comes to dependencies that Apollo used to expose, and has now deleted. I don't have repo creation powers in apollo's Github Org, and I don't have the time to maintain this additional library whose implementation I never reviewed or owned.

Given these conflicts, should we tweak the wording further? I'd in particular love a point of contact for timely input from Apollo core members on the occasional issue outside of my scope of ownership.

Thoughts?

[jpvajda]

@fbartho Sure thing! Your suggested changes are great, I committed those so feel free to merge this PR

As for your question on: #295

We are working from a private project on this particular question raised in the issue, so you can't see the linked issue, but here are the steps we are taking to resolve that.

• 1. Update graphql-anywhere README with info that communicates that we don't maintain this project - @alessbell
• 2. Address the dependency issue with apollo-link-rest - @alessbell
• 3. Publish to npm with the above changes - @alessbell
• 4. Update apollo-link-rest doc update to indicate it's maintained outside of Apollo - @jpvajda
• 5. Update apollo-link-rest readme to be more clear. - @jpvajda see Updating readme to clarify support #300

I find myself trapped, however when it comes to dependencies that Apollo used to expose, and has now deleted. I don't have repo creation powers in apollo's Github Org, and I don't have the time to maintain this additional library whose implementation I never reviewed or owned. Given these conflicts, should we tweak the wording further? I'd in particular love a point of contact for timely input from Apollo core members on the occasional issue outside of my scope of ownership.

You can definitely propose improving the language to be more explicit to the community if you feel that will help. as for a point of contact you can definitely reach out to myself (@jpvajda) and @bignimbus for any Apollo Client issues that come up that need our team's attention, feel free to just report an issue in the Apollo Clientproject and mention us if something comes up. Our team has grown a lot this year so we have a lot more maintainer eyes on the project 😎

Thanks for the maintainer support on this project. We greatly appreciate it. cc @hwillson on this as well.

[alessbell]

👋 Hi folks, cross-posting part of my comment from apollographql/apollo-client#10114:

[email protected] was just published with an updated peer deps range for graphql. (It also includes a deprecation notice.)

Since we reinstated a 2+ year old branch to add the deprecation notice to the README, bumping the peer dep version at the same time was trivial. The range includes future versions, so hopefully this will meet apollo-link-rest's needs for the foreseeable future, but given the deprecated state of graphql-anywhere we do advise moving off of it long-term.

I took a look at what would be involved in inlining the relevant function(s) from graphql-anywhere and was pleasantly surprised, so I opened this PR: #301. All tests are passing, so I'll leave it up to the maintainers to decide what the best path forward is there. Thanks!