On page https://firebase.google.com/docs/firestore/best-practices, I saw this sentence:
Keep the number of snapshot listeners per client under 100.
I read the page on 2021/02/18, and I haven't found the clear meaning of client on that page.
What does client mean? Is it a (service) account? or is it a firestore.Client object? If it is a firestore.Client object, can I use multiple firestore.Client objects as a workaround to 100 snapshot listeners per client limit?
Per the oficial documentation, it refers to the firestore.Client object,
FirestoreClient provides access to Google Cloud Firestore. Use the
API to obtain a Firestore instance, which provides methods for
updating and querying data in Firestore
Here is a question similar to yours that can enlighten you even more about the difference between Listeners and Clients and how a Client can have multiple listeners.
Related
I have my public API running on AWS API Gateway, and now I want to add API keys to it, basically to see "who is using which endpoint and how many time per month/week/whatever". My API already has user management logic, with its own users db table.
The part I need help with is the analytics part - say I have this up and running, I need to be able to extract some sort of report saying, for each user (by name), how many calls were made to each endpoint. So far, the closest I've gotten was https://stackoverflow.com/a/52361117/1514576 which gets me the info I need by API key. The part that I'm missing is how I could potentially cross-reference this data with my "users" database table.
I was hoping one of you had faced a similar problem and could share how you handled it.
I have a Flutter app which holds a username and a token to communicate with a web service.
How can I manage the username and token efficiently using best practices? Currently I am writing them into a DB and select them each time I want to do a request.
I tried to use bloc provider flutter bloc with a BlocProvider. I have the states LoggedIn and LoggedOut and the events Login and Logout.
Furthermore, I had a look at
secure storage, but I can't get the data available throughout all pages.
Also, I am not using the firebase API.
Let me know if I should provide some code snippets.
I use SharedPreferences now. The API is very simple and I wrote a wrapper to get rid of the (Strings) keys. Furthermore, the wrapper holds the values for the current session. The advantage of that is, that I can address the values directly instead of needing to read them asynchronously.
With Microsoft Graph, I can set a subscription on a resource. In my case an event. I am going to be using an admin authenticated account to access multiple calendars.
Is there a way to set a subscription to get notifications on all the calendars the admin can see?
If not, is there a way to send in a block of subscriptions with a single request? Because we are limited to how many requests we can specify in a specific timeframe. (I'm not sure what the limit is) but if I have 500 calendars I need to set subscriptions on so I get notifications of changes, how are you supposed to do this and not get hit by the request per timeframe limit?
Currently, there isn't a way to send multiple subscription creation requests in the same HTTP REST call. Every different resource for which a subscription is being created would have its own HTTP call into the Graph REST API.
You can recommend a "batching" feature (so multiple REST requests can be processed in the same HTTP call to the Graph API) on UserVoice: https://officespdev.uservoice.com/
There is also a consideration that, in my experience, the number of simultaneous subscriptions allowed is around 20, so 500 subscriptions might be out of the question. The best advice I've been given on the subject is to loop through all the objects one at a time to refresh them in sequence. The throttling that follows is a different issue altogether.
When a 429/"Unknown Error" comes back (ie throttling), it comes with a retry-after header which should be observed. I might point out that throttling, for me, is still a huge issue.
I'm just getting started with the DocuSign REST API (creating a proof-of-concept integration with my company's product) and am trying to wrap my head around everything. There are a couple things I can't find much info on:
When creating an Envelope, does the documentId matter? I assume if there are multiple documents the documentId for each would need to be different. Is it used anywhere else?
Periodically, I'd like to check the Audit Events for an Envelope. It would be much easier if I could look up the Envelope (or go straight to the Audit Events without looking up the Envelope) with a documentId instead. Is this possible?
Our product already stores documents, and therefore has a documentId - so that is the ID I am using when creating Envelopes. What I'd like to do is, with whatever document I am viewing in our product is check to see if there are any non-completed Envelopes pending. Then I wouldn't need to store any DocuSign related data in our system (i.e. envelopeId).
Can I look up an Envelope by the documentId used to create it?
The documentId is a client defined property and is simply there to help you tag the documents that were used for given envelopes. If you want to track the documents that you're supplying in your envelopes (which it sounds like you are) then you can use it to uniquely identify the underlying docs and if you already have a system that has generated the documentIds then that should make things easier.
No there is not a way to retrieve envelope information through documentId. The best solution is most likely to store a simple table on your side that links documentIds to envelopeIds, then given the documentId you want to search for use the linked envelopeId to retrieve its status.
You should note, though, that there are certain API call limits in place for some API calls and requesting envelope status is one of them. You are not allowed to request status on a given envelope more than 1 once every 15 mins. Instead, the DocuSign Connect module is recommended if you want to track real-time status (DocuSign Connect pushes status out to you as soon as it happens instead of you polling for status every so often).
For more info on API call limits check out the API Best Practices doc in the DocuSign Developer Center under the Go Live section:
https://www.docusign.com/developer-center/go-live/certification
I am interested in accessing the list of active subscriptions, but after reading all the wiki about APIs (https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_User_and_Programmers_Guide#Context_subscriptions) i haven't find any operation that allows to get the list of them.
Is there any operation to do that? Anyone can give me details about it?
The NGSI API that Orion implements doesn't include any operation to get the list of existing subscription. It is assumed that each client knows the subscription it has created and manages it, no "administrative action" to get them all has been defined by NGSI.
The only posibility with the current Orion version is to query directly the database to get that information (e.g. in a side REST server running along the Orion context broker process). Considering the data model described in the Orion documentation, it is a matter of queriying on the csubs collection.
EDIT: Orion 0.25.0 includes an operation to get a list of subscriptions in the NGISv2 API: GET /v2/subscriptions. See this document for details.