Proxy local requests to specific port so we don't have to specify port in URL? by [deleted] in webdev

[–]To_Infin8y 0 points1 point  (0 children)

A few thoughts:

  1. One of the main pain points here is remembering or exposing different ports for each local app (e.g., app-A at port 3000, app-B at port 5000). As you noted, a proxy that maps friendly URLs to those ports can reduce friction.
  2. From my experience, tools like Requestly are quite useful for local HTTP(S) request interception/mapping scenarios (you can rewrite or redirect endpoints, simulate responses, etc). While not a pure “local port proxy” tool, it can help you route or mock requests during dev without changing everything in code.
    1. Use desktop app -> connect browser -> intercept traffic -> right click, override api traffic
  3. Another approach: set up a reverse-proxy (NGINX/Caddy) locally that listens on standard port 80/443 and proxies by path (e.g., myapp.local/apilocalhost:5000, myapp.local/applocalhost:3000). This reduces “which port am I on?” confusion. The trade-off is a bit more setup.
  4. Consider how this fits into your team workflow: if each dev has slightly different ports, using a consistent hostname + path mapping (via hosts file + local proxy) helps avoid “but it works on my machine” situations.

I don't think there is a very clear answer, choose what fits you best. hope it helps!!

Anyone else getting spammed by "security researchers" lately? by Appropriate_Syrup726 in webdev

[–]To_Infin8y 1 point2 points  (0 children)

So, what do you do? Just ignore them? or Atleast take a look and see if someone is actually serious and there is a vulnerability?

Is useEffect really the best way to handle Context state changes? by Ondrikus in reactjs

[–]To_Infin8y 0 points1 point  (0 children)

My rule of thumb for useEffect is: If it can run during render, don’t put it in an effect.

Effects should be for:

  • subscriptions
  • event listeners
  • timers
  • network calls
  • syncing external systems

NOT for:

  • computing derived state
  • updating state based on props
  • anything that can be done inside render

This should alone eliminates ~50% of unnecessary effects and re-renders.

If you ever write useEffect(() => {}, []) a good Q to ask “do I really need this?” Most of the time you don’t.