[GitHub] mmiklavc edited a comment on issue #1275: METRON-1878: Add Metron as a Knox service
mmiklavc edited a comment on issue #1275: METRON-1878: Add Metron as a Knox service URL: https://github.com/apache/metron/pull/1275#issuecomment-446383790 @merrimanr Just summing up a few things I think we should have come out of this PR per our offline convo earlier: 1. Update README's with some explanation of the multiple UI and REST API communication architecture - e.g. I had expected there was a way to have the REST application and Angular application assets be served up by (or have the REST calls handled through) the same web container context, but that is not how this is setup. The pre-Knox existing architecture uses ExpressJS within the Angular app hosting container to do a very straightforward proxying of requests to the REST API as opposed to having a heavier weight facade (e.g. a Spring J2EE application) for an abstraction managing those requests to REST. This is fine, but now that we've added Knox to the mix, we should be very clear about what requests and responses go to which hosts/servers and why. 2. Developer documentation - simple diagram and/or write up that expresses what the request/response lifecycle looks like with and without Knox. This relates to number 1, but is more about showing the before/after of enabling Knox. 3. Explanation of the choice to NOT use Knox's URL rewriting capabilities. Per our convo earlier, the choice is between setting a base root that's used by Knox for routing requests (similar to the function of a controller in MVC architecture) to the appropriate host, or leaving the REST application alone and leveraging Knox's regular expression pattern matching to handle rewriting URL's that show up in the client browser. 4. EDIT - Fix logout bug 5. EDIT - Fix Travis Cypress test failure 6. I'm going to make a PR against your PR to add the Management UI to this. Here's the basic request/response lifecycle as I understand it: **Static asset call for Angular application** This is for javascript, html, and images. I realize "static" may be a misnomer for Angular javascript, but it's static insofar as the web container is concerned: ``` Client request -> knox server -> angular web server Server response <- angular web server <- knox server <- client ``` **Dynamic/REST content call.** Knox is now replacing ExpressJS entirely as the proxy mechanism. Note, ExpressJS didn't perform any function for static assets, only for calls to 3rd parties like the REST app. This is necessary because CORS restricts a browser from making the calls directly to REST (or any other non-origin host that's different from the original host that served up the client-side Angular app). This could theoretically be handled by a proper server side web application, but my understanding is that this would be superfluous given the API contract we've enacted with the REST API, i.e. it handles requests/responses in JSON that an AngularJS application can process easily. ``` Client request -> knox server -> rest api server Server response <- rest api server <- knox server <- client ``` This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mmiklavc edited a comment on issue #1275: METRON-1878: Add Metron as a Knox service
mmiklavc edited a comment on issue #1275: METRON-1878: Add Metron as a Knox service URL: https://github.com/apache/metron/pull/1275#issuecomment-446383790 @merrimanr Just summing up a few things I think we should have come out of this PR per our offline convo earlier: 1. Update README's with some explanation of the multiple UI and REST API communication architecture - e.g. I had expected there was a way to have the REST application and Angular application assets be served up by (or have the REST calls handled through) the same web container context, but that is not how this is setup. The pre-Knox existing architecture uses ExpressJS within the Angular app hosting container to do a very straightforward proxying of requests to the REST API as opposed to having a heavier weight facade (e.g. a Spring J2EE application) for an abstraction managing those requests to REST. This is fine, but now that we've added Knox to the mix, we should be very clear about what requests and responses go to which hosts/servers and why. 2. Developer documentation - simple diagram and/or write up that expresses what the request/response lifecycle looks like with and without Knox. This relates to #1, but is more about showing the before/after of enabling Knox. 3. Explanation of the choice to NOT use Knox's URL rewriting capabilities. Per our convo earlier, the choice is between setting a base root that's used by Knox for routing requests (similar to the function of a controller in MVC architecture) to the appropriate host, or leaving the REST application alone and leveraging Knox's regular expression pattern matching to handle rewriting URL's that show up in the client browser. 4. EDIT - Fix logout bug 5. EDIT - Fix Travis Cypress test failure 6. I'm going to make a PR against your PR to add the Management UI to this. Here's the basic request/response lifecycle as I understand it: **Static asset call for Angular application** This is for javascript, html, and images. I realize "static" may be a misnomer for Angular javascript, but it's static insofar as the web container is concerned: ``` Client request -> knox server -> angular web server Server response <- angular web server <- knox server <- client ``` **Dynamic/REST content call.** Knox is now replacing ExpressJS entirely as the proxy mechanism. Note, ExpressJS didn't perform any function for static assets, only for calls to 3rd parties like the REST app. This is necessary because CORS restricts a browser from making the calls directly to REST (or any other non-origin host that's different from the original host that served up the client-side Angular app). This could theoretically be handled by a proper server side web application, but my understanding is that this would be superfluous given the API contract we've enacted with the REST API, i.e. it handles requests/responses in JSON that an AngularJS application can process easily. ``` Client request -> knox server -> rest api server Server response <- rest api server <- knox server <- client ``` This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services