Kiezen tussen traditionele web-apps en apps met één pagina (SPA's)
Tip
Deze inhoud is een fragment uit het eBook, Architect Modern Web Applications met ASP.NET Core en Azure, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.
"Atwood's Law: Elke toepassing die kan worden geschreven in JavaScript, wordt uiteindelijk geschreven in JavaScript."
- Jeff Atwood
Er zijn momenteel twee algemene benaderingen voor het bouwen van webtoepassingen: traditionele webtoepassingen die de meeste toepassingslogica op de server uitvoeren en toepassingen met één pagina (SPA's) die de meeste logica van de gebruikersinterface uitvoeren in een webbrowser, die voornamelijk communiceren met de webserver met behulp van web-API's. Een hybride benadering is ook mogelijk, de eenvoudigste manier om een of meer uitgebreide BEVEILIGD-WACHTWOORDVERIFICATIE-achtige subtoepassingen binnen een grotere traditionele webtoepassing te hosten.
Gebruik traditionele webtoepassingen wanneer:
De vereisten aan de clientzijde van uw toepassing zijn eenvoudig of zelfs alleen-lezen.
Uw toepassing moet functioneren in browsers zonder JavaScript-ondersteuning.
Uw toepassing is openbaar en profiteert van zoekprogrammadetectie en verwijzingen.
Gebruik een beveiligd-WACHTWOORDVERIFICATIE wanneer:
Uw toepassing moet een uitgebreide gebruikersinterface met veel functies beschikbaar maken.
Uw team is bekend met JavaScript, TypeScript of BlazorWebAssembly ontwikkeling.
Uw toepassing moet al een API beschikbaar maken voor andere (interne of openbare) clients.
Daarnaast vereisen beveiligd-WACHTWOORDVERIFICATIE frameworks meer architectuur- en beveiligingsexpertise. Ze ervaren meer verloop vanwege frequente updates en nieuwe clientframeworks dan traditionele webtoepassingen. Het configureren van geautomatiseerde build- en implementatieprocessen en het gebruik van implementatieopties zoals containers kan lastiger zijn met beveiligd-WACHTWOORDVERIFICATIE-toepassingen dan traditionele web-apps.
Verbeteringen in de gebruikerservaring die mogelijk worden gemaakt door de beveiligd-WACHTWOORDVERIFICATIE-benadering moeten worden afgewogen tegen deze overwegingen.
Blazor
ASP.NET Core bevat een model voor het bouwen van uitgebreide, interactieve en composeerbare gebruikersinterfaces met de naam Blazor. Blazor met serverzijde kunnen ontwikkelaars gebruikersinterface bouwen met C# en Razor op de server en voor de gebruikersinterface interactief in realtime worden verbonden met de browser met behulp van een permanente SignalR-verbinding. BlazorWebAssembly introduceert een andere optie voor Blazor apps, zodat ze in de browser kunnen worden uitgevoerd met behulp van WebAssembly. Omdat het echte .NET-code is ingeschakeld WebAssembly, kunt u code en bibliotheken opnieuw gebruiken vanuit serveronderdelen van uw toepassing.
Blazor biedt een nieuwe, derde optie om rekening mee te houden bij het evalueren of een puur server-gerenderde webtoepassing of een BEVEILIGD-WACHTWOORDVERIFICATIE moet worden gebouwd. U kunt uitgebreide, beveiligd-WACHTWOORDVERIFICATIE-achtige gedrag aan de clientzijde bouwen met behulp van Blazor, zonder dat er aanzienlijke JavaScript-ontwikkeling nodig is. Blazor toepassingen kunnen API's aanroepen om gegevens aan te vragen of bewerkingen aan de serverzijde uit te voeren. Ze kunnen waar nodig samenwerken met JavaScript om te profiteren van JavaScript-bibliotheken en -frameworks.
Overweeg om uw webtoepassing te bouwen met Blazor wanneer:
Uw toepassing moet een uitgebreide gebruikersinterface beschikbaar maken
Uw team is comfortabeler met .NET-ontwikkeling dan JavaScript- of TypeScript-ontwikkeling
Als u een bestaande webformuliertoepassing hebt die u overweegt te migreren naar .NET Core of het nieuwste .NET, kunt u het gratis e-book Blazor bekijken voor webformulierontwikkelaars om te zien of het zinvol is om het te migreren naar Blazor.
Zie Aan de slag met Blazorvoor meer informatie over Blazor.
Wanneer kiest u traditionele web-apps?
De volgende sectie is een gedetailleerdere uitleg van de eerder genoemde redenen voor het kiezen van traditionele webtoepassingen.
Uw toepassing heeft eenvoudige, mogelijk alleen-lezen vereisten aan de clientzijde
Veel webtoepassingen worden voornamelijk op een alleen-lezen manier gebruikt door de overgrote meerderheid van hun gebruikers. Toepassingen met het kenmerk Alleen-lezen (of meestal lezen) zijn meestal veel eenvoudiger dan toepassingen die een groot aantal statussen onderhouden en manipuleren. Een zoekmachine kan bijvoorbeeld bestaan uit één toegangspunt met een tekstvak en een tweede pagina voor het weergeven van zoekresultaten. Anonieme gebruikers kunnen eenvoudig aanvragen indienen en er is weinig behoefte aan logica aan de clientzijde. Op dezelfde manier bestaat de openbare toepassing van een blog- of inhoudsbeheersysteem meestal voornamelijk uit inhoud met weinig gedrag aan de clientzijde. Dergelijke toepassingen zijn eenvoudig gebouwd als traditionele servergebaseerde webtoepassingen, die logica uitvoeren op de webserver en HTML weergeven die in de browser moet worden weergegeven. Het feit dat elke unieke pagina van de site een eigen URL heeft die kan worden gewijzerd en geïndexeerd door zoekmachines (standaard zonder deze functionaliteit als een afzonderlijke functie van de toepassing toe te voegen) is ook een duidelijk voordeel in dergelijke scenario's.
Uw toepassing moet functioneren in browsers zonder JavaScript-ondersteuning
Webtoepassingen die moeten functioneren in browsers met beperkte of geen JavaScript-ondersteuning, moeten worden geschreven met traditionele web-app-werkstromen (of ten minste kunnen terugvallen op dergelijk gedrag). SPA's vereisen JavaScript aan de clientzijde om te kunnen functioneren; als deze niet beschikbaar is, zijn SPA's geen goede keuze.
Uw team is niet bekend met JavaScript- of TypeScript-ontwikkeltechnieken
Als uw team niet bekend is met JavaScript of TypeScript, maar bekend is met de ontwikkeling van webtoepassingen aan de serverzijde, kunnen ze waarschijnlijk sneller een traditionele web-app leveren dan een BEVEILIGD-WACHTWOORDVERIFICATIE. Tenzij het leren programmeren van SPA's een doel is, of de gebruikerservaring die wordt geboden door een BEVEILIGD-WACHTWOORDVERIFICATIE is vereist, zijn traditionele web-apps een productievere keuze voor teams die al bekend zijn met het bouwen ervan.
Wanneer moet u SPA's kiezen
In de volgende sectie vindt u een gedetailleerdere uitleg wanneer u een ontwikkelstijl voor één pagina kiest voor uw web-app.
Uw toepassing moet een uitgebreide gebruikersinterface met veel functies beschikbaar maken
SPA's kunnen uitgebreide functionaliteit aan de clientzijde ondersteunen waarvoor de pagina niet opnieuw hoeft te worden geladen wanneer gebruikers acties ondernemen of navigeren tussen gebieden van de app. SPA's kunnen sneller laden, gegevens op de achtergrond ophalen en afzonderlijke gebruikersacties reageren sneller omdat het laden van volledige pagina's zeldzaam is. SPA's kunnen incrementele updates ondersteunen, gedeeltelijk ingevulde formulieren of documenten opslaan zonder dat de gebruiker op een knop hoeft te klikken om een formulier in te dienen. SPA's kunnen uitgebreid gedrag aan de clientzijde ondersteunen, zoals slepen en neerzetten, veel gemakkelijker dan traditionele toepassingen. SPA's kunnen worden ontworpen om te worden uitgevoerd in een niet-verbonden modus, waardoor updates worden uitgevoerd voor een model aan de clientzijde dat uiteindelijk wordt gesynchroniseerd met de server zodra een verbinding opnieuw tot stand is gebracht. Kies een beveiligd-WACHTWOORDVERIFICATIE-toepassing als de vereisten van uw app uitgebreide functionaliteit bevatten die verder gaat dan wat typische HTML-formulieren bieden.
Vaak moeten SPA's functies implementeren die zijn ingebouwd in traditionele web-apps, zoals het weergeven van een zinvolle URL in de adresbalk die de huidige bewerking weergeeft (en gebruikers in staat stellen een bladwijzer of dieptekoppeling naar deze URL terug te zetten). Met SPA's kunnen gebruikers ook de knoppen terug en vooruit van de browser gebruiken met resultaten die hen niet verrassen.
Uw team is bekend met javaScript- en/of TypeScript-ontwikkeling
Het schrijven van SPA's vereist bekendheid met JavaScript en/of TypeScript en programmeertechnieken en bibliotheken aan de clientzijde. Uw team moet bevoegd zijn om modern JavaScript te schrijven met behulp van een BEVEILIGD-WACHTWOORDVERIFICATIE-framework zoals Angular.
Verwijzingen – BEVEILIGD-WACHTWOORDVERIFICATIE Frameworks
- Angular: https://angular.io
- React: https://reactjs.org/
- Vue.js:https://vuejs.org/
Uw toepassing moet al een API beschikbaar maken voor andere (interne of openbare) clients
Als u al een web-API ondersteunt voor gebruik door andere clients, is het mogelijk minder moeite nodig om een BEVEILIGD-WACHTWOORDVERIFICATIE-implementatie te maken die gebruikmaakt van deze API's in plaats van de logica in de vorm van de server te reproduceren. SPA's maken uitgebreid gebruik van web-API's om gegevens op te vragen en bij te werken wanneer gebruikers met de toepassing werken.
Wanneer moet u kiezen Blazor
De volgende sectie is een gedetailleerdere uitleg van wanneer u Blazor kiest voor uw web-app.
Uw toepassing moet een uitgebreide gebruikersinterface beschikbaar maken
Net als op JavaScript gebaseerde SPA's Blazor kunnen toepassingen ondersteuning bieden voor uitgebreid clientgedrag zonder pagina's opnieuw te laden. Deze toepassingen reageren meer op gebruikers, waarbij alleen de gegevens (of HTML) worden opgehaald die nodig zijn om te reageren op een bepaalde gebruikersinteractie. Correct ontworpen, kunnen apps aan de serverzijde Blazor worden geconfigureerd om te worden uitgevoerd als apps aan de clientzijde Blazor met minimale wijzigingen zodra deze functie wordt ondersteund.
Uw team is comfortabeler met .NET-ontwikkeling dan JavaScript- of TypeScript-ontwikkeling
Veel ontwikkelaars zijn productiever met .NET en Razor dan met talen aan de clientzijde, zoals JavaScript of TypeScript. Omdat de serverzijde van de toepassing al met .NET wordt ontwikkeld, zorgt het gebruik ervan Blazor ervoor dat elke .NET-ontwikkelaar van het team het gedrag van de front-end van de toepassing kan begrijpen en mogelijk kan bouwen.
Beslissingstabel
De volgende beslissingstabel bevat een overzicht van enkele basisfactoren die u moet overwegen bij het kiezen tussen een traditionele webtoepassing, een BEVEILIGD-WACHTWOORDVERIFICATIE of een Blazor app.
| Factor | Traditionele web-app | Toepassing met één pagina | Blazor App |
|---|---|---|---|
| Vereiste teamkennis van JavaScript/TypeScript | Minimale | Vereist | Minimale |
| Browsers ondersteunen zonder scripts | Ondersteund | Niet ondersteund | Ondersteund |
| Minimaal toepassingsgedrag aan de clientzijde | Geschikt | Overkill | Levensvatbare |
| Uitgebreide, complexe gebruikersinterfacevereisten | Beperkt | Geschikt | Geschikt |
Andere overwegingen
Traditionele Web Apps zijn meestal eenvoudiger en hebben betere SEO-criteria (Search Engine Optimization) dan SPA-apps. Bots van zoekmachines kunnen eenvoudig inhoud van traditionele apps gebruiken, terwijl ondersteuning voor het indexeren van SPA's mogelijk ontbreekt of beperkt is. Als uw app profiteert van openbare detectie door zoekmachines, is dit vaak een belangrijke overweging.
Bovendien moeten ontwikkelaars mogelijk wijzigingen aanbrengen, tenzij u een beheerhulpprogramma voor de inhoud van uw beveiligd-WACHTWOORDVERIFICATIE hebt gemaakt. Traditionele Web Apps zijn vaak eenvoudiger voor niet-ontwikkelaars om wijzigingen aan te brengen, omdat veel van de inhoud gewoon HTML is en mogelijk geen buildproces nodig heeft om een preview- of zelfs implementatieproces uit te voeren. Als niet-ontwikkelaars in uw organisatie waarschijnlijk de inhoud van de app moeten behouden, is een traditionele web-app mogelijk een betere keuze.
SPA's schijnen wanneer de app complexe interactieve formulieren of andere functies voor gebruikersinteractie heeft. Voor complexe apps waarvoor verificatie is vereist en die dus niet toegankelijk zijn voor openbare zoekprogramma's, zijn SPA's in veel gevallen een uitstekende optie.
