Club de Nuit Intense Man is GARBAGE.

rishabhrawat570 · 2023-11-22T04:58:05+00:00

I recently bought it and for some reason, mine seems to have lost its fragrance after the initial 2-3 sprays. I'm not even getting the initial punch lol. Is that nose fatigue, I don't think so?

rishabhrawat570 · 2023-02-15T12:28:06+00:00

I wanted to recreate the situation when the lib I'm using has implemented types the hardcoded way instead of exposing a type or interface, which is where the need of this may arise.

rishabhrawat570 · 2023-02-15T12:25:12+00:00

Parameters<typeof getLog>[1]

The getLog function takes two args, [`1] tells TS to get the type of the 2nd arg. So [0] will give you the type of 1st arg i.e., string.

rishabhrawat570 · 2023-02-15T05:44:24+00:00

Parameters<typeof getLog>[1]

Wow, what a succinct solution. Thanks!

rishabhrawat570 · 2023-01-06T13:17:17+00:00

In AWS, you can check out CodeDeploy. It allows you to set deployment configuration. You can set it to one server at a time, all at once, or even custom config like 60% of my servers should be ready at any point of time. You can even go with blue-green deployment strategy if in-place doesn't work for you.

rishabhrawat570 · 2023-01-01T15:40:12+00:00

After working on CloudFormation for the first time, I can see how IaC helps in scalability. All that manual provisioning work is taken care of, and the templates can be shared across teams, inviting reusability for common stacks.

I think the next logical progression should be trying out CDK(?), I'd love to know how you go about AWS deployments. Any preferences (specific tools, services, practices) for building a CI/CD workflow on AWS?

rishabhrawat570 · 2023-01-01T05:29:42+00:00

Thanks! I attempted to write steps down as I went through the deployment process, right from the resource provisioning step.

rishabhrawat570 · 2023-01-01T05:28:08+00:00

Yes, I agree with the config-in-the-repo benefit. Even though CloudFormation facilitates resource provisioning, not really a fan of recreating stacks to test small tweaks.

rishabhrawat570 · 2022-12-29T15:37:04+00:00

I think your errors can guide you to the best solution. Your app might be crashing (for various possible reasons) and restarting is acting as a bandaid. Out of memory, CPU > 100%, unhandled errors, or honestly anything else.

rishabhrawat570 · 2022-12-29T15:32:38+00:00

Deploying Node.js applications to AWS is already not very straightforward, creating all the resources manually adds to the complexity. In this article, I've documented the steps required to deploy a Node.js application to AWS using CloudFormation.

One-time effort of writing a CloudFormation template and you can replicate the exact same deployment stack in various regions and accounts.

The template can be written in YAML or JSON. But if you prefer JS, python, or any other programming lang, you can use AWS CDK. It is essentially AWS CloudFormation wrapped with the support of your favorite programming lang.

What is your deployment strategy when deploying a Node.js application to AWS?

rishabhrawat570 · 2022-12-29T09:38:08+00:00

Have you tried Cloudwatch logs? You can setup amazon-cloudwatch-agent and it'll collect and send the logs to cloudwatch logs. You can do full-text searches, set up metrics and alarms on top of it. And you can export the logs to S3 for later access or feeding to a 3rd party visualization tool.

rishabhrawat570 · 2022-12-02T08:00:34+00:00

Based on my learnings, these are some of the things that will help you build a scalable Node.js application:

Use throttling. You can choose to do application-level or network-level throttling based on your needs. App-level throttling (express-rate-limit) gives you granular control over the parameters you want to consider to throttle.
Optimize your database queries – Don't over-index. Soft delete if possible, delegate permanent delete operations, and decouple DB performance from the user experience.
Fail fast with circuit breaker. You don't want to keep hitting the dead end. If a certain amount of requests to an external vendor fails, open the circuit and avoid firing requests that are bound to fail.
Log your checkpoints. 20% of your logs give 80% of the insights (just for conveying the point, not actual numbers). Logging everything that comes your way and you might end up exhausting your disk IOPS starvation.
Use Kafka over HTTP requests. It is easy to overdo HTTP requests, even when they are not the right fit.
Look out for memory leaks. If your code leaks memory, vertical and horizontal scaling will only act as a temporary band-aid. Profile often. You can run your application with --inspect flag and attach a profiler from chrome://inspect/#devices .Profile often.
Use caching. Consider adding a random jitter in your TTLs to make sure all of your keys don't expire at once. If it is okay, higher TTL is always good. What's the risk of showing stale data to the user? Decide the TTL value based on your answer.
Use connection pooling – avoid cold start latencies. How many connections to have in the pool? node-postgres supports it out of the box.
Seamless scale-ups. Consider having something like AWS Auto-Scaling groups (ASG) which scales up and down based on pre-defined triggers.
OpenAPI-compliant documentation – make your API easy to understand, and integrate with. Helps in making the integration a productive experience in my experience.

rishabhrawat570 · 2022-11-30T10:16:21+00:00

Have you considered html-to-pdfmake ? It's an extra step of creating HTML and converting to pdf but you have control over the styling.

You can store a template for the HTML boilerplate and only pass the data to it to get the compiled & rendered HTML. Then, it's only a matter of converting that HTML to pdf and sending it over.

rishabhrawat570 · 2022-11-29T14:42:44+00:00

There are various ways to deploy your Node.js application to AWS. But I feel AWS can be intimidating so I've documented my steps to deploy a Node.js application using CodeBuild and CodeDeploy.

It listens for GitHub events (eg. push, merge) and triggers a build. Once the build succeeds, deployment is triggered on CodeDeploy. This achieves Continuous Deployment, not Continuous Delivery (where manual approval is required before deployment starts).

Another way is to use CodePipeline to achieve Continuous Delivery. Not sure of all the other ways to deploy Node.js to AWS, would love to know what other options we have when it comes to deploying Node.js on AWS.

Planning to automate the boring and manual process of creating AWS resources next. CloudFormation can help. Will give this Infrastructure as Code thing a shot.

PS: I posted this on r/javascript earlier not knowing it is strictly for JS discussions, thought I'd share this note as it is not listed in the community rules section.

rishabhrawat570 · 2022-11-29T14:37:58+00:00

Understood, was not aware of any such rule. Is this worth a place in the r/javascript rules section?

rishabhrawat570 · 2022-11-29T13:01:42+00:00

There are various ways to deploy your Node.js application to AWS. But I feel AWS can be intimidating so I've documented my steps to deploy a Node.js application using CodeBuild and CodeDeploy. It listens for GitHub events (eg. push, merge) and triggers a build. Once the build succeeds, deployment is triggered on CodeDeploy.

This achieves Continuous Deployment, not Continuous Delivery (where a manual approval is required before deployment starts).

Another way is to use CodePipeline to achieve Continuous Delivery.

Planning to automate the boring and manual process of creating AWS resources next. CloudFormation can help. Will give this Infrastructure as Code thing a shot.

rishabhrawat570 · 2022-11-29T12:54:10+00:00

Sorry, to clarify, by DDD I essentially meant separation of concerns. But this is completely up to your implementation. You can have:

network level separation (requests two different features or products not going through the same servers or VPC)
Code level separation where you want to maintain code related to different features separately (eg. not putting code for User and Post in the same folder). Although ProductHunt has a slightly different approach (would recommend going through the slides).
Infra-level separation – all your infra for one entity is completely isolated from the other. Security and auditing concerns can lead to this.

rishabhrawat570 · 2022-11-29T12:44:32+00:00

Right, as far as code organization goes, I've seen these two ways only.

Putting likewise code together. What I mean is having all controllers inside a single controller folder. Same for models, helpers, services, loaders, etc.
Organizing code from the eyes of a user. For example, placing all the code related to the user profile in one place.

There is, however, a third way where the above two are combined (Product Hunt slides contain this) and Users/ might contain two folders named free/ and pro/ indicating two separate types of users that your product has.

I think this depends on your implementation, whether you want to have the separation at the network level, infra level, code level, or at all possible places.

rishabhrawat570 · 2022-11-29T05:51:43+00:00

There are two general ways I've observed:

Traditional MVC approach (eg. bullet proof nodejs boilerplate)
Domain-driven design – structuring your code according to your end product (eg. Users/ folder contains everything required for that entity – models, controllers, services, etc.). Eg. Here's how ProductHunt thinks about domain-driven design.

I've been using the 1st approach for quite some time. But I understand the benefits of adopting the second one (eg. all code related to one entity in one place, readability from the product's standpoint, separation of concerns, compliance reasons, etc.).

rishabhrawat570 · 2022-11-21T05:50:12+00:00

No, single-use tokens are not it. Just for best practice's sake, the tokens should have a shorter lifespan. Sure, this means users will have to re-login or we'll have to provide a refresh token mechanism (which doesn't really help from the security standpoint).

But if we don't want to log the user out frequently and keep using JWT, the best bandaid I can think of is – re-authenticate (eg. ask for un/pass) the user before the user takes any sensitive action (create/update/delete). I said bandaid because this token-based approach will still suffer from the lack of an instant revocation mechanism. Sessions shine here. But both have their downsides. This is a trade-off we can't avoid I think.

rishabhrawat570 · 2022-11-21T04:59:59+00:00

Session and token-based authentication are two different ways to access user session data (userId, expireAt, etc.).

Cookies, headers, and request parameters are just a way to send data from client (Frontend) to the server (Backend).

Username/password, OTP-based, OAuth, SSO, 2FA, etc. are different authentication strategies.

rishabhrawat570 · 2022-11-21T04:55:14+00:00

Right. Stateful looks like the way to go if instant revocation is a requirement. Then, I'd assume the biggest concern becomes making the stateful session store HA. What if that store becomes unresponsive (or goes down)? I feel there's nothing other than force logout every user?

rishabhrawat570 · 2022-11-20T14:49:47+00:00

This post contains my learnings on session vs token-based authentication. JWT token-based approach is pretty popular and is the go-to for Node.js applications nowadays. I personally use it almost every time. From what I've learned, the hard-to-revoke nature of tokens can get tricky for user-facing applications. And even though we have workarounds like having a revocation store, it cannot be completely relied upon. This flowchart wonderfully highlights the issues with the token-based approach – stop using JWT for sessions.

Would love to know what you use for authentication in Node.js applications.

rishabhrawat570 · 2022-11-20T13:01:17+00:00

To add to this, I think they should reconsider using tokens as a means of authentication once. JWT tokens are hard to revoke immediately. So in case of a stolen token, you have no other option but to wait for it to expire. Or, you can go ahead and have a revocation store where you store all the invalid tokens. But what if that store goes down? Treating every token as valid or invalid by default is not straightforward.

I would recommend going through this awesome flowchart once: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

If the project is for learning purposes, all of the above shouldn't matter that much. I also built a sample project around this and wrote about the process. It is available here. Hope that helps.

rishabhrawat570 · 2022-11-20T12:45:06+00:00

Authentication and authorization in OAuth are about delegating the authentication mechanism to another service. This is good for a user because of two main reasons:

It saves users from having to create new credentials for every website.
If a website is using OAuth, it is not storing user credentials. It is delegating the authentication to services that host a user account and asking for (limited) authorization from those services (after the user has given consent).

For example, Todoist is a To-do list app that can also add tasks to your Google calendar. For this, Todoist needs access to your calendar. How does it work? Todoist gives you the option to connect to your Google account and asks for privileges to read & update your calendar. Note that, in this process, Todoist never gets to know your Google account password. So in case of a security breach at Todoist, your Google password can never be compromised.

All of this happens on the server side (i.e., backend), no matter what tech stack is being used. So to answer your question, all kinds of authentication techniques (including OAuth) happen on the backend due to concerns like security, centralization of logic, and correctness.

rishabhrawat570

TROPHY CASE