> Probably I can still do these running a dev.silpa.org.in and
> silpa.org.in separately where development code can be tested on
> dev.silpa.org.in and I will not cause problems to production code!. Am > I missing any scenario which you are trying to solve?
yes, you are right but to understand what I'm thinking.. lets say, you have a module M which have two methods A, B
so, by definition there will be 2 different URI's to get result from these 2 methods.
these are '/api/:M/:A' and '/api/:M/:B'.
now, think on a case where you want production API to serve only for method A not for B.
So the 'Control Panel' will be a web App allowing production API service to give response only for method A not B.
and Admin will be controller for it.
now one way to list all methods is simply parsing files, and in Frontend of app you will see which methods are served by both API's. there you will be able to check/uncheck for each as I explained.
And then production API will serve according to allowed URI's by control panel.
I Hope, you are able to understand me :)
>
> I can simply comment out the module in configuration and our services
> are configured to reload the entire app on file touch and Wala it > works :). But probably a front end to config may be good idea!.
yeah!! the 'Admin Control Panel' app that I proposed was supposed to be a web application powered by Python-Flask itself.
In that admin can control API service just by using Web Interface of it and the app controls things on the backend, as you said commenting out the config.
In my view having a web-interface for it sounds obviously good then commenting out and adding again in files.
some basic routes/endpoints of app, for this case only (enable/disable a module), may be these :
'/enable/:ModuleName' [POST] => 'enables a particular module'
'disable/:ModuleName' [POST] => 'disables a particular module'
> Probably security thing is not the problem which we need to solve in > our framework isn't it?. there are tools like iptables or fail2ban > which can be enforced on misbehaving clients. Also we don't hold any > state and don't plan to do that in future also. Having no state our > application doesn't care who sends us requests then how do you plan to > solve this problem? (but I prefer external utilities to safe guard > from misbehaving clients).
I was thinking that having an authentication based API service can help to solve this, by rate-limiting or banning according to tokens provided to particular clients.
but as you said "Authentication will probably never be implemented in our case I guess."
then yes, using external libraries is also a solution.
on 'Status Board/Dashboard' Thing, I said that service will obviously run without having a status board but having it will help us as a community.
In my view it tends to attracts people about service and let you publicize that how popular/stable your service is.
yeah, it does not appears to solve a technical problem btw but it's an additional project. and I don't think there is any wrong in having it.
it will also be a web app, having graphical data statistics for -
- Status on API use (API use status in time spans) - Relative Distribution of modules in API use (which module is getting more requests) - API Response Time (mean api response time)
- API Service Uptime (relative time in which in was service operational)