I want to create some model services that do not access the database and just do some business logic. I would like to have these services be sharable such that they might be called as a composite service to call multple model services in sequence.
What is your background so far with Django? How much have you used Django?
Just getting started with Django but LOTs of experience with other MVC Frameworks and Microservices. I have also downloaded and installed Django REST Framework. Basically just doing research on what is possible, knowing full well that there are more than a few ways to skin a cat
Ok.
What you’re going to find is that the terminology used by Django is frequently different than what you’re used to using with different frameworks.
One perspective of Django is that it’s built around the idea of writing “views”, which are not the “View” of the MVC architecture.
A Django view is a Python function that receives a Request and returns a Response.
What that view does between those two is entirely up to you.
Also, a Django Model is a reference to a table in a database. In Django terms, it makes no sense to try to refer to a “model service” that doesn’t access the database. If the operations you’re proposing don’t involve the database, you’ll want to find a different way to describe them.
(You’ll confuse yourself and others trying to interpret the Django docs or ask questions if you don’t adopt the Django lexicon.)
To follow up on this from your other question, I’m going to re-emphasize one line above:
You can take this quite literally. Django applies no restrictions, constraints, or conditions on what code you execute within a view. Your only limitations are those imposed by the system on which you’re running.
Ok I can live with that, thanks. I was looking at the Django REST Framework and looking at the extensive router functions.
I am looking for a Microservices approach where I can have shared services that I can call in a sequence to apply business logic. If the Django Models are just for Data Access, that’s fine.
Let’s say I want my shareable services to be “Atomic Services” and to route a request from a View through one or more Atomic Services on its way to the Model for accessing the database table. Where would I put my Atomic Services to be compliant with the Django architecture and would I use the REST Framework to implement the routing?
Unfortunately, “routing” is one of those terms that can mean different things to different people at different times.
I’m going to need to ask you to be a bit more precise as to exactly what you want to see happen - and addressing this in terms of HTTP requests and responses.
If you’re talking about “routing” in terms of what code gets executed when a URL is requested, that’s a basic Django function. A URL pattern is assigned to a view. That view is given the HttpRequest object. The view needs to return a Response.
What that view does between the time it receives that request and returns a response is entirely up to you. If you want that view to run a Python script, fine. If you want that view to call other views, fine. If you want that view to invoke other URLs, fine. You do whatever you want.
What DRF does in this mix is remove a lot of the boilerplate code when you want a consistent set of “Http service-style” operations to be performed across a variety of URLs.
Thanks, a CustomMiddleware will achieve what I want but having trouble getting that to work.