reactivity-io/reactivity

Create the list view component

Opened this issue · 3 comments

User story

  • As a Reactivity user having an access to an organization
  • I want to display the artifacts or my organization in a list
  • So I can see my activity in a TODO list

Acceptance criteria

  • An organization called reactivity-mvp with pre-defined artifacts in the DB is accessible by all anonymous users
  • All artifacts manually added to the DB are listed from top to down in order of creation
  • Only n artifacts are retrieved by the view according to the size of the user screen. When the user scrolls, the web app retrieves the next artifacts in the spirit of twitter infinit scroll

Technical considerations

The feature shows how the web application opens a HTTP connection to the broadcaster that simply selects artifacts from a view manually created in couchbase.

When the user connects, he must be authenticated as an anonymous user who will retrieve the organization and an associated view that use the creation date as timestamp key. Then, the web application subscribes to that view in order to receive the artifacts.

Since view subscription are managed in the session, the broadcaster micro service must manage a session with spring security and provide an access to couchbase through spring-data framework.

The application must run with the HTTPS protocol.

Out of scope

Kafka and Zookeeper integration are out of scope of this feature. We also exclude the Hazelcast support for distributed session. The application will just work as a single instance not ready to scale yet.

The features are also strongly limited for this first iteration:

  • Can't edit an artifact
  • Ever green chrome and firefox are supported

Is SSE connection still needed ?

No because sending messages only for some subscribers is currently not natively supported by reactor and we need to decide how we'll handle this case. So for now we create a short-live connection with only one subscriber (the HTTP response itself) and avoid multiple subscriptions to one long-live SSE connection.

I can update the issue, but before there is also a statement regarding authentication. Subscriptions are currently mocked at API-endpoint level and we are supposed to mock them at session level instead, which means that we are supposed to deploy session management with anonymous user registration. Do we keep this target? We can or we add concrete authentication with firebase instead.

Update regarding previous comment:

  • SSE not in the scope for the first sprint. We open short lived connections to get the current state of the data, SSE will be used to push updates
  • User are anonymously authenticated