Menyusun aplikasi Angular 2 besar dengan beberapa aplikasi kecil di dalamnya


17

Setelah 3 bulan perdebatan dan penelitian dalam memilih antara React (dengan Redux) dan Angular 2, tim front-end di perusahaan saya telah memutuskan untuk menggunakan Angular 2 (mengingat bahwa itu lebih cocok untuk masalah kami).

Kami masuk ke bisnis aplikasi perusahaan, yang saat ini terdiri dari banyak teknologi front-end yang berbeda (sambil memiliki seluruh backend RESTful), dan kami ingin mengganti semuanya dan memiliki teknologi tunggal untuk membuat pelatihan di masa depan dan kontrol kualitas lebih mudah.

Mengingat sifat produk kami, ini sangat luas, dan ada modul di dalamnya, yang dengan sendirinya merupakan domain yang berbeda dan dapat dibuat sebagai aplikasi mandiri tetapi produk itu sendiri hidup dalam satu URL.

Contoh;

Sebut produk saya sebagai SuperApp.

Sebagai UI, SuperApp memiliki sistem login standar, dan navigasi ke modul / sub-produk anak, sehingga alur kerjanya muncul sebagai berikut.

  • SuperApp

    • Otentikasi Pengguna
    • Lupakan panduan kata sandi
    • Halaman publik dapat diakses tanpa auth
    • Pengguna yang Diotentikasi

      • Sistem navigasi

        • Rumah
          • Sub-produk1
          • Sub-produk2
          • Sub-produk3
        • Profil

          ...

          ...

        • Grup

          ...

          ...

Perhatikan bahwa dalam representasi di atas, Sub-product1dan Sub-product2dua area yang sepenuhnya berbeda, memiliki domain bisnis yang sepenuhnya berbeda.

Apa yang dapat saya pikirkan saat ini adalah bahwa saya dapat membuat SuperApp sebagai proyek Angular 2 tunggal yang hanya memiliki komponen dan tampilan yang relevan dengan dirinya sendiri, dan SuperApp juga bertanggung jawab untuk memuat beberapa aplikasi anak; Sub-product1, Sub-product2(sekali lagi, proyek Angular 2 yang berbeda, memiliki sendiri package.json, webpackkonfigurasi, dll.) melalui komponen bodoh, dan bertindak sebagai shell yang menyediakan perutean tingkat atas dan pengganti untuk memegang aplikasi anak tersebut.

Setelah, Sub-product1dimuat di dalam shell, itu akan menambahkan rute sendiri ke rute saat ini SuperApp telah mendarat.

Alasan saya ingin pemisahan adalah karena aplikasi yang berbeda ini (yang saat ini dibangun menggunakan ExtJS) telah mendedikasikan tim yang mengerjakannya (kami adalah perusahaan yang memiliki 500+ pengembang), jadi jika mereka memiliki proyek sudut mereka sendiri, mereka dapat mengelola alat mereka dan dependensi sesuai dengan keinginan mereka tanpa bergantung pada aplikasi grand parent.

Tapi saya tidak dapat menemukan di mana pun di dokumen resmi sudut, atau di web bahwa apakah memiliki aplikasi bersarang sudut sama sekali mungkin (sedemikian rupa sehingga kode kerangka kerja dibagikan sementara dependensi aplikasi anak sepenuhnya terisolasi dan dimuat hanya ketika aplikasi membutuhkannya), atau apakah ada pendekatan alternatif untuk menyelesaikan masalah seperti itu.

Bimbingan atau bahkan tautan apa pun ke artikel yang relevan akan dihargai.


Apakah Anda menemukan solusi untuk ini?
Dhaval Marthak

@DhavalMarthak Belum, saya masih terbuka untuk ide.
Kushal

@ Kusal Apakah Anda mendapatkan solusi untuk ini? Saya memiliki persyaratan yang sama
Keerthivasan

@Keerthivasan Belum mendapatkan apa-apa, meskipun alternatif yang baik adalah membuat paket global bersama.Json dan kemudian melakukan aplikasi-mikro dalam halaman di mana-mana, tetapi ini akan bekerja secara harmonis hanya jika semua tim pengembang frontend perusahaan disimpan di sinkronkan. Jadi, jika produk Anda benar-benar besar, ini lebih merupakan keputusan politik daripada pilihan arsitektur.
Kushal

1
Ada beberapa pembicaraan tentang mogok monolith frontend di microxchg 2018 yang berbicara tentang beberapa pendekatan. Mungkin ada sesuatu yang bermanfaat di sana. Lihat youtube.com/watch?v=rCxj-ONZmxs dan youtube.com/watch?v=7MHsPfoonqs
sapientpants

Jawaban:


1

Apa yang Anda jelaskan saya tahu dari modul therm. Jadi saya akan merujuk seperti itu.

Saya tidak akan membahas pertanyaan apakah modul dukungan sudut karena kurangnya pengetahuan tentang kerangka kerja. Juga, menurut saya Anda tidak benar-benar menginginkan ini. Dalam pemahaman saya, dan saya berharap backend Anda mencerminkan, Anda ingin mengiris semuanya menjadi bit terkecil yang Anda bisa ( layanan mikro ).

Dalam hal ini setiap titik pada diagram Anda harus merupakan aplikasi independennya sendiri. Mereka yakin harus berkomunikasi satu sama lain, sesuai dengan tanggung jawab masing-masing untuk membentuk pandangan yang Anda gambarkan. Anda melihat bagaimana Google memiliki url / alat / sistem yang terpisah untuk diautentikasi? Gmail tidak peduli tentang itu karena itu bukan tanggung jawabnya. Bahkan menguliti semua alat adalah pusat bukannya terletak di setiap alat (Anda melihat ini pada desain material). Aset tinggal di luar setiap proyek / sistem.

Dengan melakukan itu, Anda mencapai tuas yang lebih tinggi untuk dapat digunakan kembali dan fleksibilitas sistem Anda. Meskipun dalam tim kecil ini tidak dapat dipertahankan karena kompleksitas dan waktu. Sekarang adalah tugas Anda untuk mencari tahu di mana kasing Anda jatuh. Semua dalam layanan mikro dan pemisahan, semua dalam satu pkg atau di suatu tempat di tengah. Dan modul, jika tersedia, adalah sesuatu yang akan Anda gunakan di dalam setiap titik.


1

Satu opsi: Anda bisa "tautan keras" (alih-alih menggunakan tautan SPA) ke sub-aplikasi dan membuat masing-masing sub-aplikasi berbagi ketergantungan untuk pembungkus situs.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.