mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 16:15:49 -06:00
[GH-ISSUE #1387] Provide a High-level Go API #1096
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#1096
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @velovix on GitHub (Aug 15, 2019).
Original GitHub issue: https://github.com/fatedier/frp/issues/1387
I have a use-case where I need to spin up reverse proxy servers automatically on-demand. This would be very easy to do with FRP if it exposed an API for starting servers in code, but near as I can tell FRP is not designed to be used as a library. I wonder if there is interest in providing this high-level API to other Go programs. If there is, this is something I would like to work on.
The following are the problems I've identified that prevent FRP from being usable as a library, and what I would do to fix them. There may be more issues that I've yet to identify, but I would be more than happy to dig deeper if there's any interest in making this happen.
The Problem
FRP has very friendly-looking functions like
server.NewService()that, at first glance, look like exactly the kind of high-level API that I am describing. However, there are a few problems:server.NewService()andclient.NewService()expect to have access to static resources for the monitoring panel. Again, this works for a tool but not for a library.The Solution
I am only familiar at a surface level with FRP's code, so I suspect some of what I'm saying may be unreasonable or undesirable for reasons I'm not aware of. That said, here is how I would solve the above problems:
http.FileSystemor some other interface that would override the use ofstatik.@fatedier commented on GitHub (Aug 15, 2019):
Thank you for your valuable advise.
I'm glad to see this changes but i need sometime to find the suitable way to do these things.
I'm not sure if it's the suitable way to just make the global configuration object a function parameter. Or we can split it into some small objects for different modules.
Yes, this is easy to modify.
Now it support statik and static file path configured by
assets_dir.It's a hard work while it really lack of much documentation and unit tests.
@velovix commented on GitHub (Aug 15, 2019):
Thank you for your feedback! I'm glad there is interest in this.
Yes, as I look more into the code I agree. I still don't feel that I understand the client configuration enough to come up with a proposal, but for the server would it make sense to use setters?
Perhaps it would look something like this:
Server Setters Proposal
Great! I'll send a pull request.
Yes, you're right, I missed that. I guess no additional changes are needed here.
Writing meaningful unit testing does seem very challenging for this domain. I'm not really sure how it would be done.
@fatedier commented on GitHub (Aug 16, 2019):
It seems too complicated.
You can first change to this one:
I will check if it should be splited by myself.
@fatedier commented on GitHub (Aug 16, 2019):
I ignored that the static files are compiled into code by statik, it will always consume some memory.
@velovix commented on GitHub (Aug 16, 2019):
Okay, understood.
That's true, but since statik's auto-generated files aren't committed to the repository they won't be included when FRP is used as a Go module.
@velovix commented on GitHub (Aug 16, 2019):
Sorry, I'm completely wrong about this. The generated files are committed.