Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request - Add Web Front End #691

Open
freedbygrace opened this issue Sep 17, 2024 · 4 comments
Open

Feature Request - Add Web Front End #691

freedbygrace opened this issue Sep 17, 2024 · 4 comments

Comments

@freedbygrace
Copy link

Add a web based front end that allows for the creation of connections, users, groups, jwt tokens, etc

Allows for querying of backend databases

Metrics to see how many requests from where etc

@thadguidry
Copy link
Collaborator

thadguidry commented Sep 18, 2024

@freedbygrace Thanks for the ideas! We have indeed been thinking about all of these already, and have plans to tackle them in various ways.
But I have some questions to understand your thinking and needs.

  1. For adding connections, you mean, to have a webpage form that allows you to edit the environment variables for all the configuration parameters (DB_URL, DB_USER, etc...) ?
  2. For querying, would you prefer something like HTTPie for Web / HTTPie.AI ? Where you not only could type and edit parameters and modify headers, but also with HTTPie.AI you could query with natural language, such as "Fetch all films starring Tom Cruise before the year 2000".
    • or do you envision some other design for querying? If not my example above, what would your preferred design look like? Can you point to examples you like or would prefer?
  3. For metrics, I think it's best if we offer a robust API backend that users could use web hooks like from Splunk, Prometheus, Sensu, OpenNMS, Datadog, etc. We could certainly make the packaging of this seamless as a choice during installation, where the choice would run a specific installer/config script for some of those, with initial default settings. But I think this falls into very opinionated area, and so we'd likely only choose 1 as a default add-in script for our package release. The community could submit add-in scripts that download, install, config them against our proposed API backend for DB2Rest metrics.
    • Caveats: Networking issues, depending on where and how DB2Rest is hosted, so we have no control. Again, here to, the community could work on scripts which we could host in another sister repo for managing DB2Rest add-in scripts that config and solve various networking/host issues.
  4. Would you be willing to sponsor or pay for these features?
  5. Would you be OK and pay for some of these features if offered only in an Enterprise version?

@kdhrubo
Copy link
Owner

kdhrubo commented Sep 18, 2024

Metrics and health already supported

https://db2rest.com/docs/category/actuator

@freedbygrace
Copy link
Author

Hey! Thank you for the excellent feedback! I will answer questions in the same order.

  1. Similar to how Dreamfactory works where there is a WebUI for database connection configuration to avoid having to mess around with configuration files etc. This is not necessarily bad and is quite useful for automation scenarios that do not require user interaction, but from a ease of consumption perspective, a WebUI would be great.
  2. The HTTPie ideas actually look good and could actually be a better approach to what I had in mind, however, what I had originally thought of is a web based SQL query editor with intellisense, the ability to save queries, and export data to various formats.
  3. Prometheus would work just fine! If the data can be exposed over http or https then we can slap that behind a reverse proxy.
  4. I cannot sponsor, but I am definitely willing to make a donation.
  5. Yes, I would not be opposed to this as I know this type of programming is more than a heavy lift!

@thadguidry
Copy link
Collaborator

@freedbygrace Thanks for answering those. It helps us make informed decisions about the future direction of the project.

Regarding point 2. we actually try to avoid SQL somewhat since not all web developers are well versed in it, but they are quite comfortable when dealing with query URLs and parameters (hence the RQL syntax). Our main users that we target are web developers, but knowing that infrastructure backend devs and support personnel, such as likely yourself, also need easy install and config options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants