Suggestion: Implement as a browser extension to avoid server costs

[Friedjof]

Hi, I find the project compelling. What about a browser extension? That way there would be no server costs, and perhaps we could just use the DB website as is.

[PalmarHealer]

Another Idea I had was that it could be deployed as GitHub site, witch is free and let the user make the API requests themself. This would also be cost effective

[Friedjof]

This is certainly an interesting idea; however, its centralized nature inherently carries greater risks. While it may be simpler than implementing an extension, such centralization makes it more visible, more dependent on a single point of control, and more vulnerable to attacks. In contrast, a decentralized extension would likely remain unnoticed, reduce reliance on a single system, and significantly minimize the potential "attack" surface.

[PalmarHealer]

I have never worked with browser extensions and don't know how they work. Are they uniform for all browsers, or would you have to make one for every browser? And what about mobile? As far as I know, only Firefox allows extensions for mobile to be loaded. Both have their pros and cons.

[Friedjof]

Yes, that’s true. Perhaps one does not necessarily exclude the other. I’ll see what I can get done today. For mobile, extensions are always a bit tricky. However, it is possible to develop extensions for both Firefox and Chrome, which should cover about 98% (excluding mobile), in my estimation.

[mariusangelmann]

I use db-vendo-client quite a bit, and the main headache is the rate limiting.
If this was a browser add-on, the requests could come from the user’s device instead of a central server, which would avoid that issue.

That said, most people are on mobile, and that’s where it gets tricky:

• Android → only Firefox (Gecko) really supports extensions.
• iOS → Orion supports them, but it’s experimental and pretty bad. That’s about it.

Given that, I’m not sure it’s worth the effort. Personally, I wouldn’t install an add-on unless I was using the train constantly.

[PalmarHealer]

I use db-vendo-client quite a bit, and the main headache is the rate limiting.
If this was a browser add-on, the requests could come from the user’s device instead of a central server, which would avoid that issue.

That said, most people are on mobile, and that’s where it gets tricky:

But what if it's a website and all the API requests are made via JavaScript, so the client executes them and not the server? This would solve the rate limit as well, or am I wrong? This would also eliminate any updating issues because no extension has to be updated for the user.

[mariusangelmann]

@PalmarHealer: But what if it's a website and all the API requests are made via JavaScript, so the client executes them and not the server? This would solve the rate limit as well, or am I wrong? This would also eliminate any updating issues because no extension has to be updated for the user.

I think the best direction is to stick with db-vendo-client as the foundation. Since it’s built against an unofficial API, things can change without warning, and having our own rewrite or separate logic would be fragile. By relying on db-vendo-client, we stay aligned with the latest request formats and avoid maintaining duplicate code whenever methods or endpoints shift.

At the same time, the actual calls should still be routed from the user’s client rather than through a centralized service. That way we remove any single point of failure, avoid rate-limit bottlenecks, and don’t need to constantly update or push changes on our side. What we’d need is essentially a thin proxy layer, something lightweight that passes requests through the user while still leveraging the logic in db-vendo-client. This would give us flexibility even if the internals of the library change, while keeping the integration simple.

In short, the proxy ensures the requests originate client-side, but all the heavy lifting stays in db-vendo-client. This way we get the benefits of resilience, simplicity, and maintainability, while also insulating ourselves against changes in the unofficial API.

[l2xu]

I would stick with db-vendo-client as well, since it’s the most robust free option available.
I like the idea of sending requests from each client to work around the rate-limiting bottleneck of db-vendo-client.

However, I think we might run into CORS issues when trying this in a normal browser or browser extension.

My idea would be to build a smartphone app with React Native or Flutter. This way, requests could be sent directly from the user’s device (which isn’t a “normal browser environment”), avoiding both the bottleneck and centralization, as well as some potential legal concerns—since each user would be responsible for their own requests.
On top of that, I believe many users would prefer a mobile app over a Chrome extension.

[kiliankoe]

FYI, I tried out the browser extension (FF only for the time being thanks to Chrome deprecating manifest v2) approach last week (waiting for this repo here to be open-sourced 😅) to see how feasible it is. You can check it out here: https://github.com/kiliankoe/bahn.deals

It uses the same endpoints as db-vendo-client but can't use it as a direct dependency because it runs in a browser context (or because of mv2 to be more precise). It technically works, but my opinion is that it's just not as discoverable and accessible for most users. I very much agree that most users would prefer a mobile app over this.

[felixschndr]

One thing that came to my mind (as a result of the new video of Lukas where he stated that a browser extension would not make much sense (see 1:12) is to have a browser extension and a self hosted server. The user could provide the URL of the server to the extension. This extension could then to the calling to the server, which checks for deals and the extension presents the findings. This would remove the need to get the link of the trip, open a new page and insert it there.
Since presenting data in the extension might be a hassle and duplicate work another idea might be that the extension just opens the URL of the server in a new tab with the share link of the trip already filled in. Moreover, this might even be possible without an extension but with a bookmark instead as they can execute JavaScript themselves.

[gelbphoenix]

One thing that came to my mind (as a result of the new video of Lukas where he stated that a browser extension would not make much sense (see 1:12) is to have a browser extension and a self hosted server. The user could provide the URL of the server to the extension. This extension could then to the calling to the server, which checks for deals and the extension presents the findings. This would remove the need to get the link of the trip, open a new page and insert it there. Since presenting data in the extension might be a hassle and duplicate work another idea might be that the extension just opens the URL of the server in a new tab with the share link of the trip already filled in. Moreover, this might even be possible without an extension but with a bookmark instead as they can execute JavaScript themselves.

This. That browser extension (wouldn't just only support Chromium but also Firefox/Gecko) could work like the extensions for password manager already do.

Yes a bookmarklet could also useful but more for people who know what they would execute in those.

[felixschndr]

Yes a bookmarklet could also useful but more for people who know what they would execute in those.

Yeah I was thinking about adding the exact command to the README, where only the URL would have to be substituted

[koeppel]

Another Idea I had was that it could be deployed as GitHub site, witch is free and let the user make the API requests themself. This would also be cost effective

I assume you mean GitHub pages with GitHub site? Deploying as a GitHub page doesn't work for this as the app is run as a server. GitHub pages does only support static html / javascript sites that are completely client sided.

Which is basically the same limitation for the browser extension.

I assume the only working alternative to the current approach is what @l2xu state - building a app based on flutter or something else.