Comments (7)
Selection of Cloud service provider
Not sure I understand your question. I think we have all the required layers. The rest are nice-to-have.
On AWS I know there are regular historical dumps of the Data. That could be useful in case the service goes down. We also don't need load balancers I think as the number of queries will always be quite small (I assume).
Another nice-to-have would be a monitoring tool :
- For the API; e.g to know which devices are queried the most or to detect a surge in requests.
- For the DB to have ready-made queries (using metabase for example although I don't know how easy It is to develop).
Aditionnaly, a throttling component could be useful to limit malicious attempts to overload the API.
Client-side API
I created the discussion #24
from pyro-api.
Shall we close it as the linked PR ha been merged? I agree the topic is not fully closed though as we don't have a proper service for now.
from pyro-api.
Hi @florianriche,
Thanks for mentioning this topic!
Selection of Cloud service provider
Three things to consider here: ease of usage, pricing, ethics.
AWS is quite easy to use, and I wouldn't have much issue going with that option but we have to discuss this more largely as this is a big decision (cf. cc).
Now whatever we choose, I believe it's best to make sure we separate the CSP interaction parts of the code from the rest (in case we intend to change the provider later).
Credential management
If you are referring to secrets & co, perhaps we should use an .env
file?
Client-side API
I suggest we move forward with a client-side python package, so that we can easily install it on multiple environments and it can plug in with other python modules.
cc @x0s @MateoLostanlen @2ndcouteau @blenzi @Akilditu @fe51 @jeanpasquier75
from pyro-api.
Selection of Cloud service provider
Now that I think of it, I wonder if it would be easier to convince public institutions to use our solutions if we rely on french providers (OVH, Scaleway...). That would be good PR- wise.
Agree for the independence regarding the rest of the code. In the implementation of the linked PR, I tried to abstract the Cloud serviceProvider.
Credential management
I was more talking about the way AWS handles credentials, there are several ways, it can be hardcoded in a config file somewhere on the hard drive, there can be public/private keys... but a simple .env file seems indeed the GOTO solution for a first step.
Client-side API
Shall we open a new Github repository to tackle that subject or just add some code to the CV repo?
from pyro-api.
Selection of Cloud service provider
I mentioned this, because we've just had very recently an opportunity with a CSP that is using servers to provide heating to offices. However we're still unsure about the timeline here. @florianriche in your opinion, on the short-term, what is our prime requirement in regards to CSP that are not filled currently? (DB persistency?)
Client-side API
Perhaps, let's first open an issue in this repo to draft a design doc / specs for it, to make sure we don't created extra repos that are not required.
from pyro-api.
Thanks for creating all the other issues!
Back to the main topic here, whatever the choice of CSP, we need to:
- add a key/path field to the media table that will locate the content file once uploaded (by default None = not uploaded)
- add a route for uploading that will be called by the client-side (registered device)
The second one depends on the CSP, but perhaps for now, we can make a "mock" upload and still design the key/path update?
from pyro-api.
Good thinking, I agree!
from pyro-api.
Related Issues (20)
- [docs] Add a tutorial/walkthrough to deploy everything on your own HOT 4
- Running the docker compose locally does not start the API correctly HOT 6
- [admin scope issue][media] HOT 1
- [Ongoing Alerts] Specify the limit size of the response in API documentation HOT 1
- Code quality checks failing for main branch HOT 1
- Creating a group with an existing name triggers an internal error
- No timeout in api client ?
- Allow to remove max request response size HOT 2
- [media] Media deletion crashes when no bucket key is set
- [installations] Internal error when specifying datetime in payload
- How webhooks work HOT 2
- Tests failing often due httpbin.org timeout HOT 1
- Clarify when (and how) users take events into account HOT 6
- Document the process to update the db diagram HOT 1
- Fetch routes do not limit number of items for non-admin users HOT 1
- Grouping alerts HOT 2
- Access api documentation HOT 1
- Add a proxy url for the s3 media fetch HOT 2
- Set proper Continuous Deployement HOT 1
- Clarifying data/state tables from event tables HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pyro-api.