Learning Is Worth It, Always

Live Demo: justremove

It may be a little late to try Typescript as the cool new thing in 2022, but I had never really thought that I needed to use it. I justified not using it like I always do, for anything new that I refuse to initially try, by saying that I didn’t really need it because I can already do it my way.

“My way” here being just vanilla JS.

I had the same approach when the frameworks came around.

I will not lie and say that any of these frameworks have that much of a value add. It is just a different way of doing things. It is just an opinion.

I, being a bit stubborn as I often am, just was not very accepting of other opinions in how I wrote code and how I did things.

But that is a recipe for conflict.

I don’t think that the value that React has, as it is extremely overused and hyped up by people who never even learnt to write JS, is anything to do with its technical details. Nor do I think that most frameworks have anything technically superior to offer in terms of web development.

The greatest value add that they have to offer is just an opinion, to some degree. If the CTO decides that we’re going to use Blazor, well, that’s fine. Now we know what to expect from each other’s code and know that we can take a look at it and service it.

Much better than the freedom of doing things however you want and switching it up halfway through a project so that you can never revisit the old codebase again without cringing and wanting to start all over.

That is specific, indeed. That is because I have done it all too many times myself and learnt the lesson the hard way.

Though, that is not to say that I didn’t finish any of those projects to some minimum target that I wanted to achieve with them. I also tried a different methodology each time thinking that I would avoid the problem of spaghettifying my entire codebase.

That being said, let’s get to what happened that prompted me to learn Typescript, try out webpack for myself, and componentise as much as I could in React.

I have a bunch of projects that I link on my site and on my resumé and any other places that I can. The problem with those projects were that they were not directionless. I wasn’t the judge, jury and executioner for the entirity of those projects. Most of those projects were guided by FreeCodeCamp or some other thing online.

I was challenged by an acquaintance online, after he reviewed my “portfolio” to come up with something more of my own and make an entire project with it myself, hit walls and learn stuff.

At the time, the challenge was limited to only frontend development, even though I insisted on doing a full stack project.

Now, that was the intention.

I was going to use Public APIs that allowed me to remove the background from images. Simple.

No backend, right?

I was simply gonna use TS, React and webpack to build a frontend project. I would have no API keys to worry about, just a URL to send a POST request to and that’s it, I would be done!

Of course, the story doesn’t end there.

What I very quickly discovered was that there really wasn’t any public API that would do this, and for good reason, naturally.

So, obviously, since I was targeting landing frontend development jobs with the completion of this project, I should have simply switched my target to something else, like the world’s trillionth crypto price web page.

But, being who I am, a simple question came up in my mind, how difficult could it be? I’ll just use the non-public and limited APIs that I found, build a simple backend that handled the rate limits with a mongoDB, and that’s it!

I am not shy to full stack projects at all. All by myself, no issues.

Well, no issues but time.

I already had the challenge of Typescript and Webpack ahead of me. Componentising React was no big deal since I had worked with pre-hooks React before.

Now I had to work with Typescript on the backend and also use Webpack with the server that I had going on.

I hadn’t worked with mongoose in a while, which I installed to make it easier and standard to work with MongoDB from Node so that took a while to get set up.

My biggest challenge came with making Webpack work with the server and frontend. I scoured through the entire Webpack documentation for, what I remember to be, an entire week.

I would configure my webpack config as I read the documentation, see what it did and every time there were things as I did not want them, I would have to look it up as I was also reading the documentation and trying things out.

Eventually, I learnt how it worked and had two separate configs going on, one for my server and one for my frontend.

After I was done, I felt like I didn’t really need to set up my server side things with webpack. Especially so because my directory structure had already been calcified in such a way that my server was just responsible for validation, data format conversion, DB calls and API calls.

Webpack was building my frontend in a publish directory that was served as a whole on a different domain altogether.

The reason that it came to be this way was because my entire experience with Node and Express was directly serving files and endpoints being handled by the same server. But the way to achieve this with webpack was complicated to say the least.

In essence, I had no absolute need to use webpack on my server.

Looking back, I could develop my server as I normally did prior to trying webpack in a completely different directory and just used webpack on my frontend.

Typescript on the backend was no big challenge. I also read the TS documentation for days but I found out that the TS community encouraged just jumping to use TS directly in the project after reading just a brief bit about it.

Honestly, that was a great decision. The TS docs felt quite redundant and more necessary for people that want to contribute to TS or for some really hyperspecific cases. I felt like someone who had worked with C# already would more want to read those for the differences in details there between some things that overlap conceptually between the two.

Either way, searching warning messages and errors online worked just fine.

Something that I haven’t mentioned to this point is that I never actually used autocompletion or language servers on my machine for any development. Even when I was experimenting with Go and writing C/C++ programs here and there, I never felt the need to use them.

My logic with that was that I didn’t want to become dependent on autocomplete for development. I know of many people that heavily advocate developing by autocomplete in Visual Studio Code. I use Neovim which doesn’t come with the ease of simply enabling and disabling extensions by using an inbuilt search engine and it takes a bit of research and configuration to get it working to the same level of ease.

So that was a huge time sink, but a really, really worthwhile timesink. I couldn’t have imagined how good modal editing would be with the autocomplete features and definition look up. I hadn’t even utilised and still haven’t been able to get around to being used to all the keyboard shortcuts that allow me to enhance my productivity even more.

That being said, the troubles with webpack were still around every once in a while. For example, the environment variables with the dotenv package weren’t really easily accessible from within the server. I couldn’t even make it an absolute path since I wanted to deploy it online using Render.

There were very, very little resources online in general for configuring webpack with a server. I discovered through some discussions that webpack’s documentation used to be pretty lackluster but that they had improved.

In my experience, the frontend (which is what it is mainly intended for) documentation part was as good as it could really be. My situation was probably my fault for trying to use webpack on the backend to begin with.

Another challenge came with one of the APIs that I used to send the image data to.

See, the first API, which has a limit of 50 image conversions per month, accepted a base64 string as the image data and returned a base64 string.

That was really simple to handle.

The second API wanted a file in a read stream per the stated example of how I was supposed to use it.

So I implemented a function which would temporarily store a file on the server and send it to the second API and delete that and then whatever it got back it would store and send to the frontend as a file and when that was done it would delete that too.

Everything was working, I implemented the URL fetching of image on the frontend, I implemented a dropzone so people could drag and drop images on the frontend and I was done.

Or was I?! Turns out, render did not give me disk access in the tier that I was in.

Now, that was a huge problem for me because I had tried to figure out how I can store a file in RAM, that were never going to be larger than 10 MiB, and create a read stream and send that in the body to the second API that wanted that.

Turns out, there was no real straightforward way of doing that. I wasted time in days trying to figure out how I can somehow fool it into thinking that I was sending a file.

I was so fixated on the file aspect of it due to the stated example that I forgot the essence of how it must have operated on its own backend.

It was simple, I just sent a buffer from the base64 string that I was already getting, into the attached form data and boom! It was that simple.

Finally, the deployment wasn’t all that difficult. Render was excellent for what I wanted to achieve and I chose them because Heroku ended their free tiers.

All in all, I got to learn so much just by configuring webpack, TS, react issues that came with working with tandem of TS, etc. that I cannot look back in regret over it.

I am armed better than I was before and looking back, I would take the conventional route of sticking together more libraries on the frontend and backend to handle many of the things that I implemented from scratch.

One such thing deserves mention, filepond. I created my own inputs for files and URLs and drag and drop functionality but that was all redundant because filepond apparently does it all. Hindsight is 20/20.

That’s it. Bit of a journal here but I felt like I needed to get it out of my system.

My next project, I am taking on learning React Hooks by insisting on exclusively doing things with React Hooks on the frontend and it is going to utilise a public API that I hopefully do not need to make another server for.

Cheers!