Basically the above problem. I see no error in the logs, however when I check the script on a seperate server it just works fine. I'm doing an API call to Watson and a simple (get) call to an IFTTT Maker link. I write in Node.js and use the request module.
Is AWS Lambda blocking the connection of HTTPS URL's and if so, what can I do to surpass this unfortunate event? I've already seen a similar issue on another thread which was solved using the request module, but sadly this doesn't work for me.
Any help would be much appreciated.
Maybe your Lambda function lives in a private subnet, inside a VPC?
If yes, then it does not have internet access, which means all calls to public servers will time out (see the docs).
In that case, you've got 2 options:
Do not launch your Lambda function inside a VPC.
Allow your private subnet to access the internet by setting up a NAT Gateway. Example guide here.
Related
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.
I'm working on a NestJS monolith application, in the near future, we'll break it into microsservices, but right now everything is on the same project.
I have a few REST APIs for database crud operations, and right now, I'm working on a new feature that is going to receive a payload from the frontend trough a websocket connection, and will then call a few methods on a specific server.
Right now, I'm a completely newbie on sockets and a beginner on Nest, so this might be an obvious and dumb question
I'm following Nest's documentation: https://docs.nestjs.com/websockets/gateways, but I'm not sure how to apply some of that on a real life application.
My socket.gateway.ts has a handleConnection and a sendMessage method, but I need some advice for listening to new events.
Right now, the only way I can receive messages is using #SubscribeMessage on a method inside my .gateway.ts class. But that way, my gateway must inject every service that needs to receive a socket connection payload, so I would need a new method inside my gateway for every "action", like I would if I used REST endpoints on a controller.
So, here's my questions:
Following best practices, how should I receive events payload inside my other services? Should I treat the gateway as if it was "kind-of" a controller? Like a method for every "endpoint" (event) I need to receive payload on?
In case question one is correct, should I have a new gateway for every service (like 1 gateway for UserService, another for AppService, and another for MessageService, just like a controller)?
Also, as an extra question... My backend URL is https://example.com/service-name/example, that address is not callable trough my frontend... It tries to reach example.com, not the full URL, what am I missing?
ALSO: I'm not stuck to Nest socket.io lib, I could use another one, but I do prefer to keep using Nest's native lib as it's not my decision only, so...
Edit: I realized my question about "different services" might actually be better interpreted as "different domains".
I am runnig multiple Node.js servers on one Ec2 Instance , and when i need to call any API that is running on different port of same instance , i need to use AXIOS for calling,I am wondering is this the only way that i can call my API, having known it's running on same EC2 , and is this efficient solution ? please i need guidance
Thank you in advance
I would like to answer this question based on two aspects,
1) The way your application communicating with other application
You can have two ways of doing it. The first one is synchronous, if you have to wait for result from second application and complete the logic in your first application, Then go with this approach. And yes, you can use REST call(using AXION or any REST client).gRpc is another option if you are planning to stream data.
The next one is asynchronous communication, where your application is not waiting for the result from second application(Fire and forget). This can be achieved using a Message queue
2) The way your application is deployed and how it is reffered.
Assuming that you are calling the application using IP:PORT or localhost:PORT(since it is in same VM), I can say that this is not good approach.
Think about a scenario where you need to move one of the application to a different box or you want to scale the application individually. In these cases it would be difficult for you to manage.
Do you have any API gateway or Reverse Proxy or Load-Balancer in front of your application? If yes, call your application through these services.
If you are not sure about the above, please follow the links below,
https://hub.packtpub.com/6-common-use-cases-of-reverse-proxy-scenarios/
https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do
https://microservices.io/microservices/news/2015/03/15/deployment-patterns.html
I need to test my functions locally using AWS Web Socket API Gateway. Is there any possible way to mimic or duplicate the behaviour of AWS Web Socket in my local machine ? So I don't need to deploy every little changes to my Lambda function
Thanks
Unfortunately we're still waiting on local sam support for v2 of API Gateway.
https://github.com/awslabs/aws-sam-cli/issues/896
Recently I was able to find here that there is a workaround available called aws-lambda-ws-server which wraps the routes with a websocket server when ran locally and also works deployed as a AWS Lambda.
Hopefully this will help others in the future!
How is possibile to fallback to another API service if the first try fails with status code of 429 or 500?
Consider this situation:
The gateway should first try a microservice host, but if it timeouts or answer a non 2xx status code it should try a next one.
This is not supported in Express Gateway out of the box. If a request is failing, you'll get a failed request.
Right now you can specify multiple urls for a serviceEndpoint that will be used, but in a round robin manner; therefore you'll still get an error first, before trying again with the second service.
Express Gateway could — and maybe should — handle such case. In meantime I'd suggest you to look to other alternatives offered by your infrastructure. Consul could be the way to go.