I am currently creating a react native + expo application upon which essentially each page makes an API call, which is a lot of API calls. I have this app also connected to firebase for different information. The things is, each of these pages don't update more than once or twice a day for the most part, so I really don't want the End User to be calling the API that much either.
My question is, is there a way to write and host a script that will continuously run that knows to call this API once every hour (or so) and then rewrite to the firebase db from which I can then only need to pull from the database as compared to having each user individually making dozens of API calls.
Please let me know! I have spent days on google and am no closer than I was before. I'm also willing to change my set up from firebase if it is not possible to accomplish that way. Thanks!
You can use a Cloud Functions scheduled trigger to run code periodically that can make changes to your database.
Related
I am going to build application that shows real time data with React.
And I decided to use Pusher for real time data management.
I also trying to use open third party apis for getting data.
For example openweathermap for weather data.
My trouble is how can I know if the data from third party api is changed and let the Pusher know data is changed.
In one word, how can I make Pusher to connect third party apis?
Really want your help.
Thank you.
Maybe there is a system for it in Pusher but I don't know.
If it is possible for you, you can create a cron service that checks your 3rd API continually. But it has to be on a live service to run continually. If it detects any changes in the data, it can emit your client app by using Pusher, Socketio, etc.
Maybe the 3rd API provides this feature to you.
I added a WebSocket API through AWS API Gateway on my React app.
I originally added it to build a chat messaging section, however, I soon realized how useful it could be for other things in the app that might need real-time updates.
I had an idea, and that is to store the socket in a React context so it's accessible from all the components of the app and that should work fine, without re-establishing a connection every time a component mounts.
Now, the question is, is there a better way to do what I'm trying to do? Hence, create a socket connection that I can then take advantage of for multiple functions? Say for instance, "is online" status.
The alternative is to create yet another socket API but is that really necessary?
Keep in mind I'm using a serverless framework (API) with lambda functions on AWS.
This is going to depend on the applications planned scale, keeping in mind that as the app usage grows you may want to refine the endpoint architecture and code.
Remember that an auth endpoint/api for example may only need to be accessed a few times over a chat interaction endpoint/api. For scalability (and cost per endpoint call too) id be looking at keeping them separate.
I'm sending data from my backend every 10 seconds and I wanted to display that data in reactjs. I've searched on the net to use socket.io to display real-time data. Is there a better way to use it?
If you're dead set on updating your data every 10 seconds, it would make more sense to make a request from the client to the server, as HTTP requests can only be opened from client to server. By using HTTP requests, you won't need to use socket.io, but socket.io is an easy alternative if you need much faster requests.
Depending on how you are generating the data being sent from your backend, specifically if you are using a database, there is most likely a way to subscribe to changes in the database. This would actually update the data in realtime, without a 10 second delay.
If you want a more detailed answer, you'll have to provide more detail regarding your question: what data are you sending? where is it coming from or how are you generating it?
I'm working on an autodialer feature, in which an agent will get a call when I trigger the button from the frontend (using react js language), and then automatically all the leads in the agent assigned portal will get back-to-back calls from agent number. However, because this process is automatic, the agent won't know who the agent has called, so I want to establish a real-time connection so that I can show a popup on the frontend that contains information about the lead who was called.
Is it sensible to use the stop() method to issue a rest api call, and send data up to the cloud (which may take 0.1s-5s based on connectivity)?
requestBuilder.acceptJson().body(jsonDataBody).getAsJsonMap()
I ask, as i can consistently reproduce an issue on the simulator where no data is being sent when i close the app, but it goes if i call the same process via a button. On real devices it seems to work fine, but i am getting occasional customer feedback that it isn't always working, ie. data isn't being sent to the cloud (tho no errors). I cannot reproduce it using my own real devices.
I'm having to code blind and just force it by putting in a new async rest call when i do screen navigation, which does the same as stop() except uses this method
requestBuilder.acceptJson().body(jsonDataBody).fetchAsJsonMap()
Background:
I have my data in a cloud database, fronted by Rest APi's. My app uses storage to store the datetime of when the last upload and download of data was. When i open my app, via start(), it issues a rest call and gets all data, with a datetime stamp > last download datetime. when i close my app i issue another call, via stop(), to send all data locally changed since the last upload datetime, to the cloud. Each record has a lastUpdateDatetime entity property.
Thanks
That's problematic due to two reasons. First the simpler case:
OS's can invoke stop()/start() quickly so you're app will stop and start almost immediately and this might trigger data corruption if you don't guard against it
The worse problem is that if an operation takes a bit longer some OS's might kill it. You can use background fetch to perform downloads/uploads while your app isn't running and that would solve the technical problem here
Personally, I would just send data on change. If change it too rapid I'd add a time threshold for sending but send during the app running and not on stop(). Notice that on the device the situation is far more complex as it can suddenly decide to kill the app to make room for the phone app or another critical app. You need to program defensively and try to avoid assumptions where possible.
Hey guys kind of a n00b in App engine and I have been strugling with this is there a way that I can add/bulk default data to Data Store.
I would like to create catalogs or example data, as well user or permission. I am not using the default App engine user instead I am using webapp2 User auth session base model.
Thanks
You can use the bulkloader: https://developers.google.com/appengine/docs/python/tools/uploadingdata
Or upload data to the blobstore and move it to the datastore.
This is a large topic but, I am using Java code running in task queues to do this.
Much easier to create random test and demo data through code.
Much more friendly to unit testing.
This requires no dependencies. It is just code running and accessing the datastore.
Sometimes easier to manipulate the datastore through code instead of scripts when logic is involved in the changes.
Allows us to upload new task definitions (a Java classes) embedded in a new app version. Then, we trigger the tasks executions by calling a servlet URL. These task classes are then removed from the next app version.
And using tasks, you get around the request execution timeout. If a task is long running, we split it as sequential tasks. When a task completes, it queues the next one automatically.
Of course, this requires a fair amount of coding but is really simple and flexible at the same time.