Change the repository name, folder/file names, comments, documentation, and database collections.

Currently, the Error 404 page is JSON which is not great for a web application. I think this can be improved by using this JSON page for API route errors, but the main error page, especially the shortID not found page should be HTML.

• Refactor the short link controller to make the code cleaner and more reusable.
• Switch document models to typegoose?
• Do I need to use indexes for MongoDB?
• Change some of the generic object types to more strongly typed references.
• Add users and authentication.
• Build a simple front end.
• Make front end responsive.
• Upload & update design documentation.
• Update project license.
• Update README.
• Add any needed comments for code clarity.
• Clean up extra comments and commented out code.
• Improve front end to be more responsive for Mobile.
• Add low security message
• Move more of the error messages into a config to make it configurable.
• Maybe set Defaults for properties like the name to untitled before sending the API response.
• Handle route without specified ID (Show error)

Instead of the image button with a callback, I would love to redo the login to use Googles official button. The should also be a clear way to log out.

After the changes in commit 5b443e2 to use the database indexes the links stopped sorting my most recently created in the dashboard. I think all I need to do is sort the results before sending them.

Update this property name throughout the code base because this would be more clear.

Make a system so that it can be restricted to only certain users creating an account. This would make it ideal for use as an internal link shortener that a company may want to deploy for their use only. This might mean adding support for local accounts, or locking the sign-ups to a specific email domain. Alternatively, this could involve an admin or approval system to verify new accounts first, or require that the admin makes the account.

Should I add multithreading to handle requests in parallel? To do this we will need to take advantage of worker threads in NodeJS. It will also need to manage the complexities of concurrent modifications issues with threads.

Resources:

• https://nodejs.org/api/worker_threads.html
• https://medium.com/@Trott/using-worker-threads-in-node-js-80494136dbb6
• https://tsh.io/blog/simple-guide-concurrency-node-js/
• https://blog.logrocket.com/node-js-multithreading-worker-threads-why-they-matter/
• https://www.google.com/search?q=nodejs+worker+threads&oq=nodejs+worker+thread
• https://www.google.com/search?q=concurrent+express+api&oq=concurrent+express+api

Add the option to use the application in a guest mode. In this mode the features would be restricted, here are some possible ideas:

• One time links only
• Expire quickly
• Account and links disappear after the short guest session.

To fix the production Demo I will want to add some features that allow me to better moderate and block bad actors trying to abuse the demo service.
The biggest thing would be adding checks on the destination links users use to ensure they are not malicious/harmful scams. This can be accomplished using either the the Google Safe Browsing API (Demo) or the Google Web Risk API to check these links against a known list. If users is found to be abusing the service with a harmful link there should be a way to configure the response behavior with multiple different options:

• Obviously ban the user
  • Ban Google account
  • Block IP address
  • Block device
  • Shadow ban
• Maybe even block known bad IPs beforehand
• Report User to Google
• Page for users to report malicious links for review.
• Link Managing (how to change the link)
  • Remove short link completely (blacklist the nickname)
  • Redirect to a specified safe page, this could be used to inform a victim that this link is a part of a scam.

In addition, I think it could be valuable to add ability to disable/block accounts with a message for the user. Maybe add additional tracking for stuff like click times. I could also block links to other link shorteners. Maybe we could make use of reCAPTCHA here as well. A more extreme approach maybe to make the demo more temporary when everything only lasts a short time before it gets removed, but this would be an additionally measure on top of the other security improvements above.

Another more extreme approach would be to put the demo in a demo mode with a feature flag that doesn't actually redirect to the URL, but simple displays a page saying the URL and that it won't actually redirect due to abuse. This demo mode could also offer several other restricting features like fast expiring links or one time use, IDK.

There seems like there might be a possible memory leak accruing on the front end. I assume it has something to do with the adding and removing of our shadow DOM components. Anyways, this is a slow leak, but ideally, this would be fixed...

What if there was an option to simplify the self hosting process. Instead of clients hosting the code base on their own servers, there could be a paid feature where we can host the application and simply make a subdomain to host a client specific version of the application. In this version all the links would be separate from the main link pool so different subdomains can share the same short ID. Then all the client would need to do is add some stuff to their DNS records on their chosen custom domain.

https://tanbt.medium.com/subdomain-web-server-implementation-with-node-js-431359574f7e

Currently the site is not built to be responsive for mobile devices. Some parts even seem to be broken and fail to load on the IOS Safari browser.

Have the front end be hosted as static on the express backend. With this also make sure to add a 404 page

Write an organized README and potentially other documents detailing information about the project:

• What is the project?
• What's the purpose of the project? Why was this project developed?
• What tools and concepts were used to develop this project?
• Skills and tools learned and developed along the way
• Document the components of the project
  • The API endpoints
• Describe how to install and use the application

I was thinking about whether it would make sense for the click counter to reset after specific properties like the shortID or the destination URL change. This is just something to think about.

Filter profanity for custom shortID's

Use secure HTTPS transfer for session cookies when application is in a production environment.
Tracking issue for: https://github.com/Navnedia/Link-Shortener/security/code-scanning/3

Apparently, bit.ly has a feature where you can add a + to the end of a shortened URL and it will launch a page that shows you where the link goes rather than actually launching it. I think it would be cool to add this feature for link peaking in the same way.

There could also be an endpoint /peek/{shortID} or /preview/{shortID}. If you don't supply a shortID in the url, then the page should give an input box to look up.

Additionally, there should be the same endpoints under /api/shortlink so you can get a JSON response.

Now that I've built out a frontend I feel like the error messages returned from the backend could be improved to make them more useful for displaying on the frontend. It would also be nice to make error handling more modular, reusable, and clean. It would be cool if we returned all the errors in the input rather than just the first error we find. After backend error messages are improved I would like to refactor the front end to use these messages more effectively for informing the user of issues.

Add accounts with the ability to sign in with google so access your own short links to manage them.

Restructure the database to allow for old shortID's to remain active after it's been manually changed.

• Add a QRCode endpoint.
• Add tags
• API access (Add API Token Support)
• Query sorting, limiting, and pagination
• Ordering items
• Search by name
• Favorite links
• Use limit (Dashboard deletion prompt when limit reached)
• Expiration time
• Password protected link
• Temporarily deactivate a link
• Maintain old shortID(s) after the change and allow them to continue redirecting (either with a duplicate entry, a different type of schema or with a new property on the schema)
• Max link limit per user
• Creation date
• Can't shorten it's own shortlinks
• Delete Confirmation by typing the name
• Prank link, redirects to. Fake location if the user is a specific IP address.
• Add guest mode
• Automatically fetch link page titles on the server side (maybe using a serverside fetch package)

Add a custom 404 page on the /{shortid} route when the page isn't found.

There is a huge issue with some of the regex expressions used to validate the inputs on the front and backend. I have experienced this infinite loop issue, particularly with the URL Validation regex when you enter many of the same characters. This bug may also apply to some of the other regex expressions.

Perhaps this could be fixed by switching to using some form of validation library, IDK.