Closed inetol closed 5 months ago
@tnfAngel Que te parece esta reimplementación?
@tnfAngel Que te parece esta reimplementación?
Hace tiempo probé hono y es parecido a Elysia, pero también es bastante más maduro (por sus implementaciones anteriores en node etc)
Y si usamos la vieja confiable de express 🥹 (broma)
Alguien puede mirarme esta fantasmada y porque ocurre? Me lo miré varias veces y no encuentro la razón de este error. Hono se carga en el instance.fetch de index.ts
, pero las propiedades de Server.ts
ya deberían de estar cargadas con anterioridad y no parece ser el caso?
3 | import { Server } from '../classes/Server.ts';
4 | import { ErrorCode } from '../types/ErrorHandler.ts';
5 |
6 | export class MiddlewareUtils {
7 | // FIXME(Server.DOCUMENT_MAXSIZE): Cannot access uninitialized variable ???
8 | public static bodyLimit(maxSize: number = Server.DOCUMENT_MAXSIZE) {
^
ReferenceError: Cannot access uninitialized variable.
at bodyLimit (/home/inetol/gitgud/Backend/src/utils/MiddlewareUtils.ts:8:51)
at editRoute (/home/inetol/gitgud/Backend/src/endpoints/v2/edit.route.ts:9:27)
at /home/inetol/gitgud/Backend/src/endpoints/v2/index.ts:19:3
at /home/inetol/gitgud/Backend/src/endpoints/v2/index.ts:9:1
voy a ver
creo que lo encontre, el problema no radica en las propiedaes, ni siquiera puede cargar la clase en si, esto se deben probablemente al bloque estatico de las clases V1/V2, que llaman a xRoute (en tu caso el edit) y inmediatamente llama a MiddlewareUtils.bodyLimit(), al estar en el bloque estatico se llama antes de instanciarse su propia clase, y antes de instanciar a cualquier clase, asi que no puede acceder a las otras clases y/o sus propiedades
^ no probe lo demas pero al menos ya no da ese error
No esta mal hono, creo que asta me gusta mas que elysia
Estaría interesante que haga un benchmark de esos entre el último commit de dev y ff27a43 para ver que ha empeorado
Es mejor usa la versión Sync en vez de la async?
No debería de afectar en este caso, no obstante lo volveré a probar antes de hacer merge
Brotli es significantemente más lento comprimiendo pero para descomprimir no habría problema
Que mas le falta a la pull para que se pueda mergear
por cierto habría que al menos comprimir se ejecute asincrónicamente por que usar solo un nucleo de la cpu para comprimir con brotli caca
Que mas le falta a la pull para que se pueda mergear
Las docs/types que tengo que ver como lo implemento bien, el ErrorHandler y algún arreglo
por cierto habría que al menos comprimir se ejecute asincrónicamente por que usar solo un nucleo de la cpu para comprimir con brotli caca
La implementación de brotli de Bun ahora mismo solo usa un núcleo (como todo en JS), tengo planes de implementar worker threads en una clase dedicada para la compresión y descompresión de documentos.
La implementacion de brotli que hize yo no era suficiente?
La implementacion de brotli que hize yo no era suficiente?
Podría no serlo, no llegue a probar del todo como se maneja
No lo he dicho pero todas las rutas ahora están debajo de /api
, por ejemplo para acceder a la documentación es /api/docs
, la referencia igual /api/oas.json
por lo que si se rompe algún endpoint es por eso. Esto se hace para simplificar la configuración de Frontend-Backend en el mismo servidor, más adelante haré que se pueda especificar la ruta de la API cuando lo pruebe más a fondo.
Este PR soluciona todos los problemas que había con Elysia y los types consiguiendo una estructura mucho más limpia y cómoda. No se harán cambios en la API.