People API improvements

[renaudboyer]

People API is an aggregation API

It's used by user autocomplete component.

The issue with this API is that it waits until every provider answer to respond. So response time depends on the slowest provider.

For now, we've added a time out but we need a better solution.

Solution hints:

• Use Web Sockets to respond
• Split calls
• ...

The people API is mainly called by user autocomplete which is used in several places/projects as:

• Inbox Composer
• Calendar Event form

CRITERIA:

• [ ] Architecture diagrams/proposals
• [ ] Impact analysis
• [ ] Performance considerations

[vincent-zurczak]

Regarding the Calendar components, here what has been identified as something to improve: right now, when the people API searches for contacts, it first invokes Elastic Search and then contacts Sabre. Having a single call instead of two would improve performances.

The calendar team should first understand why there are 2 calls and try to reduce it.

[chibenwa]

A good idea would be streaming the results (eg over webSocket). Each sources of the people API would stream its search results at its own pace, and we would only need to add a search result provider for the PEOPLE CACHE. That way, we would no longer be impacted by the slowest result.

[chamerling]

In this case, streaming using SSE (Server Sent Event) will be enough and easier to integrate in any search component:

Client (AngularJS): GET

const source = new EventSource("/api/people/sse/search?q=ben");
source.onopen = () => console.log("Connected");
source.onerror = console.error;
source.onmessage = data => {
  // populate your angularjs scope
};

On the Node server, SSE is easy to add without any external dependency.

Using websocket is really more complex for such case and quite useless IMO (one way communication)

[chibenwa]

In this case, streaming using SSE (Server Sent Event) will be enough and easier to integrate in any search component

Fair :-)

I do think it might be easier than leaking the endpoints hidden away by the people search API so that they can perform distinct HTTP API call to each one of the providers. Opinion on this @chamerling ?

[chamerling]

I do not see exactly what you mean but this is what I understand: Keeping the people API hides all the providers, which is good because we do not have to expose to API consumer that people API will do a search in LDAP, Mongo, ElasticSearch or any other Person source. Also keeping the people API allows us to keep a simple and defined Person format. For example, dealing with vCARD on the client side is a nightmare, and is really useless.

By using SSE and so streaming, the people API will return arrays or person as soon as the provider sends back result to the people backend (which is in charge of translating anything to a Person[]). SSE endpoint and people service will have all the things needed to manage provider timeout, etc, which is quite good IMO.

Last thing to check: Does this fit well with production deployments (I guess yes)? cc @tanandy

[tanandy]

Hi guys, this is not a priority right now as said yesterday and personnaly i dont have time to dig into it right now btw:

Im really not sure using streaming or SSE is a good idea in that use case.

For sse, there are some downsides to consider to scale it widely and its mainly use for chat app or notification services

One last thing, i like the idea of having a common people api but there are also some challenges to achieve to make it work before too