Reposilite 4.x wishlist #2005
Comments
dzikoysk
added
investigation
|
Since it seems like the UI is going to be majorly reworked: thoughts on adding "looks at least somewhat decent on mobile" to the list? (especially the admin interface, so admin stuff can be done from a mobile device) |
|
also, one note: you mentioned using jte. |
Sure, the mobile support should be way better there. In current UI, it's mainly blocked by the tabs & jsonforms libraries, but it's a minor issue, so I didn't decide to invest my time into it for now.
When I'm thinking about a desired stack for a new frontend, I want to cover these 3 crucial requirements:
The main reason behind JTE choice is performance - it provides a compilation mode, where it generates classes for all template components:
This + a possibility to implement Node-like hot reloading makes it a good candidate. It has some issues tho - writing a JavaScript code inside a template might be a bit painful. Even if HTMX/Unpolly/something similar would cover most of the features, there are still some side cases, when we may need to cover with JS. Raw JS/state management is kind rough, so we could try to utilize something like Preact locally, for some specific features. |
|
The only thing I'm missing is an indexer+search built-in. |
I was working on that for a bit as a plugin sometime ago, and may continue it one day™ (or I might just forgor again) |
|
Maybe not too related to Reposilite. But what about an integrated docker registry? |
|
Yes, the Docker registry would be absolutely great. Unfortunately, it requires a lot of work, as the specification seems to be quite complex - there's an issue for that: It'd be nice to document all things we need to do (from specification perspective), so later on we could try to estimate if we'll be able to do that or not. |
There is already Harbor for that, so I don't think it is strictly necessary. I do appreciate Reposilite's focus on providing great light weight solution for hosting Maven repositories. |
|
Yeah you're right. There is enough software which is already capable of providing a registry and reposilite should stay simple-ish |
|
I'd like to see support for byte ranges. I want to use reposilite as a simple arch mirror, and arch is complaining about failed downloads. |
Well, yes and no. These days, you're often distributing JVM apps as containers, so it'd be kinda nice to have it supported at some point - I could even distribute Reposilite itself there. Of course, it can't be considered as the new main target, because we don't have enough resources to compete with dedicated tools, like e.g. Harbor. Hopefully, something like that should be possible to implement purely as an optional plugin.
It'd be nice if you could submit a new issue with a bit more detailed description. As long as we don't aim to support arch itself, supporting http range requests probably could be a thing. |
|
One thing I would like to see is the ability to customize the appearance |
|
yeah, the ability to provide your own css styles/themes would be quite nice ie. use the default frontend, but just have some customized css (ie. to make the frontend a bit less "harsh") also here's a few misc. things:
~ edit: merged both comments / @dzikoysk |
I'll most likely implement the new frontend with HTMX+Tailwindcss. These sources don't need a build process, so users should be able to pretty much do whatever they want there. I don't think I'll target the appearance that much tho, because it's quite niche feature, but the idea with a separate CSS file for some most common stuff like e.g. colors might be interesting. I think I'll be able to tell more once I'll start doing this, because I'm not completely sure how it should be done yet.
This is already possible - just create a new repository per each mirrored repository and link these local mirrors via local loopback link: You can set individual storage limits per each repo as it'd be a regular repo.
Currently, we're only providing a built-in option to delete snapshot files, but if we'd have an option to determine if a given file was proxied or not, then date based cleanup for mirrors would be a great enhancement. This is not really related to 3.x/4.x, so I created a new issue for this:
It was requested a lot of times - not sure how it'll look like on the new frontend, but in general this is already planned ✔️
I still think that the search option in UI should be implemented internally in Reposilite, based on some metadata we'll store in the database. Speaking about the maven-indexer, we have a separate issue for this: There were some issues with it, if you have some more data on this, it'd be nice to continue this thread there, just so we can keep this in one place.
The problem with detailed statistics is that it highly increases the database usage - that's why we're currently only counting unique requests per month by default. On the other hand, the prometheus integration will be merged into the core sources, so we should be fine with just pushing some extra events instead of storing this on our own. In this case, it's also not important to address this directly in 4.x - extra metrics can be added later as a feature requests.
It wouldn't be a breaking change, so I think it could be moved to a standalone issue if needed. In general, I have a limited time for the project, so such issues usually have really low priority for me, but feel free to submit a PR - it's cool to have such options.
Probably could be addressed after 4.x, but I'll try to remember about this after rewriting the layout.
|
|
Ability to hostdart/flutter packages: https://github.com/dart-lang/pub/blob/master/doc/repository-spec-v2.md |
|
Copying this over here just in case: #1011 (comment) |
As for the UI of Reposilite, I think that using something like Tailwind or UnoCSS would be a good fit. I wonder if there could be a redesign of the way that data was fetched from the backend and the frontend that wouldn't require a templating engine serving the content. I wonder if there is some sort of RPC that existed for generating Web based code from Kotlin types and APIs? If not then a templating engine and a lightweight framework with styling sugar sounds like a good step towards there, as I don't think Kotlin has amazing web features. |
I'm a bit tired of introducing intermediate layers, just to display some sort of static content. Having a template engine, I could possibly get rid of the whole frontend module. There are some drawbacks as always, but as far as I see it could be an option to significantly reduce the size of the codebase, so it'd be easier to maintain it. Another benefit of having the frontend generated by backend is extensibility - currently, there is no option to modify frontend via plugin API, because frontend is just a standalone app that is precompiled earlier. It's even hard to inject custom base path url, not speaking about some more advanced effects.
Even if we'd have some sort of RPC framework, it'd still need to make some calls over the network to fetch/update latest state for client-side logic. It means we're falling once again into the world with 2 independent states (client and server) that we need to synchronize at some point.
I had some time to prototype a basic plugin for Javalin, and it's promising: 7GvUf0FLo5.1.mp4So we can prototype frontend with hot-reloads. Of course, for backend changes we need to rebuild a project, but it's good enough I'd say. |
if you don't introduce any methods/etc. you can hotswap code in intellij when running in debug mode. I personally have a macro set up to execute:
when pressing ctrl + s (you can create a similar macro by starting macro recording, using double shift then searching for and executing each action, and then afterwards edit the macro to remove all the double shifts & other useless stuff) it won't hotswap anything which introduces new methods or new classes, but if it's just a change to the method body, it hotswaps it. quite useful. |
That's perfect yeah! I understand that reasoning. |
I do feel like that for this, if an RPC framework existed, there are good solutions for syncing up backend and client. Even just a simple SSE connection could go a long way for a simple dynamic frontend, and if there was an RPC, all the API infrastructure for the framework side code could be standardized and modified from the backend, without requiring a change to the frontend. Obviously this is easier said than done, but I'd be happy to look into if this is a possible solution, since generally the downsides of a templating engine can introduce limitations in the future, but I think in this case, either solution would work generally well. |
|
As long as we are talking about choices of frontend technology, what about going for a nice "clean" HTMX powered front-end? Backend could use your own favorite templating engine to serve html smippets, so we get best of both worlds -- fast in-place reloads and templated/skinnable frontend. |
afaik, htmx was/is already being considered. (and, from what I can tell, is currently the preferred option) |
|
We've got a decent conversation regarding the 4.x, so I'd say we're close to finalizing the RFCs list. I'll try to refine this in the upcoming month, so we'll have a batter overview of what needs be done. Looking at my schedule, I think the roadmap is still quite up-to-date - the development phase will more likely start in Q3. |
|
So searching for an artifact didn't make it into the list? :( |
|
The RFCs list is not yet updated, but I can already say that some sort of artifact browser should be a part of 4.x :) |
|
As discussed on discord: adding the ability to have the metrics served on another port so you don't need to expose an authenticated endpoint but can just use a docker network to grab the data without auth and security risk |
|
Wanted to comment on OAuth/OIDC: |
|
Just noticed that configuration via environment variables (for docker/kubernetes) is not on the task list for v4 |
|
@Minecraftschurli Complex configuration via environment variables is not something that would work for us quite good - e.g. consider some predefined access tokens, there's no way we can include more advanced details like routes etc. I don't quite like the way Reposilite is configured right now, so it'll be definitely reworked from scratch. My rough idea on how it should work in 4.x:
|
|
everything that is set up through a ui should also be able to be preconfigured using parameters/env/configfiles so installation in cloud environments (docker/kubernetes) is easier |
About
Reposilite 3.x is a stable piece of software and for most of the time it serves you well. Of course, some decisions I made during 2.x -> 3.x rewrite were good, and some of them are a bit of a problem these days. I think that's a good time to start summing up the 3.x release line, so we can prepare for the next major version. Fortunately, this time we're more likely talking about an evolution, not a revolution - the backend module is much easier to maintain, Kotlin really paid off here. Sadly, I can't say it about frontend in JS + Vue 3.
Roadmap
Some high level estimation of a roadmap for Reposilite 4.x 💕
General goals
RFCs
Thanks to all sponsors that decided to support me this year! We wouldn't be here without you 💛
The text was updated successfully, but these errors were encountered: