In particular, can multiple threads use the same GMail service instance?
Nope. Gmail implementation is not thread-safe.
Therefore, if you are running as a multi-threaded application, each
thread that you are making requests from must have its own instance of
httplib2.Http().
Resource Link: gmail api service
Related
I currently have a mobile application talks to a GraphQL API service which terminates SSL and then proxies requests to gRPC services. The gRPC services only talk to each other via gRPC.
This system works okay but writing all of the boilerplate to plumb the gRPC APIs through the GraphQL layer to the client is tedious and can be error prone.
I’ve started exploring the idea of talking directly to the backend via gRPC as the tooling has improved substantially over the last few years.
One issue I’m still wondering about, though, is the best way to disambiguate APIs only meant to be called internally by other services from those callable publicly by the native client.
There is also a third category, “hybrid” APIs where it can be called either internally or externally.
Examples —-
Internal: Sending an SMS via Twilio
Public: Log in to account
Hybrid: Update whether an inbox item is read (both from the app when opening a conversation and on the backend when a message is sent)
One option I thought of was an interceptor that passes along a context to indicate if the request is internal or public and use this in the code to return an error or perform additional validation on public requests.
Another option is creating an API service which is still gRPC but fulfills the same purpose as the GraphQL API service.
A third option is disambiguating public and internal services at an organizational level which might require duplicating some APIs that exist for both.
Are there other options I’m unaware of? How have you tackled this issue?
I got this error when I'm using streaming subscription with impersonation.
After the connection opened and receive notification successfully for minutes, it just pops up a bunch of this for almost all subscriptions.
How can I avoid this error?
One or more subscriptions in the request reside on another Client Access server. GetStreamingEvents won't proxy in the event of a batch request., The Availability Web Service instance doesn't have sufficient permissions to perform the request
I need to keep the connection stable and avoid this error.
Sounds like you haven't use affinity https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-maintain-affinity-between-group-of-subscriptions-and-mailbox-server
Also if its a multi threaded application ExchangeService isn't thread safe and shouldn't be used across multiple threads.
I am fetching Gmail inbox to the web application by using Gmail API. I am using RestAPI to connect with the web application. Everything is working and ready to go live. But the app is rejected by Google and asks for a Security assessment which has around $75K expenses.
As we are only reading messages through API and users are also already permitted to perform the same activity.
My question is, How to avoid Security assessment as we are using restricted and sensitive scope like GMAIL API & PubSub. But without these scopes, we can't fetch the messages.
How to avoid Security assessment? Is there any other way to achieve this requirement?
Looking forward to the community help. It's a major blocker for us to go live.
Thanks in advance.
If you need to use a sensitive or restricted scope, and you are not exempt from verification.
There is no work around to the security assessment.
info from docs.
sensitive-scopes
Apps that request sensitive scopes must verify that they follow Google’s API Services User Data Policy and will not have to undergo an independent, third-party security assessment. This sensitive scopes verification process typically takes 3-5 business days to complete.
Option: don't request a sensitive scope.
https://mail.google.com/ (includes any usage of IMAP, SMTP, and POP3 protocols)
https://www.googleapis.com/auth/gmail.readonly
https://www.googleapis.com/auth/gmail.metadata
https://www.googleapis.com/auth/gmail.modify
https://www.googleapis.com/auth/gmail.insert
https://www.googleapis.com/auth/gmail.compose
https://www.googleapis.com/auth/gmail.settings.basic
https://www.googleapis.com/auth/gmail.settings.sharing
restricted-scopes
Apps that request restricted scopes must also verify that they follow Google’s API Services User Data Policy, but they must also meet the Additional Requirements for Specific Scopes. One of these additional requirements is an independent, third-party security assessment. For this reason, this restricted scopes verification process can potentially take several weeks to complete.
Option: Dont request a restricted scope.
https://mail.google.com/ (includes any usage of IMAP, SMTP, and POP3 protocols)
https://www.googleapis.com/auth/gmail.readonly
https://www.googleapis.com/auth/gmail.metadata
https://www.googleapis.com/auth/gmail.modify
https://www.googleapis.com/auth/gmail.insert
https://www.googleapis.com/auth/gmail.compose
https://www.googleapis.com/auth/gmail.settings.basic
https://www.googleapis.com/auth/gmail.settings.sharing
Exceptions to verification requirements
Could your app be exempt from the verification requirements.
Currently I'm building an application in a micro service architecture.
The first application is an API that does the user authentication, receive requests to initiate/keep a realtime connection with the user (via Socket.io or SockJS) and the system store the socket id into the User object.
The second application is a WORKER doing some stuff and sometime he has to send realtime data to the user.
The question is: How should the second application (the WORKER) send realtime data to the user?
Should the WORKER send a message to the API then the API forward this message to the user?
Or the WORKER can directly send the message to the user?
Thank you
In a perfect world example, the service that are responsible to send "publish" a real time push notifications should be separated from other services. Since the micro service is a set of narrowly related methods, and there is no relation between the authentication "user" service, and the realtime push notification service. And to a deep break down, the authentication actually is a separate service, this only FYI, There might be a reason you did this way.
How the service would communicate? There is actually many ways how to implement the internal communication between the services, MQ solution, which could add more technology to your stack, like Rabbit MQ, Beanstalk, Gearman, etc...
And also you can do the communication on top of HTTP protocal, but you need to consider that the HTTP call will add more cost.
The perfect solution is that each service will have to interfaces to execute on their behalf, HTTP interface and an MQ interface (console)
I have been reading articles about asynchronous messaging between clients using MVC3 and the SignalR library (http://sergiotapia.com/2011/09/signalr-with-mvc3-chat-app-build-asynchronous-real-time-persistant-connection-websites/)
We currently use activemq for some of our fat client apps and use topics to broadcast data to everyone. Does anyone know if this sort of thing could be used in MVC3 as well?
I'd like to create an application that doesn't require a user to install anything (and could even be used on a phone), but it would be monitoring continuously-changing data. We're talking refreshing data every 2-3 seconds.
If you want to have asynchronous messaging with client (browser) use SignalR. ActiveMQ and MSMQ are technologies for thick clients and server-to-server communication. They require installation (MSMQ requires windows installation) and they are not accessible from browser (well I can imagine accessing MSMQ through ActiveX or ActiveMQ from Java applet but that is not what you are looking for).
One of the possible ways to go is to build a web service which will implement communication with AMQ/MSMQ via their APIs and do poll this web service from your webpage (via ajax call for example) to refresh the data as it's needed.