I have a Facebook Messenger bot written with Node.JS. Currently, it initializes the database (and cache) before initializing Express and receiving requests. I wonder if some requests are sent during initialization, will they get lost?
I'm using Heroku, it that matters.
For free or hobby dyno in heroku there is no zero-downtime setup or preboot as a feature available. While deployment, your Node.js dyno will not serve
the incoming request from the point it restarts the process on that dyno till your server is running successfully on the specified port.
If you have zero-downtime setup already, then your requests will be served by
previous deployed instance unless the new one is spawn and ready to serve.
here is reference link for more info. on zero-downtime heroku
Related
i have a nodejs application, which using express.
My problem:
The app working well on localhost, until i stop that
I bought a shared hosting on Namecheap.com and deployed my app
Everything working, except one thing, this is the 24/7 availability
After half hour of idle (When server does not get request(s)) application shuts down, until it gets new request, and this causes high load time
There are no errors
My question is, is there anything that i can do to prevent this?
Like a custom code that does not let server to go idle?
Application uses: Express, MySql, Express-session, nodecache, Body and cookie parser, gz compression, nodemailer, path, fs
I am using pm2.
Code is long so i won't paste here, if you have suggestions i'll check and provide you more info!
(App registered in cPanel Application Manager powered by Phusion Passanger, NodeEnv=Production)
Introduction
So I made a discord bot and hosted it on Heroku server. The bot is basic, it just listens to new messages and responds to them.
I am using a free tier of heroku and discovered that there are so called "free dyno hours". When it is end of the month, all the free hours are consumed and my bot will go offline until next month.
I own a Raspberry pi and so I thought it would be a good idea to host it there as well in case Heroku goes offline.
What I want to achieve
Host discord bot on hosting platform(Heroku).
use my Raspberry pi as a failover server.
Ensure that only one instance of the bot is running at a time.
If both servers are online Heroku(chosen as the main server) has priority.
If the application on Heroku somehow crashes or goes offline the bot on my Raspberry gets activated.
And vice versa.
How would that work if I had 3 and more servers?
How would I approach this if I had the bot connected to database?
This is just an example I would appreciate if more general solution would be provided.
NginX(load balancer)
When searching for help, I came across load balancers and NginX.
If I am right, it basically functions like a gateway, all requests go to the server NginX is hosted on and then they get redirected to one of many servers(depending on how loaded they are etc.).
I have few problems with this:
my bot doesn't receive any requests, it just listens to the discord api.
if the server with Nginx fails it all falls apart?
My solution 1
My first approach was to let the bot running on both Heroku and Raspberry at the same time.
It guarantees that the bot runs on at least one server if the other one fails.
But it is not ideal as the bot responds 2 times when both servers are up.
My solution 2
Heroku:
I added a simple Rest api endpoint with express.js to the bot app.
This way I can check if the bot on Heroku is running.
Raspberry pi:
I wrapped the bot app with this Node program that basically functions like a switch.
Link to a git repo: https://github.com/Matyanson/secondary-node-server.git
Every 3 minutes the program calls the endpoint and then by looking at the status code it checks whether the app is down.
Then it either starts the app or shuts down the app on raspberry(using pm2).
This kinda works but I am sure there is a better solution!
There is also a problem with Heroku(you can skip this):
Heroku uses Dynos(containers) to run the apps. There are different configurations of dynos including 'Web' and 'Worker'.
Worker is used for background job and never is never put to sleep.
Web dyno is the only dyno to receive HTTP traffic. It is put to sleep after 30min of receiving no web traffic.
I can switch on/off either of these.
both: there are 2 instances of my bot.
Worker: Can't connect to the endpoint.
Web: have to 'ping' the api at least every 30min or the bot sleeps.
Why am I asking?
Not because I need to solve this exact problem but because I want to learn a good way of doing this to use it in the future projects.
I also think this would be a good way to not 100% rely on external Hosting providers.
I deployed a very simple nodejs app using expressjs. It has a few routes and static content with no database connection or anything. The problem is the ridiculously slow response of service. This is the link:
nodejs app deployed on heroku
It literally takes 10 seconds to load up for the first time, though faster in next requests obviously because of cache. Do I need to add paid dyno or add-on to make it faster?
If your application is running on free dyno, it goes to sleep when unused for 30 mins. You could find the information here.
You could verify the sleep by checking the logs heroku logs --tail.
You could add additional dyno other than free type to make it not to sleep. Dyno Types
I am running a parse server on a heroku web dyno. I need to run a long requests on a worker dyno. Do I need to run two parse servers, one for web and one for the worker dyno?
How would one go about running worker dynos when working with parse? I see an example of a nodejs worker, but not sure if it applies to a parse server.
I'm hosting a NodeJS+Express+Mongoose app on Heroku and have been struggling to understand why some of my GET requests are serving stale data, after repeated changes to resources using the api. The changes only get reflected through the GET call after about half an hour or if I restart the server.
The stale resource data gets returned for requests from multiple clients, my Angular JS webapp as well as curl. So, I'm guessing it isn't something to do with caching on the client.
Based on the logging it looks like the requests aren't even making it to the Express app routes, so I'm guessing there's some kind of caching that's happening on the server. I don't see this behaviour on my local system, so is it something that can be disabled on Heroku?
Generally, if you are using Express then your request passes through multiple Express Middleware before actually reaching your app routes. You have to see if there is some error in any of those middleware or there is some validation error for the data which you feed in.
I would suggest you to exhaustively test the data which failed on the heroku app on your local app too.