SPOnline - Caching (REST) UserProfileProperties for better UX response time

Question

Looking for briljant ideas...

I have a 100% Front-End driven UX only pulling in content from SharePoint
Nothing fancy, the usual stuff: News Carousel & Summary, My Tasks , Birthday list etc.
All the 100% Front-End stuff we are now supposed to do with SPFx

A large part is about user-context (Department, Office etc), so I need all his/her properties FAST
Before I can fire other REST requests for more content.

I can live with 150 milliseconds, but regularly taking a whole second is ludicrous

(I did a replay-XHR manually so these are fairly random response times)

I can't do much about SharePoint (ASPX) content being slow

I can however cache this content myself and proces slow incoming userdata later

Caching UserProfileProperties ?

LocalStorage

• easy to develop

• tied to Browser

use my own HTTPS server

• Less easy to develop (but done it in non-Microsoft days.. 40% of this code ran on WordPress)

• feels a bit like the first step to building SharePoint myself
  next question then would be:

Why store content IN SharePoint? As SPO Content requests are as whimsical in performance

---

Any other suggestions?

iSPEED iREST

Answer 1

You can also Batch REST API calls using SPHttpClientBatch class. Will save you some round trips. After that you can use the local/session storage as suggested by Eric.

What you need to do:

1) Add the below import statement

import { SPHttpClient, ISPHttpClientBatchOptions, ISPHttpClientBatchCreationOptions, SPHttpClientBatchConfigurations, SPHttpClientResponse, SPHttpClientBatch } from '@microsoft/sp-http';

2) After that in your method, you need to use it as follows:

const spBatchCreationOpts: ISPHttpClientBatchCreationOptions = { webUrl: this.context.pageContext.web.absoluteUrl };

const spBatch: SPHttpClientBatch = this.context.spHttpClient.beginBatch(spBatchCreationOpts);

// Queue first call to get current user properties
const getMyProperties: Promise<SPHttpClientResponse> = spBatch.get(`${this.context.pageContext.web.absoluteUrl}/_api/SP.UserProfiles.PeopleManager/GetMyProperties`, SPHttpClientBatch.configurations.v1);

// Queue second call to get another user's properties
const getAnotherUsersProperties: Promise<SPHttpClientResponse> = spBatch.get(`${this.context.pageContext.web.absoluteUrl}/_api/SP.UserProfiles.PeopleManager/GetPropertiesFor(accountName=@v)?@v='i:0%23.f|membership|user@tenantname.onmicrosoft.com'`, SPHttpClientBatch.configurations.v1);


spBatch.execute().then(() => {

      getMyProperties.then((response: SPHttpClientResponse) => {
        response.json().then((props: any) => {
          console.log(props); 
        });
      });

      getAnotherUsersProperties.then((response: SPHttpClientResponse) => {
        response.json().then((props: any) => {
          console.log(props);
        });
      });      
});

Reference - SPHttpClient class

Excellent blog post by Vardhaman - Batch REST requests in SPFx

Answer 2

Local storage would be the best option I suppose, first load initially, or first load on a new browser would be slow but pick up after that, but that is the norm for most sites (when talking about static assets anyway). Make the expensive calls once, merge them up into your own object and hand it off to store.js to manage.

Passing it off to a provider hosted app won't make much of a difference. You still have to get the SharePoint user context to then pass off to your service, so you're still waiting for SharePoint.

I know you've harped on this speed issue a couple times, but there are fundamental differences in WordPress and SharePoint. Totally different architectures and designs, stand alone versus hosted and shared. It's like wondering why your Fiat has a terrible 0-60 versus the Porsche, they're just cars right?