יעוץ בתכנון שליחת נתונים לצד קליינט כאשר יש לקליינט כמה צורות סינון לנתונים

[chagold]

בצד הקליינט אמור להיות מוצג לקליינט רשימה של אובייקטים, והתכנון שהוא יוכל לקבל אותם לפי כמה סוגי מיון לדוגמא לפי תאריך / לפי א'ב' / לפי תגית אובייקט ועוד (וגם בתוך המיונים יהיה סינון). עלול להיות שהרשימה של הנתונים תהיה גדולה, אבל אין שליחה של אובייקטים נוספים חוץ מהנתונים עצמם שבJSON.
אני חושב על 3 אפשרויות:

1. שלכל בקשת תצוגה של הקליינט (שליחת המיון והסינון כפרמטרים) השרת שולח לו חזרה JSON במבנה הזה (זאת אומרת גם מבנה הנתונים וגם הנתונים המסוננים).
2. לעשות מעיקרא מערך ענק של כל הנתונים שיהיה שם לכל בקשת תצוגה אובייקט נפרד הכולל את רשימת הנתונים במבנה הנכון, והמערך הענק הזה ישלח לקליינט בבקשה הראשונה, ומעכשיו בכל בקשת תצוגה או סינון הקליינט יברור את התצוגה הנכונה ויקבל אותה מתוך הנתונים שיש אצלו. (ורק הסינון יתבצע על הנתונים שהקליינט מקבל)
3. גם כן שהקליינט יקבל מערך אחד הכולל את הכל, אבל בשונה מהאופציה הקודמת הוא לא יקבל 10 מערכים עם כל סוגי הסינון אלא יקבל מערך אחד שבו יהיה אפשרות לסנן את כל הנתונים לפי הסדר הרצוי.

גם באופציה הראשונה וגם בשלישית יהיה צריך לתכנן את צד הקליינט כתואם לכל צורות הבחירה, והשאלה היא רק צורת השליחה.
האופציה השניה היא הכי מגושמת, וגם בראשונה וגם בשלישית יהיה צריך לקבל רשימת נתונים לפי בקשה של הקליינט. רק שבראשונה המיון נעשה ע"י השרת ובשניה הוא נעשה ע"י הקליינט, אחרי הקבלת המערך.

השאלה:
א' האם יש בכלל אפשרות לעשות סינון למערך JS בצד הקליינט?
ב' במידה ויש אפשרות לסנן, האם עדיין יש עדיפות לעשות פינג אחד 'כבד' (אופציה ג') או הרבה פינגים קטנים (בכל בקשת תצוגה - אופציה א')?

תודה מראש.

[dovid]

הדילמה הזו בגדול היא נחלת כל אתר כמעט.
אין שום בעיה וחיסרון בהרבה בקשות לשרת (כל עוד הם לא בו זמנית, כי בזמן נתון אחד ברור ששתיים גרועות בהרבה מאחת כפולה).
יש לזה אמנם אפקט צידי (ושולי מאוד בד"כ) של העמסת השרת (הכינוי פינגים לא מקובל - שאילתת HTTP כבדה וגדולה בהרבה מפינג), אבל בד"כ מתכננים לא אמורים ולא לוקחים דקדוקי עניות שקשורים באופן הדוק לתצורת השרת. ולכן גם לאפשרות השלישית אני לא ידון מצד שהCPU בשרת יעבוד הרבה פחות (כי הקליינט הוא זה שיסנן) כי זה נחשב off-topic בזמן התכנון וגם דה פקטו זה שולי לחלוטין, לפחות במקרים סטנדרטיים.

אז נשאר לנו שיקולים של חווית צד לקוח.
האפשרות השלישית היא יקרה ברגע טעינת הדף לטובת חוויית צד לקוח מהירה יותר בפעולות ההמשך, זה נכון אבל צריך לקחת בחשבון:

• כמה גדולה הבקשה הזו תהיה (למשל בגמייל יש פס התקדמות בגלל שהם טוענים המממון הודעות מיידית לתת חויית SPA מעולה).
• כמה בקשות מרובות יש לקיינט ממוצע. אם יש לממוצע פחות משתיים שלוש סינונים, אז רק הרענו את המצב,

(האפשרות השניה היא שגוייה, הקליינט יודע מצויין לסנן ועל הצד שלא (כגון שהסינון הוא מסבוך או עתיר ביצועים לקליינט רגיל) ודאי שיש ללכת על הראשונה).

ותודה על ההשקעה בשאלה!

[clickone]

@chagold אני ממש כעת אוחז במשהו דומה עם האובייקט של https://datatables.net/ (כדאי לך לבדוק אותו. יש שם סינונים, מיונים ושאר ירקות...)
הם טוענים שעד 10000 רשומות הכי טוב לטעון הכל מראש ולעשות את המשחקים בקליינט.

ואני עדיין מתלבט, כי ב7000 רשומות אני מרגיש טיפה איטיות, ועדיין יש לי התלבטות כי יש עוד כמה שעובדים במקביל. מה שאומר שעל כל עידכון אני צריך לרענן. או את כל הרשימה, או רק את מה שהתעדכן.

וכמו שאמר @dovid זו אכן התלבטות שתהיה לך כמעט בכל אפליקצייה שתכתוב....

[chagold]

@clickone אמר ביעוץ בתכנון שליחת נתונים לצד קליינט כאשר יש לקליינט כמה צורות סינון לנתונים:

כי יש עוד כמה שעובדים במקביל

בנוגע לאנשים שעובדים במקביל חשבתי שאת זה אמורים לעדכן את הקליינטים האחרים עם 'סוקט'ים, לא?

[clickone]

@chagold זה אפשרי לגמרי.
רק שגם את זה אתה אמור לתכנן....