[Feat] Built-in management interface

looterz / grimd

:zap: fast dns proxy that can run anywhere, built to black-hole internet advertisements and malware servers

MIT License

1.38k stars 108 forks source link

[Feat] Built-in management interface #99

Closed soulteary closed 2 years ago

soulteary commented 2 years ago

hello maintainer 👋 @looterz

I tried using reaper with grimd and it worked fine.

https://github.com/looterz/reaper

But using two projects at the same time can be a bit complicated at deployment or startup time.

I have an idea, if you agree, I'll simply tweak the build, add steps to get the reaper interface, and then build reaper into grimd.

I can also add a simple user authentication feature to this interface if necessary.

Looking forward to hearing your views.

looterz commented 2 years ago

I really like that idea, it's been a long time coming and something I wanted to do years ago, the current separation of the projects isn't ideal. It could be a good opportunity to modernize the interface portion of the project and improve the API as well, they were thrown together quite quickly years ago.

soulteary commented 2 years ago

I can try to make a demo.

For more ready-made examples, please refer to the docker-flare project or the docker-flame project.

Sorry that the description languages of these two projects are not in English, but it should have little effect. You can use docker run directly to verify and experience.

My imaginary result is that we can have an "AIO" , a good product out of the box, the user can enable or disable the interface or API with a parameter as someone like.

If you think this way works, I will try it. Looking forward to hearing your views.

soulteary commented 2 years ago

There is a choice here, we may need to discuss whether the future grimd project will be a pure golang project, and whether the project will consider including front-end code (eg: javascript).

If keeping it a pure standalone golang project, then I would use git submodule or download the github project release zipball to integrate the interface.
If you consider simple maintenance, we may try to integrate the front-end interface into this project, which may lower the integration and development threshold for other users.

How to choose, you need to make a judgment, I will quickly implement the demo after you confirm it. @looterz 🍻

looterz commented 2 years ago

There is a choice here, we may need to discuss whether the future grimd project will be a pure golang project, and whether the project will consider including front-end code (eg: javascript).
* If keeping it a pure standalone golang project, then I would use **git submodule** or download the github project **release zipball** to integrate the interface.

* If you consider simple maintenance, we may try to integrate the front-end interface into this project, which may lower the integration and development threshold for other users.
How to choose, you need to make a judgment, I will quickly implement the demo after you confirm it. @looterz 🍻

Personally like the idea of a git submodule, easy enough to implement but still has a separation of concerns between the web management interface and the grimd project itself.

soulteary commented 2 years ago

OK, then let's move in this direction first and make a try.

I will provide a demo later, let's try it together.

soulteary commented 2 years ago

@looterz welcome to review the code, and use docker for early trial.

https://github.com/looterz/grimd/pull/102

As before, GitHub actions require you to merge code to be able to test.

looterz commented 2 years ago

Looks great, testing out a merge

soulteary commented 2 years ago

Then this issue can be closed, and the next step is to optimize the integrated functions.