I recently moved a web app I was working on locally to a server. When working locally, any changes I would make to my express routes would be reflected. As soon as I moved the app to the server, I noticed that I could comment out every line of code pertaining to my routes, e.g. app.get('/') etc.
but those changes would never be reflected, i.e. I would still be served files as if the first version of the website I transferred was still in effect.
Something that is weird, is that any changes not pertaining to routes is taken into consideration, so if I console.log outside of a middleware it will print.
Any idea on how to make sure that express takes into consideration my changes to its routes?
EDIT:
I figured out the issue: somehow, the browser was fetching from localhost even when I was using the remote server's domain (really weird).
As soon as I stopped listening on my local machine, the browser started to make requests to the server.
Guess your host isn't doing any new BUILDS. Check is there's any way to stop process and run the build again.
If you're hosting it on VPS then you can stop all process with SIGTERM or something alike
Related
I have an Express Node API on Heroku. It has a few open routes that makes upstream requests to another web server that then executes some queries and returns data.
So client->Express->Apache->DB2.
This has been running just fine for several months on a Heroku Hobby dyno. Now, however, we exposed another route and more client requests are coming in. Heroku is then throwing H12 errors (bc the Express app isn't giving back a response within 30S).
I'm using axios in the Express app to make the requests to Apache and get data. However, I'm not seeing anything fail in the logs. No errors are getting caught to give me some more details about why things could be timing out. Investigated the Apache->DB2 side of things and the bottleneck doesn't seem there and is almost certainly on the Express side of things.
Per Heroku's advice, I connected the app to NewRelic but haven't gained any insights yet. Sounds like this could be a scalability issue with Express and a high number of new requests coming in at a short period of time? There's not particularly that many. i.e ~50/min at highest. Would beefing up the Heroku dyno do anything? Any other ways to actually see what's going on with Express?
It seems like 10-15% of the client requests are receiving the timeout (and seems to happen at a time when there's lots of incoming requests)
Thanks!
I have deployed a simple javascript memory game to heroku with lite-server.
https://happy-birthday-eline.herokuapp.com
To my surprise, when a user turns a card, all other users see the card turn too. I can't figure out why. I thought client-side actions were limited to the client and could in no way update the server or impact other users.
How do I prevent a user action (click on card) from propagating to all other users?
Thanks
Answer: I thought I could just deploy using lite-server (rather than express) but lite-server has file listening enabled, which is why user actions were impacting all other users. (Obvious) solution was to use express on Heroku, not lite-server!
It's caused by BrowserSync. Looks like you deployed a development version of your code and BrowserSync is connected.
In order to avoid it, you have to deploy a production version of your application.
I'm trying to do [thing] with a Vue.js project created with Vue CLI. [Thing] is not super-important to this question, so I'll omit it for the sake of brevity. I've noticed when I run the local web server for this project with
$ npm run serve
that GET requests work just fine; but POST requests give me a 404 - "Cannot POST". I need to be able to do both.
Using Express, it's straightforward to serve the same page with both GET and POST by simply adding router.post(...) in addition to the default router.get(...). However, in Vue.js this seems difficult.
I've spent some time playing with Vue Router, but poring over the documentation I haven't found a configuration option to tell it "Here's how to respond to a POST request" - it seems to require GET.
But maybe I'm trying to pound a square peg into a round hole. Vue.js is geared toward applications that run in the browser, and browsers send GET requests (For the moment I'm not interested in form submissions...) where POST requests tend to be more of a web app/integration/back end kind of a thing.
What do you guys think - is there something obvious I'm missing, or should I do this the "easy" way and switch to Express?
UPDATE: My "problem" is not Vue.js, specifically - it's the binary vue-cli-service, which definitely listens for GETs, but not POSTs. (GETs from Postman succeed; POSTs from Postman fail.) If I build for deployment, webpack turns the project into HTML/JS/CSS, which is served by a different web server and POSTs work just fine - it's just in dev mode where vue-cli-service is serving my application locally that I can't use POST requests.
Is there an undocumented way to make vue-cli-service respond to POST requests? I've scoured the documentation but haven't found anything. I'm not sure how to make another web server serve a Vue.js project, because the webpack configuration is...complex.
Vue Router is not receiving a (GET) request and responding, it is simply reading the current URL and inserting the corresponding component. So in short, no, there is no POST request handler... I'd argue it's not even handling GET requests either, just reading the URL which looks like a GET request.
If you are trying to POST between pages inside your app, Vuex is what you want.
If you are trying to POST to your app from outside, having an actual server listening for requests which you can ping will be easier (ie Express).
There may be a way to use Axios to do this from your app. It can listen to responses from POST requests, so if it were listening I don't see why it couldn't receive. However, I suspect you'd have to listen to a port from the machine where your app is running which would be a major security issue (if a client's browser/OS/Antivirus even let you).
It's been nearly two weeks since I posted this question, but I didn't even post the question until I'd been struggling with the problem on my own for a week. I finally came to a solution after much head-desking and more dead ends than it would be healthy for my blood pressure to recount. Here it is:
Deciding perhaps my best bet was to look at the vue-cli source code, I happened to notice it includes documentation
The README.md file under docs/config is a bit sparse-looking in what it says about the devserver option, but it also mentions that All options for webpack-dev-server are supported. Ooh.
The Webpack documentation shows a devserver.before option that allows you to access the Express app object and add your own custom middleware to it
This allows you to intercept the POST and redirect it as a GET
Which this guy, who was having the exact same problem as I was, ultimately did. (Note that he used devserver.setup, which does the same thing, but is deprecated in favor of devserver.before.) In vue.config.js, include
devServer: {
before: function(app) {
app.post('/about.html', function(req, res) {
res.redirect('/about.html');
});
},
}
I am working on multiple apps that communicate between each other. I am using Chrome and Firefox both to test my apps on. The problem seems to be persistent in both browsers.
The problem:
I am sending a PUT request from app nr.1 to the Express Node server that essentially sends an update to my mongo database server. Once updated app nr.2 will retrieve the updated value with a GET request. Websockets are being used to notify apps on changes.
The problem however is that the HTTP GET requests on the receiving app nr.2 is taking multiple seconds for it to complete (after a few of them have been done).
To explain the written lines above look at the screenshot below:
the first few GET request take 3-5ms to complete, then the upcoming GET requests will take up to 95634ms to complete....
What could be the cause of this and how could this be fixed?
It is difficult to tell without seeing your whole stack.
Sometimes a reverse-proxy that sits in front of you applications can cause issues like this
They could be trying to route to ipv6 instead of ipv4 especially if you are using localhost to point your GET requests. The fix is to use 127.0.0.1 instead of localhost
Also, a high keepalive timeout setting on a proxy can cause this
Good first places to look in a situation like this are
Proxy logs
Node logs
Server logs (ie firewall or throttling)
I am facing a weird problem with push notifications on Chrome and Firefox. I have created a push notification service in a similar fashion to the recent tutorials on this issue (such as https://developers.google.com/web/ilt/pwa/introduction-to-push-notifications), using an index.js javascript page to register the service, which for the sake of argument is named mypushservice.js. Both are located in the same folder on my web server.
The registration works fine in my development environment, and when I deploy the files on my (SSL) production server environment and call the index.js from a different test location, the registration seems to work fine as well.
However, upon integration of the application with the product that needs to utilise the push notification service, the
navigator.serviceWorker.register('./mypushservice.js')
fails with a 404 not found Http exception. The javascript file is available (and can be registered from my test location), but somehow the service fails when called from another environment.
Has anyone had similar issues and found a solution for this problem?
Thanks
I managed to find the solution to this problem. Apparently the index.js and mypushservice.js both need to be accessed from the same server in order to work. The call to index.js was made from another (client) server, which created a security problem. We managed to create a workaround by adding an html page to the server that calls index.js on loading, and embedding this html file in an IFrame from the client server. I am still looking for a neater solution, but for now this works fine