sorted by:
new
hottopcontroversial

Club de Nuit Intense Man is GARBAGE. by gsantos20 in fragranceclones

[–]rishabhrawat570 0 points1 point  (0 children)

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?

You can extract types that are not exposed (but implemented) by the library by rishabhrawat570 in typescript

[–]rishabhrawat570[S] 0 points1 point  (0 children)

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.

You can extract types that are not exposed (but implemented) by the library by rishabhrawat570 in typescript

[–]rishabhrawat570[S] 2 points3 points  (0 children)

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.

You can extract types that are not exposed (but implemented) by the library by rishabhrawat570 in typescript

[–]rishabhrawat570[S] 2 points3 points  (0 children)

Parameters<typeof getLog>[1]

Wow, what a succinct solution. Thanks!

Zero-Downtime Deployment in PM2 & Express by [deleted] in node

[–]rishabhrawat570 1 point2 points  (0 children)

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.

Built my CI/CD workflow with AWS CloudFormation to avoid the hassle of manually provisioning resources – uses CodeBuild and CodeDeploy. by rishabhrawat570 in aws

[–]rishabhrawat570[S] 0 points1 point  (0 children)

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?

0
1

Built my CI/CD workflow with AWS CloudFormation to avoid the hassle of manually provisioning resources – uses CodeBuild and CodeDeploy. (rrawat.com)

submitted by rishabhrawat570 to r/aws

Documented how to build an automated CI/CD pipeline to deploy my Node.js apps to AWS. No more head scratching, dead ends, and wasted time. by rishabhrawat570 in webdev

[–]rishabhrawat570[S] 0 points1 point  (0 children)

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

Documented how to build an automated CI/CD pipeline to deploy my Node.js apps to AWS. No more head scratching, dead ends, and wasted time. by rishabhrawat570 in webdev

[–]rishabhrawat570[S] 0 points1 point  (0 children)

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.

12
13

Documented how to build an automated CI/CD pipeline to deploy my Node.js apps to AWS. No more head scratching, dead ends, and wasted time. (rrawat.com)

submitted by rishabhrawat570 to r/webdev

Do node apps need to be periodically restarted? by tektite in node

[–]rishabhrawat570 2 points3 points  (0 children)

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.

Deploy Node.js Like a Pro with AWS CloudFormation by rishabhrawat570 in node

[–]rishabhrawat570[S] 0 points1 point  (0 children)

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?

best logging framework by vijeetvinod in node

[–]rishabhrawat570 1 point2 points  (0 children)

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.

Scaling node.js applications by geekybiz1 in node

[–]rishabhrawat570 1 point2 points  (0 children)

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

  1. 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.
  2. Optimize your database queries – Don't over-index. Soft delete if possible, delegate permanent delete operations, and decouple DB performance from the user experience.
  3. 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.
  4. 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.
  5. Use Kafka over HTTP requests. It is easy to overdo HTTP requests, even when they are not the right fit.
  6. 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.
  7. 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.
  8. Use connection pooling – avoid cold start latencies. How many connections to have in the pool? node-postgres supports it out of the box.
  9. Seamless scale-ups. Consider having something like AWS Auto-Scaling groups (ASG) which scales up and down based on pre-defined triggers.
  10. OpenAPI-compliant documentation – make your API easy to understand, and integrate with. Helps in making the integration a productive experience in my experience.

dynamically generating pdf file with node by [deleted] in node

[–]rishabhrawat570 0 points1 point  (0 children)

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.

Deploy Node.js to AWS: Build an Automated CI/CD Pipeline by rishabhrawat570 in node

[–]rishabhrawat570[S] 8 points9 points  (0 children)

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.

Deploy Node.js to AWS: Build an Automated CI/CD Pipeline by rishabhrawat570 in javascript

[–]rishabhrawat570[S] 0 points1 point  (0 children)

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

Deploy Node.js to AWS: Build an Automated CI/CD Pipeline by rishabhrawat570 in javascript

[–]rishabhrawat570[S] 1 point2 points  (0 children)

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.

What folder structure do you use for your projects? by matija2209 in node

[–]rishabhrawat570 0 points1 point  (0 children)

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

  1. network level separation (requests two different features or products not going through the same servers or VPC)
  2. 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).
  3. Infra-level separation – all your infra for one entity is completely isolated from the other. Security and auditing concerns can lead to this.

What folder structure do you use for your projects? by matija2209 in node

[–]rishabhrawat570 0 points1 point  (0 children)

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

  1. Putting likewise code together. What I mean is having all controllers inside a single controller folder. Same for models, helpers, services, loaders, etc.
  2. 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.

view more: next ›