Consider turning this repository into a `remix-stack`

[devraj]

Is your feature request related to a problem? Please describe. Remix stacks are meant to be a software stack that incorporate the Remix application into it. They are meant to provide a standardised way implementations of:

• Database
• Automatic deployment pipelines
• Authentication
• Testing
• Linting/Formatting/TypeScript

The above is the problem we are trying to solve for Anomaly via these labs.

Describe the solution you'd like If this breaking change deems that Remix is the suitable production framework (since we already use react router) then we:

• rename this to become a Remix stack
• make the web-client redundant
• all Anomaly apps boot up as a remix-stack with our preferred server side frameworks

This also fundamentally changes the way we are managing repositories for Anomaly projects, combining the server and client side workflows into the single repository.

There is possibly a use case where we archive the current lab repositories and the work that was done in them and create a separate repository for psychedelic-stack

Describe alternatives you've considered

For as long as I have maintained this repository, I have been trying to standardise the client side and maintained a template here. There have been many changes to frameworks like NextJS and Remix since the introduction of React 18 (which had some fundamental improvement).

This lead to standardisation of production framework with unified set of features like routing, caching, header management, which would mean that we can give up tracking many individual projects and take a more wholistic approach.

This would be a breaking change and would mean that the client project be unified into this repository.

Additional context remix recommend you name your stacks after a musical sub-genre. Proposed name for the stack be psychedelic-stack where p presents python and the musical sub-genre honours Pink Floyd.

[devraj]

Thoughts on SSL for development

create-react-app support SSL for development and we have been using this as part of the lab-web-client, moving to remix means that there's no native support for SSL.

There are some documented workarounds where we configure the express server. This also applies for proxying the api endpoints from the docker container (something that create-react-app lets us do also).

The broader discussion here is what anomaly deems to be the stack going forward.

The aim of these labs has been to create a stack that is agnostic of any deployment targets i.e as open as possible so we can choose a infrastructure provider.

Remix templates provide the option of pre-configuring the project to be run in environments like Netlify or Vercel something that Anomaly does use to deploy say their web site.

If we were to choose netlify as the front end host, then:

• we can run SSL via their command line tools
• proxy the api endpoints via their command line tools

There's also a follow up ticket for the cli tools to autogenerate the SSL certificates which would take away another function from our templates.

Read this blog post about Remix and Netlify cli

This approach would mean that the stack will depend on Netlify for all projects. While it's noted that remix allows for the deployment target to be changed, it would see there are some gotchas.

The question remains as to how much we build upon what Netlify is doing or do we want to stay completely agnostic of providers?

It is also noted that we are using Remix as a Backend for our Frontend and not buying into the complete stack, as our Python based server framework is preferred.

[devraj]

Adding the following achieves SSL and proxying the API to the container.

[dev]
  command = "remix watch"
  port = 3000
  [dev.https]
    certFile = ".cert/cert.pem"
    keyFile = ".cert/key.pem"

[[redirects]]
  from = "/api/*"
  to = "http://localhost:8000/:splat"
  status = 200
  headers = {X-From = "Netlify"}

Once we decide where to store the remix applicaiton (in this repository or another), we can make a decision on if we run the netlify cli inside of a container (taking away the need to run a separate process in another window).

We have to make a decision as to what a deployed version looks like specially on a fully managed version e.g on AWS.

[devraj]

When I use the ntl dev development server, the app throws hydration exceptions complaining that the app state is different to that of what's on the server.

Initially I went down the rabbit hold where developers are talking about hydration issues caused by react18 and workarounds until 18.3 fixes this.

Eventually I ran the ntl dev with and without TLS and then ran yarn dev to find that the app works when using the remix server but not when being served via ntl dev. I also found this where @nickytonline from @netlify is attempting to fix the developer experience of the netlify template.

My hypothesis is that the netlify server is injecting something in the response which makes the app drift from the server state.

[devraj]

Thought I would check on the @vercel if I can use their cli tools:

• SSL is possible but not supported out of the box - not a show stopper but would be nice to have
• Proxying is not supported at the moment
• Hot reloading works ✅

[devraj]

Following on my discussion on the PR on the remix repository, it turns out that the maintained template lives at https://github.com/netlify/remix-template and hence creating a remix app via

npx create-remix@latest --template netlify/remix-template test

does the trick and everything works.

It's suggested at this point that we restart the stack with this template for Netlify hosted projects.

[nickytonline]

Glad to see it's working @devraj!

[devraj]

Hey @nickytonline, I am chasing my tail to figure the browser would loose the websocket connection for live reload when I am running ntl dev. My setup is

• Project bootstrapped via the netlify template for remix
• SSL configured to run locally, with a little help from mkcert
• Proxy /api to a docker container running a Python application

I am not seeing something that's defined in this issue here and have lost the ability to live reload when going the netlify server + https.

If I hit the app at port 3000 all works well.

The issue lodged on remix suggests that adding devServerPort in the remix configuration should work but that does not seem to make a difference.

If you have any thoughts on this I would appreicate a comment. 🙏

My current efforts are in this repository.

A thread on Stackoverflow suggests that this might be due to the TLS certificate not being recognised by the websocket server, which seems completely plausible as there's no configuration for that portion of it.

I also checked that if we drop TLS support for development then Netlify CLI supports reload

[devraj]

Please track the issue on @remix-run/remix LiveReload doesn't work when TLS is enabled for a discussion on this exact same pending issue on Websockets not working when TLS is enabled.

See also:

• LiveReload doesn't work when TLS is enabled
• feat(remix-dev): add devServerSecureContextOptions config option
• feat(remix-dev): add devServerCert & devServerKey config option

[devraj]

See this discussion which reveals that we have to import from the deno runtime if we want to execute remix on netlify edge functions