-
Notifications
You must be signed in to change notification settings - Fork 27
Description
Is your feature request related to a problem? Please describe.
The 2025 survey indicates that about 80% of PeeringDB respondents rely on our website instead of the API. API users can benefit from a local cache, like the one provided by peeringdb-py. Web users don't have this option.
We always try to keep API and web feature equivalent. We should extend peeringdb-py, so that users can quickly and easily set it up to include a local web interface that can handle queries in the same way www.peeringdb.com does.
Who is affected by the problem?
PeeringDB users.
What is the impact?
Letting users query peeringdb-py in a web browser will make it a viable alternative to www.peeringdb.com and give users the fastest possible level of service as their queries will stay local.
Are there security concerns?
No.
Are there privacy concerns?
No.
Describe the solution you'd like
- During installation, the user should be asked if they want to install a web interface.
- The installed software should remind them to update the web interface after each production release to www.peeringdb.com. This should be a simple one click task.
- The installed software should remind them to manually sync the local cache with www.peeringdb.com on a regular schedule if they don't have the automatic sync enabled in the configuration. For instance, show an interstitial letting them know the time since the last sync and presenting them with a "sync now" button to press.
- There should be a prominent link to documentation for HOWTO run PeeringDB locally in the website header, so users know about this feature.
It is probably not necessary to include support for managing updates. If including that support is simple, authenticated by a user API Key, then it would be nice to have.
Do you think this feature will require a formal design?
Probably.
Describe alternatives you've considered
This approach ensures that peeringdb-py users will always have a reliable service with current data.
We are thinking about other approcahes for improving the reliability of www.peeringdb.com and these include:
- Running www.peeringdb.com from multiple locations in any anycast fashion. This would mean that even if the nearest instance is not available, another instance would be able to provide service.
- Provide authenticated web users a dedicated instance, with anonymous queries handled separately.
- Engage a 24/7 NOC service.
These approaches aren't mutually exclusive. all should be considered.
Could this feature request need support from the Admin Committee?
It should not.
Deployment approach
Ideally, do this in a single release.
What is the proposed priority?
To be decided by the @peeringdb/pc
Provide a rationale for any/all of the above
We have recently had some service reliability issues. These had most impact on web users and least impact on peeringdb-py users. Their cache might have been more than an hour old but that would have been the full extent of the impact. Encouraging the most regular users to use peeringdb-py is only possible if they can use it in the way they want and we think that most users access PeeringDB through a web browser.
Additional context
We should consider likely corporate IT policies for installing and running software. It should be possible to run from a container on a physical server, on a cloud platform, and on a local machine, whether it runs Linux, macOS, or Windows.