Almacenar 5000 elementos en el lado del cliente en una aplicación web [cerrado]

Acabo de tener una entrevista telefónica para el desarrollador de ASP.Net, después del material introductorio inicial, el entrevistador me hizo la primera pregunta técnica:

"Cómo almacenaría 5000 elementos en el lado del cliente para cada usuario en una aplicación web".

Mi respuesta comenzó con

¿Cuál es el tamaño promedio de cada elemento? ¿Realmente tenemos que almacenar esta cantidad de datos en el lado del cliente? ¿No podemos mantener eso en la base de datos y vincular esto a la sesión del usuario / ID del cliente de alguna manera ?

Su respuesta fue "No, usted me dice cómo lo almacenaría en el lado del cliente, considerando que cada elemento es un registro con alrededor de 8 campos que incluyen int / string, una fila de tabla normal".

Le dije: "Puede mantenerlos en una sesión, pero como las sesiones se mantienen en el lado del servidor para cada usuario, podría ser costoso o la otra opción es almacenar esa cantidad de datos en cookies", también dije que no Seguro si esa cantidad de datos podría almacenarse en la cookie. Mencioné que las opciones de almacenamiento HTML5 están ahí, pero no he trabajado con ellas. Como se basa en SQLite, podría almacenar esa cantidad de datos teóricamente .

Ahí es donde el entrevistador dijo algo sarcásticamente , por lo que tiene 3 años de experiencia en desarrollo web y finalizó la entrevista.

Me pregunto, ¿qué hice mal? o hay algo realmente básico que me falta con respecto al almacenamiento de datos en el lado del cliente.

Estoy de acuerdo con los comentarios de que probablemente estaba buscando almacenamiento local HTML5 y que esperaba que tuvieras experiencia con él.

Francamente, a menos que fuera un requisito integral del trabajo y usted declarara que tenía experiencia con él, sus expectativas y reacciones no eran razonables, en mi opinión, para cualquier persona con alguna experiencia.

¿Por qué?

Porque, hace tres años, HTML5 como especificación aún estaba en pañales. En otras palabras, para usted, específicamente, su carrera es casi tan larga como la historia de la especificación misma. No es raro ver trabajos en busca de personas con más experiencia con un producto que el producto ha existido. Es raro ver que ocurra lo mismo para una especificación completa. Por eso, te aplaudo por encontrar una gema así.

Más en serio, sin embargo, parece que el problema radica más en que su entrevistador le haga una pregunta demasiado vaga y lo juzgue con demasiada dureza. No es raro que los entrevistadores hagan preguntas vagas, especialmente en el ámbito del desarrollo. Por lo general, esto se hace para tratar de evaluar cómo piensa y hacia dónde lo lleva su primer instinto. Para eso, lo hiciste bien al cuestionar la necesidad de almacenar ese tipo de datos localmente. Estas preguntas no son, en sí mismas, malas, pero lo que el entrevistador hace con ellas puede conducir a un mal resultado para usted (posiblemente, la finalización de la entrevista significa que probablemente no quiera trabajar para esa compañía, de todos modos).

Ahora, es posible que las necesidades comerciales de la compañía requieran que usen almacenamiento local por una razón u otra. Si ese es el caso, debería haberse explicado en la descripción del trabajo, y debería haber sido descartado como un candidato potencialmente viable cuando su currículum no reflejara tal experiencia si sentían que no podían o no debían capacitar o proporcionar El nuevo empleado con el tiempo / los medios para ponerse al día con la tecnología.

En cuanto al almacenamiento local en sí mismo, como mencioné anteriormente, HTML5 como una especificación solo ha existido durante aproximadamente tres años, y eso es ser generoso y contar los borradores de la "última llamada". Luego, tiene el problema de la compatibilidad con el navegador, que puede o no tener una larga historia (por ejemplo, mientras que los pares de nombre-valor han sido ampliamente compatibles incluso antes de la solidificación HTML5, IndexedDB y Web SQL DB todavía son incompletos ).

Finalmente, el uso del almacenamiento local HTML5 es aún menos común. En mis años como desarrollador web, me he encontrado una aplicación que conozco lo utilizaron todos una vez (puede haber algunos que lo utilizan de forma invisible, pero eso es más difícil de cuantificar), y tal vez media docena de proyectos que pueden ser capaces para usarlo (pero realmente no los necesitaba en ese momento, o el costo de usar ese enfoque frente a otro no estaba justificado).

En un sentido más general, ocurren entrevistas fallidas. El desarrollo de software es ahora campo de una demasiado grande para poder conocer todos los pequeños detalles acerca de cada cosa (en este caso, los límites de almacenamiento de almacenamiento local de HTML5), y ser honesto acerca de no saber una cosa dada es, en mi opinión, sigue siendo la mejor ruta (personalmente respeto más a alguien que reconoce sus lagunas en el conocimiento y busca llenarlas, que a alguien que intenta encubrir el hecho de que no sabe algo). Con eso en mente, diría que manejó bien la pregunta, dada la información que ha brindado aquí. Si hubiera algo que tu hizo mal, puede haber estado en los detalles de cómo respondiste, con lo que no podemos ayudarte, porque no estábamos en la entrevista para evaluar los aspectos no lingüísticos de tus respuestas.

La respuesta 'correcta', al menos, la que estaban buscando, era de hecho HTML5 LocalStorage (un excelente enlace de Steven Burnap). Y el entrevistador probablemente estaba ... bueno, creo que la frase técnica es "un poco perilla ".

Esto se logra básicamente mediante un proceso de eliminación, ya que una cookie no puede ser lo suficientemente grande , las sesiones son del lado del servidor y no una mecánica de almacenamiento del lado del cliente, etc. El entrevistador presumiblemente pensó que esto era de conocimiento común y usted debería saberlo, lo cual es divertido ya que solo necesita capacidades HTML5 LocalStorage típicamente en trabajos de IU con muchos datos, que es la excepción y no la regla. Una persona puede programar durante muchos años y no tener necesidad de la función, mientras que otros pueden tenerla en su primer proyecto.

Sin embargo, generalmente diría que en casos como este es menos una cuestión de su respuesta y más bien una cuestión de cómo la respondió y el proceso que utilizó para llegar allí. Según tu descripción, lo hiciste bien, pero yo no estaba allí, por lo que su impresión podría ser muy diferente.

La mayoría de los entrevistadores sensatos no declararán una pequeña faceta de la tecnología como una prueba de fuego donde cada persona debe responderla de manera excelente ... sin embargo, he tenido muchas entrevistas con personas que no son entrevistadoras sensatas. Conocer tales curiosidades puede ser una bendición cuando te encuentras con esas personas.

Finalmente, quisiera señalar que al declarar la entrevista de una manera no muy agradable, es muy probable que la persona ya estuviera molesta y ya haya decidido por usted (su respuesta a esta pregunta específica podría no haber importado en el lo más mínimo). Solo esperaban un momento para que tropezaras para poder señalarlo y no exponer el hecho de que habían decidido en los primeros 30 segundos más o menos si eras un candidato viable o no.

Tal vez practique cómo responder preguntas para las que no conoce de inmediato la respuesta "correcta", ya que la capacidad de equivocarse con gracia y parecer informado e inteligente de todos modos es una habilidad muy útil, y todos podríamos beneficiarnos de la práctica adicional . Repase algunos artículos de "novedades en [la última versión de tecnología importante]" y luego vuelva a salir.