search

JSPaste / Backend

JSPaste Backend
European Union Public License 1.2
4 stars 1 forks source link

Establecer versiones del endpoint #2

Closed inetol closed 10 months ago

inetol commented 10 months ago

Algo que era un horror con el JSPaste antiguo era implementar cambios en la librería a la par de la API, y no me gustaría tenerlo aquí esa arquitectura.

Propongo establecer un sistema de versiones (/v1/...), por si hubiera cambios que rompiesen las librerías pues se usa una nueva iteración de la API, se sube la versión y todo OK hasta que las librerías (o el frontend) alcancen ese hito actualizando sus rutas. Eso sí, al hacer el sistema de versiones que se establezca una spec detallada.

tnfAngel commented 10 months ago

LGTM, aunque siempre va a haber retrocompatibilidad, tendrá un sistema de versiones (implementado en Caddy, con múltiples instancias de las diferentes versiones (tipo jspaste.eu/v1/documents, y la ruta default /documents también será la última versión

tnfAngel commented 10 months ago

implementado, ya existe jspaste.eu/v1/documents

tnfAngel commented 10 months ago

hablando de la spec, creo que estaría bueno un generador de OpenAPI (Por lo que veo Elysia lo soporta) Algo bastante interesante que encontré también es esto: https://elysiajs.com/eden/overview.html

inetol commented 10 months ago

Interesante, por soportar soporta hasta WS lo que sería mucho mejor que hacer requests HTTP

inetol commented 10 months ago

LGTM, aunque siempre va a haber retrocompatibilidad, tendrá un sistema de versiones (implementado en Caddy, con múltiples instancias de las diferentes versiones (tipo jspaste.eu/v1/documents, y la ruta default /documents también será la última versión

Como harás entonces distintas versiones de los documentos, es decir, si hay un cambio en /documents (algun fichero) que tendrás varios ficheros con las versiones correspondientes o como que no lo he entendido

tnfAngel commented 10 months ago

LGTM, aunque siempre va a haber retrocompatibilidad, tendrá un sistema de versiones (implementado en Caddy, con múltiples instancias de las diferentes versiones (tipo jspaste.eu/v1/documents, y la ruta default /documents también será la última versión

Como harás entonces distintas versiones de los documentos, es decir, si hay un cambio en /documents (algun fichero) que tendrás varios ficheros con las versiones correspondientes o como que no lo he entendido

tendré varias carpetas y múltiples servidores web, por ejemplo uno para v1, y otro para v2 junto con latest (mismo servidor), lo único malo es que entre cada versión se perderán los ficheros que se crearon en versiones anteriores, pero todavía no sé si será un problema porque no sé si hacer que los ficheros sean temporales y se borren cuando pase x tiempo o si hacerlos "permanentes"

tnfAngel commented 10 months ago

O si no tener una carpeta de datos compartida e intentar "migrar" los documentos a las ultimas versiones (sin romper retrocompatibilidad) o simplemente desactivar las nuevas features en documentos que sean de una versión anterior

inetol commented 10 months ago

Pero y porque no tener en "src/routes/\<vX>/documents/" directamente con sus cosas separadas entre sí? Lo de versiones no digo de por cada commit ir creando versiones, sino con cambios importantes que rompan la compatibilidad, si no míralo como la gateway de Discord que hace lo mismo.

tnfAngel commented 10 months ago

ya, claro, las versiones serán solo "major releases". Se podría hacer el versionado dentro del propio servidor sí, pero el problema de los ficheros guardados sigue (por ejemplo, imagina que en un publish del v1 se agrega un "secret" para borrar el fichero (y este se guardará dentro del propio fichero o en uno de metadatos con la misma id), y en la v2 se renombra a token, por poner un ejemplo, ya los ficheros de la v1 no servirían a no ser que se "migren" automáticamente yo lo que tenía pensado era crear ramas (tipo v1 y v2) (no creo que vaya a haber más versiones) y simplemente instanciar dos servidores webs en diferente puerto uno a la escucha de v1/documents y otro a la escucha de v2/documents y /documents

inetol commented 10 months ago

Que las nuevas versiones añadan alguna especie de retrocompatibilidad, o crear el "Backend del Backend" que se encargue del manejo del almacenamiento con sus propios métodos (ignora todo eso último), solo como idea. Lo de tener varios servidores corriendo con cada versión me parece muy ineficiente y seguro que hay formas más simples de manejar este problema.

tnfAngel commented 10 months ago

tienes razón, lo voy a hacer dentro de routes entonces, y sobre lo otro intentar no romper la retrocompatibilidad y listo, es decir que solo se añadan cosas nuevas y opcionales partiendo de v1

tnfAngel commented 10 months ago

bueno, si se va a hacer de la forma "añadir cosas nuevas y opcionales partiendo de v1" las versiones no serian redundantes? lo que funciona en v1 funcionará igual en v2 solo que si no actualizas la lib faltarán features, si se va a hacer así simplemente veo las versiones como tema de spec mas que otra cosa

inetol commented 10 months ago

bueno, si se va a hacer de la forma "añadir cosas nuevas y opcionales partiendo de v1" las versiones no serian redundantes? lo que funciona en v1 funcionará igual en v2 solo que si no actualizas la lib faltarán features, si se va a hacer así simplemente veo las versiones como tema de spec mas que otra cosa

La lib usará la última versión que haya disponible, si hay una v2 disponible en el backend y la v1 esta deprecated el mantenedor de la librería tendrá que actualizar todo lo que haga falta desde su lado para que funcione correctamente con el v2, y si, la redundancia es necesaria, se usará algún import, symlink, ruta del Caddy ya se verá que es lo mejor.