Handling package and function names dynamically

I'm on my first Golang project, which consists of a small router for an MVC structure. Basically, what I hope it does is take the request URL, separate it into chunks, and forward the execution flow to the package and function specified in those chunks, providing some kind of fallback when there is no match for these values in the application .

An alternative would be to map all packages and functions into variables, then look for a match in the contents of those variables, but this is not a dynamic solution.

The alternative I have used in other languages (PHP and JS) is to reference those names sintatically, in which the language somehow considers the value of the variable instead of considering its literal. Something like: {packageName}.{functionName}() . The problem is that I still haven't found any syntactical way to do this in Golang.

Any suggestions?

func ParseUrl(request *http.Request) {

	//out of this URL http://www.example.com/controller/method/key=2&anotherKey=3

	var requestedFullURI = request.URL.RequestURI()       // returns '/controller/method?key=2key=2&anotherKey=3'
	controlFlowString, _ := url.Parse(requestedFullURI)
	substrings := strings.Split(controlFlowString.Path, "/")       // returns ["controller","method"]
	
	if len(substrings[1]) > 0 {

		// Here  we'll check if substrings[1] mathes an existing package(controller) name
        // and provide some error return in case it does not

		if len(substrings[2]) > 0 {
			// check if substrings[2] mathes an existing function name(method) inside 
            // the requested package and run it, passing on the control flow
		}else{
			// there's no requested method, we'll just run some fallback
		}
	} else {
		err := errors.New("You have not determined a valid controller.")
		fmt.Println(err)
	}

}

You can still solve this in half dynamic manner. Define your handlers as methods of empty struct and register just that struct. This will greatly reduce amount of registrations you have to do and your code will be more explicit and readable. For example:

handler.register(MyStruct{}) // the implementation is for another question

Following code shows all that's needed to make all methods of MyStruct accessible by name. Now with some effort and help of reflect package you can support the routing like MyStruct/SomeMethod. You can even define struct with some fields witch can serve as branches so even MaStruct/NestedStruct/SomeMethod is possible to do.

dont do this please

Your idea may sound like a good one but believe me its not. Its lot better to use framework like go-chi that is more flexible and readable then doing some reflect madness that no one will understand. Not to mention that traversing type trees in go was newer the fast task. Your routes should not be defined by names of structures in your backend. When you commit into this you will end up with strangely named routes that use PascalCase instead of something-like-this.

What you're describing is very typical of PHP and JavaScript, and completely inappropriate to Go. PHP and JavaScript are dynamic, interpreted languages. Go is a static, compiled language. Rather than trying to apply idioms which do not fit, I'd recommend looking for ways to achieve the same goals using implementations more suitable to the language at hand.

In this case, I think the closest you get to what you're describing while still maintaining reasonable code would be to use a handler registry as you described, but register to it automatically in package init() functions. Each init function will be called once, at startup, giving the package an opportunity to initialize variables and register things like handlers and drivers. When you see things like database driver packages that need to be imported even though they're not referenced, init functions are why: importing the package gives it the chance to register the driver. The expvar package even does this to register an HTTP handler.

You can do the same thing with your handlers, giving each package an init function that registers the handler(s) for that package along with their routes. While this isn't "dynamic", being dynamic has zero value here - the code can't change after it's compiled, which means that all you get from being dynamic is slower execution. If the "dynamic" routes change, you'd have to recompile and restart anyway.