Add Web UI for managing Golem

[Myestery]

/claim #1189

[Myestery]

Golem macos exexutable can be found here https://drive.google.com/drive/folders/1lrbZsLgdb0d_Q8xvqrQ6QuMRq1ZIUqwC,
couldn't upload it due to github restrictions

How it works

A new service is created called golem-ui-service, this service has an axum server and a react/TS project
The axum server serves as a proxy to the golem backend which the frontend then interacts with. It also serves the frontend assets when compiled.

Assets

The frontend assets are added to the golem executable using rust-embed

Usage

The UI server can be switched on by running golem ui command
This command takes in 3 optional arguments

• port: default=3000
• host: default=127.0.0.1
• api_url: default=http://localhost:9881

Building

run npm run build under golem-ui-service/frontend and then cargo build

[jdegoes]

@Myestery

Thanks for submitting your proposed solution to #1189!

I have not reviewed the code very closely, because first the UI must be in a state where it meets the requirements for the ticket. Once the UI meets the requirements, I will proceed to perform a code review, which may ask for additional revisions.

Overall, I want to congratulate you on so quickly developing a user-interface for the REST API! It was easy for me to find my way around the user-interface, and for the most part, it feels snappy an modern. Great job!

Now, I have to say the UI still need a lot of work before I can consider merging it. Let me review the main areas:

• Branding. The UI is not branded with Golem logo or name, and in fact, the title is "Vite + React + TS" from the template used. The color scheme is not designed with https://golem.cloud in mind.
• Workers. Aside from a few toolbar actions, there is no user-interface for workers. While ephemeral workers do not need a worker page, each durable worker needs its own page, which can be used to interact with the worker. All functionality related to the worker should be accessible from the worker page, including updating, logs, system events, configuration, files in the file system, etc. This is one of the biggest omissions of your user-interface. See Console for some inspiration around this.
• Browser-based Routing. Here I mean routing in the sense of URL mapping to a user-interface view--if you refresh each page (for example, a given API Definition page), sometimes you get "not found", which is a sign routing is not implemented properly.
• Route Editing. Route editing does not support all the binding types (for example file server, which was recently added, and allows serving static files at an endpoint; see Initial File System Issue for documentation). Further, it is not designed with Rib in mind. Rib is how one enters the worker name and the response. Right now, these are not text areas but text fields, and there is no support for inserting function names in Rib or specifying the component. It feels very incomplete and was clearly not used to build anything significant.
• Error Management. In the happy path, most things work (adding API definition, uploading component, etc.), but in the unhappy path, no inside-UI error is reported, one has to check the JS error console. For example, add a route using invalid response or worker-name. In general, every action must provide inline help when bad data leads to failure of the API. That's not being done generally or at all right now.
• File System. Components may have attached files, which seems to be supported; but the read/read-write status of these files cannot be changed in the interface. In addition, files cannot be browsed on a running worker (related to missing worker UI).

There are a number of other missing features and usability improvements that are required, but I will wait until if and when you decide to address these issues. I do think the pull request can be pushed forward to completion, but what I strongly recommend is building a TODO app in one of the Golem-supported languages, including with a full REST API and simple UI served by the backend. Once you write the code, force yourself to upload the component, create all API definitions, and serve the static content, using only the front-end you built. This will force you to add missing features and fix bugs that will end up making the UI production-ready and mergeable (right now, though a promising start, the UI is not really production-ready and does not replicate or extend upon the features of Console).

Please re-open when you get a chance to work on these issues!

[Myestery]

@Myestery

Thanks for submitting your proposed solution to #1189!

I have not reviewed the code very closely, because first the UI must be in a state where it meets the requirements for the ticket. Once the UI meets the requirements, I will proceed to perform a code review, which may ask for additional revisions.

Overall, I want to congratulate you on so quickly developing a user-interface for the REST API! It was easy for me to find my way around the user-interface, and for the most part, it feels snappy an modern. Great job!

Now, I have to say the UI still need a lot of work before I can consider merging it. Let me review the main areas:

• Branding. The UI is not branded with Golem logo or name, and in fact, the title is "Vite + React + TS" from the template used. The color scheme is not designed with https://golem.cloud in mind.
• Workers. Aside from a few toolbar actions, there is no user-interface for workers. While ephemeral workers do not need a worker page, each durable worker needs its own page, which can be used to interact with the worker. All functionality related to the worker should be accessible from the worker page, including updating, logs, system events, configuration, files in the file system, etc. This is one of the biggest omissions of your user-interface. See Console for some inspiration around this.
• Browser-based Routing. Here I mean routing in the sense of URL mapping to a user-interface view--if you refresh each page (for example, a given API Definition page), sometimes you get "not found", which is a sign routing is not implemented properly.
• Route Editing. Route editing does not support all the binding types (for example file server, which was recently added, and allows serving static files at an endpoint; see Initial File System Issue for documentation). Further, it is not designed with Rib in mind. Rib is how one enters the worker name and the response. Right now, these are not text areas but text fields, and there is no support for inserting function names in Rib or specifying the component. It feels very incomplete and was clearly not used to build anything significant.
• Error Management. In the happy path, most things work (adding API definition, uploading component, etc.), but in the unhappy path, no inside-UI error is reported, one has to check the JS error console. For example, add a route using invalid response or worker-name. In general, every action must provide inline help when bad data leads to failure of the API. That's not being done generally or at all right now.
• File System. Components may have attached files, which seems to be supported; but the read/read-write status of these files cannot be changed in the interface. In addition, files cannot be browsed on a running worker (related to missing worker UI).

There are a number of other missing features and usability improvements that are required, but I will wait until if and when you decide to address these issues. I do think the pull request can be pushed forward to completion, but what I strongly recommend is building a TODO app in one of the Golem-supported languages, including with a full REST API and simple UI served by the backend. Once you write the code, force yourself to upload the component, create all API definitions, and serve the static content, using only the front-end you built. This will force you to add missing features and fix bugs that will end up making the UI production-ready and mergeable (right now, though a promising start, the UI is not really production-ready and does not replicate or extend upon the features of Console).

Please re-open when you get a chance to work on these issues!

Hello @jdegoes
I finally opened another PR with all the fixes you requested here #1234