On Mon Dec 01 2014 at 4:18:42 PM Thai Q Tran <tqt...@us.ibm.com> wrote:
> 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 *might* be necessary to add additional APIs.
> Consider that you want to delete 3 items in a given table.
>
> If you do this on the client side, you would need to perform: n * (1 API
> request + 1 AJAX request)
> If you have some logic on the server side that batch delete actions: n *
> (1 API request) + 1 AJAX request
>
> Consider the following:
> n = 1, client = 2 trips, server = 2 trips
> n = 3, client = 6 trips, server = 4 trips
> n = 10, client = 20 trips, server = 11 trips
> n = 100, client = 200 trips, server 101 trips
>
> As you can see, this does not scale very well.... something to consider...
>
Yep, though in the above cases the client is still going to be hanging,
waiting for those server-backend calls, with no feedback until it's all
done. I would hope that the client-server call overhead is minimal, but I
guess that's probably wishful thinking when in the land of random Internet
users hitting some provider's Horizon :)
So yeah, having mulled it over myself I agree that it's useful to have
batch operations implemented in the POST handler, the most common operation
being DELETE.
Maybe one day we could transition to a batch call with user feedback using
a websocket connection.
Richard
> [image: 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]Richard
> Jones ---11/27/2014 05:38:53 PM---On Fri Nov 28 2014 at 5:58:00 AM Tripp,
> Travis S <travis.tr...@hp.com> wrote:
>
> From: Richard Jones <r1chardj0...@gmail.com>
> To: "Tripp, Travis S" <travis.tr...@hp.com>, OpenStack List <
> openstack-dev@lists.openstack.org>
> Date: 11/27/2014 05:38 PM
> Subject: Re: [openstack-dev] [horizon] REST and Django
> ------------------------------
>
>
>
>
> On Fri Nov 28 2014 at 5:58:00 AM Tripp, Travis S <*travis.tr...@hp.com*
> <travis.tr...@hp.com>> wrote:
>
> Hi Richard,
>
> 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.
>
>
> Thanks Travis!
>
>
>
> 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]).
>
> 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.
>
>
> 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.
>
>
>
> 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.
>
>
> I'm glad to hear it. I'm a fan of optimising when necessary, and not
> beforehand :)
>
>
>
> Of course if anybody is able to do some performance testing between
> the two approaches then that could affect the direction taken.
>
>
> I would certainly like to see us take some measurements when performance
> issues pop up. Optimising without solid metrics is bad idea :)
>
>
> Richard
>
>
>
>
> [1]
>
> *https://review.openstack.org/#/c/136676/8/openstack_dashboard/api/rest/urls.py*
>
> <https://review.openstack.org/#/c/136676/8/openstack_dashboard/api/rest/urls.py>
> [2]
> *https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign*
> <https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign>
>
> -Travis
>
> *From: *Richard Jones <*r1chardj0...@gmail.com*
> <r1chardj0...@gmail.com>>
> * Date: *Wednesday, November 26, 2014 at 11:55 PM
> * To: *Travis Tripp <*travis.tr...@hp.com* <travis.tr...@hp.com>>, Thai Q
> Tran/Silicon Valley/IBM <*tqt...@us.ibm.com* <tqt...@us.ibm.com>>,
> David Lyle <*dkly...@gmail.com* <dkly...@gmail.com>>, Maxime Vidori <
> *maxime.vid...@enovance.com* <maxime.vid...@enovance.com>>,
> "Wroblewski, Szymon" <*szymon.wroblew...@intel.com*
> <szymon.wroblew...@intel.com>>, "Wood, Matthew David (HP Cloud -
> Horizon)" <*matt.w...@hp.com* <matt.w...@hp.com>>, "Chen, Shaoquan" <
> *sean.ch...@hp.com* <sean.ch...@hp.com>>, "Farina, Matt (HP Cloud)" <
> *matthew.far...@hp.com* <matthew.far...@hp.com>>, Cindy Lu/Silicon
> Valley/IBM <*c...@us.ibm.com* <c...@us.ibm.com>>, Justin
> Pomeroy/Rochester/IBM <*jpom...@us.ibm.com* <jpom...@us.ibm.com>>,
> Neill Cox <*neill....@ingenious.com.au* <neill....@ingenious.com.au>>
> * Subject: *Re: REST and Django
>
> 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.
>
> 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.
>
> 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.
>
> Your thoughts?
>
>
> Richard
>
>
> On Wed Nov 26 2014 at 2:40:52 PM Richard Jones <
> *r1chardj0...@gmail.com* <r1chardj0...@gmail.com>> wrote:
>
>
> Thanks for the great summary, Travis.
>
> I've completed the work I pledged this morning, so now the REST API
> change set has:
>
> - no rest framework dependency
> - AJAX scaffolding in openstack_dashboard.api.rest.utils
> - code in openstack_dashboard/api/rest/
> - renamed the API from "identity" to "keystone" to be consistent
> - added a sample of testing, mostly for my own sanity to check
> things were working
>
> *https://review.openstack.org/#/c/136676*
> <https://review.openstack.org/#/c/136676>
>
>
> Richard
>
> On Wed Nov 26 2014 at 12:18:25 PM Tripp, Travis S <
> *travis.tr...@hp.com* <travis.tr...@hp.com>> wrote:
>
>
> Hello all,
>
> 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:
>
> 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].
>
> 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.
>
> 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/.
>
> [1]
>
> *https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/keypair.py*
>
> <https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/keypair.py>
> [2]
>
> *https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/launch.py*
>
> <https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/launch.py>
> [3]
>
> *https://review.openstack.org/#/c/133767/8/openstack_dashboard/dashboards/identity/users/views.py*
>
> <https://review.openstack.org/#/c/133767/8/openstack_dashboard/dashboards/identity/users/views.py>
> [4]
>
> *https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py*
>
> <https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py>
> [5] *http://www.django-rest-framework.org/*
> <http://www.django-rest-framework.org/>
>
> Thanks,
>
>
> Travis_______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
