I have several instances of an angular app that are hosted on the same server (with different base-hrefs like https://my.server/app0, https://my.server/app1, ...).
I tried to persist my ngxs state using the #ngxs/storage-plugin, but i cannot find an option to define a prefix or namespace for my data to prevent the different app-instances to interfere with each other.
Does anybody have an idea how to do this properly?
Thanks!
I think you can achieve that using the Custom Storage Engine of #ngxs/storage-plugin, by implementing your own storage engine and adding a prefix (that refers to your app instance) to the stored key.
Related
I am trying to implement two different QuarkusTestResourceLifecycleManager for my testing. Problem is I need data from one of them in order to start the other one. For example, a resource that needs a Database server (hence it needs its recently created IP etc).
How this can be achieved? I've seen there is already a QuarkusTestResourceLifecycleManager.setContext method but this object just has the test profile, not the config Map.
Thanks!
My app use a Google cloud Firestore instance. Among the data my App manages there some classical data (string, number, ...): No problem with that / Firestore handle these use case easily.
But my app also need to consume images that are linked to the other data.
So I'm looking for the right solution to manage images.: I try to use the "reference" type Field from my Firestore instance but I'm not sure that the right way...
Is there another solution outside Firestore?
What about Google cloud Filestore?: It seems available only from an app engine or a VM...
I try to use the "reference" type Field from my Firestore instance but I'm not sure that the right way...
Is there another solution outside Firestore?
What about Google cloud Filestore?: It seems available only from an app engine or a VM...
Disclosure: I work on the Firebase team at Google.
When I want to use both structured and unstructured data in my application, I use Cloud Firestore for the structured data, and Cloud Storage for the unstructured data. I use both of these through their Firebase SDKs, so that I can access the data and files directly from within my application code, or from server-side code (typically running in Cloud Functions).
There is no built-in reference type between Firestore and Storage, so you'll need to manage that yourself. I usually store either the path to the image in Firestore, or the download URL of the image. The choice between these two mostly depends on whether I want the file to be publicly accessible, or whether access needs to be controlled more tightly.
Since there is no managed relationship between Firestore and Storage (or any other Firebase/Google Cloud Platform services), you'll need to manage this yourself. This means that you'll need to write the related data (like the path above), check for its integrity when reading it (and handle corrupt data gracefully), and consider periodically running a script that removes/fixes up corrupt data.
I have this use case, where I have created server side views on sync gateway based on a rolling time window of 10 days. Is there a way to directly pull those on my device side?
When I look at the documentation, I see that there's no way these can be replicated directly and one needs to make REST calls:
http://developer.couchbase.com/documentation/mobile/1.2/develop/guides/sync-gateway/accessing-cb-views/index.html
Is that assumption correct?
The other approach I saw was that let all the data be replicated on the client side and then write Couchbase lite views on the client side using Map reduce functions. Which one's the correct approach out of the 2?
Yes I believe that your assumption is correct - views have to be queried directly via the public REST API. I also believe that your solution for syncing data and then querying it on the client side will also work.
In order to find the "correct approach" I would consider your app needs and deployment workflow:
Using view on the server will require:
Managing (CRUD) of the views in SG - similar to managing functions in a database. These would ideally be managed by some deployment / management code.
Clients need to be able to make the API call to the public interface to access view info. This then requires a cache to work offline.
Slicing data locally means that sync will bring down all data and the device will have to perform the search / slice / aggregation previously carried out by the server. This will:
Work offline.
Put a potential extra strain on the app device.
I don't think that there are any easy answers here - ideally views would be synced to the device, but I don't know if that's even possible with the current SG implementation.
(Note 1: that the views must be created in Sync Gateway via the admin REST interface and not through the Couchbase web interface.).
(Note 2: I'm a server-side programmer, so this view is tainted.)
What I ended up doing was writing webhooks, which basically let me have the same docs replicated onto a Couchbase server. Then I did all needed aggregations and pushed those to syn gatewy(which got replicated to the app).
May or mayn't be right but works for my case....
Say I have some objects that need to be created only once in the application yet accessed from within multiple requests. The objects are immutable. What is the best way to do this?
Store them in the session.
If you don't want to lose them after a server's restart, then use a database (SQLite, which is a single file, for example).
You want to persist your objects. Normally you'd do it with some ORM like Active Record or Datamapper. Depending on what is available to you. If you want something dead simple without migrations and you have access to a MongoDB use mongomapper.
If that object is used only for some time, then it is discarded (and if needed again, then recreated), use some caching mechanism, like memcached or redis.
If setting up such services is heavy and you want to avoid it, and - say - you are using Debian/Ubuntu then save your objects into files (with Marshal-ing) in the /shm device which is practically memory.
If the structure of the data is complex, then go with SQLite as suggested above.
I am developing a web service that will be invoked (using JSON) from client side each time the selection of a drop down changes.
The goal is to register each "intermediate" change (on client side) using the "OnSelectedIndexChanged" event and before submitting the form to the Server.
Each new selected value will be written to a shared txt file calling a relative web method via Ajax/JSON.
Would it be better to write these changes to a txt file (having to implement a lock/unlock policy to assure exclusive access) or rather define a DB table and save the changes there?
Everyday the web app will have around 10 to 20 active users that might potentially changes the DropDownLists and usually the right value will be selected at first, hence generally no more than one "intermediate" entry would be registered.
Thanks.
Don't use the filesystem. It's slow. Use mongodb via a node.js webserver.
http://howtonode.org/express-mongodb
Good Luck!
This sounds exactly like what you would want to use a database for, since ACID is already implemented there.
If you want a real headache (and a programming challenge!) trying to debug overlapping writes, resource starvation and deadlocks, by all means, go with a shared text file!