Add first concept for link-sharing

[pylipp]

Rendered document.

PasswordPusher ADR

It got more detailed in the BE part. For the UI it's rather some questions/ideas.

LMK if parts are not clear.

[pylipp]

2.0: Draft concept for public link sharing of statviz

[jamescrowley]

Is this already the case? Or something we're doing specifically for link sharing?

[pylipp]

No, we're not doing this yet. It's a suggestion for the link-sharing use case.

[jamescrowley]

can you share context on why you're suggesting this? It seems strange to me to host the FE on what appears to be an API endpoint?

[pylipp]

I suggested this for simplicity (less devops effort because we don't need to establish a new subdomain nor any new GAE services). The endpoints we currently have for the api subdomains are the GraphQL one at / and the documentation at /docs.
For a separation of concerns it probably makes sense to have a dedicated subdomain for link-sharing.

[jamescrowley]

@pylipp got it. Is there any other way we can achieve that? If the back end link sharing is going to be part of the standard API on the api subdomain, then any reason the link sharing can't just operate as part of the same FE code base? Or am I misunderstanding here?

[pylipp]

Sorry, this comment slipped through somehow. @jamescrowley

any reason the link sharing can't just operate as part of the same FE code base?
Do you want the link-sharing back-end to be part of the FE code base? Or do you want the public FE for shared links to be in the same code base as the standard FE?

One more thing re the new public BE: When we introduce a new /shared route on the api subdomain, we can (and will) use a new schema there, different from the standard API schema (hosted on /).

[jamescrowley]

when you say resolve, does the FE actually need to map to a different route? Is it just crafting a graphql query directly? I wasn't clear why the FE would need to "process the returned data as if it was a GraphQL response?" - or specifically, why it therefore wouldn't be a graphql response in the first place?

[pylipp]

We (Hans, Felipe, me) talked about this yesterday; it seems to be feasible but requires adjustments to existing queries.

I'll try to explain it like this: in v2, when the user visits e.g. /bases/2/statviz, it will load the page and send a GraphQL request to the BE. A GraphQL response is returned and used to build the page.
For the scenario of link-sharing I was thinking whether the following is possible:

1. user visits link at .../<code>
2. FE sends request incl the code
3. BE checks the code. Since it has saved the type of requested data at the time of link creation, it can now look up the data and return it in the response, incl the corresponding route for FE
4. FE goes to the returned route and plugs in the returned data (instead of issuing another GraphQL request)
   You can see this as a mind experiment of mine rather 😄 does it make sense to you?

The approach we agreed on is different though:

1. FE sends request with code
2. BE validates code and sends metadata route
3. FE goes to route and runs GraphQL queries to fetch data

[HaGuesto]

@pylipp sorry, but did we really agree on that? Performance-wise this is not a nice solution since we are creating a waterfall, e.g. you have to wait for two requests instead of just one. This is rather how I would do it:

1. FE sends request with code
2. BE validates code and sends back information which view is behind that code and the corresponding requested data needed to show the view, e.g.

{
    resolveSharableLink {
        view
        viewData {
             createdBoxes { 

3. FE should either render the returned view under the same route or redirect (not sure what is easier).
4. Since the data is already cached in the FE from the first request, no additional request to the BE should happen.

[jamescrowley]

Could look at rate limiting server side based on the link hash being passed in. Could also consider https://cloud.google.com/armor/docs

[aerinsol]

@jamescrowley , would be interested in getting your input with all the findings made by the team, especially for the password pusher library (or suitable alternative).

[aerinsol]

LGTM, would like to hear more technical commentary on @jamescrowley from the answer, and both @jamescrowley and @HaGuesto on PP analysis.

[HaGuesto]

I took a look at the PP REST API. Here my thoughts:

Pro:

• it does what we need and is not much more complex than this.
• we can integrate it in a modular way so that we can easily replace it by another provider or our own structure if we really run into problems at some point.
• the integration is very simple (PP account creation and then API token creation, implementing two kind of requests from the BE, adding secrets to CircleCI) and will save us time to get first prototypes out.

Con:

• I didn't see what the rate limit is but from the documentation it sounds like we should not run into problems in the near future.
• repo is active, but mainly maintained by one person.
• we need to be careful what data we want to store in the links. There shouldn't be user information in there, maybe a user id but only if we really need it.

I'd go for it. @pylipp feel free to book me if you want to talk about it. I also pinged @jamescrowley on it.

[pylipp]

@HaGuesto Thanks for the feedback and the new idea of integrating PP, I quite like it too. I directly updated the doc acc. a couple of comments.

[pylipp]

Related follow-up discussion on Slack

[pylipp]

2.0: Draft concept for public link sharing of statviz