Dynamic Pluggable Microservice Framework

Quickly and easily deploy RESTful Microservices using this pluggable microservice framework.

No more coding RESTful Interfaces. No more having to debug your RESTful Interfaces.

This is functional programming meets pluggability meets minimal code meets ease of use.

What could be easier than coding your microservices as Python functions in a single module, drop your microservice module into a directory, and then make RESTful AJAX Calls to run your microservices?

Oh, you have a complete Python Package for your microservices? Ok. No problem. You will want to expose some of them as endpoints and call them from some RESTful Interface, yes? So now you code your exposable functions that call your fundamental functions from your actual Packages and drop your exposed modules into a directory. All those microservice functions are now exposed as RESTful endpoints without restarting the server.

Sounds too good to be true? Check it out for yourself. https://github.com/raychorn/microservices-framework

Need a Docker Container ready to run this framework? docker pull raychorn/microservices-framework:0.7.0 Then do a “git clone https://github.com/raychorn/microservices-framework” followed by “git pull origin main” to get the latest code from the repo. Or check out the Releases to pick the release you want to install. It requires Python 3.8.x, PIP and virtualenv have been installed in the Docker Container along with MongoDB as a bonus. There is a requirements.txt file you can use to install all the required Python Packages for this framework. Need to see how the framework works? See the unit tests and the sample Modules.

Let’s talk about Dynamic RESTful URLs. Most of the time, when working with Django, one ends up coding a bunch of urls in the urls.py file, one url spec for each endpoint, and the list of urls can become quite complex and unwieldy. What if there was a better way to handle this complexity? What if you could code a single URL spec for Django to address every conceivable RESTful url you wish to use? What if there were a way to configure this behavior using a config file? Some urls need 1 or 2 parameters, others require 3 or 4, while some require 5 or 6. What if you wanted to add another url spec that, for some reason, needed many url parameters, which was configurable? Does this sound too good to be true? Maybe so. Or perhaps there is some working code that can do this. The point is that now you can break free from coding individual urls for Django.

Ok. So dynamic urls for Django. Cool. How do you access all those url parameters at runtime? Have you ever heard about **kwargs? This allows you to ingest a Python dictionary into your function via kwargs (see the modules in the plugins directory for examples of how this works). By default, the first url parameter is accessed from kwargs as: “kwargs.get(‘param1’),” which says if the variable exists in the dictionary, give it to me or give me a default of None. What if you wanted to rename these parameters because you don’t like the defaults? See the file named “.env,” where this can be done. What if you tried to rename or remap the url parameters on the fly? The 1.0.0 release also supports this. Now you can remap url parameter names on the fly for each RESTful Call, and they all appear in your functions via **kwargs.

Ok. What if you wanted to use Query Parameters for your GET calls? This is supported, and they appear in the **kwargs. Nice, huh?

Which HTTP methods are supported? GET, PUT, POST, and DELETE.

Can I get a directory of my plugged-in modules? Yes, this is supported.

What about Module Aliasing? Yes, this is supported along with API versioning. Put your API versions into separate Python Modules and alias them as “v1”, “v2”, and “v3.” Now, you can publish your API Versions that look like API Versions without exposing the actual modules or module names.

What about exposing a single microservice function using more than one HTTP Method? This, too, is supported. You can specify the list of HTTP Methods as a Python list or a pipe-delimited list in a string or a single HTTP Method name. Again, see the example modules provided by the Release you want to use. The built-in directory function provides all these details as JSON so you can easily publish your endpoints.

Be sure to use unique function aliases; this, too, is supported, or bad things might happen.

Be sure to use unique module aliases, or bad things might happen.

Do I need to restart the server whenever I want to deploy a new module? Nope. Just drop the module into the plugin's directory and issue the directory URL to see the information on the newly plugged module. This is all dynamic.

What if you wanted to deploy your Java microservices using this framework? This, too, is supported. Code a command-line interface for your Java classes and use the appropriate Python code to issue each command line via separate Python functions. Your Java or node.js or Go or any other Language or technology you wish to use can be easily deployed without having to restart the RESTful Server.

What if you wanted to deploy your Rust code using this framework? Well, this, too, is supported. You can code Python extensions using Rust, call your Rust functions from your Rust Python extensions, and then deploy Python-based “.pyd” files from your Rust development environments. Slick, huh?

Stop coding Microservice RESTful Interfaces by hand and start doing this automatically using this framework. Automation frees us from the tediousness of ordinary everyday activities. This framework frees everyone from the most tedious part of the publishing function, as RESTful AJAX calls. Now, you can focus all your efforts on producing Python Modules with easy-to-understand function decorators to “expose” endpoints. Be sure to notice how to code “private” functions in your modules; bad things might happen if you try to “expose” a “private” function, but you can learn all about this by doing it.

Welcome to the 22nd Century.