I have a need to build a microservice. This will be very interesting and neat. What I will like to achieve is very simple. I am not very certain how the architecture will work. Here it is in django framework:
*We have users on smartphones and PCs.
***Initial onboarding will happen and all will be authenticated for licensing purposes.
This information is carried on to the data base and will be used for matching the devices and/or PCs on the microservice as a part of the mechanism for licensing.
*They will keep certain unique information on their devices or PCs.
***With an API any authenticated server can request to offload their collection collated for this specific purpose at certain time o the day or night.
***Through an API the information from the devices will move straight to the server that called it and it continues to the chosen DB.
The bottom is this:
We will design so that a pull request from the web server (affiliates servers) can do this and cause the device to push what they have already collected.
Let me know what you guys think. I know that a strong connection to the internet will be required for this to happen as planned.
I can’t speak for the business side of things, although it does seem strange to me in regards to who is paying for which service in this scenario. It sounds like the users are paying to store “unique information”? Or are they being paid to hold (and gather/compute?) this information? Anyway, none of my business.
On the technical side there are some more things I find strange. But before that, what does this even have to do with Django specifically? Yes, Django can probably help with constructing systems that have an API and handle requests, but this seems like buying the cart before you know whether you should buy a horse or a donkey. Design the architecture first, then decide which technology to use.
Some technical/architectural things:
- Somewhere along the line you are trusting the client. This is considered a Really Bad Idea.
- Devices can be offline for any number of reasons. Is that a problem? If so, this is a fundamental design flaw. If it’s not a problem, why even have the server initiate the connection?
- The client/device will need to constantly listen to requests. This requires either a light-weight server on the device or a fancy message protocol that can handle sporadic connections and is secure enough for this purpose. Again the question why you even need the server to initiate the connection.
- I don’t know if this will be “interesting and neat”, but I can assure you it will not be “very simple”.
- It sounds to me the code running on the device is an app that Does Some Stuff, then periodically sends stuff to a server, who will handle it further. For licencing, money-making and numerous technical reasons the standard architecture is to have servers that clients send requests to and the server, upon handling the request, will decide if the user is credited for whatever they send. If the client never sends stuff… too bad, for the user.
- No really, why have the server initiate the connection? I don’t see any benefit over the client deciding when to send stuff. If it needs to be configurable by a central authority, have a seperate endpoint where the client can ask when Sending Some Stuff is scheduled and have the other endpoint ignore any requests outside this schedule.