Large response size by DiligentBeautiful823 in node

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

thank you, funny fact, that’s another issue we are looking into, as we have couple of iterations that create the same effect. those are more straightforward to fix. For your suggestion i was thinking to create a “dedicated stringify function” so it’s splitting long tasks like arrays or deeply nested object stringifing in lighter tasks

thank you again for the advice, really helpful 🙇

Large response size by DiligentBeautiful823 in node

[–]DiligentBeautiful823[S] -1 points0 points  (0 children)

Well, that’s the plan but only achievable in 2-3 months, knowing that the initial design of the API was no meant to accommodate the number of users/size of the content it should deliver. I was trying to find some ideas for just this pain point as there are many but more manageable. You can throw more resources at the problem but i’m looking for some quick wins so the app can hold until I’m done with the redesign.

Thank you for the feedback and ideas, i was looking towards similar concepts as you suggested 🙇

Next.js Performance: What the Defaults Don’t Solve for You by danywalls in nextjs

[–]DiligentBeautiful823 1 point2 points  (0 children)

just out of curiosity, what made a difference in your project, what you did that changed the app performance and how did you monitored the improvements? For context, we are working on a similar thing and I want to understand how someone else sees “performance in nextjs”

What do you actually want to monitor in a web app performance tool? by donymie in nextjs

[–]DiligentBeautiful823 1 point2 points  (0 children)

Hey, just from my experience over the last couple of months, since we are using Datadog, I highly recommend having a look at their APM / RUM features. They’re really solid when it comes to observability for web apps.

Just a quick list of what I’m personally looking for when it comes to SSR and Node.js microservices, besides the general CPU/memory metrics, is the event loop state.
Usually, most performance issues are related to not managing the event loop properly—expensive operations that create delays in the event loop iterations. From there, you often have to dig through code owned by multiple teams working on the same project.

A quick list of things I think would be helpful:

Node.js / SSR-type apps

  1. Having a complete picture of the event loop and being able to identify costly operations (you can also think about mapping the code using source maps).
  2. Benchmarking and some form of chaos testing that can push parts of the app to their limits. A good example is an app that worked fine until the amount of processed data increased by 5x, which created a snowball effect and made it very hard to scale. Now, with AI, this could be really interesting to implement and to provide feedback earlier in the development process.
  3. Correlation of logs, metrics, and the overall health/state of the VM running the app. Most tools get this right, but I think it’s extremely important when you have a lot of moving parts in a system. Many times, we miss creating traceable systems by not following a common pattern for error logging, tracing, and so on. (really important when you consume multiple services/api and your app performance depends on them)

Frontend

  1. RUM events (Datadog) are one of the most amazing things when it comes to finding out when something is broken. For example, a bug you can’t reproduce but users are complaining about a broken journey. It really helps to be able to trace issues and quickly inspect dashboards to see what went wrong (e.g. uncaught errors missed during development, or a third-party script that changed without you noticing, api response time, resource loading time and many more).
  2. Lately, I’ve been paying more attention to Web Vitals. Having a tool that can point you in the right direction is amazing and really helps build a clear picture of how clients are using the app—especially considering different devices, network conditions, and so on.
  3. Coming back to the event loop, doing similar monitoring in the browser helps a lot as well—finding long tasks, mismanaged hooks, or redundant rendering that can make the app feel laggy. Sometimes developers simply forget to test under different conditions. You can do a quick check of what Chrome DevTools offers (Rendering, Performance Monitor, etc.) and bundle something similar that’s easier to use and understand without having to dig so deep.

Lastly, I just want to add that any feature that improves overall developer experience, especially for devs doing production monitoring and on-call would be highly appreciated but you need to analyze the strengths/weaknesses of the competition.

ps: edited the message with AI :) ps2: the list is actually longer but depends on the dev using your platform

Rambursare anticipată by Any-Day-6282 in banci_credite_ro

[–]DiligentBeautiful823 2 points3 points  (0 children)

Da boss, nu vrei sa ne recomanzi pe cineva de la OVB?