cellivar / netgolynx Goto Github PK

Just make it use clipboard.writeText() already. https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/writeText#Browser_compatibility

go/link is not a valid link as most things understand them, such as Slack or Confluence or Jira. Building an extension for everything so they all natively understand them sounds like an unpleasant feature request.

Instead, a browser extension could insert links into any webpage where it finds a go/link. Something like this: https://stackoverflow.com/questions/11696661/chrome-extension-making-a-link-from-key-words-in-the-body

Links ultimately end up as extremely read heavy operations, they're generated once and can be served many more times than they will be modified. They're an excellent target for heavy long-lived caching with distributed caches such as Redis.

Currently there is an in-memory cache that will temporarily cache entries for a set amount of time before purging. This mostly only helps with rapid repeat queries and only helps individual instances. If a cluster of instances are running as HA round-robin style the benefits of the in-memory cache go way down.

Add support for an external caching service that will automatically disable the in-memory cache in favor of the external distributed cache. For a first implementation go for Redis support since it seems to be both pretty easy as well as pretty popular.

The specific detail to implement here would be support for cache updates on deletes and re-creates. Because 'editing' a golink isn't a relevant concept at the moment we can simply forcibly delete the cache entry for a link when we delete it out of the database.

To discourage use as a cheap and hacky internal DNS service add in some rate limiting so that people don't try to use it in an automated fashion.

That'd be cool right?

Right now there's no insight into what the system is doing or how healthy it is. This makes monitoring, uh, difficult.

Investigate various ways of exposing metrics (safely!) that would be useful for monitoring and observation.

Consider how SLO's work according to SRE practices and make it easy to expose those metrics specifically.

Apparently exposing Prometheus formatted JSON is the way to go these days and is relatively easy to do. Add a meta endpoint under the underscore URL for /healthz and /metricz, and while we're at it why not add a /readyz endpoint to indicate that it's up, running, has a db connection, and is good to go.

Introduce a feature for URL templates. This is akin to URL rewrite modules.

Currently the format of a link is go/, which is a static redirect to a specific URL.

Modify this format to allow for go//, which will then take the and inject it into the URL in the appropriate location.

Example:
go/jira/JIRAID
redirects to
https://jira.somecompany.com/browse/{JIRAID}

Navigating the browser to http://go/jira/JIRA-53 would redirect to https://jira.somecompany.com/browse/JIRA-53

This is obviously a hilarious phishing opportunity which drives home the idea that this should be run only internally.

There are apparently situations where accessing the underlying SQLite database file is non-trivial for backup purposes. Add an ability for admin accounts to perform a SQLite database dump via the web interface so they can perform backups.

It seems prudent to have accounts which can view all links in the system.

The links page assumes people are using the DNS trick to get go/ working. Make it configurable instead of hardcoded.

Link lists can get quite long. Paginating them would be good.

Dropping go/thing into a slack conversation and having it either rewrite it to a link or just have a bot chime in with the link would be nice.

Add a chrome extension that is published out of this repository to the Chrome web store in an automated fashion. There are GitHub Actions available for just such an occasion: https://github.com/marketplace/actions/chrome-extension-upload-publish

It would be quite nice if viewers could sort the list of links on the list page.

If a user no longer wishes to own a link the only way to relinquish that ownership is to delete it. Provide a mechanism to transfer the link to another account.

Currently NetGoLynx will only use a built-in SQLite database file mapped to the local filesystem somewhere.

Make the database layer agnostic and able to support remote DB endpoints, especially PostgreSQL as that appears to be the db du juor. MySQL is a nice bonus. Realistically anything that supports the same SQL subset should be sufficient for storage.

Make sure that performance won't be harmed much by adding a remote DB. It's likely in live deployments that it'll not be as fast on first pull but once it's cached it should be quicker.

List out fuzzy matches if a link isn't known.

Do the thing!

The OmniBar allows extensions to add their own search provider. Add this ability to the Chrome extension.

Add ability to redirect go/lynx to the configured server in the browser extension.

A number of people have mentioned Okta support would be cool (and probably easier than getting GSuite/Google auth working).