I know that Azure Function Apps supports using the SendGrid binding out of the box to send emails using SendGrid. But what I can't seem to find is any information on the architecture/advantages/purposes of this as opposed to just calling the SendGrid API directly.
So at the moment I have a python function app and a function for an HTTP request/response (i.e. 2 output bindings, the HTTP Response and the SendGrid output binding). Is there any disadvantage if instead I'd rather just call the SendGrid API directly through python HTTP requests and not by setting the output binding?
I cannot figure out what is happening under the hood - does Azure wait to make the Sendgrid request (from the output binding) before making the HTTP response? That doesn't seem to be the case, as the HTTP request errors if something goes wrong on the sendgrid part. So is there any time/network advantage to using the output binding?
Or is it that the output binding exists simply to provide a language-independent "client" (JSON-string) to sendgrid emails and the main client to sendgrid can be maintained in a C# extension?
I almost feel like it is advantageous to make the calls directly to Sendgrid. If I am attempting to send an email earlier on in my function, and that function is written as async, then it could return as soon as the rest of it is done (if sendgrid has already returned). I just want to make sure I am not missing something and not taking advantage of something the output binding offers.
Output bindings of any sort are just for convenience mostly as they will handle the clients and connections established without you having to set up code yourself for this. They are optimized too, with the backend architecture in mind to ensure connections are re-used and handled properly so you may not reach any issues with SNAT port exhaustion or Connection limits on the machine itself. They are mostly a convenience, but they are all open source as well on github. You can take the time to look through them if you like if you want a better understanding of how they work:
-https://github.com/Azure/azure-webjobs-sdk-extensions/blob/dev/src/WebJobs.Extensions.SendGrid/SendGridAttribute.cs
If you need any special considerations or configurations that the binding doesn't have, then I would say go ahead and use your code. Just remember to take connection handling for functions into consideration such as re-using connections and establishing a singleton or static global variable for your http client.
Related
I need to interface a secure system that is situated in a protected LAN environment that absolutely must not expose any inbound tcp connections. Thus serving up an http server to provide a means to a webhook service to call as its callback is not an option.
I need to use a third party SMS provider to send and receive text messages. Receiving text messages is the problem.
So I've never really understand how so many services require their customers to provide a webhook. It's such a headache. Companies provide nice things like SDK. For example, when I want to send SMS messages using Twilio of Telnyx for example, I take their jar files, and basically just call a few methods and the SMS is sent without much fanfare. But the fun starts when I want process incoming SMS messages with those (and other) providers. They demand you host a webhook. So there are webhook providers that remove the pain of providing ways to fend of ddos attacks and other heinous scripting kiddies and whatnot, but then those webhook providers still require me to host an http server for it to drop its events to. Why can't I just keep a tcp connection alive to such a provider, and read from a connection that won't send data back until there is something to report, with a periodic heartbeat? And why can't companies like Twilio and Telnyx and others provide all this, without webhooks? It ought to be as simple as providing an event handler interface that simply gets called when needed. The customer shouldn't have to worry about anything more than just dropping in a library and providing a callback method, imo! It's completely feasible, yet it's not provided! Why?
So, because those companies are forcing me to provide a webhook, is there a webhook provider that I can keep a connection open to, where read request trickle out content as needed? A way where I do not have to host any http server?
Objective
I need to show a big table of data in my React web app frontend.
My backend is an Express server with a GraphQL layer and a few "normal" endpoints.
My server gets data from various sources, including an external API, which is the data source for my current task.
My server has a database that I can use freely. I cannot directly access the external API from my front end.
The data all comes from the external API I mentioned. In fact, it comes from multiple similar calls to the same endpoint with many different IDs. Each of those individual calls takes a while to return but doesn't risk timing out.
Current Solution
My naive implementation: I do one GraphQL query in which the resolver does all the API calls to the external service in parallel. It waits on them all to complete using Promise.all(). It then returns a big array containing all the data I need to my server. My server then returns that data to me.
Problem With Current Solution
Unfortunately, this sometimes leaves my frontend hanging for too long and it times out (takes longer than 2 minutes).
Proposed Solution
Is there a better way than manually implementing long polling in GraphQL?
This is my main plan for a solution at the moment:
Frontend sends a request to my server
Server returns a 200 and starts hitting the external API, and sets a flag in the database
Server stores the result of each API call in the database as it completes
Meanwhile, the frontend shows a loading screen and keeps making the same GraphQL query for an entity like MyBigTableData which will tell me how many of the external API calls have returned
When they've all returned, the next time I ask for MyBigTableData, the server will send back all the data.
Question
Is there a better alternative to GraphQL long polling on an Express server for this large request that I have to do?
An alternative that comes to mind is to not use GraphQL and instead use a standard HTTP endpoint, but I'm not sure that really makes much difference.
I also see that HTTP/2 has multiplexing which could be relevant. My server currently runs HTTP/1.1 and upgrading is something of an unknown to me.
I see here that Keep-Alive, which sounds like it could be relevant, is unusable in Safari which is bad as many of my users use Safari to access the frontend.
I can't use WebSockets because of technical restraints. I don't want to set a ridiculously long timeout on my client either (and I'm not sure if it's possible)
I discovered that GraphQL has polling built in https://www.apollographql.com/docs/react/data/queries/#polling
In the end, I made a REST polling system.
I am developing an email sending service, probably for sending bulk emails using sendgrid web API, but I am not able to figure out best practice for scalable system. I wish to keep a record of all those emails which failed to deliver and retry sending to those failed emails after all emails have been sent. I am using NodeJs, so just wanted to know if there is any way to speed up my process(something like sending multiple emails at the same time)
There are multiple ways to handle this, I will suggest two which seems obvious to me.
(Recommended - Easy) Use Async module's control flow option called queue Async Documentation. You can feed in all the request in form of an array of object request and then change concurrency setting to let's say 100, it'll run concurrent 100 workers at one time and to log errors make a separate mechanism and once all the values have been run through handle it separately.
Spawn multiple workers using node.js native approach.
Sendgrid offers an npm package for node.js integration, so you don't have to reinvent the wheel. It accepts messages at a high rate, so you shouldn't have problems delivering yours to sendgrid. You just dump your messages into sendgrid.
Email, being a store-and-forward system, is inherently asynchronous. That means it operates far from real time. Some messages are delivered in a few seconds, and others take hours (when they get soft--"retry later"--rejections from destination servers, for example).
Sendgrid handles this issue with a "bounces" API. (And with "bounces" features in their web back end application). Many bounces are "hard" bounces, meaning you must avoid trying to send messages to that address again. You can use the bounces API to retrieve a list of bounced messages. You should remove those addresses from your email list, and not try to send them again. (Sendgrid bans users who repeatedly send mailings with a high undeliverable rate.)
They also have an "invalid emails" API. This works like "bounces" and returns lists of addresses that are ill-formed or, if sendgrid can tell, not present on the destination server. Again, you should remove these addresses from your email list. If they're invalid now, they will be invalid tomorrow.
Sendgrid offers all sorts of tutorials on this subject.
Given an event driven micro service architecture with asynchronous messaging, what solutions are there to implementing a 'synchronous' REST API wrapper such that requests to the REST interface wait for a response event to be published before sending a response to the client?
Example: POST /api/articles
Internally this would send a CreateArticleEvent in the services layer, eventually expecting an ArticleCreatedEvent in response containing the ID of the persisted article.
Only then would the REST interface response to the end client with this ID.
Dealing with multiple simultaneous requests - is keeping an in-memory map of inflight requests in the REST api layer keyed by some correlating identifier conceptually a workable approach?
How can we deal with timing out requests after a certain period?
Generally you don't need to maintain a map of in-flight requests, because this is basically done for you by node.js's http library.
Just use express as it's intended, and this is probably something you never really have to worry about, as long as you avoid any global state.
If you have a weirder pattern in mind to build, and not sure how to solve it. It might help to share a simple example. Chances are that it's not hard to rebuild and avoid global state.
With express, have you tried middleware? You can chain a series of callback functions with a certain timeout after the article is created.
I assume you are in the context of Event Sourcing and microservices? If so I recommend that you don't publish a CreateArticleEvent to the event store, and instead directly create the article in the database and then publish the ArticleCreatedEvent to the Event store.
Why you ask? Generally this pattern is created to orchestrate different microservices. In the example show in the link above, it was used to orchestrate how the Customer service should react when an Order is created. Note the past tense. The Order Service created the order, and Customer Service reacts to it.
In your case it is easier (and probably better) to just insert the order into the database (by calling the ArticleService directly) and responding with the article ID. Then just publish the ArctileCreatedEvent to your event store, to trigger other microservices that may want to listen to it (like, for example, trigger a notification to the editor for review).
Event Sourcing is a good pattern, but we don't need to apply it to everything.
I'd like to implement push notification server using node.js. The basic scenario is:
Some applications sends notification messages to the server.
Notification server receives the request and forwards the message to uesr's mail or IM client based on user's preference.
In step 1, which protocol (e.g. REST, socket, HTTP/XML and so on.) would you recommend from the performance perspective?
Also in step 2, I have a plan to use node-xmpp module for IM client but for mail, which way is the best to implement? For example,
Just use SMTP. (But I think this might occur performance degradation because SMTP is an expensive communication and performance depends on SMTP server capacity.
use queue mechanism, in order to avoid drawbacks from the above. node.js app simply puts the message into the queue, and smtp server pulls the message.
other solutions...
Thanks in advance.
With regards to what to use as a protocol, i would go for a REST interface, whereby the application posting sends a POST request to a resource associated with the USER. something along the lines of "http://example.com/rest/v1/{userID}/notifications
I personally would use json as the data/content of the rest request and have node.js write this information to a message queue. (as a json string).
You can than have xmpp readers for each user, as well as an SMTP handler reading from this queue as fast as the SMTP server allows it to go.
However, this full post is what i would do in your situation, rather than a factual response on what is best. I know JMS fairly well and i've been working a lot with rest interfaces lately, therefore this is the way i would do it.