-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Define the WASP_SERVER_URL
env var
#1856
Conversation
WASP_SERVER_URL
env var
34801a6
to
afd1622
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good from a quick check!
The only thing I thought about is that the name doesn't fit the name we use for the client. So on client, to specify the server's URL, we use REACT_APP_API_URL
, where API_URL
is really the important part, REACT_APP is just prefix. And that prefix is also silly, it is just a reminder from using CRA.
So, if we call it "API_URL" there, it is a bit weird that we call it "SERVER_URL" here. Would be nicer if they are the same. If we don't want to do it now, maybe we can open an issue for it, or maybe it is better to handle now. I don't think "API_URL" is a good name really though. "SERVER_URL" sounds like a good name. So it would be breaking change. Maybe we can do it at the same time when we drop the REACT_APP prefix?
Btw pls also add to Changelog immediately what you did, once PR has taken final shape.
@@ -28,6 +28,7 @@ type CommonConfig = BaseConfig & { | |||
|
|||
type EnvConfig = BaseConfig & { | |||
frontendUrl: string; | |||
serverUrl: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha, so basically we need server to know its own URL! So far we had client know server URL, and we had server know client/frontend URL, but now we have server also knowing its own url.
@@ -28,6 +28,7 @@ type CommonConfig = BaseConfig & { | |||
|
|||
type EnvConfig = BaseConfig & { | |||
frontendUrl: string; | |||
serverUrl: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this include the port and the protocol?
It seems like it does. If so, we have a coupling between two config fields (port
and serverUrl
) and should modify our code to account for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
So we need the server URL to be able to implement OAuth successfully. In dev, we need the default local server URL to be set automatically e.g.
http://localhost:3001
. If the user can change the port to6000
then it would be good if we set theserverUrl
tohttp://localhost:6000
. -
In the production use case, the port start being meaningless since they use a domain name e.g. if their port is
7000
for some reason, the server URL will still be the same e.g.https://my-server.com
-
This means, we need to make sure that. the default dev server is set according to the port, but in the production case we should just use the user env var.
@@ -124,3 +125,6 @@ toESModulesImportPath :: FilePath -> FilePath | |||
toESModulesImportPath = changeExtensionTo "js" | |||
where | |||
changeExtensionTo ext = (++ '.' : ext) . fst . splitExtension | |||
|
|||
defaultDevServerUrl :: String | |||
defaultDevServerUrl = "http://localhost:3001" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to support subpaths (like we do for the client)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we don't yet support running the server from the subpath, I'd say no need to do that now. We'll cross that bridge when we get to it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple of questions I think we should address before merging.
Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>
afd1622
to
fb4115b
Compare
@@ -1,9 +0,0 @@ | |||
import { stripTrailingSlash } from "./universal/url"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This template file wasn't used anywhere, so I removed it. It's a leftover from migrating to the SDK.
@@ -40,7 +41,7 @@ const config: { | |||
all: { | |||
env, | |||
isDevelopment: env === 'development', | |||
port: parseInt(process.env.PORT) || 3001, | |||
port: parseInt(process.env.PORT) || {= defaultServerPort =}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sodic Now the default server port and default server URL are both defined in Haskell and the URL is constructed using the default port variable.
@Martinsos Based on your comment, you are fine with the FYI We would still need to keep some sort of prefix. |
Ideal would probably be something like WASP_, or CLIENT_ -> whatever makes most sense, but I would try to not have it specific to underlying technology. I understand if we are not syncing the names now, but in that case pls create a GH issue to do this. |
I've created an issue to sync the env var names: #1885 |
Before we did the OAuth redirect like this:
We need the
serverUrl
variable for the new OAuth setup since we are doing the redirect like this: