Page MenuHomePhabricator

[server] initial commit to support new app URL
ClosedPublic

Authored by varun on Mar 10 2022, 9:25 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 15, 9:00 AM
Unknown Object (File)
Fri, Nov 15, 9:00 AM
Unknown Object (File)
Fri, Nov 15, 9:00 AM
Unknown Object (File)
Thu, Nov 14, 8:52 AM
Unknown Object (File)
Sun, Nov 10, 12:12 AM
Unknown Object (File)
Sun, Nov 10, 12:12 AM
Unknown Object (File)
Sun, Nov 10, 12:12 AM
Unknown Object (File)
Sun, Nov 10, 12:12 AM

Details

Summary

per https://linear.app/comm/issue/ENG-660/make-web-app-accessible-via-commapp, we need a different JSON file for the new web app URL. this diff adds some functions to fetch the appropriate data from files and introduces a small rename.

Test Plan

ran flow

Diff Detail

Repository
rCOMM Comm
Branch
varun/eng-660 (branched from master)
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

varun retitled this revision from initial commit to support new app URL to [server] initial commit to support new app URL.Mar 10 2022, 9:25 PM
Harbormaster returned this revision to the author for changes because remote builds failed.Mar 10 2022, 9:27 PM
Harbormaster failed remote builds in B7294: Diff 10284!

i'm gonna have to update the buildkite script to create a new_app_url.json file

i'm gonna have to update the buildkite script to create a new_app_url.json file

Did it for BuildKite, but you're going to have to do it for .github/workflows/eslint_flow_jest.yaml in this diff (or I guess one that's landed before this) to keep things green on GitHub

varun requested review of this revision.Mar 10 2022, 9:59 PM
tomek requested changes to this revision.Mar 11 2022, 6:11 AM

It was not clear to me why do we need a new file with a url. After some time I realized that we should still support the old one, because of the native clients - but this should be explained in the summary.

There's a lot of going on in this diff:

  1. A new function that reads a new file is added
  2. We check in a lot of places if we're using a new url - should be a separate function
  3. We choose which facts to use
  4. We modify the router to serve the new path

We should split this diff into multiple ones, each having only one purpose

server/src/responders/handlers.js
52 ↗(On Diff #10284)

We have this logic (startsWith(basePath)) duplicated in a lot of places. It would be a good idea to extract it to a function, preferably the one that takes base path and returns AppUrlFacts.

server/src/session/cookies.js
539 ↗(On Diff #10284)

Adding the flag isn't a good idea. It works ok now, but what if we wanted to introduce yet another url in the future? A much more maintainable approach could be to instead accept AppURLFacts as a parameter.

This revision now requires changes to proceed.Mar 11 2022, 6:11 AM

will address inline comments and split this into multiple diffs

server/src/responders/handlers.js
52 ↗(On Diff #10284)

makes sense

server/src/session/cookies.js
539 ↗(On Diff #10284)

yeah fair enough. i was thinking we'd have at most one old and one new URL at any point in time, but i guess we could have more...

Add a new function that reads json file for commAppURLfacts, rename appURLFacts to squadCalURLFacts, add new function that returns the appropriate AppURLFacts based on the URL provided

varun edited the test plan for this revision. (Show Details)
varun added inline comments.
server/src/utils/urls.js
34

probably could have put this in a separate diff but it's so small that I just included it here

Thanks for splitting the diff - it's a lot easier to review now!

server/src/utils/urls.js
35–37

Just a nit: we can avoid calling getCommAppURLFacts function twice

This revision is now accepted and ready to land.Mar 16 2022, 3:49 AM