chrsmith
commented
5 months ago @vdavid, the breakdown looks right. Some notes:
Figure out auth (we have something like
getSAMSIDForUseron dotcom)
Yes, we already have a way to lookup the SAMS "account external ID" for a the current dotcom user. Note however, that it's possible the dotcom user has multiple SAMS identities. We'll need to handle that some way. (We have an approach that works well enough for now to disambiguate which subscription we should use...)
Move/copy the graphql schema to dotcom
That would work, if we wanted to keep the same names for the root query and mutation operations.
However, I imagine this might be a bit too restrictive and difficult to maintain. So I wouldn't see using a different GraphQL schema as a major problem. Especially if it would make the resulting code easier to understand or more maintainable.
Figure out how to keep the schema in sync
I wouldn't worry about this. Yes, we need to make sure to preserve the GraphQL schema as-is and not introduce any breaking API changes. But just having a big, scary // WARNING: comment in the code is probably sufficient. (And, the fact that we are only talking about ~6 top-level query/mutation objects, and the several source file's worth of types.)
Setting up git submodules, or some sort of auto-commit bot to keep the two repos in-sync is probably more trouble than its worth. (Especially since the accounts.sourcegraph.com repo is private.)
Set up the TypeScript and Go generation tooling
- Can someone help who has set this up before? → Check out the git blame to find people who know this
We would just use the existing infrastructure in the monorepo for generating TypeScript or backend resolvers, right? e.g. we wouldn't necessarily need to setup a separate codegen pipeline or anything. Right?
Create the Go-side handler to proxy requests to the configured SSC instance
- Ask Chris, he might have a prototype for this?
Yes. The thing you are looking for is httputil.ReverseProxy.
After you get the frontend wired up and are able to execute Golang code in the dotcom backend, I can walk you through how to use that type. But it should be all that we need to make this work.
Recreate the existing pages (/cody/welcome and /cody/subscription) with Wildcard Naming is hard: What should be the URL?
Naming is hard. Note that /welcome isn't exactly necessary to be ported. It serves a fairly unique purpose...
Because we are using Stripe Checkout, and do not "own" the new subscription UI, we actually don't know if the subscription sign up was successful or not. So Stripe redirects the user to /cody/welcome?checkout_session=xxxxxx, so that we can do the backend book-keeping to finish creating their team if they completed the checkout flow.
This means:
- We will not need a
/welcomepage at all once we no longer use Stripe Checkout, and manage our own checkout page. - The "backend book-keeping" we do for the user to finish creating their team is technically unnecessary. Since in theory, as long as we see the Stripe webhook for the new subscription, we will perform that book keeping. (But performing that logic when the user navigates to
/cody/welcomeis a belt-and-suspenders type of thing.)
In other words: migrating the welcome page might require some extra care. But nothing that would prevent us from the sort of "request proxying to the SSC backend" we have been talking about.
🆕 requirements
- You probably were already thinking this, but I assume we'd want to have the new UI pages and URL change for the "manage subscription" button behind a feature flag. (And maybe the GraphQL endpoints too?)
ff-native-cody-plg-frontend?
vdavid
Task breakdown:
getSAMSIDForUseron dotcom)/cody/welcomeand/cody/subscription) with Wildcard/cody/welcomeis OK but https://sourcegraph.com/cody/subscription is already taken. Ideas:/cody/plan← My favorite so far/cody/payment/cody/billing