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

websockets client / wrapper #4209

Closed
jakemcdermott opened this issue Dec 10, 2018 · 6 comments
Closed

websockets client / wrapper #4209

jakemcdermott opened this issue Dec 10, 2018 · 6 comments

Comments

@jakemcdermott
Copy link
Contributor

This is for adding a basic ws module to the client:

  • global subscriptions / global states
  • view-specific / per-job subscriptions
@jakemcdermott
Copy link
Contributor Author

jakemcdermott commented Dec 10, 2018

some notes:

when we launch a job in AWX, the following things happen sequentially:

  1. client makes an http request to /api/v2/item/n/launch
  2. api responds with a job id
  3. client uses job id to subscribe to a channel with the shared socket service, which delivers the job-specific ws events over that channel.

Ideally we want to eliminate the possibility for race conditions and missed job events between steps 2 and 3.

@jakemcdermott
Copy link
Contributor Author

jakemcdermott commented Dec 10, 2018

more notes:

  • The implementation should be framework-agnostic and testable in isolation. For example, it should be straightforward to write a functional test or debugging script that imports this module by itself to test important behavior (connect / disconnect, subscribing, unsubscribing, etc.) with a real or mocked backend.

  • The api design encourages clients to be idempotent with subscription state, which is favorable for a variety of reasons. We should:

    • keep the client-side representation of the subscription state as close to the API version as possible, ideally identical. In current AWX, we maintain a separate data structure and convert it to the one the API expects whenever subscriptions are changed. This is fragile and difficult to debug.

    • expose asynchronous parts of the connect, disconnect, and (re)subscribe cycle as promises or something chainable. For example, someone developing a new page or feature should, if necessary, be able to ensure that a newly requested subscription state is ready before something else happens.

@jakemcdermott
Copy link
Contributor Author

Potentially useful for any presentational components that are driven by job statuses (status icons, etc.): https://reactjs.org/docs/hooks-custom.html

@mabashian mabashian transferred this issue from another repository Jul 1, 2019
@jakemcdermott jakemcdermott changed the title websockets websockets client / wrapper Jul 1, 2019
@mabashian mabashian transferred this issue from another repository Jul 1, 2019
@wenottingham
Copy link
Contributor

tangentially: #1611

@wenottingham
Copy link
Contributor

Also tangentially: as part of this we should revisit moving to a daphne/channels version from this century

@jakemcdermott
Copy link
Contributor Author

Mike and I are breaking this work up into smaller issues:

#5883
#5885
#5886

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

4 participants