could move index.html to /public if it’s going to be sent by a bare sendFile with no templating
“All FIelds are Required” FI -> Fi
is this res ... .json('{"success": ... }') redundant? I think I saw other examples do it like res.json({success: ...})
consider using constant-time comparison when checking the password
if this is specialized for deployment on Glitch, it might be nicer to put the password in .env instead of config.json
maybe move password checking to a middleware function, so that there aren’t so many repetitions of a rather critical routine. this would help the maintainability of the project, because you would otherwise have to be very careful about updating each occurrence
storing titles and bodies in separate stores–this leads to complications with creating/deleting these entries non-atomic. you’d additionally have to deal with the case when one of the two operations fails
fire-and-forget promises: invocations like find(req.query.id); support the happy path of working correctly and sending a response, but there’s no error handling. in the /create and /delete routes, the handler sends a ‘success’ response without even waiting for the database. maybe you’ll be lucky and never encounter any problems. but if there is a problem, you’ll be a lot worse off in debugging it due to this
string interpolation into JSON '{ ... "result": "' + id + '"}' – although id is generated internally, it’s just risky to get in the habit of doing this. because what’s next, concatenating content in HTML code?
no check for req.query.body in /create? dunno if this is intentional.
passwords in the URL parameters? am I reading this right? how hard would it be to avoid this? maybe I’m just superstitious, but I fear that some software is just not very careful about data stored in a URL
I’m going to try to answer everything that you said, If I missed something, I’m sorry
Points 1 & 2: I accidentally forgot to set it to res.location(302, journalish.github.com) for the time being
Point 3: Thanks, I’ll fix that
Point 4: I don’t know what you mean
Point 5: Ok
Point 6: It’s not just for Glitch
Pont 7: Ok, I’ll try that
8: I don’t really have another solution
9: Ok, I’ll make sure to add error handling
10: ???
11: Intentional. In my old memo app, you just needed a title or a body. I’ll try to fix this
12: I’ll also try to fix this
hi, thanks for reading through all that. sorry I didn’t number everything in that last post
for point 4: I’m looking at the express API https://expressjs.com/en/api.html#res.json and it says you would pass res.json an object, and it internally does JSON.stringify to convert it to a string and sends it to the client. in your program, it passes res.json a JSON string, as if you were calling JSON.stringify yourself.
for point 10: what would happen if id contained a " character? I know your program is written in such a way that id only ever contains strings of a certain form, and you may happen to know that this randstring library would never output a double quote. but the point in thinking of what if isn’t because we doubt that. it takes us on a path where (1) we find a solution that would work in the more general case, where idcould contain contain a "; (2) we analyze the pros and cons of this more general solution and this string concatenation solution; and (3) we find the analysis so overwhelming we take one solution entirely out of our repertoire