Open Stack

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...




From:	Richard Jones <r1chardj0n3s at gmail.com>
To:	"Tripp, Travis S" <travis.tripp at hp.com>, OpenStack List
            <openstack-dev at 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.tripp at 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
  [2]
  https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign

  -Travis

  From: Richard Jones <r1chardj0n3s at gmail.com>
  Date: Wednesday, November 26, 2014 at 11:55 PM
  To: Travis Tripp <travis.tripp at hp.com>, Thai Q Tran/Silicon Valley/IBM <
  tqtran at us.ibm.com>, David Lyle <dklyle0 at gmail.com>, Maxime Vidori <
  maxime.vidori at enovance.com>, "Wroblewski, Szymon" <
  szymon.wroblewski at intel.com>, "Wood, Matthew David (HP Cloud - Horizon)"
  <matt.wood at hp.com>, "Chen, Shaoquan" <sean.chen2 at hp.com>, "Farina, Matt
  (HP Cloud)" <matthew.farina at hp.com>, Cindy Lu/Silicon Valley/IBM <
  clu at us.ibm.com>, Justin Pomeroy/Rochester/IBM <jpomero at us.ibm.com>, Neill
  Cox <neill.cox at 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 <r1chardj0n3s at 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


         Richard

   On Wed Nov 26 2014 at 12:18:25 PM Tripp, Travis S <travis.tripp at 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
     [2]
     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
     [4]
     https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py
     [5] http://www.django-rest-framework.org/

     Thanks,
     Travis_______________________________________________
     OpenStack-dev mailing list
     OpenStack-dev at lists.openstack.org
     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141130/ade67337/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141130/ade67337/attachment.gif>