Neden Profesyonel Geliştiriciler localhost:3000'den Gerçek Domain Adlarına Geçiyor

Kendi bilgisayarında çalışan geliştirme ortamının, daha sonra çöpe atılacak geçici bir kurulum olmak zorunda olmadığını fark ettiğin an gerçekten özel bir şey oluyor.

Geçen hafta bir iç aracı ekip arkadaşlarıma gösterdim. İlk tepkiler belli oldu—ama herkes aynı soruyu sordu: "Bu domain için kaç para harcadın?" Bazıları düşünüyordu ki sadece bu sunum için özel bir domain almışım. Diğerleri ise kendilerine özel erişim izni verilmiş olduğunu zannetti.

Gerçek şu ki: bir kuruş harcamadım. Her şeyi bilgisayarımda çalıştırıyordum, sadece localhost:3002 yerine www.internaltool.com üzerinden.

Günümüz Geliştirme Paradoksu

Node.js ve Rails gibi framework'lerin gelmesiyle birlikte, gömülü web sunucularının yaygınlaşması bize inanılmaz bir kolaylık sağladı. npm start komutunu çalıştır, anında 3000 portunda canlı ol. Hiç konfigürasyon yok, sunucu kurulumu yok.

Ama bu kolaylığın bir bedeli var.

Eğer aynı anda üç-dört projeyle uğraşıyorsan ve her biri farklı bir portta çalışıyorsa (3000, 3001, 8080, 5173...), beyniniz adeta bir port haritasına dönüşüyor. Artık kodunuzu düşünmüyorsunuz, hangi portun hangi projeye ait olduğunu hatırlamaya çalışıyorsunuz. Bunu bir takım ortamına çıkar, işler hızlıca kontrolden çıkar.

Daha da önemlisi: geliştirme ortamın artık üretim ortamına benzemiyor. İşte hatalar tam da burada saklanıyor.

Eskinin Hiç Modası Geçmeyen Yöntemi

Modern framework'ler sunucu yazılımını kendileriyle birlikte getirmeden önce, geliştiricilerin çalışma süreci farklıydı. Yerel ağda custom domain'ler kullanıyorlardı ve bunları sistem ayarlarıyla gerçek domain adlarına bağlıyorlardı.

Bu sadece estetikten ibaret değildi. Üretim kurulumunun birebir aynısını bilgisayarında oluşturmak istiyorlardı.

Teknik olarak şaşırtıcı derecede basit: işletim sisteminin hosts dosyasını Nginx gibi bir ters proxy'siyle birleştir. Böylece birden fazla projeyi profesyonel görünümlü gerçek domain adlarıyla çalıştırabilirsin—dev.projen.com, qa.projen.com ve hatta gerçek üretim URL'i, hepsi farklı yerel portlara işaret ediyor.

Kazanç? Profesyonel görünümlü URL'ler, daha net bir zihinsel yapı, takım işbirliğinin kolaylaşması ve üretim ortamını gerçekten andıran bir geliştirme ortamı.

Yerel Custom Domain'ler Nasıl Kurulur: Tam Rehber

Adım 1: Hosts Dosyasını Ayarla

İşletim sisteminizin hosts dosyası kişisel bir DNS sunucusu gibi davranır—bilgisayarınızın internete çıkmadan önce kontrol ettiği bir arama tablosu. Buraya bir giriş ekliyorsanız, aslında makineye şunu söylüyorsunuz: "Biri myproject.com'u istediğinde, internette arama yapma. Benim yerel makinem demek istiyor."

Hosts dosyasını bulun:

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

Dosyayı favorit editörünüzle açın (yönetici/sudo yetkisi gerekir). Şu satırları ekleyin:

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

Artık tarayıcınız bu domain'leri internete değil, yerel bilgisayarınıza (127.0.0.1) yönlendirecek.

Adım 2: Ters Proxy Olarak Nginx Kur

İşte burası ilginçleşiyor. Tarayıcıya myproject.com yazıp enter bastığında, varsayılan olarak port 80'i (HTTP) kullanır. Node veya Rails uygulamanız muhtemelen port 3000'de çalışıyor. Bunlar eşleşmiyor, bağlantı başarısız oluyor.

Nginx bu sorunu çözer. Port 80'i dinler ve istekleri doğru yerel porta yönlendiren bir trafik yöneticisi görevi görür.

Nginx konfigürasyon dosyasını oluştur veya düzenle (Linux'te genellikle /etc/nginx/sites-available/ klasöründe veya Nginx'in kurulu olduğu yer). Şöyle bloklar ekle:

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;
    }
}

Konfigürasyonu tamamladıktan sonra Nginx'i yeniden başlat:

# macOS
brew services restart nginx

# Linux
sudo systemctl restart nginx

Hepsi bu. Tarayıcıda myproject.com'u ziyaret et, localhost:3000'e profesyonel bir domain adı üzerinden erişiyorsun artık.

Pro İpucu: WSL2 Üzerinde Kullanıyorsan

Geliştirme ortamını Windows Subsystem for Linux (WSL2) içinde çalıştırıyorsan, bir adım daha var. Linux ortamının Windows'tan farklı bir sanal IP adresi vardır. Bunu bulmak için şunu çalıştır:

wsl hostname -I

Çıktısı 172.x.x.x gibi bir şey olacak. Windows hosts dosyasında 127.0.0.1 yerine bu IP'yi kullan:

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

Neden Gerçekten Önemli?

İlk bakışta bu sadece kozmetik bir iyileştirme gibi görünüyor. Ama daha derin birşey oluyor burada.

Birincisi, ortam uyumu. Yerel kurulumun mimarisi artık üretim ortamının mimarisine uyuyor. Eğer üretimde ters proxy kullanıyorsan (ki kullanmalısın), artık aynı konfigürasyonla geliştiriyorsun. Localhost'un arkasında gizlenen hatalar yerel ortamda ortaya çıkıyor.

İkincisi, takım iletişimi. "Port 3000'de aracı başlat" demek yerine "dev.internaltool.com'u ziyaret et" diyorsun. Bu daha net, daha az hata yapma ihtimali ve daha profesyonel.

Üçüncüsü, zihinsel açıklık. Port numaraları arasında bağlam değiştirmiyorsun. Sadece gerçek dünyada yaptığın gibi domain'lere gidiyorsun.

Ve en önemlisi—belki—seni sıradan geliştirici zihniyetinden ayırıyor. Hızlıca localhost'ta proje açmaya alışmış biriyle, geliştirme ortamını nasıl yapılandırması gerektiğini derinlemesine düşünmüş birinin arasında fark var.

Hiç Modası Geçmeyen Bir Beceri

Bu teknik yıllardır var ve sessizce kolaylık adına tercih dışı bırakılmış. Ama kolaylık her zaman profesyonellik veya ölçeklenebilirlik anlamına gelmez.

20 dakika ayırıp yerel custom domain'leri kurmak, bu ayın en iyi yatırımı olabilir. Bunun gibi temel altyapı sayesinde asıl önemli şeye odaklanabilirsin: harika yazılım geliştirmeye.

Bir sonraki seferde biri localhost:3000 kullanmıyor musun diye sorduğunda, "çünkü daha havalı" demekten başka bir cevabın olacak. Çünkü profesyoneller ortamlarını böyle yapılandırıyor, o yüzden diyebileceksin.