<html><body>
<p><font size="2" face="sans-serif">I agree that keeping the API layer thin would be ideal. I should add that having discrete API calls would allow dynamic population of table. However, I will make a case where it </font><font size="2" face="sans-serif"><b><i>might</i></b></font><font size="2" face="sans-serif"> be necessary to add additional APIs. Consider that you want to delete 3 items in a given table. </font><br>
<br>
<font size="2" face="sans-serif">If you do this on the client side, you would need to perform: n * (1 API request + 1 AJAX request)</font><br>
<font size="2" face="sans-serif">If you have some logic on the server side that batch delete actions: n * (1 API request) + 1 AJAX request</font><br>
<br>
<font size="2" face="sans-serif">Consider the following:</font><br>
<font size="2" face="sans-serif">n = 1, client = 2 trips, server = 2 trips</font><br>
<font size="2" face="sans-serif">n = 3, client = 6 trips, server = 4 trips</font><br>
<font size="2" face="sans-serif">n = 10, client = 20 trips, server = 11 trips</font><br>
<font size="2" face="sans-serif">n = 100, client = 200 trips, server 101 trips</font><br>
<br>
<font size="2" face="sans-serif">As you can see, this does not scale very well.... something to consider...</font><br>
<br>
<br>
<img width="16" height="16" src="cid:1__=07BBF732DF9D58788f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Richard Jones ---11/27/2014 05:38:53 PM---On Fri Nov 28 2014 at 5:58:00 AM Tripp, Travis S <travis.tr"><font size="2" color="#424282" face="sans-serif">Richard Jones ---11/27/2014 05:38:53 PM---On Fri Nov 28 2014 at 5:58:00 AM Tripp, Travis S <travis.tripp@hp.com> wrote:</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Richard Jones <r1chardj0n3s@gmail.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">"Tripp, Travis S" <travis.tripp@hp.com>, OpenStack List <openstack-dev@lists.openstack.org></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">11/27/2014 05:38 PM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [horizon] REST and Django</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<font size="3" face="serif">On Fri Nov 28 2014 at 5:58:00 AM Tripp, Travis S <</font><a href="mailto:travis.tripp@hp.com"><font size="3" color="#0000FF" face="serif"><u>travis.tripp@hp.com</u></font></a><font size="3" face="serif">> wrote:</font>
<ul style="padding-left: 9pt"><font size="1" face="Calibri">Hi Richard,</font><br>
<br>
<font size="1" face="Calibri">You are right, we should put this out on the main ML, so copying thread out to there. ML: FYI that this started after some impromptu IRC discussions about a specific patch led into an impromptu google hangout discussion with all the people on the thread below.</font></ul>
<br>
<font size="3" face="serif">Thanks Travis!</font><br>
<br>
<font size="3" face="serif"> </font>
<ul style="padding-left: 9pt"><font size="1" face="Calibri">As I mentioned in the review[1], Thai and I were mainly discussing the possible performance implications of network hops from client to horizon server and whether or not any aggregation should occur server side. In other words, some views require several APIs to be queried before any data can displayed and it would eliminate some extra network requests from client to server if some of the data was first collected on the server side across service APIs. For example, the launch instance wizard will need to collect data from quite a few APIs before even the first step is displayed (I’ve listed those out in the blueprint [2]).</font><br>
<br>
<font size="1" face="Calibri">The flip side to that (as you also pointed out) is that if we keep the API’s fine grained then the wizard will be able to optimize in one place the calls for data as it is needed. For example, the first step may only need half of the API calls. It also could lead to perceived performance increases just due to the wizard making a call for different data independently and displaying it as soon as it can.</font></ul>
<br>
<font size="3" face="serif">Indeed, looking at the current launch wizard code it seems like you wouldn't need to load all that data for the wizard to be displayed, since only some subset of it would be necessary to display any given panel of the wizard. </font><br>
<br>
<font size="3" face="serif"> </font>
<ul style="padding-left: 9pt"><font size="1" face="Calibri">I tend to lean towards your POV and starting with discrete API calls and letting the client optimize calls. If there are performance problems or other reasons then doing data aggregation on the server side could be considered at that point.</font></ul>
<br>
<font size="3" face="serif">I'm glad to hear it. I'm a fan of optimising when necessary, and not beforehand :)</font><br>
<br>
<font size="3" face="serif"> </font>
<ul style="padding-left: 9pt"><font size="1" face="Calibri">Of course if anybody is able to do some performance testing between the two approaches then that could affect the direction taken.</font></ul>
<br>
<font size="3" face="serif">I would certainly like to see us take some measurements when performance issues pop up. Optimising without solid metrics is bad idea :)</font><br>
<br>
<br>
<font size="3" face="serif"> Richard</font><br>
<font size="3" face="serif"> </font>
<ul style="padding-left: 9pt"><br>
<font size="1" face="Calibri">[1] </font><a href="https://review.openstack.org/#/c/136676/8/openstack_dashboard/api/rest/urls.py" target="_blank"><font size="1" color="#0000FF" face="Calibri"><u>https://review.openstack.org/#/c/136676/8/openstack_dashboard/api/rest/urls.py</u></font></a><br>
<font size="1" face="Calibri">[2] </font><a href="https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign" target="_blank"><font size="1" color="#0000FF" face="Calibri"><u>https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign</u></font></a><br>
<br>
<font size="1" face="Calibri">-Travis</font><br>
<br>
<font size="2" face="Calibri"><b>From: </b></font><font size="2" face="Calibri">Richard Jones <</font><a href="mailto:r1chardj0n3s@gmail.com" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>r1chardj0n3s@gmail.com</u></font></a><font size="2" face="Calibri">></font><font size="2" face="Calibri"><b><br>
Date: </b></font><font size="2" face="Calibri">Wednesday, November 26, 2014 at 11:55 PM</font><font size="2" face="Calibri"><b><br>
To: </b></font><font size="2" face="Calibri">Travis Tripp <</font><a href="mailto:travis.tripp@hp.com" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>travis.tripp@hp.com</u></font></a><font size="2" face="Calibri">>, Thai Q Tran/Silicon Valley/IBM <</font><a href="mailto:tqtran@us.ibm.com" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>tqtran@us.ibm.com</u></font></a><font size="2" face="Calibri">>, David Lyle <</font><a href="mailto:dklyle0@gmail.com" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>dklyle0@gmail.com</u></font></a><font size="2" face="Calibri">>, Maxime Vidori <</font><a href="mailto:maxime.vidori@enovance.com" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>maxime.vidori@enovance.com</u></font></a><font size="2" face="Calibri">>, "Wroblewski, Szymon" <</font><a href="mailto:szymon.wroblewski@intel.com" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>szymon.wroblewski@intel.com</u></font></a><font size="2" face="Calibri">>, "Wood, Matthew David (HP Cloud - Horizon)" <</font><a href="mailto:matt.wood@hp.com" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>matt.wood@hp.com</u></font></a><font size="2" face="Calibri">>, "Chen, Shaoquan" <</font><a href="mailto:sean.chen2@hp.com" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>sean.chen2@hp.com</u></font></a><font size="2" face="Calibri">>, "Farina, Matt (HP Cloud)" <</font><a href="mailto:matthew.farina@hp.com" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>matthew.farina@hp.com</u></font></a><font size="2" face="Calibri">>, Cindy Lu/Silicon Valley/IBM <</font><a href="mailto:clu@us.ibm.com" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>clu@us.ibm.com</u></font></a><font size="2" face="Calibri">>, Justin Pomeroy/Rochester/IBM <</font><a href="mailto:jpomero@us.ibm.com" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>jpomero@us.ibm.com</u></font></a><font size="2" face="Calibri">>, Neill Cox <</font><a href="mailto:neill.cox@ingenious.com.au" target="_blank"><font size="2" color="#0000FF" face="Calibri"><u>neill.cox@ingenious.com.au</u></font></a><font size="2" face="Calibri">></font><font size="2" face="Calibri"><b><br>
Subject: </b></font><font size="2" face="Calibri">Re: REST and Django</font><br>
<br>
<font size="1" face="Calibri">I'm not sure whether this is the appropriate place to discuss this, or whether I should be posting to the list under [Horizon] but I think we need to have a clear idea of what goes in the REST API and what goes in the client (angular) code.</font><br>
<br>
<font size="1" face="Calibri">In my mind, the thinner the REST API the better. Indeed if we can get away with proxying requests through without touching any *client code, that would be great.</font><br>
<br>
<font size="1" face="Calibri">Coding additional logic into the REST API means that a developer would need to look in two places, instead of one, to determine what was happening for a particular call. If we keep it thin then the API presented to the client developer is very, very similar to the API presented by the services. Minimum surprise.</font><br>
<br>
<font size="1" face="Calibri">Your thoughts?</font><br>
<br>
<br>
<font size="1" face="Calibri"> Richard</font><br>
<br>
<br>
<font size="1" face="Calibri">On Wed Nov 26 2014 at 2:40:52 PM Richard Jones <</font><a href="mailto:r1chardj0n3s@gmail.com" target="_blank"><font size="1" color="#0000FF" face="Calibri"><u>r1chardj0n3s@gmail.com</u></font></a><font size="1" face="Calibri">> wrote:</font>
<ul style="padding-left: 9pt"><font size="1" face="Calibri">Thanks for the great summary, Travis. </font><br>
<br>
<font size="1" face="Calibri">I've completed the work I pledged this morning, so now the REST API change set has:</font><br>
<br>
<font size="1" face="Calibri">- no rest framework dependency</font><br>
<font size="1" face="Calibri">- AJAX scaffolding in openstack_dashboard.api.rest.utils</font><br>
<font size="1" face="Calibri">- code in openstack_dashboard/api/rest/</font><br>
<font size="1" face="Calibri">- renamed the API from "identity" to "keystone" to be consistent</font><br>
<font size="1" face="Calibri">- added a sample of testing, mostly for my own sanity to check things were working</font><br>
<br>
<a href="https://review.openstack.org/#/c/136676" target="_blank"><font size="1" color="#0000FF" face="Calibri"><u>https://review.openstack.org/#/c/136676</u></font></a><br>
<br>
<br>
<font size="1" face="Calibri"> Richard</font><br>
<br>
<font size="1" face="Calibri">On Wed Nov 26 2014 at 12:18:25 PM Tripp, Travis S <</font><a href="mailto:travis.tripp@hp.com" target="_blank"><font size="1" color="#0000FF" face="Calibri"><u>travis.tripp@hp.com</u></font></a><font size="1" face="Calibri">> wrote:</font>
<ul style="padding-left: 9pt"><font size="1" face="Calibri">Hello all,</font><br>
<br>
<font size="1" face="Calibri">Great discussion on the REST urls today! I think that we are on track to come to a common REST API usage pattern. To provide quick summary:</font><br>
<br>
<font size="1" face="Calibri">We all agreed that going to a straight REST pattern rather than through tables was a good idea. We discussed using direct get / post in Django views like what Max originally used[1][2] and Thai also started[3] with the identity table rework or to go with djangorestframework [5] like what Richard was prototyping with[4].</font><br>
<br>
<font size="1" face="Calibri">The main things we would use from Django Rest Framework were built in JSON serialization (avoid boilerplate), better exception handling, and some request wrapping. However, we all weren’t sure about the need for a full new framework just for that. At the end of the conversation, we decided that it was a cleaner approach, but Richard would see if he could provide some utility code to do that much for us without requiring the full framework. David voiced that he doesn’t want us building out a whole framework on our own either.</font><br>
<br>
<font size="1" face="Calibri">So, Richard will do some investigation during his day today and get back to us. Whatever the case, we’ll get a patch in horizon for the base dependency (framework or Richard’s utilities) that both Thai’s work and the launch instance work is dependent upon. We’ll build REST style API’s using the same pattern. We will likely put the rest api’s in horizon/openstack_dashboard/api/rest/.</font><br>
<br>
<font size="1" face="Calibri">[1] </font><a href="https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/keypair.py" target="_blank"><font size="1" color="#0000FF" face="Calibri"><u>https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/keypair.py</u></font></a><br>
<font size="1" face="Calibri">[2] </font><a href="https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/launch.py" target="_blank"><font size="1" color="#0000FF" face="Calibri"><u>https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/launch.py</u></font></a><br>
<font size="1" face="Calibri">[3] </font><a href="https://review.openstack.org/#/c/133767/8/openstack_dashboard/dashboards/identity/users/views.py" target="_blank"><font size="1" color="#0000FF" face="Calibri"><u>https://review.openstack.org/#/c/133767/8/openstack_dashboard/dashboards/identity/users/views.py</u></font></a><br>
<font size="1" face="Calibri">[4] </font><a href="https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py" target="_blank"><font size="1" color="#0000FF" face="Calibri"><u>https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py</u></font></a><br>
<font size="1" face="Calibri">[5] </font><a href="http://www.django-rest-framework.org/" target="_blank"><font size="1" color="#0000FF" face="Calibri"><u>http://www.django-rest-framework.org/</u></font></a><br>
<br>
<font size="1" face="Calibri">Thanks,</font><br>
<font size="1" face="Calibri">Travis</font><tt><font size="2">_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
</font></tt><br>
</ul>
</ul>
</ul>
</body></html>