While this isn’t the most exciting thing to every hit the forums (IMHO), nor possibly the best use of Netlify as a platform, I thought I’d share with you a little project I’ve created (which stemmed from another.)
In essence, a URL shortener service for the JAMstack called FYDLI(get it!? because long URLs are fiddly!; bet I’m not the first to do it—yes, there is netlify-shortener.)
This came about (in part) as a way to test/utilise Scheduled Functions.
Tools
Node.js
Supabase
Netlify (functions, redirects)
HTML, CSS, JavaScript
How
A Node.js script pulls data from Supabase to create a _redirects file on deploy.
Between builds, a function acts as the fallback, redirecting valid short codes, returning 404 for invalid.
This is slower than desired currently because of the location of the database (AU) and the functions (US)—I’m not trying to put Bitly out of business though, so I can live with it!
More…
This is a no-sign-up thing, open a free to all. It is (by design) a simple system (I think.) I’ve added utilisation of Local Storage for a user ID to enable editing of links (with caveats.)
(I always wanted to make such a tool, but didn’t want to get a domain and using .netlify.app subdomain doesn’t really serve a purpose of “URL shortner” )
I hope you won’t mind a suggestion
This might have been done as a hobby-project, but if this does end up being popular, it might start hitting bottlenecks because of its current implementation. _redirects file, the larger it gets the slower the site becomes and furthermore at one point, your site might as well stop deploying. It would take time to get there (the file should be a few MB in size), but it’s definitely possible.
Instead, why don’t you carry out a redirect directly using a function? The primary benefit apart from covering the limitation explained above would be instant deploy - no need to wait for scheduled function to trigger. Let me know what you think.
Thanks @hrishikesh, I always welcome suggestions/feedback
A function does handles redirects until the _redirects file is rebuilt/deployed at the scheduled time. Was trying to cover all bases. I did have an inkling there was a limit on the file size of number of redirects.
The next possible issue is smashing through the function invocation limit (depending on a user’s plan) as they are used for creation, updating, and redirecting (although at 125k/month on the Starter Tier that is around 4,000 invocations a day!)
As for popularity, I wasn’t ever thinking this would become such. While I managed to find a catchy domain that lead to the project name, my intention was for it to act more as a demonstration of functionality. I figured people would then clone the repository and set up their own (possibly private) shortener.
I would hope that, that is the case, but at least in my case, if I was getting something for free that exactly suits my case, I’d simply use it rather than trying to build it. I go on the building path when I’m not perfectly happy with the current available solution (or if building something is out of my league ).
But considering that people would need a domain for this, I’d believe more people would rely on the existing solution.
I’ve published an update. It removes the original intention of the project (to utilise Scheduled Functions) by removing the build/re-build of the _redirects file. Largely this is because of the “disable link” functionality which requires a rebuild to remove it from the _redirects file. I was aware of this in the beginning but left it as this was intended purely as a working demonstration. However, as this may get publicly used (it is public after all) I switched methods. If this was functioning as a private shortener service I believe the original method is still viable.
)
).
