Implement SPA

[edufschmidt]

• Implement meetbot's UI as a React SPA using Rendition, and replace the old static UI.
• Apply minor changes to the backend
  • Add /api prefix to API endpoints
  • Apply minor refactoring of the server/app structure

[20k-ultra]

can you rebase and push then ping me again

[edufschmidt]

Rebased and pushed @20k-ultra :)

[edufschmidt]

Why does the UI have to be an entirely new project (new package.json) inside the meetbot project ? I think it will add a lot of confusion for versioning and general maintenance.

I tend to like the idea of keeping the backend and the UI apart. In my opinion it makes both projects easier to maintain. Besides, this is more or less what the Jellyfish team is doing. Of course, I'm willing to change this if the team prefers to have a single project for both the UI and the backend.

[Hades32]

@edufschmidt

this is more or less what the Jellyfish team is doing

Is not quite right, as in JF the UI is a separate deployment. I would argue that you should have separate package files, when you deploy separately and have a single on if you deploy as a monolith

[edufschmidt]

@edufschmidt

this is more or less what the Jellyfish team is doing

Is not quite right, as in JF the UI is a separate deployment. I would argue that you should have separate package files, when you deploy separately and have a single on if you deploy as a monolith

Yes @Hades32, what I meant is that JF also keeps nested Node projects within a single repository. Do you see any important downsides of keeping the current structure? I believe it helps keep concerns separate and makes it simpler to develop and maintain the API and UI independently. Plus, in the end all we need from the UI project is a static bundle we can serve from our express app.

[Hades32]

@edufschmidt I think it complicates things without a good reason. Two places to check for dependencies, double the code for actually building the thing.

If you really want to keep things separate, then you should go full in, have a nginx UI container, some reverse proxy container and the api container separate. Then you have a real separation and the compose file tells people exactly where to look for changes. That would be a great approach, but might be a bit overkill. But I feel we're in the middle where we don't reap the benefits of either side

[edufschmidt]

Why does the UI have to be an entirely new project (new package.json) inside the meetbot project ? I think it will add a lot of confusion for versioning and general maintenance.

@20k-ultra the two projects were merged, as suggested.

[20k-ultra]

Is there a way to run the UI so it actually communicates with the bot API ?

[edufschmidt]

Is there a way to run the UI so it actually communicates with the bot API ?

By default, when running in development mode the MirageJS server is initialized, so all requests made by the SPA are intercepted, and mock data is returned. When running in production, the SPA should communicate with the API normally.

In case you need to modify this behavior, you can change the following lines in src/ui/src/main.tsx:

if (DEV) {
    setupMockServer();
}

If setupMockServer() is never called, the MirageJS server will never be initialized, and all requests should go straight to the API.

Hope that answers your question @20k-ultra.