JavaScript Modulių Federacijos Įvaldymas: Bendrai Naudojamos Srities ir Priklausomybių Dalijimosi Galia

Sparčiai besikeičiančioje interneto kūrimo aplinkoje, kuriant keičiamo dydžio ir lengvai prižiūrimas aplikacijas dažnai tenka taikyti sudėtingus architektūrinius modelius. Tarp jų, mikrofront-endų koncepcija sulaukė didelio populiarumo, leidžianti komandoms kurti ir diegti aplikacijos dalis nepriklausomai. „Webpack“ Modulių Federacijos įskiepis ir esminis jo galios komponentas – bendrai naudojama sritis (shared scope) – yra šios sklandžios integracijos ir efektyvaus kodo dalijimosi tarp šių nepriklausomų vienetų pagrindas.

Šis išsamus vadovas gilinsis į JavaScript Modulių Federacijos bendrai naudojamos srities mechanizmą. Išsiaiškinsime, kas tai yra, kodėl tai būtina priklausomybių dalijimuisi, kaip tai veikia ir kokios yra praktinės strategijos efektyviam įgyvendinimui. Mūsų tikslas – suteikti kūrėjams žinių, kaip panaudoti šią galingą funkciją siekiant geresnio našumo, mažesnių paketų dydžių ir geresnės kūrėjo patirties įvairiose pasaulinėse kūrėjų komandose.

Kas yra JavaScript Modulių Federacija?

Prieš gilinantis į bendrai naudojamą sritį, svarbu suprasti pagrindinę Modulių Federacijos koncepciją. Pristatyta su „Webpack 5“, Modulių Federacija yra kūrimo ir vykdymo laiko sprendimas, leidžiantis JavaScript aplikacijoms dinamiškai dalytis kodu (pvz., bibliotekomis, karkasais ar net ištisais komponentais) tarp atskirai sukompiliuotų aplikacijų. Tai reiškia, kad galite turėti kelias atskiras aplikacijas (dažnai vadinamas „nuotolinėmis“ arba „vartotojų“), kurios gali įkelti kodą iš „konteinerio“ arba „pagrindinės“ aplikacijos, ir atvirkščiai.

Pagrindiniai Modulių Federacijos privalumai:

• Kodo Dalijimasis: Pašalinkite perteklinį kodą keliose aplikacijose, sumažindami bendrą paketų dydį ir pagerindami įkėlimo laiką.
• Nepriklausomas Diegimas: Komandos gali kurti ir diegti skirtingas didelės aplikacijos dalis nepriklausomai, skatindamos lankstumą ir greitesnius išleidimo ciklus.
• Technologinis Agnosticizmas: Nors daugiausia naudojama su „Webpack“, ji tam tikru mastu palengvina dalijimąsi tarp skirtingų kūrimo įrankių ar karkasų, skatindama lankstumą.
• Vykdymo Laiko Integracija: Aplikacijos gali būti sudaromos vykdymo metu, leidžiant dinamiškus atnaujinimus ir lanksčias aplikacijų struktūras.

Problema: Perteklinės Priklausomybės Mikrofront-enduose

Įsivaizduokite scenarijų, kuriame turite kelis mikrofront-endus, kurie visi priklauso nuo tos pačios populiarios UI bibliotekos, pvz., „React“, arba būsenos valdymo bibliotekos, pvz., „Redux“, versijos. Be dalijimosi mechanizmo, kiekvienas mikrofront-endas į savo paketą įtrauktų nuosavą šių priklausomybių kopiją. Tai lemia:

• Išpūsti Paketų Dydžiai: Kiekviena aplikacija be reikalo dubliuoja bendras bibliotekas, todėl vartotojams tenka atsisiųsti didesnius failus.
• Padidėjęs Atminties Vartojimas: Kelios tos pačios bibliotekos instancijos, įkeltos naršyklėje, gali sunaudoti daugiau atminties.
• Nesuderinamas Elgesys: Skirtingos bendrai naudojamų bibliotekų versijos skirtingose aplikacijose gali sukelti subtilių klaidų ir suderinamumo problemų.
• Iššvaistyti Tinklo Resursai: Vartotojai gali atsisiųsti tą pačią biblioteką kelis kartus, jei naršo tarp skirtingų mikrofront-endų.

Būtent čia į pagalbą ateina Modulių Federacijos bendrai naudojama sritis, siūlanti elegantišką sprendimą šioms problemoms spręsti.

Modulių Federacijos Bendrai Naudojamos Srities Supratimas

Bendrai naudojama sritis (shared scope), dažnai konfigūruojama per shared parinktį Modulių Federacijos įskiepyje, yra mechanizmas, leidžiantis kelioms nepriklausomai įdiegtoms aplikacijoms dalytis priklausomybėmis. Kai sukonfigūruota, Modulių Federacija užtikrina, kad būtų įkeltas vienas nurodytos priklausomybės egzempliorius, prieinamas visoms aplikacijoms, kurioms jo reikia.

Iš esmės, bendrai naudojama sritis veikia sukurdama globalų registrą arba konteinerį bendrai naudojamiems moduliams. Kai aplikacija paprašo bendrai naudojamos priklausomybės, Modulių Federacija patikrina šį registrą. Jei priklausomybė jau yra (t. y. įkelta kitos aplikacijos ar pagrindinės aplikacijos), ji naudoja tą esamą egzempliorių. Kitu atveju, ji įkelia priklausomybę ir užregistruoja ją bendrai naudojamoje srityje ateities naudojimui.

Konfigūracija paprastai atrodo taip:

            // webpack.config.js

const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ... other webpack configurations
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      remotes: {
        'app1': 'app1@http://localhost:3001/remoteEntry.js',
        'app2': 'app2@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Pagrindinės Bendrinamų Priklausomybių Konfigūracijos Parinktys:

• singleton: true: Tai turbūt svarbiausia parinktis. Kai nustatyta į true, ji užtikrina, kad visose ją naudojančiose aplikacijose būtų įkeltas tik vienas bendrai naudojamos priklausomybės egzempliorius. Jei kelios aplikacijos bandys įkelti tą pačią singleton priklausomybę, Modulių Federacija joms suteiks tą patį egzempliorių.
• eager: true: Pagal nutylėjimą, bendrai naudojamos priklausomybės yra įkeliamos „tingiai“ (lazily), t. y. jos gaunamos tik tada, kai yra aiškiai importuojamos ar naudojamos. Nustačius eager: true, priklausomybė priverstinai įkeliama vos paleidus aplikaciją, net jei ji nėra iš karto naudojama. Tai gali būti naudinga kritiškai svarbioms bibliotekoms, pvz., karkasams, siekiant užtikrinti, kad jos būtų prieinamos nuo pat pradžių.
• requiredVersion: '...': Ši parinktis nurodo reikiamą bendrai naudojamos priklausomybės versiją. Modulių Federacija bandys rasti atitinkančią versiją. Jei kelios aplikacijos reikalauja skirtingų versijų, Modulių Federacija turi mechanizmus, kaip tai spręsti (aptarsime vėliau).
• version: '...': Galite aiškiai nustatyti priklausomybės versiją, kuri bus paskelbta bendrai naudojamoje srityje.
• import: false: Šis nustatymas nurodo Modulių Federacijai automatiškai neįtraukti bendrai naudojamos priklausomybės į paketą. Vietoj to, tikimasi, kad ji bus pateikta iš išorės (tai yra numatytasis elgesys dalijantis).
• packageDir: '...': Nurodo paketo katalogą, iš kurio reikia išspręsti bendrai naudojamą priklausomybę, naudinga monorepo aplinkose.

Kaip Bendrai Naudojama Sritis Įgalina Priklausomybių Dalijimąsi

Panagrinėkime procesą su praktiniu pavyzdžiu. Įsivaizduokite, kad turime pagrindinę „konteinerio“ aplikaciją ir dvi „nuotolines“ aplikacijas, `app1` ir `app2`. Visos trys aplikacijos priklauso nuo `react` ir `react-dom` 18 versijos.

1 Scenarijus: Konteinerio Aplikacija Dalijasi Priklausomybėmis

Šioje įprastoje sąrankoje, konteinerio aplikacija apibrėžia bendrai naudojamas priklausomybes. `remoteEntry.js` failas, sugeneruotas Modulių Federacijos, atskleidžia šiuos bendrai naudojamus modulius.

Konteinerio Webpack Konfigūracija (`container/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      filename: 'remoteEntry.js',
      exposes: {
        './App': './src/App',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Dabar `app1` ir `app2` naudos šias bendrai naudojamas priklausomybes.

`app1` Webpack Konfigūracija (`app1/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      filename: 'remoteEntry.js',
      exposes: {
        './Feature1': './src/Feature1',
      },
      remotes: {
        'container': 'container@http://localhost:3000/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

`app2` Webpack Konfigūracija (`app2/webpack.config.js`):

`app2` konfigūracija būtų panaši į `app1`, taip pat deklaruojant `react` ir `react-dom` kaip bendrai naudojamus su tais pačiais versijos reikalavimais.

Kaip tai veikia vykdymo metu:

1. Pirmiausia įkeliama konteinerio aplikacija, padarydama savo bendrai naudojamus `react` ir `react-dom` egzempliorius prieinamus savo Modulių Federacijos srityje.
2. Kai `app1` įkeliama, ji paprašo `react` ir `react-dom`. Modulių Federacija `app1` aplikacijoje mato, kad jie pažymėti kaip bendrai naudojami ir `singleton: true`. Ji patikrina globalią sritį ieškodama esamų egzempliorių. Jei konteineris juos jau įkėlė, `app1` pakartotinai naudoja tuos egzempliorius.
3. Panašiai, kai `app2` įkeliama, ji taip pat pakartotinai naudoja tuos pačius `react` ir `react-dom` egzempliorius.

Dėl to į naršyklę įkeliama tik viena `react` ir `react-dom` kopija, žymiai sumažinant bendrą atsisiuntimo dydį.

2 Scenarijus: Priklausomybių Dalijimasis Tarp Nuotolinių Aplikacijų

Modulių Federacija taip pat leidžia nuotolinėms aplikacijoms dalytis priklausomybėmis tarpusavyje. Jei `app1` ir `app2` abi naudoja biblioteką, kuria *nesidalija* konteineris, jos vis tiek gali ja dalytis, jei abi deklaruoja ją kaip bendrai naudojamą savo atitinkamose konfigūracijose.

Pavyzdys: Tarkime, `app1` ir `app2` abi naudoja pagalbinę biblioteką `lodash`.

`app1` Webpack Konfigūracija (pridedant lodash):

            
// ... ModuleFederationPlugin viduje `app1` aplikacijai
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

`app2` Webpack Konfigūracija (pridedant lodash):

            
// ... ModuleFederationPlugin viduje `app2` aplikacijai
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

Šiuo atveju, net jei konteineris aiškiai nesidalija `lodash`, `app1` ir `app2` sugebės dalytis vienu `lodash` egzemplioriumi tarpusavyje, jei jos įkeliamos tame pačiame naršyklės kontekste.

Versijų Neatitikimų Tvarkymas

Vienas iš dažniausių iššūkių dalijantis priklausomybėmis yra versijų suderinamumas. Kas nutinka, kai `app1` reikalauja `react` v18.1.0, o `app2` reikalauja `react` v18.2.0? Modulių Federacija siūlo patikimas strategijas šiems scenarijams valdyti.

1. Griežtas Versijų Atitikimas (numatytasis elgesys `requiredVersion`)

Kai nurodote tikslią versiją (pvz., '18.1.0') arba griežtą diapazoną (pvz., '^18.1.0'), Modulių Federacija tai vykdys. Jei aplikacija bando įkelti bendrai naudojamą priklausomybę su versija, kuri neatitinka kitos jau ją naudojančios aplikacijos reikalavimo, tai gali sukelti klaidų.

2. Versijų Diapazonai ir Atsarginiai Variantai

requiredVersion parinktis palaiko semantinio versijavimo (SemVer) diapazonus. Pavyzdžiui, '^18.0.0' reiškia bet kurią versiją nuo 18.0.0 iki (bet neįskaitant) 19.0.0. Jei kelios aplikacijos reikalauja versijų šiame diapazone, Modulių Federacija paprastai naudos aukščiausią suderinamą versiją, kuri atitinka visus reikalavimus.

Apsvarstykite tai:

• Konteineris: shared: { 'react': { requiredVersion: '^18.0.0' } }
• `app1`: shared: { 'react': { requiredVersion: '^18.1.0' } }
• `app2`: shared: { 'react': { requiredVersion: '^18.2.0' } }

Jei konteineris įkeliamas pirmas, jis nustato `react` v18.0.0 (arba bet kurią versiją, kurią jis iš tikrųjų įtraukia į paketą). Kai `app1` paprašo `react` su `^18.1.0`, tai gali nepavykti, jei konteinerio versija yra mažesnė nei 18.1.0. Tačiau, jei `app1` įkeliamas pirmas ir pateikia `react` v18.1.0, o tada `app2` paprašo `react` su `^18.2.0`, Modulių Federacija bandys patenkinti `app2` reikalavimą. Jei `react` v18.1.0 egzempliorius jau įkeltas, ji gali išmesti klaidą, nes v18.1.0 neatitinka `^18.2.0`.

Siekiant to išvengti, geriausia praktika yra apibrėžti bendrai naudojamas priklausomybes su plačiausiu priimtinu versijų diapazonu, paprastai konteinerio aplikacijoje. Pavyzdžiui, naudojant '^18.0.0' suteikiamas lankstumas. Jei konkreti nuotolinė aplikacija turi griežtą priklausomybę nuo naujesnės pataisytos versijos, ji turėtų būti sukonfigūruota aiškiai pateikti tą versiją.

3. `shareKey` ir `shareScope` Naudojimas

Modulių Federacija taip pat leidžia kontroliuoti raktą, pagal kurį modulis yra bendrinamas, ir sritį, kurioje jis yra. Tai gali būti naudinga sudėtingesniuose scenarijuose, pvz., dalijantis skirtingomis tos pačios bibliotekos versijomis su skirtingais raktais.

4. `strictVersion` Parinktis

Kai įjungta `strictVersion` (tai yra numatytasis elgesys `requiredVersion`), Modulių Federacija išmeta klaidą, jei priklausomybė negali būti patenkinta. Nustačius strictVersion: false, galima leisti lankstesnį versijų tvarkymą, kur Modulių Federacija gali bandyti naudoti senesnę versiją, jei naujesnė nėra prieinama, tačiau tai gali sukelti vykdymo laiko klaidų.

Geriausios Bendrai Naudojamos Srities Naudojimo Praktikos

Norėdami efektyviai išnaudoti Modulių Federacijos bendrai naudojamą sritį ir išvengti dažniausių klaidų, apsvarstykite šias geriausias praktikas:

1. Centralizuokite Bendrai Naudojamas Priklausomybes: Paskirkite pagrindinę aplikaciją (dažnai konteinerį arba specializuotą bendrų bibliotekų aplikaciją) kaip tiesos šaltinį bendroms, stabilioms priklausomybėms, pvz., karkasams (React, Vue, Angular), UI komponentų bibliotekoms ir būsenos valdymo bibliotekoms.
2. Apibrėžkite Plačius Versijų Diapazonus: Naudokite SemVer diapazonus (pvz., '^18.0.0') bendrai naudojamoms priklausomybėms pagrindinėje dalijimosi aplikacijoje. Tai leidžia kitoms aplikacijoms naudoti suderinamas versijas, nepriverčiant griežtai atnaujinti visos ekosistemos.
3. Aiškiai Dokumentuokite Bendrai Naudojamas Priklausomybes: Palaikykite aiškią dokumentaciją apie tai, kurios priklausomybės yra bendrinamos, jų versijas ir kurios aplikacijos yra atsakingos už jų dalijimąsi. Tai padeda komandoms suprasti priklausomybių grafiką.
4. Stebėkite Paketų Dydžius: Reguliariai analizuokite savo aplikacijų paketų dydžius. Modulių Federacijos bendrai naudojama sritis turėtų sumažinti dinamiškai įkeliamų dalių dydį, nes bendros priklausomybės yra iškeliamos į išorę.
5. Valdykite Nedeterministines Priklausomybes: Būkite atsargūs su priklausomybėmis, kurios dažnai atnaujinamos arba turi nestabilius API. Dalijantis tokiomis priklausomybėmis gali prireikti atidesnio versijų valdymo ir testavimo.
6. Naudokite `eager: true` Apgalvotai: Nors `eager: true` užtikrina, kad priklausomybė bus įkelta anksti, per didelis naudojimas gali lemti didesnį pradinį įkėlimą. Naudokite tai kritiškai svarbioms bibliotekoms, kurios yra būtinos aplikacijos paleidimui.
7. Testavimas yra Būtinas: Kruopščiai testuokite savo mikrofront-endų integraciją. Įsitikinkite, kad bendrai naudojamos priklausomybės yra teisingai įkeliamos ir kad versijų konfliktai yra sprendžiami sklandžiai. Automatizuotas testavimas, įskaitant integracijos ir „end-to-end“ testus, yra gyvybiškai svarbus.
8. Apsvarstykite Monorepo dėl Paprastumo: Komandoms, pradedančioms dirbti su Modulių Federacija, bendrai naudojamų priklausomybių valdymas monorepo aplinkoje (naudojant įrankius, tokius kaip Lerna ar Yarn Workspaces) gali supaprastinti sąranką ir užtikrinti nuoseklumą. `packageDir` parinktis čia yra ypač naudinga.
9. Spręskite Kraštutinius Atvejus su `shareKey` ir `shareScope`: Jei susiduriate su sudėtingais versijavimo scenarijais arba reikia atskleisti skirtingas tos pačios bibliotekos versijas, išnagrinėkite `shareKey` ir `shareScope` parinktis detalesniam valdymui.
10. Saugumo Aspektai: Užtikrinkite, kad bendrai naudojamos priklausomybės būtų gaunamos iš patikimų šaltinių. Įgyvendinkite saugumo geriausias praktikas savo kūrimo grandinėje ir diegimo procese.

Pasaulinis Poveikis ir Apsvarstymai

Pasaulinėms kūrėjų komandoms Modulių Federacija ir jos bendrai naudojama sritis siūlo reikšmingų privalumų:

• Nuoseklumas Skirtinguose Regionuose: Užtikrina, kad visi vartotojai, nepriklausomai nuo jų geografinės padėties, patirtų aplikaciją su tomis pačiomis pagrindinėmis priklausomybėmis, sumažinant regioninius neatitikimus.
• Greitesni Iteracijų Ciklai: Komandos skirtingose laiko juostose gali dirbti su nepriklausomomis funkcijomis ar mikrofront-endais, nuolat nesirūpindamos dėl bendrų bibliotekų dubliavimo ar priklausomybių versijų konfliktų.
• Optimizuota Įvairiems Tinklams: Bendro atsisiuntimo dydžio sumažinimas per bendrai naudojamas priklausomybes yra ypač naudingas vartotojams su lėtesniu ar limituotu interneto ryšiu, kuris paplitęs daugelyje pasaulio šalių.
• Supaprastintas Įtraukimas: Nauji kūrėjai, prisijungiantys prie didelio projekto, gali lengviau suprasti aplikacijos architektūrą ir priklausomybių valdymą, kai bendros bibliotekos yra aiškiai apibrėžtos ir bendrinamos.

Tačiau pasaulinės komandos taip pat turi atsižvelgti į:

• CDN Strategijos: Jei bendrai naudojamos priklausomybės yra talpinamos CDN, užtikrinkite, kad CDN turėtų gerą pasaulinį pasiekiamumą ir mažą delsą visuose tiksliniuose regionuose.
• Neprisijungusio Režimo Palaikymas: Aplikacijoms, kurioms reikalingos neprisijungusio režimo galimybės, bendrai naudojamų priklausomybių ir jų talpyklos (caching) valdymas tampa sudėtingesnis.
• Reguliavimo Atitiktis: Užtikrinkite, kad bibliotekų dalijimasis atitiktų bet kokius atitinkamus programinės įrangos licencijavimo ar duomenų privatumo reglamentus skirtingose jurisdikcijose.

Dažniausios Klaidos ir Kaip Jų Išvengti

1. Neteisingai Sukonfigūruotas `singleton`

Problema: Pamirštama nustatyti singleton: true bibliotekoms, kurios turėtų turėti tik vieną egzempliorių.

Sprendimas: Visada nustatykite singleton: true karkasams, bibliotekoms ir pagalbinėms priemonėms, kurias ketinate unikaliai bendrinti visose savo aplikacijose.

2. Nenuoseklūs Versijų Reikalavimai

Problema: Skirtingos aplikacijos nurodo labai skirtingus, nesuderinamus versijų diapazonus tai pačiai bendrai naudojamai priklausomybei.

Sprendimas: Standartizuokite versijų reikalavimus, ypač konteinerio aplikacijoje. Naudokite plačius SemVer diapazonus ir dokumentuokite bet kokias išimtis.

3. Perteklinis Nebūtinų Bibliotekų Dalijimasis

Problema: Bandoma dalytis kiekviena maža pagalbine biblioteka, kas sukelia sudėtingą konfigūraciją ir galimus konfliktus.

Sprendimas: Susitelkite į didelių, bendrų ir stabilių priklausomybių dalijimąsi. Mažesnes, retai naudojamas pagalbines priemones gali būti geriau įtraukti į paketą lokaliai, kad išvengtumėte sudėtingumo.

4. Neteisingas `remoteEntry.js` Failo Tvarkymas

Problema: `remoteEntry.js` failas nėra pasiekiamas arba teisingai patiekiamas jį naudojančioms aplikacijoms.

Sprendimas: Užtikrinkite, kad jūsų nuotolinių įrašų talpinimo strategija būtų patikima ir kad `remotes` konfigūracijoje nurodyti URL adresai būtų tikslūs ir pasiekiami.

5. `eager: true` Pasekmių Ignoravimas

Problema: Nustatoma eager: true per daugeliui priklausomybių, kas sukelia lėtą pradinį įkėlimo laiką.

Sprendimas: Naudokite eager: true tik toms priklausomybėms, kurios yra absoliučiai kritinės pradiniam atvaizdavimui ar pagrindinėms jūsų aplikacijų funkcijoms.

Išvada

JavaScript Modulių Federacijos bendrai naudojama sritis yra galingas įrankis kuriant modernias, keičiamo dydžio interneto aplikacijas, ypač mikrofront-endų architektūroje. Įgalindama efektyvų priklausomybių dalijimąsi, ji sprendžia kodo dubliavimo, išpūtimo ir nenuoseklumo problemas, kas lemia geresnį našumą ir lengvesnę priežiūrą. Suprasti ir teisingai sukonfigūruoti shared parinktį, ypač singleton ir requiredVersion savybes, yra raktas į šių privalumų atskleidimą.

Kadangi pasaulinės kūrėjų komandos vis dažniau taiko mikrofront-endų strategijas, Modulių Federacijos bendrai naudojamos srities įvaldymas tampa itin svarbus. Laikydamiesi geriausių praktikų, kruopščiai valdydami versijas ir atlikdami išsamų testavimą, galite panaudoti šią technologiją kurdami patikimas, našias ir lengvai prižiūrimas aplikacijas, kurios efektyviai aptarnauja įvairią tarptautinę vartotojų bazę.

Pasinaudokite bendrai naudojamos srities galia ir atverkite kelią efektyvesniam ir bendradarbiavimu grįstam interneto kūrimui visoje savo organizacijoje.