I was excited to see that the Google Realtime API has offline / in-memory support now, but I'm wondering how to load the script. Is there anything like an npm module for it, or do I have to fetch it with gapi every time I want to use it?
It is not available as a standalone module. You have to fetch it as some point, although you could cache it locally for some time. Just be sure not to let it get too far out of date, so it doesn't get out of sync with the server.
For example, you are expecting to be offline at some point, you could maintain a cache of it, and update it every time you come online.
Related
I just released my react app in a production environment in Cloud Foundry, but the only problem is that if I make changes to the app, and reupload the app, my users don't see the changes unless they clear their browser data, what can I do?
Reason for this issue: Browser is using its cache not your build to serve the client
Remedy to outcome: Inform the changes in metadata.json
metadata.json is a file that swings between request and browser checks for any mismatch with it's cache. if no then cache is served to client.
There are more then one way, thus am not telling direct solution, instead gothrough the below link will take to through various steps to follow
flexdinesh blog from dev.to
I have been using GAE and Endpoints for a couple weeks now. I see when I make changes to my code, the devserver will automatically pick up the changes and I am able to sometimes run tests against my updated API in the local API browser. However, I have also noticed some instances where it appears the changes were not picked up automatically and my API browser was hitting old code.
What is the proper process for updating my application to test locally? Do I have to restart my devserver? Do I need to refresh my browser and build new request objects? Can I simply execute a previous request again? (from experience, the last question appears to be no).
Thanks.
While working with the Development Server, I have found that it is best to :
Restart the Server &
Refresh the browser to ensure that any updated services definition is picked up by the API Explorer.
I have created a small project in Google apengine and like it apart from one thing: It seems virtually impossible to delete or change an endpoint, once it has been made. The API often stays the same, regardless of code changes in the java endpoint classes. I tried to delete the complete API, but that is not possible either. Is there any way to do this?
RE: Deletion
it's not currently supported, but we're working on it.
RE: API Changes
The Google APIs Explorer web app aggressively caches, so you'll need to clear your cache or force a refresh when you update your API server side to see the changes in the client.
I and my friend are working on a GWT-Google App Engine project, using Tortoise SVN and Google Code to synchronize the code.
We also synchronize the local_db.bin file in appengine-generated folder. But we cant get it work. After synchronize the db file, our local datastore is not updated as we expected.
That is a pain. Im worrying about our future, when our database get bigger and more complicated #A#.
Anyone please give me an advice. What should i do to synchronize our local datastore?
I have to suggestions:
1) Use remote api : https://developers.google.com/appengine/articles/remote_api to share a GAE hosted db locally.
2) Maybe you can use Gdrive to sync folders.
This is a really bad idea. Even if you weren't having trouble making both ends read from the same datastore file, the local datastore is in a binary format, and thus you won't both be able to work on the app at the same time, or you'll get merge conflicts you will be unable to resolve.
Instead, both for collaboration purposes and for testing and deployment, you should provide a set of test data you can easily load into the datastore. Store the test data in version control, and load it in using bulkloader or your own code.
I am a beginner in GAE and still evaluating if I should use this for my school project. I need to show that how an application can be scalable, the definition I wanna use here is whether it can serve 1000s of users concurrently.
Now load testing is one way of doing it. But load is futile when Google will scale out the application to a number of different instances depending on the load.
So hence, I am thinking of simulating data store read/writes access memcache etc to show the scalability prospects of the application.
Now, using JUnit Test is a good way to do this. But they can only be run locally. Is there a way to run them on the server, the actual production environment? If that can be done, then I can just write these tests and execute them via eclipse and I should be done!
The other way is to use functional testing with selenium to simulate the load and actual user conditions but this would most probably crash my computer and also not be concurrent.
The other option is to use a python load testing script and use sample json data to throw requests at the server urls. This however I tried but I cant test the options where genuine user interaction is needed since the live site requires a google sign in.
Any ideas where do I proceed to?
Look at either Siege (http://www.joedog.org/siege-home/) or JMeter (http://jmeter.apache.org/) for doing remote testing of your apps. The problem is though that you will hit the limit of your actual testing machine before you hit the limit of what you're trying to test so a lot of people spin up a few EC2 instances and run the load tests from there. Seige is very simple, it just reads a list of urls from a text file and clobbers the server as hard as you tell it to. JMeter lets you create more robust tests that can do things like log into a server and log more fine grained details about how your app behaves.
Those are the two best free and easy to use tools out there (IMHO).
It sounds like you really want to simulate datastore operations.
You can write a HTTP request handler that loads your junit tests and calls them, then either dump the results to log or as the HTTP result.
If they take a long time to run, you can run them on a backend instance.
Along the lines of Rick's suggestion, you can also probably run a test on a backend instance that makes HTTP requests to your frontend instances using the async HTTP API, and cause your front end instances to do a lot of work, if that's what you need to simulate.