Lack of clarity on scope of "webapp" and "dashboard"

[championswimmer]

Calling in everybody here for this discussion
@juslee @mariobehling @aayusharora @niranjan94 @rafalkowalski @aviaryan

So I and Aayush want to get some clarity on a few questions basically that'll help us create a roadmap for the webapp more clearly.

1. When we say "Webapp" that means the view-only client side part right ?
2. Since @juslee mentioned "dashboard UI" in our feature focus, we want to know how much of the dashboard UI are we supposed to be build ?
3. How will the server finally work ? Will it be a pure JSON-API server (i.e. no frontend) ? Or will the server have it's own HTML rendered views ?
   this question needs to answered at the beginning. Will the server provide a non-human-readable CRUD API with ACL, and a separately coded web page + js lib interact with it, wherein the user's logged in id will determine if he can or not change/update. Or will the server generate tables, forms and buttons in the frontend and serve it's own HTML (in which case, ACL takes place in the view-rendering stage, and a non-authorised user cannot even see the page for editing an event).

Please everyone give your views.

[aviaryan]

I believe both android app and web app should be client side apps, read-only, audience or attendees oriented with optional feature to add reviews, mark attendence and so on.

How will the server finally work ? Will it be a pure JSON-API server (i.e. no frontend) ? Or will the server have it's own HTML rendered views ?

My vote goes to Orga-Server having it's own HTML rendered views (like it has currently) and the client apps should fetch data from server and display to user in nicely formatted manner.

[championswimmer]

@aviaryan

Do keep in mind even for purely client sided apps, certain user-based update actions have to be there - like for example putting upvotes on sessions.
For those cases the server needs to expose an ACL-protected api endpoint.

[aviaryan]

For those cases the server needs to expose an ACL-protected api endpoint.

Yup. The same goes with features like session reviews. We can run authentication of identity on the server side to validate these types of actions. fossasia/open-event-server#367 is about that.

BTW, I think it will be more clear if we divide our userbase into 2 groups -

1. Event hosts (admins, organizers, speakers, managers etc)
2. Public (Audience, Attendees, users)
   Both the groups expect different features from the open event "project" so it would be easy this way.
   Client side apps are for the second group (Public) whereas the orga-server (and the android organizer app) is for the first group (Event hosts).

[juslee]

1. Web App will have 2 modes - Hosted and On-Prem. as discussed in Propose suitable technologies #201

2. Web App will take care of 4 states which is determined by server backend

   • Calling for Papers (getting speakers which is a 1 page which can be redirected back to the server),
   • Pending Event Schedule (close getting speakers),
   • Schedule is out (display schedule and other user features TO BE EXPANDED if there's time),
   • Event is over closing.

   Web App's 4 states will be enabled on Hosted. On-Prem will only have the last 2 states - Schedule and Event is over, which can be triggered by a date or something.

   Web App will not have any event users EXCEPT moderators (which is currently termed as "other user features").

3. Orga-server will be both a mix of server render (~99%) and client (~1%) for now depending on the progress. Eventually it will move to purely client render, but not slated for V1.

[championswimmer]

Ok for now this clears most of the doubts.

We will focus as of now immediately on making a webapp that satisfies states 3 and 4 (whether it is hosted on server or on-prem).

@aayusharora Please reopen if you have any remaining issues to be cleared.