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

Create the list view component #4

Open
gdrouet opened this issue Nov 11, 2016 · 3 comments
Open

Create the list view component #4

gdrouet opened this issue Nov 11, 2016 · 3 comments
Labels
Milestone

Comments

@gdrouet
Copy link
Contributor

gdrouet commented Nov 11, 2016

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
@gdrouet gdrouet added this to the 0.1.0 milestone Nov 11, 2016
This was referenced Nov 11, 2016
@NathanDM
Copy link
Member

Is SSE connection still needed ?

@NathanDM NathanDM mentioned this issue Jan 12, 2017
Merged
@gdrouet
Copy link
Contributor Author

gdrouet commented Jan 12, 2017

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.

@gdrouet
Copy link
Contributor Author

gdrouet commented Apr 7, 2017

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

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

No branches or pull requests

2 participants