Wat is het beste om paginering af te handelen? Serverkant of dynamisch doen met javascript?
Ik werk aan een project dat zwaar is voor de ajax en dynamisch gegevens binnenhaalt, dus ik heb gewerkt aan een javascript-paginatiesysteem dat de dom gebruikt – maar ik begin te denken dat het beter zou zijn om regel het allemaal aan de serverzijde.
Wat zijn de gedachten van iedereen?
Antwoord 1, autoriteit 100%
Het juiste antwoord hangt af van uw prioriteiten en de grootte van de te pagineren dataset.
Paginering aan de serverzijde is het beste voor:
- Grote dataset
- Sneller laden van eerste pagina
- Toegankelijkheid voor degenen die geen javascript gebruiken
Paginering aan de clientzijde is het beste voor:
- Kleine dataset
- Sneller volgende pagina’s worden geladen
Dus als u pagineert om voornamelijk cosmetische redenen, is het logischer om dit aan de clientzijde te doen. En als je pagineert om de initiële laadtijd te verminderen, is de serverkant de voor de hand liggende keuze.
Natuurlijk neemt het voordeel van de klant op de laadtijden van volgende pagina’s af als u Ajax gebruikt om volgende pagina’s te laden.
Antwoord 2, autoriteit 12%
Als u dit aan de clientzijde doet, downloadt uw gebruiker eerst alle gegevens die mogelijk niet nodig zijn, en verwijdert u het belangrijkste voordeel van paginering.
De beste manier om dit te doen voor dit soort AJAX-apps is om AJAX de server voor de volgende pagina te laten bellen en de huidige pagina bij te werken met behulp van client-side script.
Antwoord 3, autoriteit 9%
Als je grote pagina’s en een groot aantal pagina’s hebt, kun je pagina’s beter in delen opvragen bij de server via AJAX. Laat de server dus de paginering doen op basis van uw verzoek-URL.
U kunt ook de volgende paar pagina’s die de gebruiker waarschijnlijk zal bekijken, vooraf ophalen om de interface responsiever te laten lijken.
Als er maar een paar pagina’s zijn, is het misschien een betere keuze om alles van tevoren te pakken en te pagineren op de client.
Antwoord 4, autoriteit 8%
Zelfs met kleine gegevensgroottes zou paginering aan de serverzijde de beste keuze zijn. U hoeft zich later geen zorgen te maken als uw webapplicatie verder schaalt.
En voor grotere gegevensomvang ligt het antwoord voor de hand.
Antwoord 5, autoriteit 5%
Serverzijde – stuur net genoeg inhoud naar de client voor de huidige weergave.
Antwoord 6, autoriteit 5%
In een praktische wereld van limieten zou ik aan de serverkant gaan om alle bronnen te sparen die verband houden met het verzenden van de gegevens. Ook moet de server zichzelf beschermen tegen een kwaadwillende/niet-functionerende client die om een ENORME pagina vraagt.
Zodra die code met plezier voortkabbelt, zou ik “smarts” aan de client toevoegen om de “volgende” en “vorige” pagina te krijgen en die in het geheugen te bewaren. Update je cache wanneer de gebruiker naar de volgende pagina gaat.
Als de clientsoftware dit soort paginacaching uitvoert, overweeg dan hoe snel uw gegevens verouderen (waarschijnlijk zullen veranderen) en of u moet controleren of uw in het cachegeheugen opgeslagen gegevenspagina nog steeds geldig is. Misschien opnieuw aanvragen als het meer dan 2 minuten oud is. Misschien een “vuile” vlag erin. Zoiets. Ik hoop dat je dit nuttig vindt. 🙂
Antwoord 7, autoriteit 5%
Bedoelt u dat uw JavaScript alle gegevens in het geheugen heeft en één pagina per keer toont? Of dat het elke pagina van de server downloadt als het nodig is, met behulp van AJAX?
Als het laatste het geval is, moet u wellicht ook nadenken over sorteren. Als je met JavaScript sorteert, kun je maar één pagina tegelijk sorteren, wat niet zo logisch is. Je sortering moet dus op de server gebeuren.
Antwoord 8, autoriteit 4%
Ik geef de voorkeur aan paginering aan de serverzijde. Wanneer u het echter implementeert, moet u ervoor zorgen dat u uw SQL op de juiste manier optimaliseert. Ik geloof bijvoorbeeld in MySQL, als je de LIMIT-optie gebruikt, wordt de index niet gebruikt, dus je moet je sql herschrijven om de index correct te gebruiken.
G-Man
Antwoord 9
Een ander ding om hier op te wijzen, is dat u zelden zult worden beperkt tot het eenvoudig doorbladeren van een onbewerkte dataset.
Misschien moet u naar bepaalde termen zoeken in een of meer kolommen die u weergeeft, en vervolgens sorteren op een paar kolommen zeggen en de gebruikers vervolgens de mogelijkheid geven om door deze gefilterde dataset te bladeren.
In een situatie als deze moet je misschien kijken of het beter is om deze logica te laten zoeken en/of sorteren op de client- of serverkant.
Een ander ding om te overwegen is dat Amazon’s cloud-zoek-api je een aantal zeer krachtige zoekmogelijkheden biedt en je wilt natuurlijk dat cloud-zoeken het zoeken en sorteren voor je kan afhandelen als je je gegevens daar laat hosten.
>