launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 24 November 2010 23:46, Julian Edwards <julian.edwards@xxxxxxxxxxxxx> wrote:
> On Wednesday 24 November 2010 11:50:45 Jonathan Lange wrote:
>> On Tue, Nov 23, 2010 at 11:07 PM, Gary Poster <gary.poster@xxxxxxxxxxxxx>
> wrote:
>> > On Nov 22, 2010, at 10:48 AM, Aaron Bentley wrote:
>> ...
>>
>> >> (In fact, Robert has
>> >> suggested that Launchpad itself should actually use the web API, which
>> >> would make the developer API identical to the web API.)
>> >
>> > I've heard this, and was interested in it.  I'm now pretty skeptical that
>> > this is reasonable.  Transactions, for instance, are very useful in a
>> > database.  They can be exposed in a webservice, but are not natural for
>> > it.
>>
>> I don't get the scepticism. They are still part of some over-arching
>> operation, and that operation can be exposed as a remotely-accessible
>> API.
>
> The problem is that you need to export a new method on the API for anything
> you want to be done in an atomic transaction.  That's going to bloat things
> significantly and add to development overhead.  And unless you can ever get
> the webservice overhead *tiny*, it's also a massive performance impact.

In one variation of this plan, you wouldn't need to actually call out
across http to the apis.  We'd just have an architectural design rule
that presentation-level code should only rely on things that are
exported through the API; you could (hand wavey) enforce this even in
process.

There's perhaps a weak reason to do this being that it would introduce
a kind of layer clarity; the stronger one is that it would reduce the
frequency of the web ui 'cheating' by doing things that an external
ui, or an ajax ui, couldn't possibly do.  There are a fair number of
pages in Launchpad that would take many minutes, at least, to generate
over the API, because ordering or filtering that can be done in the
database in the app server needs to be done by brute force externally.

Obviously making the web app as slow as the api would not help anyone.
 But making the api strong enough and fast enough that you could in
principle sit the web ui on top of it would be a great step forward.
It might need new thinking about what kind of model the API presents,
getting away from one roundtrip to modify an object.

But the API is not really on top of the queue at the moment...

-- 
Martin