Closed JavierJia closed 6 years ago
@haochen07 Could you add a new picture to reflect the targeting architecture? Thanks.
Here is the new image.
Great diagram. Thanks!
The architecture below illustrates how twitterMap will work in detail.
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.
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: {},
...
}
...
}
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.
For clarity, I moved the second part of tasks mentioned in this issue to a new one #435 .
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.