CCC vs in-app requests…

[hawkrives]

I know that I've gone back and forth on this topic, but I'm revisiting it again.

I was thinking about future features, especially personalized ones, and how we won't be able to proxy those through CCC, which means that we'll still need arbitrary network access in the app, and probably HTML parsing as well.

At that point, why involve CCC?

1. Caching - especially for slow origin servers (cough presence cough)
2. Energy - it's probably more efficient to parse HTML on the server, and send down JSON?
3. Caching - it avoids overloading the origin servers, as well
4. Redirects - we can cover for origin-level changes in routes or data, as long as we can transform it server-side

But, are those upsides enough to outweigh "another service that we have to maintain", and "we become a point of failure", and still having to include the code client-side?

Or do I need to bite the mental bullet and figure out how to proxy authenticated requests (eww)?

[drewvolz]

CCC is definitely part of the answer to those 3 or 4 items you called out. To your question of whether being a point of failure outweighs the alternative —— I think so.

With our proxying we at least have the ability to wrap many dynamic areas of input and API contracts that we do not own the data of in order to intercept things as best we can.

Until we control all of the data shapes, I do not know of a saner pattern (unless we implement a circuit breaker).

Proxying authenticated requests does sound like additional complexity and we would probably prefer not to take that on. We could have some things related to auth remain on-device as a hybrid solution to save us the trouble and users their security (not that we couldn't find a secure way to go about it).

Maybe it would be worth our time to put together a small investigation of the approaches we could take, their pros and cons, and a recommendation before going a certain direction.

[drewvolz]

One additional thought: if we ever seek to be the mobile campus product for a college or university we would probably want to have a live config of data we pull from. In that case I would think our architecture would have a lot more dynamic but heavily cached data. In that case I think having a server is very helpful. What do you think?

[drewvolz]

Another thought: an idea to avoid an external proxy server for requests while doing most if not all fetching on-device could be done via codepush bundles?

I know codepush has its own complications and complexity but this would let us avoid store review cycles for stale link and data fixes while keeping most everything else all in the bundle.

[hawkrives]

I've been convinced to support the server approach again – it seems less fragile than the codepush approach… (e.g., if our codepush server goes down, then any new downloads / redownloads of the app would get the original bundle without any of the fixes?)

My next question: how do we handle authenticated endpoints? Things like "get my class schedule", etc.

Below: a random graphql example of how we could structure part of the classes stuff…

query MySchedule {
  myClasses {
    title
    subtitle
    grade { code option }
    offerings { 
      instructor 
      schedule { 
        dayOfWeek startTime endTime
        location { 
          building { id name } 
          room
        }
      }
    }
  }
}

[hawkrives]

New idea: once CCC is Rustified, we could bundle it in the app and run a server copy; that way, if the server dies, it could fall back to the local copy!