I have a backend application and there are insert/update endpoints. They mostly go as:
Check and validate the input
Submit the input to db
Return status 200/201 with location header set and body contains status message
Would it be ok to make the 2nd step without await so that response can be returned faster? The returned status will be set to 202, which means it is currently processing. The possibility of 2nd step to throw error is extremely low, or if it does there is a bug going on somewhere and does not relate to the end-user anyways, hence no need to return such error to user.
Would this work? Even if this works, would it be a good practice?
It's OK to not wait for the database response to succeed before doing other things (like sending back a response) if that's how you want your app to work and you're sure that's the right design and you've thought through what happens (from the end user's point of view) if that database call (that you didn't wait for) fails.
BUT, it's not OK to ignore a rejected promise that might come back from the database call because unhandled promise rejections should not happen in a nodejs server. So, if you're not going to use an await, then you probably need a .catch() to catch and at least log the error.
Would this work?
Yes. There's nothing in the language or in nodejs stopping your from sending a response before the database call has completed. It's more about whether that's the appropriate way to design your response handler.
Even if this works, would it be a good practice?
It's not a widely recommended practice because the usual sequence is this:
Check and validate the input
Submit the input to db
If success, return status 200/201 with location header set and body contains status message
If error, return appropriate error status (based on type of error) and status message.
I'm not saying that you can never deviate from this sequence, but doing so would generally be the exception, not the rule.
Keep in mind that data validation does not necessarily catch everything that might cause the database to generate an error. For example, you could be creating a new user on your site and the email address is perfect valid in validation, but then the database rejects it because it's not unique (there's already a user with that email address).
And, the database itself could be having problems, causing an error and the user should be informed that the transaction they were trying to submit to the database did not happen event though the error was not directly caused by the user.
Related
I'm confused about this. I have seen a lot of people ending responses with just res.send();. At the same time, some tend to include a status code, like res.status(422).send();. I understand that this is useful when a user, for example, has sent a request to /log-in/ with data that represents a type different from the one needed and appropriate. In such cases, I'm ending my responses with res.status(422).send();. If I'm expecting a username, but I instead receive an array, it seems to me that such an approach is appropriate. However, if everything is technically alright and the user has just entered a username that does not exist, do I need to include a status code? When such a thing happens, a message under the form will be displayed instead. And res.send("This username does not exist."); is the function I would call. Should I call res.status(401).send("This username does not exist."); instead?
Technically you are not forced to use status codes however it's recommended to follow the best practices.
When the user does not exist return 404 not 401. 401 is unauthorized
When user input is not expected, that's validation error(bad request) and return 400 instead of 422. 422 is used in slightly different scenarios.
Read more about it 400 vs 422
More details about http status codes
Yes, status codes are very important as a good practice I would prefer 404 instead of 401 in your case res.status(404).send("This username does not exist.");
stackOverflowAnswer
Why do we use the status code?
To make your debug life easy/ better error handling and to log the error in production to know the severity of the error your application has in case it crashes.
How to Specify statusCode in Node.js
When to use what status code
By default, Express answer all endpoints with 200 unless you didn't specified an endpoint, in this case it will automatically reply with 404.
by the way, Express also has res.sendStatus() function that ends the request and sending status
This has to do with your api design. Generally you would be publishing your api specs (Api specification) and there would mention how your client can find out if something is going wrong or going fine.
HTTP Response code are some of easiest way to inform client about outcome of request. So they don't have to go inside the payload of response to check what was outcome. Since most of codes are well know and there is consensus you will write more standard code which works with network elements like proxies, load-balancer etc and understandable developers.
Advantages of status codes
I am using sails JS and mongo db for my web app.
my code is working fine. But i am having a doubt.
my database statements are like this:
var a = await users.create({username:username,id:id}).fetch();
No try and catch. No error handling.
it is working perfectly fine in my local host. If i Moved to production, will that create a problem??
Any promise that has any chance of rejecting MUST have an error handler of some type. If you don't and you hit that error, your JS will essentially crash with an unhandled exception.
It's just bad programming not to handle any possible errors in some way. You should catch the error, log it and return some sort of error status from whatever http request probably initiated this call.
No error handling. it is working perfectly fine in my local host.
Sure, as long as there's NEVER an error with the database call, it works perfectly fine. What would you expect to happen if there was some sort of database error? Do you want your server crashing? Would you know what was causing it if your server just crashed? Would your users get any feedback that there's a problem?
If i Moved to production, will that create a problem??
It certainly could. If something happened with the data for this call or something happened to your database that led to an error, then your server may crash and whatever http request initiated this would never get a response.
It is just poor programming to not handle all possible errors in some way in your server. It's a common shortcut or lack of attention to detail, but it's always a mistake. As a senior developer involved in code reviews for less senior developers, this was a reason to fail the code review and require further attention to proper error handling.
No it will Not cause probleme but if you got error when this procedure is runing how would you know imagine you did that in many several places in your app and there is some ood issue happining how would you know where is coming from ?
so you Need to do that for more error handling!
When I build server using Node.js. Requests can sometimes fail. For example, there can be error in parsing POST data. When any error happens:
should I continue handling the request and risk that some of those POST data may be corrupt or missing and respond as if nothing happened (or respond and notify the user, that some error happened)?
try to reparse POST data (and if it fails for, let's say, 3 times, stop trying, add error to error log and show error page to user)?
stop the request handling immediately and throw 500 error?
What is the best way?
The key questions to ask yourself in this situation are IMO:
do I know why the error happened;
can I recover from it?
The answers depend solely on your application. Generally, retrying something only makes sense if you can expect a different outcome with the next attempt. This typically applies to various unexpected errors when integrating with external systems. On the other hand, if the error that you get clearly states that it received e.g. a bad request, or that a file does not exist, then this is probably not going to change no matter how many times you retry the same operation.
If your business rules allow you to continue the operation while ignoring the error entirely, then do so. If your business rules allow you to carry out the request partially and you're able to report the partial failure - then do so. If the error prevents any processing of the request whatsoever, then you'll have to terminate it and report back to the user.
It seems to me that you had a particular situation in mind, so let me address request body re-parsing. In a proper system doing this should be utterly pointless - if you expect different outcomes, then there is something fundamentally wrong with your setup because the body of a request should not change once it's received. Your application should never modify request data in any way.
As a more general rule - if you expect that something unexpected might happen in your application, but you have no idea when, why or how, then there is something wrong with how the application is structured / executed. You should own your code and know exactly what it does.
I am coding for a Netty based Notifying Server, which takes in Message Buffer many hundreds at a second from a Server(A) through RPC, and then sends it to an Http Real Time Server, after checking for the validity(the validation consists of checking for a tag ID and its value). If the validation is not successful, the System needs to send an error feedback back to the Server(A) with an Error Code.
I intend to write the validation logic inside a handler, but how do we make the handler to send the feedback if message is found to be invalid?
Can we include database code also into a handler, so I can persist the validation specific details to a Database? Will adding this DB code handicap the Netty performance? If Yes, what's the better way of using a Database (insert) code inside a handler?
Please can anyone guide me? Can I write the DB code inside an Executor?
Kindly excuse me if I am asking a too basic questions. I am still on Learning phase.
Let me try to answer the questions.
1) I think it does not not matter if you want to send an ERROR or SUCCESS response. Just use Channel.write(..) to write it and have an encoder that can handle the encoding to a ChannelBuffer. There is not difference here
2) You should add an ExecutionHandler in front to make sure your db calls do not block the IO-Thread. See [1].
[1] http://netty.io/docs/stable/api/org/jboss/netty/handler/execution/ExecutionHandler.html
So I have a REST service setup with Jersey.
My POJO is simply annotated as #XmlRootElement
I send a POST request to my REST service and everything works fine.
1- I send malformed XML to the service I get back the containers default 400 Bad Request page. Using Glassfish 3 I can't remember exactly but I know I can change or tell my web app to map to my own 400 bad request right? Where can I look for docs on that specific subject.
2- I send valid XML but in one of the expected fields I put empty value. My service tries to do something and it throws a persistence exception. I get back the containers default 500 Internal Server Error page and it list the exception thrown. I guess I can map to my own custom error page as well, but I do not just want to show the exception message. This is considered a security issue.
I would basically like to validate the fields myself based on my business logic and return back to the client an error message such as "Field1 is invalid" Nothing more nothing less. And the client should be able to parse the error code and also know which field was wrong.
Also what can I do when my service has more then one type of bad request error? For instance, the field can expect an INT value between 1-3, but specific business request expects value of 2 and a 3 is sent.
So for type/value validation I want to simply say "Invalid field name here". But for specific business logic say for instance "Invalid account" or "Account Expired" or "Address Does Not Match" etc...
Or how about when I have more then 1 success code?
Basically I'm taking an old "xml" type service and converting to REST style for proof of concept and bring it up to standards. The old one pretty much is 100% POST even when "querying for results. I.e: GET. So basically you POST to it XML, it reads the XML, calls the business logic and logic returns appropriate code in the XML response. So everything is HTTP 200 OK and the business logic code is returned in an XML response. So the only time a client gets a 500 error is when there is hard failure where the service can't produce an XML response. Even invalid XML is returned as 200 OK, but the XML response back indicates this with my own errors codes.
A while back I was suggested I use SOAP for more "message" oriented services, but I still think it's to heavy and I can achieve with REST what my service does, even though I don't need most of REST?
You can map exceptions to HTTP responses using ExceptionMappers - see:
http://jersey.java.net/nonav/documentation/1.11/jax-rs.html#d4e433
http://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/ext/ExceptionMapper.html
If you want to do validation before the request even reaches the resource method, you can try writing a ContainerRequestFilter for that and throw a WebApplicationException which takes Response as a parameter - jersey automatically maps that exception to the response it was initialized with.