|
| From: | pravendra rathore |
| Subject: | Re: [silpa-discuss] Continue Working on Proposal |
| Date: | Tue, 22 Apr 2014 22:07:33 -0700 |
On Tue, Apr 22, 2014 at 5:42 PM, pravendra rathore <address@hidden> wrote:That is some use case I think we don't have! But I'm curious to have
> Hi,
>
>>
>> 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.
some real world example here, may be we might have something in future
which we want to test ourself before making public. Also note that we
already have a JSONRPC api, and I would also like to know how do you
configure it there.
I don't want implementation detail but explanation on how you plan to
implement it.
Check uncheck part is still unclear to me, do you have some PoC code
> 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 :)
which we can explore? If not do write one, check development branch on
our repository and use it as base.
We don't want multiple Flask applications, or 2 separate code base,
>
>
>>
>> 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.
obviously its possible to create your application in our existing code
base check how I've done it for api and frontend and come up with your
idea there to implement this.
Yes right, Its good to provide some gui to allow editing the conf
> 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'
> '/logout', '/login' [GET/POST] => 'admin login thing'
files, and I'm all for implementing things as API and then consuming
it in UI, we already do it with other front end which consumes JSONRPC
api.
I'm okay with this part please go ahead and write a POC code for this,
base it on development branch.
@Santhosh @jishnu are you okay with this?
I'm not sure but idea seems good, how do you plan to implement this?
>
>>
>> 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)
>
> as many tech services uses a status board like
> https://dev.twitter.com/status , https://status.github.com
It looks more like separate service than part of our existing
framework isn't it? Can you explain more or give some Poc?
| [Prev in Thread] | Current Thread | [Next in Thread] |