IS THIS REPOSITORY STILL MAINTAINED?

[onhate]

There are tens of PRs pending to be reviewed, some of them with fixes that are pretty important and I don't see a single comment on any of them.

Who is the responsible for reviewing the open PRs in this repository?

[flux627]

Looks like the last non-bot, non-documentation PR that was merged happened on March 11th 2019... doesn't look good.

[onhate]

@abernix @ashleygwilliams @cheapsteak @daniman @DxCx @evans @helfer @hwillson @jasonpaulos @jbaxleyiii @jbaxleyiii @jgzuke @ndintenfass @pcarrier @peggyrayzis @trevor-scheer @trevorblades

anyone?

[Sytten]

It seems to me that it is on the low priority side for apollo team. Though we don't currently have any choice but use it when using apollo server.

[hwillson]

Sorry all, the Apollo team is unfortunately tied up in other areas (we're actively hiring if anyone is interested!). Would someone here be able to list the most important outstanding PR's, that we could quickly sweep through, to get into a new subscriptions-transport-ws release? I'm not familiar enough with this project to know what is the most pressing, but if someone can help I can get a new version published.

[onhate]

hi @hwillson thanks for the attention, I've collected this list of PRs that are relevant and have the minimal requirements to be reviewed (tests...), some of them are pretty old and I'm not sure if the owners will still be willing to rebase, fix merge issues, but I could managed that if I have the permission for that.

#775
#675
#615
#599
#587
#561
#514
#347

There's also a big list of Documentation PRs that are pretty simple to be merged, and some PRs that can just be closed as they are irrelevant or unfinished work, I could make a list of those too if needed.

[Sytten]

@hwillson I think it could be very beneficial to have a team from the community to maintain this critical package so we don't have to wait months to get approval for PRs. Just an idea!

[hwillson]

@Sytten for sure, I agree - we're discussing this more internally, and will post back shortly.

[onhate]

count on me for that

[Urigo]

Hi @hwillson, I believe there might be a better solution than just merging some PRs and releasing a new version, without a long term vision for maintenance of the library.
That way we'll get to the same place we are today very quickly...

As a member of The Guild and also someone who happen to write a lot of the code on this library (together with @dotansimha), we would love to take the maintenance burden of the repository and transfer it to us.

Please let me know if that aligns with your strategy.

[hwillson]

Thanks very much for the offer @Urigo - we'll definitely keep this in mind!

[james-pellow]

I would like to add my +1 here. We depend on this library as well, and would love to see a new release with the mentioned PRs.

[enisdenjo]

Check out the refreshed GraphQL subscriptions WebSocket client: graphql-transport-ws@v0.0.2. This version follows the GraphQL over WebSocket Protocol described in this repo, meaning - it is a drop-in client-side replacement of this library.

UPDATE:
🎉 graphql-transport-ws@v1 has just been released. It follows a revamped GraphQL over WebSocket Protocol, check it out!

[onhate]

Looking forward for 0.9.18 release! 😃

[hwillson]

0.9.18 has been published, and should address a lot of the items discussed in this issue. Thanks all!

[Sytten]

@hwillson There is still no clear path for future maintenance, still 28 PR open and 181 issues. Would be nice to have a plan for a stable v1.0.0 release...

[fiLLLip]

I don't agree with this being fixed/closed, as #599 did not make it into 0.9.18, and is IMO a critical fix. When using Playground (which uses this project under the hood) it causes a "race condition" where the connection_ack has not been sent before the start command. When using serverless functions on AWS this must come in order. Please reconsider this.

[hwillson]

👋 all! Is anyone in this thread still interested in helping us maintain this project? We would like to keep this as an active Apollo project, but we're swamped at the moment. If anyone is interested in stepping into a collaborator role, to help review PR's, fix bugs, and potentially add new features, we'd love the help.

[evenfrost]

Me, as an ex-Meteor user from the day one, going through its hype and abandonment and now seeing similar vibes in the Apollo ecosystem, to all of you, folks

[hwillson]

@evenfrost rest assured, Apollo (the company) is healthy, and moving full steam ahead on various projects. Our commitment to open source has never been stronger (we're hiring more OSS team members shortly), but there are so many great projects we wish we could spend more time on and just don't have the capacity to maintain at the moment ("moment" being key here). We'd love to get community help with this project in particular.

And total side note - I still use Meteor every single day, and still absolutely love it 😂.

[kbobrowski]

@hwillson I could provide some help from the community side, relying on Apollo subscriptions right now and would like to see it mature. I can start from improving implementation of authentication + documenting it better (see #349), I can also dedicate some time to PR reviews / fixing bugs

[OmgImAlexis]

If anyone is interested in stepping into a collaborator role, to help review PR's, fix bugs, and potentially add new features, we'd love the help.

👋 I'd be happy to help so long as someone that's around regularly has merge permission. I don't want to start helping to find that nothing is going to be merged, etc.

[evenfrost]

@hwillson not getting into much detail and not trying to diminish your guys work in any way. Meteor had its ups and downs for sure, and as I quit working with Meteor long ago and don't actively keep a track of it I may be wrong, but what I see from quick googling is that its strategic flaws are still here to stay.

As for Apollo, it's for sure a better approach than an all-in-one Swiss Army knife. But I'm actively developing with Apollo and relying on our infrastructure and I see similar vibes here and there so these are my worries. One of these was the decision to rewrite react-apollo from HOC to hooks, which itself an improvement for sure, but the way how it was done left many of us with a broken library which required either to stay on unsupported architecture or rewrite it from scratch.

And now I see react-apollo is deprecated in favor of the new Apollo Client. And the way it's done assures me of another similar scenario. I see a lot of open issues in react-apollo that don't seem to be bothered to be transferred to the apollo-client repository. And making a note to their authors stating you should move it by yourself is absolutely not the way to go.

Another example of these 'vibes' is the apollo-boost package. This is essentially an abstraction combining other abstractions in form of separate packages, which was promoted as an easy setup for Apollo infrastructure. And now, when we got used to it to some extent, it is stated that it should be avoided and we should get back to the initial setup.

As for 'not having a capacity for this' and wanting to spend time on 'more great projects', is actually the key alert for me. I've already seen this with Meteor. And I understand that this is — to some extent — OSS and contributions are welcome. But this is not the type of OSS where you don't owe anything to anybody. You're building a paid SAAS around your technology, and that, in my opinion, requires more thorough care of the libraries your build your product on, both for its own stability and for potential customers to make sure they get quality and well-maintained services with good reputational history.

[Sytten]

Please consider this point in the roadmap to understand the position @hwillson is trying to hold:

Removal of subscription-transport-ws in favor of a built-in solution that takes full advantage of the main request pipeline.

So for me this package is EOL but we might be waiting for 1 year+ before GraphQL server 3 is released so in the meantime the best the community can do is get some people WITH MERGE AND RELEASE privileges and maintain that package. We also need from the dev team that this package becomes a peer dependency of the server otherwise we are blocked by the released cycle of the server. I think at this point text discussion is not enough and we need some kind of meeting with people at Apollo.

[onhate]

agree with @Sytten I already have a PR waiting for someone to review/merge it
#809

[asmeikal]

I don't agree with this being fixed/closed, as #599 did not make it into 0.9.18, and is IMO a critical fix. When using Playground (which uses this project under the hood) it causes a "race condition" where the connection_ack has not been sent before the start command. When using serverless functions on AWS this must come in order. Please reconsider this.

I really need #599 too. The only thing blocking the PR is an easily solved conflict, but the original author cannot contribute anymore. @hwillson I'd be happy to help in any way possible, the project I'm working on relies on subscriptions-transport-ws and switching to other libraries would be a nightmare.

[hwillson]

Thanks @asmeikal - if you or anyone else in this thread would like write permission on this repo, to help us close out bugs and merge in PR's, please let me know. We'd love the help (but would like to keep ownership of this repo).

[asmeikal]

Hi @hwillson, I'd be glad to help and take this responsibility! I'd need some info on what the release process is for this repo, and how to coordinate with other maintainers.

[glasser]

No.