ISG-ICS / cloudberry

Big Data Visualization
http://cloudberry.ics.uci.edu
91 stars 82 forks source link

Rearchitect the TwitterMap web server #414

Closed JavierJia closed 6 years ago

JavierJia commented 6 years ago

Currently, the architecture of the TwitterMap is as this picture. The web server only generates the front-end UI and then the front-end JS talks with Cloudberry separately. It serves the purpose of demonstrating the usage of Cloudberry, however, the TwitterMap application is largely limited by this architecture. On one side, it is easier to implement the logic on a server than on a web page. On the other side, it is difficult for a browser to process the heavy computation.

We propose a new architecture where the TwitterMap server will take care of communicating with Cloudberry, and the web page only talks with the TwitterMap server. It is a much cleaner architecture and it enables more optimization (e.g., server cache) for the TwitterMap application.

JavierJia commented 6 years ago

@haochen07 Could you add a new picture to reflect the targeting architecture? Thanks.

haochen07 commented 6 years ago

Here is the new image.

cloudberry_architecture

chenlica commented 6 years ago

Great diagram. Thanks!

haochen07 commented 6 years ago

The architecture below illustrates how twitterMap will work in detail.

twittermap_architecture

We introduce an actor in TwitterMap server called TwitterMap Pigeon, which is responsible for rendering all user requests come from front end page and transmitting to cloudberry with respect to cloudberry Rest API. It handles the response from cloudberry and forwards to twitterMap front end as well.

The advantage of this change is to largely reduce the code complexity in front end's scripts and as we immigrant everything to the server, it makes twitterMap more extensible for new features and communication channels.

haochen07 commented 6 years ago

As the TwitterMap server is on, we need now to redefine the json request sent from front-end to TwitterMap server so that the front-end only transmits necessary information instead of fully formatted cloudberry requests. This design draft discuss how we define the front-end requests.

{
  click: {
    keyword: [],
    samples: [],
    normalization: true/false,
    ...
  } 
  drag: {
    map: {}
    timeline: {},
    ...
  }
  ...
}
chenlica commented 6 years ago

Per our F2F discussion today, while this simplification is very nice, let's give it a low priority due to other tasks we need to do. We can find another person to work on this task in the future.

haochen07 commented 6 years ago

For clarity, I moved the second part of tasks mentioned in this issue to a new one #435 .