IT Tools

Overview

A collective of tiny tools, that may, or may not be of used to developers and goobers around the world.

This project was created as a solution for a Software Design course project, for which the requirements are so:

• There are at least 10 sections of tools.
• Each section consists of at least 3 tools.
• There should be some image-related tools (optional).
• Split permission levels into users, premium users and administrators.
• Implement the system in one of three ways:
  • Worst: Adding/removing tools would require editing existing files and the recompilation of the entire system.
  • Medium: Adding/removing tools would only require recompiling the existing system without any edits.
  • Best: Adding/removing tools doesn’t require any recompiling of the existing system.

Tech Stack

Very classic NodeJS server-rendered application for the following reasons:

• Keep it super simple, full client-side interactivity.
• Free hot reload with how Express and EJS resolves files.
• Server-rendered has benefits for amazing SEO, while still having the full suite of the JavaScript Interactivity on the web like the old times.
• Each tool is completely independent from each other with no need for some hard-coded inheritance base, so a tool can use an image as an input or an output, completely up to them.
• Tools can easily be added and removed by adding or removing the associated entry in the database. If adding, a file with the same name must be provided in the tools path.

Screenshots

Reflection

Apparently the “idealized implementation” of these requirements is using .NET with some sort of “Plugin” as the base class. And all tools should derive from this “Plugin” class.

Even up to now, I am still not convinced this is the way for doing such this specific project. Even if they were trying to teach new structures, they should have designed a better project that actually fits Inheritance. Their idea of plugging in hot-reload is adding an arbitrary .dll file to the web interface, and the server would run that plugin using the base class. I can think of 1000 problems with this architecture:

• This is extremely unsafe. Instead of having a fully “open-sourced” version of the tool that you are fully aware of what is being added, you decide to use a closed, assembled version of the tool. How do you know the plugin isn’t tampered with?
• This may implement the “hot reload”, but is it really optimal? For my design, a simple git pull is enough to “hot reload” ALL TOOLS ALL AT ONCE. I don’t have to go through each .dll file to replace them.
• If you think about it, my approach is of a microservices-architecture. Each tool can be completely independent of each other. One breaking does not lead to others, which gives great resilience. While Plugin changing the public API would lead to EVERY SINGLE TOOL breaking.

While it may be the best way in an extremely secure enterprise application, it is extremely far-fetched and solves no real issues.