Wip development

[Thrilleratplay]

This is a very much a work in progress and is largely untested at this point. I am approaching this in three phases.

Thus far:

• Replace settings.json with environment variables. This makes it easier to break up front end and back end development.
• Replace Axios-Hooks with Tanstack React Query. Its caching is largely unnecessary but cache invalidation simplify needing to keep track of data being refetched. Allowing data and display to be abstracted and easier to change in the future.

TO DO:

• Update Vite and libraries that currently have security errors.
• Replace contexts with Jotai for simplified state management.

[EduardoOliveira]

HI

Thank you for the PR.
There are some very nice improvements there already.

[EduardoOliveira]

Hard-coding http might cause issues if the user is using a secured reverse proxy

[Thrilleratplay]

You're right. I'll move that so it is a part of the environmental variable. This is an artifact of when I thought the SSE were websockets and had a second variable exported.

[EduardoOliveira]

Btw I agree with @alyxdeburca, let's keep the current env file as a fallback behavior to reduce breaking changes.

[Thrilleratplay]

OK. I can readd it.

[alyxdeburca]

I haven’t had time to review the code but might I suggest allowing settings to be loaded from the json file as a failsafe if the environment variables cannot be loaded, just to keep the breaking changes to a minimum

[Thrilleratplay]

@alyxdeburca Funny enough, that is why I switched to environmental variables. If the settings.json file was loaded asynchronously, there is a change the values would not be available when first loaded. The fail safe is the values in the .env are always available. If a user wants to provide their own using docker, docker compose or the command line, those will supersede the values in the .env file. Additionally, other information can but added to it, such as a debug flag, then different versions based on deployment .env.development. What is currently used is probably the simplest use case through Vite for a very robust configuration system. The dotenv project shows how it can be better utilized and extended to the back end if found to be useful.

EDIT: I'll readd it to prevent breaking changes.

[EduardoOliveira]

@Thrilleratplay, please correct me if I'm wrong, but the values from the .env are baked into the source code at transpile time, right?
Doesn't that prevent the load of the value from the docker env assuming that we provide images with the "production" code only?

[Thrilleratplay]

@EduardoOliveira I think the confusion is due to using the wrong port in the .env, it should be localhost:8000. I forgot I had changed the ports locally and did not set them back the defaults. My apologies and will correct it.

To answer your question, the default values are baked in. If we use the docker-compose.yml, this is what currently exists:

environment:
      - "AGENT_ADDRESS=agent:8000" 

The changes I made would make this unnecessary and unused as the agent is exposed on localhost:8000.

After I correct this in the PR, the defaults will be:

environment:
    MMP_BACKEND_HOST="http://localhost:8000"
    MMP_BACKEND_PATH="/api"

So if a user wanted to have the UI and agent on different machines, or through a reverse proxy, they could adjust these as necessary. Hopefully that clarifies things. I will make sure it will work with the default values and readd the setting.json to prevent breaking changes.