DASHBOARD_URL in code defaults to 3333

[mlsad3]

Hi, I'm really excited about saving $200-300/month as a startup with 0 customers a ton of end-to-end tests!
It was a little confusing getting this up and going since the DASHBOARD_URL for the director has it default to localhost:3333, when I think the dashboard is defaulting to port 4000. This should probably be updated.

[agoldis]

@mlsad3 What was the main pain trying to set it up? I'd love to make it easier...

[mlsad3]

Hi @agoldis , I think most of my problems are self-induced. Mostly around AWS :)

[mlsad3]

That said, I'll need to send you a link to my updates just so you know what I have had to do. For instance, for Director, I have it running on Elastic Beanstalk and launched using concurrently (launching multiple nodejs on the same machine). This means a couple things:

• I can't use PORT environment variable, since it is too specific, and had to rename it to SORRY_CYPRESS_DIRECTOR_PORT (I actually have been working on getting API and Dashboard up on same machine as well)
• I tried forwarding all traffic from my main nodejs, using Express, and sending it to the localhost:1234 (so that someone can point their Cypress to www.mywebsite.com/dev/testing/director instead of www.mywebsite.com:1234), but it seems like Cypress can't handle this.
• I instead setup the load balancer in AWS to point port 1234 to the Director, but the Load Balancer couldn't check the status of the Director (health) and so always thought it was broken. For this, I had to add an api.get("/status", res.send("looks good")) so that the service would know that the process was healthy. Probably should have just sent 200, oh well :)
• Unfortunately after a lot of work, I still haven't gotten Dashboard (or API) working correctly, as they don't fully support working through express. For instance my main app is enforcing sign-in permissions to Dashboard/API (using cookies), and then users navigate to www.mywebsite.com/dev/cypress to get run data. Too much to write about what I tried, so I'll just have to send my code for perusal :)

[agoldis]

@mlsad3 thanks for sharing the details!

I've fixed the original issue you've reported 53e2f54

As for the rest, let me ask few more questions

I can't use PORT environment variable, since it is too specific, and had to rename it to SORRY_CYPRESS_DIRECTOR_PORT (I actually have been working on getting API and Dashboard up on same machine as well)

Was it because all the processes were running on the same machine and all were using the same PORT env var?

I tried forwarding all traffic from my main nodejs, using Express, and sending it to the localhost:1234 (so that someone can point their Cypress to www.mywebsite.com/dev/testing/director instead of www.mywebsite.com:1234), but it seems like Cypress can't handle this.

Was it because cypress client does not support redirects?

I instead setup the load balancer in AWS to point port 1234 to the Director, but the Load Balancer couldn't check the status of the Director (health) and so always thought it was broken. For this, I had to add an api.get("/status", res.send("looks good")) so that the service would know that the process was healthy. Probably should have just sent 200, oh well :)

👍🏻

Unfortunately after a lot of work, I still haven't gotten Dashboard (or API) working correctly, as they don't fully support working through express. For instance my main app is enforcing sign-in permissions to Dashboard/API (using cookies), and then users navigate to www.mywebsite.com/dev/cypress to get run data. Too much to write about what I tried, so I'll just have to send my code for perusal :)

So you want restricted access to the dashboard and tried to create some kind of wrapper that lets users in?

---

I am wondering whether having CloudFormation / Terraform template with a single host / docker setup would make it easier for you to deploy the whole system.

If you have some already existing setup, may be we can enhance it and share?

[mlsad3]

My setup is pretty ugly at the moment, so I'm not sure how good it would be to enhance/share from. Sometime (not in the next few months unfortunately due to timeframes), I'd like to put the whole package into a single nodejs express process.

As for your questions:
The PORT issue was due to having all the processes running on the same machine and using the same PORT env variable.

I I'm not sure about Cypress client and redirects (I wasn't using redirects). Instead, my site was more like a proxy. Cypress client would make request, I would forward request to localhost:1234, and then respond back to the client with the resulting response. I think Cypress has issues when there are extra things after the host url. i.e. https://mywebsite.com versus https://mywebsite.com/dev/director. It just wouldn't run, but I didn't debug too deep into that.

Final question: Yes, I wanted to restrict access to particular users. I already had user infrastructure in my existing website. I had to mess around a bit in both API and Dashboard to ensure they could handle the extra endpoint "/dev/dashboard" and "/dev/api". I also added express into the API project so that the authentication cookies were sent in requests. ...but I kept hitting some issues with the API pinging the wrong URL, and the Dashboard/API interaction also hitting something weird. Sorry, I got down deep and got lost, so I probably can't explain everything :)

[agoldis]

@mlsad3 alright, thanks for sharing the insights! Please tell me if 53e2f54 closes the issue for you

[mlsad3]

Hi @agoldis yes, it closes the issue. Thanks!

[mlsad3]

Hi @agoldis , I've pushed my changes out to my fork. Definitely not anything you would want to pull in (since you've already made changes to help) but just to give you an idea.
master...mlsad3:add-aws-eb-updates

Of note, you can see how my .env files' urls have extra paths after them (instead of http://localhost:3000, it is http://localhost:3000/testing/cypress/graphql). This caused me to go down other routes to get Dashboard / API working with those. Take a look at "ASSET_PATH" to see another example. And "playground" for another. In the end, I wasn't able to fully get API/Dashboard to work with the extra paths in urls, but I left in some comments.

...just in case you're curious. Thanks for your work!

[agoldis]

@mlsad3 You made my day! Thanks for your generosity! I will take a look at the files!