2025 Week 14
This week, I started one of the project I've been looking forward to - something like bolt.new but focused on Laravel / PHP. I've been mustering over this for a while as I considered it as something around the radars of PHPSandbox.
All these while, I've been removing the barriers to doing this using PHPSandbox one after the other. For example, PHPSandbox now has an SDK that can be used to programmatically create and control all the aspects of a notebook. This makes it easier to build other things on top of PHPSandbox.
While the SDK part was one, finding motivation to actually start is the other half. Anytime I look at all that needs to be done, I don't usually have the energy to at least have the ball rolling. But this time, I had some help - LLMs. I figured, that, maybe I can offload this early process of scratching out what needs to be done to something like Cursor.
This worked very well as expected and now I have done more regarding this idea than before. To me this is one of the reasons I find LLMs useful - the potential for it to get you unblocked and start something.
So, I've spent a good part of the weekend prompting and also just being patient to see where this will lead to. I'm sure there's ore I'll be able to share later on how this goes, but I'm pretty optimistic that I'm closer than ever to making this idea a reality.
For a long time, PHPSandbox has been using WebSockets to deliver most of it's features. One aspect haven't really took seriously is the use of Binary Serialization for WebSocket message exchange between the server and the client.
There are a couple of benefits I personally think PHPSandbox will get from it, one is lesser message sizes, hence, faster delivery. Another is to unlock possibilities of other features like file upload and download through the WebSocket server.
I didn't bother to look deeper into how we can have this implemented since these benefit doesn't look like something we immediately need. This week, a customer raised an issue around upload where images uploaded are not being displayed correctly when previewed.
At first, I was surprised that the customer was able to upload because this is not a feature we directly provide. Somehow, they figured out that since we are using the VSCode explorer on the editor UI, they thought a drag and drop would be a thing and it worked - the image was uploaded as expected but doesn't display as expected.
The problem is that an image is a binary file and not the usual UTF8 encoded text files. When we send message back and forth the WebSocket, they are delivered as JSON. Since all file operations happened through the WebSocket, JSON encoding the binary file would cause the original file content to be modified as the final JSON text will be a Unicode text.
So, by the time we get the content of the file in the backend and put it on disk, it is already corrupted. Thanks to this customer I can another look at this problem and the first thing I did was to look at what others are doing. I had initially handled cases like this with Base64 encoding but this will heavily increase the size of the JSON payload. So, at this point I know I needed a better solution.
So in my research I encountered MessagePack, a binary serialization format that supports JSON and supports both PHP and JavaScript. This was the final nail in the coffin for the problem. All I had to do was to use both the PHP and JavaScript libraries I found to pack the data to JSON (including binary content) when sending and also unpack in to native data types in the respective languages when receiving the messages.
My favorite part is where encountering a new problem forces me to look deeper into an existing. challenge that was ignored making room for a little innovation. Now I think the WebSocket is even now better equipped for better features because I wanted to solve a customer problem.
Till next time, Bosun