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/';
...
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.
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)
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?
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)?
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.
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
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.
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.
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.
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
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),
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.
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).
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.