Apakah Filsafat Unix telah ditinggalkan dalam desain aplikasi web? [Tutup]

Unix Philosophy mendorong penggunaan program kerja sama kecil yang dapat digunakan kembali secara umum yang berkolaborasi dengan bentuk komunikasi antar-proses seperti pipa, fifos, soket, sebagai lawan ruang memori bersama dan hubungan. Program MH dan uzbl sering diberikan sebagai contoh aplikasi yang mencontohkan Filsafat Unix dalam desain mereka.

Jika ini masalahnya, bukankah benar bahwa Unix Philosophy telah sepenuhnya ditinggalkan dalam desain aplikasi web? Hampir semua aplikasi web yang memproses permintaan sekarang dibangun sebagai satu proses berjalan lama tunggal monolitik yang menangani seluruh siklus permintaan / respons (selain dari panggilan ke program basis data eksternal) tidak hanya untuk satu sumber daya, tetapi semua sumber daya di seluruh domain.

Apakah ini terutama karena menyalurkan ke kumpulan program eksternal untuk membangun respons dinamis terhadap permintaan web memiliki terlalu banyak proses overhead waktu startup? Saya dapat melihat bagaimana hal ini terjadi jika Anda ingin menggunakan skrip Ruby atau Python, tetapi mungkin jika Anda menggunakan bahasa seperti Haskell yang dapat Anda kompilasi, ada hambatan nyata untuk mengikuti Filsafat Unix dalam membangun aplikasi web hilang?

Saya pikir itu sangat tergantung pada di mana Anda menggambar batas antara aplikasi (yaitu apa definisi Anda tentang aplikasi), dan apa kasus penggunaan yang Anda pertimbangkan.

Meskipun Anda dapat mengimplementasikan browser web sebagai penggabungan dari wget/ curl, parser HTML / XML yang akan memanggil aplikasi sederhana untuk setiap node dokumen, mesin JavaScript mandiri yang akan berinteraksi dengan semua ini dan displayer "sederhana" yang akan "hanya" letakkan output di atas pada layar (dan kembalikan input ke beberapa proses koordinasi inti) bahkan akan lebih berantakan daripada (mungkin ada) browser hari ini lainnya.

Adapun memipipkan data ke proses eksternal - begitulah sebenarnya itu dimulai . Jika Anda khawatir tentang ukuran kode aplikasi web rata-rata, ya mereka sering besar (dan sering karena mereka adalah lapisan yang duduk di atas platform yang ditulis dalam bahasa pemrograman yang ditafsirkan daripada aplikasi "sederhana"), tetapi bandingkan untuk setara mereka. Klien email, suite kantor ... sebut saja. Semua ini cukup kompleks dan memiliki terlalu banyak fungsi untuk diimplementasikan sebagai beberapa proses berkomunikasi melalui pipa. Untuk tugas-tugas yang Anda gunakan untuk aplikasi ini seringkali rumit juga. Tidak ada solusi sederhana yang baik untuk masalah yang kompleks.

Mungkin sudah waktunya untuk melihat sedikit di luar motivasi di balik moto UNIX "aplikasi yang melakukan sedikit tetapi baik dalam hal itu". Ganti "aplikasi" dengan "unit modular umum" dan Anda tiba di salah satu praktik pemrograman dasar yang baik: lakukan hal-hal secara modular, sehingga bagian-bagian dapat digunakan kembali dan dikembangkan secara terpisah . Itulah yang benar-benar penting, IMHO (dan pilihan bahasa pemrograman sangat sedikit hubungannya dengan itu).

ps (mengikuti komentar) : Dalam arti paling ketat Anda sebagian besar benar - aplikasi web tidak mengikuti filosofi UNIX (dibagi menjadi beberapa program mandiri yang lebih kecil). Namun keseluruhan konsep tentang apa yang tampak aplikasi agak keruh - sedmungkin dapat dianggap sebagai aplikasi dalam beberapa situasi , sementara biasanya bertindak hanya sebagai filter.

Oleh karena itu tergantung pada seberapa harfiah Anda ingin mengambilnya. Jika Anda menggunakan definisi proses yang biasa - sesuatu berjalan sebagai proses tunggal (dalam arti kernel melihatnya), maka misalnya aplikasi web PHP yang ditafsirkan dalam httpd oleh modul adalah kebalikannya. Apakah pustaka bersama yang dimuat masih termasuk dalam ruang lingkup proses tunggal (karena mereka menggunakan ruang alamat yang sama) atau apakah mereka sudah sesuatu yang lebih terpisah (tidak dapat diubah dari titik pemrogram, sepenuhnya dapat digunakan kembali dan berkomunikasi melalui API yang terdefinisi dengan baik)?

Di sisi lain, sebagian besar aplikasi web saat ini dipecah menjadi bagian klien dan server, yang berjalan sebagai proses terpisah - biasanya pada sistem yang berbeda (dan bahkan perangkat keras yang terpisah secara fisik). Dua bagian ini berkomunikasi satu sama lain melalui antarmuka yang didefinisikan dengan baik (biasanya tekstual) (XML / HTML / JSON melalui HTTP). Seringkali (setidaknya di browser) ada beberapa utas yang memproses sisi klien dari aplikasi (JavaScript / DOM, input / output ...), kadang-kadang bahkan sebuah proses terpisah menjalankan sebuah plugin (Java, Flash, ... ). Itu suara persis seperti filosofi UNIX asli, terutama pada Linux, di mana benang adalah proses oleh (hampir) setiap akun.

Selain itu, bagian server cukup banyak selalu dibagi menjadi beberapa bagian yang berbeda - mesin database terpisah melakukan operasi yang diminta pada data terstruktur (atau tidak terstruktur) adalah contoh kanonik. Tidak masuk akal untuk mengintegrasikan database ke server web. Namun itu juga tidak masuk akal untuk membagi database menjadi beberapa proses yang akan mengkhususkan diri dalam mengatakan hanya mengurai permintaan, mengambil data dari penyimpanan data, menyaring data .... Kita harus mencapai keseimbangan antara menciptakan raksasa yang mahakuasa dan sebuah segerombolan pekerja yang hampir tak berdaya yang menghabiskan sebagian besar waktu mereka berbicara satu sama lain.

Adapun antarmuka tekstual : perhatikan bahwa apa yang benar untuk data yang diproses 40 tahun yang lalu belum tentu benar hari ini - format biner lebih murah baik dalam ruang dan daya yang diperlukan untuk de / serialisasi, dan jumlah data jauh lebih besar.

Pertanyaan penting lainnya adalah, apa yang sebenarnya menjadi target filosofi UNIX? Saya tidak pernah berpikir simulasi numerik, sistem perbankan atau galeri foto / jejaring sosial yang dapat diakses publik. Namun, pemeliharaan sistem yang menjalankan layanan ini sudah dan kemungkinan akan terjadi bahkan di masa depan.

Saya tidak yakin Unix Philosophy pernah hadir dalam desain aplikasi web - namun, walaupun mungkin benar bahwa banyak aplikasi web berperilaku seperti yang Anda jelaskan, orang mungkin menganggap bahwa aplikasi web saat ini lebih cenderung menjadi konsumen data (mengingat semakin meningkatnya api / metode layanan web menghasilkan data untuk konsumsi web).
Ini pada gilirannya mungkin terlihat untuk mendorong penggunaan komponen kecil yang dapat digunakan kembali (dalam bentuk fungsi JavaScript) yang berkolaborasi satu sama lain, sehingga paralel kecil mungkin ada.