3 ms·

I started using AWS API Gateway + Lambda for these type of problems where I don't actually need a 24/7 running server. Bots / webhook listeners do really fit f

by webo 10y ago

I started using AWS API Gateway + Lambda for these type of problems where I don't actually need a 24/7 running server. Bots / webhook listeners do really fit for API Gateway + Lambda use cases.

LAMike 10y ago
Are you using Javascript for that? I thought the API needed to have a server that's always running so the chats can be instant, but is it possible to do that with Lambda? I'm currently using Modulus and I think it will get pretty expensive if I keep making more bots, so a cheaper way to do it would be nice! Edit: Found a tutorial: https://medium.com/@igorkhomenko/run-facebook-messenger-chat-bot-on-aws-lambda-2fa800a67d76#.4v5va9iaz https://medium.com/@igorkhomenko/run-facebook-messenger-chat...
- happyslobro 10y ago
  Lambda functions initialize in <10ms when warm, <100ms otherwise, in my experience. They seem to stay warm for 15 minutes or so after a cold start. The excellent Serverless framework is pure JS, but you can also deploy jars to Lambda, which lets you use any JVM language. Clojure Lambdas have a more extreme profile: ~500ms for a cold start, <1ms once warm. You could keep it warm with a timer event source, which could do double duty as a watchdog / heartbeat thing.
happyslobro 10y ago
How do you handle the FB API concurrency limits? I'm not familiar with the messenger API, but the marketing API is pretty strict about not allowing more than a few requests (2? 5?) per second. Once I hit that, I hashed out a scheme where I serialize and queue outgoing requests (SQS), and then execute them from a lambda that is triggered by a 1 second timer. At this point, I was in a crunch for what was supposed to be a fairly simple task, and modern AWS is somewhat of an unfamiliar environment for me, so I just deployed it as a classic Node worker on Heroku.

3 ms·

I started using AWS API Gateway + Lambda for these type of problems where I don't actually need a 24/7 running server. Bots / webhook listeners do really fit f

by webo 10y ago

I started using AWS API Gateway + Lambda for these type of problems where I don't actually need a 24/7 running server. Bots / webhook listeners do really fit for API Gateway + Lambda use cases.

LAMike 10y ago
Are you using Javascript for that? I thought the API needed to have a server that's always running so the chats can be instant, but is it possible to do that with Lambda? I'm currently using Modulus and I think it will get pretty expensive if I keep making more bots, so a cheaper way to do it would be nice! Edit: Found a tutorial: https://medium.com/@igorkhomenko/run-facebook-messenger-chat-bot-on-aws-lambda-2fa800a67d76#.4v5va9iaz https://medium.com/@igorkhomenko/run-facebook-messenger-chat...
- happyslobro 10y ago
  Lambda functions initialize in <10ms when warm, <100ms otherwise, in my experience. They seem to stay warm for 15 minutes or so after a cold start. The excellent Serverless framework is pure JS, but you can also deploy jars to Lambda, which lets you use any JVM language. Clojure Lambdas have a more extreme profile: ~500ms for a cold start, <1ms once warm. You could keep it warm with a timer event source, which could do double duty as a watchdog / heartbeat thing.
happyslobro 10y ago
How do you handle the FB API concurrency limits? I'm not familiar with the messenger API, but the marketing API is pretty strict about not allowing more than a few requests (2? 5?) per second. Once I hit that, I hashed out a scheme where I serialize and queue outgoing requests (SQS), and then execute them from a lambda that is triggered by a 1 second timer. At this point, I was in a crunch for what was supposed to be a fairly simple task, and modern AWS is somewhat of an unfamiliar environment for me, so I just deployed it as a classic Node worker on Heroku.