Dynamic Pluggable Microservice Framework
Tags: Python, Functional Programming, Dynamic Programming, Rest Api, Microservices

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 and then drop your microservice module into a directory and then simply 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 kind of a RESTful Interface, yes? So now you code your exposable functions that call your real functions from your real Packages and drop your exposed modules into a directory and now all those microservice functions are exposed as RESTful endpoints without having to restart the server.

Sounds too good to be true? Check it our 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. Requires Python 3.8.x and PIP and virtualenv all of which have been installed in the Docker Container along with MongoDB as a bonus. There is, of course, 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 end-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 that could handle every conceivable RESTful url you might wish to use? What if there were a way to configure this behavior using a config file? Some urls need 1 or 2 parameters and others require 3 or 4 parameters while some require 5 or 6 parameters. What if you wanted to add another url spec that for some reason required 10’s or 100’s of url parameters and this too was configurable. Does this sound too good to be true? Maybe so. Or maybe there’s working code that can do this. Point being now you can break free of having to code individual urls for Django.

Ok. So dynamic urls for Django. Cool. So how do you access all those url parameters at runtime? Ever hear about **kwargs? Yup, this allows you to ingest a Python dictionary into your function via kwargs (see the modules in the plugins directory for some 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 then 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 wanted to rename or remap the url parameters on the fly? This too is supported by the 1.0.0 Release. Now you can remap url parameter names on the fly for each RESTful Call and they all appear in your functions via **kwargs.

Ok. So 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 too is supported along with API Versioning. Put your API versions into separate Python Modules and alias them as “v1”, “v2” and “v3” and now you can publish your API Versions that look like API Versions without having to expose the name of 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 every time I want to deploy a new module? Nope. Just drop the module into the plugins directory and issue the directory URL to see the newly plugged module’s information. 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 and your Java or node.js or Go or whatever other Language or technology you may wish to use can be easily deployed all 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 and then 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 common every day activities. This framework frees everyone from the most tedious part of 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 tried to “expose” a “private” function but you can learn all about this by doing it.

Welcome to the 21st Century.