Γιατί οι επαγγελματίες developers εγκαταλείπουν το localhost:3000 υπέρ κανονικών domains

Πρόσφατα παρουσίασα ένα εσωτερικό εργαλείο σε συναδέλφους. Δεν εντυπωσιάστηκαν από τη λειτουργικότητα. Ρωτούσαν μόνο: "Πόσα πλήρωσες για το domain;". Κάποιοι νόμιζαν ότι το αγόρασα ειδικά για την demo. Άλλοι πίστευαν ότι έχουν ειδική πρόσβαση.

Η αλήθεια; Τίποτα δεν πλήρωσα. Όλα έτρεχαν τοπικά, αλλά στο www.internaltool.com αντί για localhost:3002.

Το πρόβλημα της σύγχρονης εξέλιξης

Τα frameworks όπως Node.js και Rails έφεραν ενσωματωμένους servers. Με ένα npm start είσαι online αμέσως, συνήθως στο port 3000. Άνεση χωρίς ρυθμίσεις.

Αλλά έχει παγίδες.

Όταν δουλεύεις 3-4 projects ταυτόχρονα, με ports 3000, 3001, 8080, 5173, χάνεσαι. Ο εγκέφαλός σου γίνεται κατάλογος ports. Σε ομάδα, γίνεται χάος.

Χειρότερα: τοπικό περιβάλλον διαφέρει από production. Εκεί κρύβονται bugs.

Η παλιά μέθοδος που ακόμα κρατάει

Παλιά, πριν τα ενσωματωμένα servers, οι developers έδεναν custom domains τοπικά μέσω hosts file. Δεν ήταν μόνον για στυλ. Ήταν για να μιμείται το production.

Η λύση; Hosts file + reverse proxy όπως Nginx. Τρέχεις projects σε domains όπως dev.yourproject.com, qa.yourproject.com. Κερδίζεις καθαρά URLs, καλύτερη οργάνωση, ευκολότερη συνεργασία.

Οδηγός ρύθμισης custom τοπικών domains

Βήμα 1: Ρύθμιση hosts file

Το hosts file λειτουργεί σαν προσωπικό DNS. Προσθέτεις εγγραφές και ο υπολογιστής σου "ξέρει" πού να πηγαίνει.

Τοποθεσία:

• macOS/Linux: /etc/hosts
• Windows: C:\Windows\System32\Drivers\etc\hosts

Άνοιξέ το με sudo/admin. Πρόσθεσε:

127.0.0.1 myproject.com
127.0.0.1 dev.myproject.com
127.0.0.1 qa.myproject.com

Τώρα το browser πηγαίνει εκείνοματα στο localhost.

Βήμα 2: Nginx ως reverse proxy

Το domain κανονικά "κοιτάει" port 80. Το app σου τρέχει στο 3000. Χρειάζεσαι "συντονιστή".

Nginx ακούει στο 80 και στέλνει traffic στο σωστό port. Στο config σου (π.χ. /etc/nginx/sites-available/), πρόσθεσε:

server {
    listen 80;
    server_name myproject.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    server_name dev.myproject.com;

    location / {
        proxy_pass http://localhost:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    server_name qa.myproject.com;

    location / {
        proxy_pass http://localhost:3002;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Επανεκκίνησε:

# macOS
brew services restart nginx

# Linux
sudo systemctl restart nginx

Δοκίμασε myproject.com. Πάει στο localhost:3000.

Συμβουλή για WSL2

Σε WSL2, βρες το IP του Linux:

wsl hostname -I

Χρησιμοποίησέ το στο Windows hosts αντί 127.0.0.1:

172.x.x.x myproject.com
172.x.x.x dev.myproject.com

Γιατί αξίζει τον κόπο

Δεν είναι απλά ομορφιά.

Παραλληλότητα περιβάλλοντος. Τοπικά μιμείται production. Με reverse proxy όπως στο server, bugs φαίνονται νωρίς.

Επικοινωνία ομάδας. "Πήγαινε στο dev.internaltool.com" αντί "port 3000". Πιο ξεκάθαρο.

Καθαρό μυαλό. Domains όπως στο web, όχι ports.

Επαγγελματισμός. Ξεχωρίζεις από ερασιτέχνες που μένουν στο localhost.

Μια δεξιότητα διαχρονική

Αυτή η τεχνική υπάρχει χρόνια. Η "άνεση" των ports την ξέχασε. Αλλά επαγγελματισμός θέλει δομή.

Δώσε 20 λεπτά. Θα βελτιώσει το workflow σου. Εστίασε στο code, όχι σε ports.

Επόμενη φορά που ρωτήσουν για localhost:3000, πες: "Γιατί σκέφτομαι σαν pro developer".