A Passion for Recreating Storage Buckets

I always hear people say: “Reinventing the wheel is a bad, really bad idea” But the truth is, reinventing has grown me up as an engineer, taught me engineering in the first place, and more importantly, helped me love engineering again in tough times. It was a priceless gift that I forgot along the way, and got back when I decided to reinvent some wheels. After wrestling with Bluetooth and a JPEG algorithm, I decided to dive deep into modern storage buckets, and that’s what I’ve been doing for the last 4 months: A storage bucket for the 21st century: StorageBowl, sounds cool right? I thought sharing a vision for a modern way of handling media could be useful to anyone, whether one uses the thing I built or not. So, it would be a sin not to write about it.

Before we start, this is the only promotion you’ll see here: StorageBowl is open and gives up to 100GB of free storage away for a lifetime. The number of people we gave storage became way more than I could even dream of, even before I finished writing this blog. We gifted almost a terabyte of free space! So I’ll have to close this system soon. Get your free storage, or see how much storage we gifted to people at https://storagebowl.com!

What’s Wrong With Storage Buckets

Actually, nothing! Modern storage buckets are capable enough to let you implement any feature you want. However, the problem itself lies in the process of implementation. The problematic nature of maintaining an upload functionality is that it’s easy to cut corners in the beginning, but becomes rough to keep it functional as you scale and gain real users. The evidence of this is that every team I’ve worked in has gone through the same cycle of iterations as the application scaled up:

• Let’s implement a basic upload functionality!
• Users start requesting some basic features like cropping and focusing only on a part of their pictures.
  • Nudge the designer.
  • Backend starts implementing the functionality using a JavaScript library, not without digging a grave for performance.
  • Frontend brings these features to life using these designs and endpoints.
• Product manager asks why our homepage takes a whole goddamn 15 secs to load. You decide to implement a placeholder mechanism and run it on the images people already uploaded. A few workweeks later, you’re good to go!
• Boss says he’ll fire you if you can’t fix the 8k storage bill. You know he’s serious this time after some guy convinced him to switch from good old servers to edge functions, costing 15k+ bill. You write an image optimization function in Rust because turns out JavaScript wasn’t a good choice for image processing. But this led to a salary increase for genius Tom, since he is the only one with Rust experience.

This process is a loop that introduces many problems:

• Each iteration cycle blocks multiple teams (backend, UI/UX, etc.) simultaneously.
• It becomes a burden to maintain some parts of your code, think about what happens when Tom leaves the company.
• Uploading is not a one-step process. Over time, you notice that it is only a step of this pipeline:
  • Upload: Implement helper tools, and reimplement them for mobile again.
  • Store: Create optimization middlewares for best performance and lowest cost, check for malware, and check for prohibited content.
  • Send back: Create placeholder images, stream video and audio if necessary, protect your media from unauthorized access, and make sure the optimizations are enough so your app loads fast.

The only solution to this endless loop of improvement cycles is having a team that predicts future needs, and one that never cuts corners. This is impossible, or at least too hard in a world where human beings are neither perfect nor seek perfection at work, since in many places unfortunately finishing a feature seemingly fast and coming back many times makes people received as smarter than finishing it once and for good. The only way to fix this humane flaw is to agree with Andrew Kelley: Make the lazy way the right way, so we programmers will do it correctly on the first try.

How Did I Fix It?

So, this is the vision for StorageBowl: Making the lazy way the right way. The only solution to provide a lazy way that fixes uploading flaws is making the product itself focused on uploading solutions itself! This way, cutting corners would mean under-delivering to customers, which makes it unacceptable instantly.

So let’s talk about the three pillars of my vision for easy and flawless file storage:

1. Toggle a Switch Instead of Week-Long Huddles

I know, this smacks too much of copywriting. But it’s the only way to describe it. Instead of creating configuration files, StorageBowl provides a simple interface where you choose the features you want to enable. This way, you can implement any feature without writing a dime of code. If you enable streaming, then your video component will get your video as a stream, simple, isn’t it? This is the modern way of storage, and it’s a philosophical difference from any other storage provider that enables scaling and adding new features to StorageBowl, without anything new to learn, just toggle!

2. Folders are All You Need

A folder, that’s right. Just like you don’t put a PDF file in your travel photos folder, in your app you don’t put an audio in your profile-photos folder. So in every storage bucket, folder structure is the main tool for organization. It was nothing more than a naming tool before, but in StorageBowl you organize your whole media requirements only using folders. Think about the profile-photo example. You want it to:

• Accept only common image formats.
• Optimize and compress the image down for 32x32 size, if that’s the max size you specified for your avatar component.
• Enable placeholder images, you can even choose between showing a blurred version of the whole image or just a predefined image for your avatars!

You achieve these needs when you create the folder: Click create and choose your whips.

One important thing to notice is that when the product itself becomes the solution to this single task, it becomes flexible like a Lego brick. For example: At some point, if you change your mind and decide to use blurry images instead of a pre-defined one, you’d need to go through all of your files to create blurry hashes. But with StorageBowl, it’s just a toggle! The same thing is valid for each use case. You don’t need to write any more code if you change your mind at some point. This is the flexibility we aimed for when we decided to fix this problem.

3. A Powerful, Doughy Foundation

StorageBowl uses the most flexible structure possible, and that’s the main pillarstone of the project. I call it the Doughy Foundation. This means:

• You can integrate StorageBowl to any backend with any language out there. It’s designed in a way that’s so flexible that even building tools for different languages to help you build applications took minimal effort.
• Components are designed in a Shadcn-like fashion, meaning you have your components as if you’ve written them. This not only makes customization possible but makes it as if you had written it down to every pixel already.
• The tools are developed in a way to understand the tech stack you use for your projects. e.g. If you use React with Tailwind, you’ll automatically have components that are adapted for them. If you use plain CSS, you don’t have to follow any more steps, when you install a component it’ll automatically detect this and be installed accordingly.
• This flexibility made multi-platform support possible. Besides, you can adapt it to any backend language and framework you might use, StorageBowl currently supports React & React Native with Vite, NextJS, and Expo; and I’m extending its reach to even Flutter! I’ll continue to extend it even further to be usable with any technology you can imagine soon. This makes writing a full-fledged family of applications possible, using the same technology for any platform and device.

These were the three most important topics I wanted to improve for developers, and I hope to continue doing a meaningful job for people who like the process of building just for the sake of creation.

Conclusion

At the end of the day, creating StorageBowl was a huge fun and it’s becoming a success as we can see the number of free storage we’ve given/are still giving is beyond my best guesses!

I must say that building the things you’re passionate about is important, and reinventing the wheel is so much fun! If you love the building part of programming, please don’t deprive yourself of it like I did for quite some time. Trust me, my friend, it gets depressing as hell. Starting this project was an escape from many things to me, and it felt like the water of life. I hope you find your passion. And of course, if your passion requires a storage option, Better Call Bowl!