Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: dependency update for subscriptions-transport-ws #2775

Open
2 of 4 tasks
Maxwell2022 opened this issue Apr 17, 2023 · 8 comments
Open
2 of 4 tasks

chore: dependency update for subscriptions-transport-ws #2775

Maxwell2022 opened this issue Apr 17, 2023 · 8 comments

Comments

@Maxwell2022
Copy link

Maxwell2022 commented Apr 17, 2023

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

I've searched for it and this issue has been historically closed here: #2406

This project is now archived and flag as deprecated (as of April 14th 2023)

From official Apollo v4 documentation

This article uses the graphql-ws library to add support for subscriptions to Apollo Server 4. We no longer recommend using the previously documented subscriptions-transport-ws, because this library is not actively maintained.

Minimum reproduction code

https://github.com/nestjs/graphql/blob/master/packages/graphql/package.json#L31

Steps to reproduce

No response

Expected behavior

this package should not used deprecated package but the recommended one

Package version

11

Graphql version

graphql:
apollo-server-express:
apollo-server-fastify:

NestJS version

No response

Node.js version

18

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

No response

@erikwrede
Copy link

erikwrede commented Jul 11, 2023

I disagree with this one. Just dropping protocol support because the protocol is not maintained anymore doesn't do graphql a favor. This library has full support for graphql-ws, but there may be users relying on subscriptions-transport-ws. Cutting them off from updates to nestjs/graphql doesn't feel like the right way to do it. Especially because both protocols are working perfectly fine. It's just recommended for clients to use the newer library and protocol. The server should continue supporting both in the foreseeable future.

@Maxwell2022
Copy link
Author

Just dropping protocol support because the protocol is not maintained anymore doesn't do graphql a favor

It's not dropping protocols 🤔. From my understanding websocket is still supported but using graphql-ws.

but there may be users relying on subscriptions-transport-ws

These users could migrate to graphql-ws as recommended by the maintainer of subscriptions-transport-ws

The subscriptions-transport-ws package is no longer maintained. We recommend you use graphql-ws instead. For help migrating Apollo software to graphql-ws, see https://www.apollographql.com/docs/apollo-server/data/subscriptions/#switching-from-subscriptions-transport-ws For general help using graphql-ws, see https://github.com/enisdenjo/graphql-ws/blob/master/README.md

You don't want to drag old packages that could introduce security risk

@erikwrede
Copy link

erikwrede commented Jul 12, 2023

It's not dropping protocols 🤔. From my understanding websocket is still supported but using graphql-ws.

There are two separate GraphQL protocols on top of web sockets that determine the client server communication messages. One of them (the older one) is subscriptions-transport-ws, the other, newer one is graphql-ws. They are incompatible with each other and a client has to support each protocol separately.
Since it's just a protocol (more explicitly an agreement on the structure of GraphQL Data and connection initialization) on top of Websocket, I don't really see a security risk here.

However, I agree about using old, archived dependencies. The alternative would be to implement the subscription-transport-ws protocol inside of @nestjs/graphql without the external library. For now, all of the 5 dependencies of transport-ws seem to be up to date though https://github.com/apollographql/subscriptions-transport-ws/blob/master/package.json.

I'd say as long as Apollo & server keep supporting the old protocol there should be no reason to drop support. Some older apps and clients don't support graphql-ws yet, and switching to the new protocol would cut them off of updates for nestjs.

@ssipos90
Copy link

ssipos90 commented Jul 13, 2023

shouldn't the packages be peer dependencies, both subscription-transport-ws and graphql-ws?

@belmeopmenieuwesim
Copy link

This package should 100% not be forced. Instead like @ssipos90 already said, it should be a peer dependency. Would not break anything, just require users to install the optional subscriptions-transport-ws package.

@ssipos90
Copy link

I checked and it's also required to be added as an optional peer dependency: https://docs.npmjs.com/cli/v7/configuring-npm/package-json#peerdependenciesmeta

cc @belmeopmenieuwesim

@elijaholmos
Copy link

This is what semantic versioning is for. Release a major version with a breaking change that switches from subscriptions-transport-ws to graphql-ws. Users are not forced to adopt the newest @nestjs/graphql version if they do not want to switch WS clients; likewise, other users are not forced to use a package which has a deprecated dependency if they do not want to.

@ruscon
Copy link

ruscon commented Jan 18, 2024

In our project we are currently using nestjs + graphql + subscriptions via sse (yoga + http 2), so need to think about whether ws is needed in this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants