sa-mw-dach / opendj Goto Github PK

The PartyOwner needs to registry with his spotify credentials, go through the spotify auth flow as describe https://developer.spotify.com/documentation/web-api/quick-start/ and https://github.com/spotify/web-api-auth-examples
The resulting access and refresh tokens need to be persistet so we do not loose them on container restart.
Needs new endpoint in spotify backend component ("initiateSpotifyLogin()"), and also a new view on the front-end side.

OpenDJ conflicts with the directory server project also found on github
We need to decide if we stay with the current name and risk the conflict when going really public, or decide on an alternative name.

We need to decide on Project Tooling used for:

1. Modelling (Architecture, Design, DataModel) - UML? Modelio?
2. Project Management (Epics, Use Storie, Sprint Planning etc) - Trello? GithUb?
3. ...

created by Michael Leibfried

To get a better feeling for:

• async event stuff #24, #15
• persistence of state #8
  i am going to experimentally implement the spotify oauth flow (which results in persistent state, i.e. the auth and refresh tokens).

Which roles do we need, and who has which roles?
Candiates:

• Product Owner
• Project manager / Scrum Master
• Lead UX
• Lead Architect
• Lead QS
• ...

depends on #15

Instead of the Playback Controller polling the Playlist for the first track, the Playlist should submit an event what the first track is which the Playback controller reacts upon. This would make it easier to handle multiple playbacks in parallel (because the playback controller needs no awareness which playlists exist/are active, it just reacts on events.

This is usually done via some data store, i.e. there's concepts to perform leader election using MongoDB, Zookeeper or etcd. Each choice introduces new technical dependencies, maybe there's a concept for leader election using messaging?

We need an OpenShift Cluster that is easily available, without VPN.
Options:
A: Employee OpenShift

• dfroehli has an account and acces
• no additional cost

• very limited ressources
• located at AWS US EAST

B: OpenShift4 on AWS

• wrichter has one available
• can be located in germany

• ocp v4 is beta/unstable
• creates external costs

The design and MVP* included a moerator view with the option to reorder items

UI needs a backend endpoint to vote songs up and down

We need a nice slick UX Design, consistent colors etc.

For example create the swagger definition of an API first before then implementing it in a separate micro service.

Make sure we have decent domain names for public access.

Such as Zuul CI or others. Prerequisite is a repo where not everyone can push to master but master is owned by the project gating system and a pull request is then evaluated by the gating system and merged or rejected

This could be install of the finished application at first, the install/setup of a complete dev+qa+prod environment incl. CI/CD second, and a more complex lifecycle third.

E.G. Apache Kafka / AMQ Streams or AMQ Pub/Sub

For HTTP interfaces, we can use a Swagger/OpenAPI definition, which can be rendered into a Test UI and used for scaffolding of implementations and client code. Can we use something equivalent for event bus based interfaces(#16)?

functionality is commented out in the services for whatever reasons.

there are several options to sort the array of subdocuments.

I do suggest to focus on the drag and drop capability of the UI. ie. the UI will send the things being changed and we do an atomic update in the database.

prerequisites: Moderator View

Decide on how to use git.
Options:
a: collective code ownership
no forking branching, single master branch where everybody pushes to

• less overhead

• risk of breaking builds

b: forking/branching with maintainers
Every ticket / feature / story is developed on a branch / fork and then merged into central master repo by the maintainers

• de-coupling of individual developments
• true open source apprach

• overhead

OpenDJ needs several screens. To facilitate communication between UX design and implementation, a tool would be good.

In the long term, we will need to decide on how/where we persist states (Playlists, Auth Tokens).

Github is complaining about nodejs sec vuls in various components. That should be fixed!

Thats not good, makes it impossible to move to different environments.
Example:
OpenDJ/frontend/app/src/app/home/home.page.ts:
...
const playlistUrl = 'http://playlist-dfroehli-opendj dev.apps.ocp1.hailstorm5.coe.muc.redhat.com/api/v1/';
...

I see Tdd relevant on two different but related areas:

• testing interfaces independent of their implementations, e.g. when implementations can be exchanged (eg. SpotifyBackend vs. AmazonMusicBackend or SimplePlaybackController vs. FadingAndBeatsAligningPlaybackController)
• testing component behavior spanning multiple interfaces (e.g. PlayList Service emitting an event after the playlist has been changed via Front API)

We need a good way to organize

• api definitions
• src
• tests
• docs
• ...

To allow easy showcase/demo/testing/partying, but also to comply with our defintion of done, we need to re-deploy to a different (public) openshift instance.

AsyncAPI is an extension/variation of OpenAPI by adding async/event handling capabilities.
AsyncAPI .
Could be a good way to describe async interfaces, but needs more investigation / experimentation.

I think we should experiment with this, e.g. define a simple async api, use it to generate prducer/consumer code against kafka and see how it works.

Derived from: #24 (comment)_

For easy testing / showcases, until we fixed the Outh Flow issue, the spotify backend should have a mock, responding with some track data.

Not sure if full REST actually solves problems for us or creates new problems:

• swagger/openAPI can’t do HATEOAS: OAI/OpenAPI-Specification#577
• we dont need to decouple client and server implementation
• using well known http verbs is probably a good idea (use DELETE to delete instead of POST)
  *...

right now we only show a playlist and play the first item in it.

the design wasn't that precisely about which items will be in the list. (will it include the current song or is this being popped out as soon we are playing it ie. the list would be next tracks. and the model might need a redesign),