Dynamically resolving URLs in .Net 5
Should you choose a static programming language or a dynamic runtime? And why is Winnie the Pooh relevant to the answer to that question?
Join the DZone community and get the full member experience.
Join For FreeMy favourite feature with .Net and C# is that it's a static programming language. This is also the largest problem I have with .Net 5 - As in, its blessing also becomes its curse. Simply because sometime I need a bit more "dynamic nature" than that which .Net provides out of the box. However, .Net 5 has a lot of interesting features, allowing you to circumvent this, opening it up for a more "dynamic nature". Let me illustrate with an example C# HTTP API controller.
x
[Route("magic")]
public class EndpointController : ControllerBase
{
[HttpGet]
[Route("{*url}")]
public async Task<ActionResult> Get(string url)
{
/* Do interesting stuff with URL here */
}
}
Notice the [Route("{*url}")] parts in the above code? This tiny little detail implies that everything going towards "magic/xxx" will be resolved by the controller, and its "xxx" parts will end up becoming the url argument to our method.
This tiny little trick allows you to create a dynamic controller, that resolves everything, within a root URL, where the URL itself becomes an argument to your method. This was what I hinted towards in my previous article when I said "now all you need to do is a way to dynamically invoke endpoints". You can see the entire code in my magic.endpoint project, specifically in its EndpointController class. The MagicEndpoint controller class in Magic, basically resolves all the 5 most commonly used verbs in this way.
- GET
- POST
- PUT
- DELETE
- PATCH
All the methods in this controller, takes the URL dynamically, where the relative URL becomes an argument to its method. This allows me to dynamically load my Hyperlambda files, and execute them as such. All in all quite brilliant if I may be so courageous as to say so myself in fact :)
Using tiny little tricks as this, I am able to take something that is fundamentally static in nature, turning it completely on its head, making it 100% dynamic. This allows me from a use case basis to choose which paradigm I want to use for each individual problem I face. If I need static typing, I use normal C#. If I need a more dynamic runtime, I choose Hyperlambda. And both paradigms perfectly aligns with each other, allowing me to interoperate between everything with a simple signal invocation.
- 100% dynamic platform - Check!
- 100% static typing - Check!
It's almost as if you can hear Winnie the Pooh in the background answering "Yes please both" to the question of whether or not he wants chocolate or honey. Basically, once confronted with the question of "do you want static typing or a dynamic runtime", your knee jerk reaction should be as follows ...
Yes please, both!
The above little trick, allows you to use .Net API controller endpoints to literally execute any dynamic scripting language you need, where the URLs resolves to the script files on your server's file system. Of course, Magic only executes Hyperlambda files, but you can just as easily execute Lizzie files, Python files, or Ruby files for that matter - As long as it is an interpreted language of some sort. In fact, I am not sure if I would recommend it, but you could probably also resolve your HTTP invocations directly to SQL files using this little trick.
Below you can find a link to download Magic and try out the whole platform tying all of these constructs together if you wish.
Opinions expressed by DZone contributors are their own.
Comments