GraphClient limit $select

Question

Thanks to this forum, I last week learned that I could use RawOrderBy and RawFilter when using the GraphClient. But is there also a RawSelect somewhere?

I'm asking because I noticed that the options we have for GraphMessageFields (e.g. Default, Info, ...) results in rather poor performance.

To test, I made the calls directly using Microsoft Graph rather than the Rebex component (which I prefer to use because of the excellent support for encrypted messages)

A call with (basically GraphMessageFields.Envelope)

$select=id,subject,internetMessageId,receivedDateTime,from,sender,toRecipients,ccRecipients,bccRecipients,replyTo&$top=1000

takes about 10 times more time than one with (a limited set of what was in GraphMessageFields.Info)

$select=id,subject,receivedDateTime,from,parentFolderId,isRead,hasAttachments&$top=1000

So if I could specify the fields needed, the performance gain of my application would be huge.

Answer 1

Unfortunately, it is not possible to specify custom $select in the current version.

We already planned this feature, but we have decided to postpone it because of 3 things we were unsure:

• how to handle values not directly accessible through the API (e.g. internetMessageHeaders), this would lead to another API for reading such values
• or whether to add every single property of the GraphMessageInfo into the GraphMessageFields enum (instead of using raw string)
• finally, how custom $select would affect future features (e.g. GraphMessageFields.AttachmentInfo would possibly affect the final URL, but in other way than $select does)

However, we were not aware of the tremendous difference in server computation time between GraphMessageFields.Envelope and GraphMessageFields.Info.

We will discuss the possibilities for implementing custom $select. I will send you link to preview version ASAP.

Comments

Regarding

"However, we were not aware of the tremendous difference in server computation time between GraphMessageFields.Envelope and GraphMessageFields.Info."

I agree, the performance is pretty much the same. Both suffer from the same thing. Selecting one of the following fields which exist in both is what is causing the 'large' performance drop:
- toRecipients
- ccRecipients
- bccRecipients
- replyTo

My guess is that those fields are calculated on the fly on the server side by parsing the actual messages while the rest is stored already separately.

---

I have just sent you an email with link to current preview version, which includes possibility to specify GraphMessageSearchQuery.RawSelect