Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add first concept for link-sharing #1831

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

pylipp
Copy link
Contributor

@pylipp pylipp commented Dec 6, 2024

Rendered document.

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

LMK if parts are not clear.

@pylipp
Copy link
Contributor Author

pylipp commented Dec 6, 2024

- the shared data will be live (as opposed to "freezing" the data to the time of link creation)
- link format is `.../<code> (can't use `.../bases/X/statviz`: insecure because it's easy to navigate to other bases and view their data; also not unique (can't expire))
- the expiration time of the link is one week. Later we can make is customizable, and/or add an action to invalidate a created link
- we expose the public app in the `api` GAE service. Hence it won't interfer with the main `app` service
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


- there has to be a new action-based permission to allow link-creation for certain usergroups
- there has to be a public FE and a public GraphQL endpoint to fetch data
- the public FE is hosted under `api.boxtribute.org/shared` and deployed with the `deploy-api` CircleCI job (depends a new `build-statviz` job)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

### Open questions

- how do avoid misuse of the link, or the exposed public GraphQL endpoint (DDoS mitigation)?
- can FE resolve a URL like `.../<code>` into a route like `.../<code>/bases/X/statviz` on the FE **and** process the returned data as if it was a GraphQL response?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


### Open questions

- how do avoid misuse of the link, or the exposed public GraphQL endpoint (DDoS mitigation)?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@pylipp pylipp force-pushed the draft-for-link-sharing branch from df7f4b5 to df392c6 Compare December 23, 2024 18:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants