DEV Community: Sami supreme

SSE (service side events) example to update a table

Sami supreme — Wed, 29 Jan 2025 17:31:42 +0000

If you need to make constant calls to server to fetch data (ie. for SPA app), instead of making the call over and over again you can implement Server Side Socket.

Server side socket is a listener/route/endpoint on server (ie php/laravel app) that runs a while loop constantly querying DB and returning the info in JSON.

Once you implement this you can make a call from frontend to the backend.

This call creates CONSTANT socket/steam connection to backend endpoint. ie. backend.com/file-status

This frontend is contantly listening for an update from backend.

When update comes from backend, the frontend stream code echoes it.

Useful when there’s other services/code/crons that might be populating the backend, so whenever backend updates, the data is returned.

This is opposite of a normal http connection where FRONTEND doesn’t even know that backend data has been updated until is explicitly make the request!

public function filesStatus($clientId) {
    $resp = new StreamedResponse();
    $resp->setCallback(function() use($clientId){
        while(true) { // Keep connection alive
            $data = ClientLink::where('client_id', $clientId)->get();
            echo "data: " . json_encode($data) . "\n\n"; // Required format
            ob_flush();
            flush();
            sleep(2);
        }
    });

    $resp->headers->set('Content-Type', 'text/event-stream'); // Must have to start Server event
    $resp->headers->set('X-Accel-Buffering', 'no');
    $resp->headers->set('Cach-Control', 'no-cache');
    $resp->send();
}

Then on frontend we create and Stream connection (as soon as backend return data, stream echoes it on page):

var clientId = document.getElementById('client_id').value;
    var evtSource = new EventSource("/files-status/"+clientId, {withCredentials: true});
    evtSource.onmessage = function (e) {
        let d = JSON.parse(e.data);
        const tb = document.querySelector('#files tbody');
        tb.innerHTML = '';

        d.forEach(function(item){
            var data = `<tr>
                <td><a href="${item.link}" target="_blank"> ${item.link}</a></td>
                <td>${item.download_status}</td>
                <td>${item.upload_status}</td>
                <td>${item.filename}</td>
                <td>${item.last_download}</td>
                <td>${item.last_upload}</td>
                <td>${item.last_download_file_hash}</td>
                <td>${item.last_upload_file_hash}</td>

                <td>
                    <form method="POST" action="/re-download/${item.id}">
                        {{ csrf_field() }}
                        <button type="submit">Download</button>
                    </form>
                </td>

                <td>
                    <form method="POST" action="/upload/${item.id}">
                        {{ csrf_field() }}
                        <button type="submit">Upload</button>
                    </form>
                </td>

                <td>
                    <form method="POST" action="/delete-link/${item.id}">
                        {{ csrf_field() }}
                        <button type="submit">Delete</button>
                    </form>
                </td>
            </tr>`;

            tb.innerHTML += data;
        });
    };

Why I don’t buy into “Self explanatory code”

Sami supreme — Fri, 15 Sep 2023 18:58:34 +0000

I think most people would be blown away once they see how heavily complex codebases are commented.

I don’t buy into “Your code should be self explanatory” and the reasoning for that is once we start adding business insights into codebase, it loses half its meaning.

The code can’t talk back to us and tell why certain things are behaving in certain way. No matter how “clean” we keep it. We can’t always add meaning to it.

So for me, “WHY” something was done in certain way is absolutely critical before I can add any new features or refactor it.

I know “WHAT” I need to do if requirements are clear but from what I’ve seen most codebases rarely answers “WHY” unless someone has been kind enough to leave comments.

What I’ve also seen is as the code becomes more and more complex, the developers who maintain it tend to add as many comment as possible, not for future developers but for themselves (tests are not a replacement for comments, sorry!).

I guess it goes to show that even people who regularly maintain it need additional comments to make sense of their own code as the complexity grows.

I don’t think a function, class name, variable, how things are connected can ever give you a full picture.

For context I’m working on an invoice management software and there’s no way it would’ve continued making sense without meaningful comments.

Even though the “code” itself is quite clean the insights/comments and tests have become essential for proper development.

Maybe this problem is specific to certain type of software!

5 methods I personally use to fix bugs

Sami supreme — Tue, 01 Aug 2023 17:26:44 +0000

BUGS & more bugs in your code!

Bugs will happen whether you like it or not.

But it pays off to know the type of bugs they are.

External bug in an API/service your system relies on?

A syntax bug?

A logical bug?

A bug caused by server itself?

The list goes on. But that’s really the first step. You must know the type of bug you’re dealing with!

That out the picture here’s 5 methods I use personally:

1. Dig deeper into system’s architecture.

Pretty simple but without having broad understanding of the system you’ll struggle to find or fix the bug in a reasonable way. There’s a time when you should narrow down vs think broadly.

Do both, you can think in details but you can’t think broadly without understanding the system. Thinking broadly means you’re less likely to break other parts of the system.

2. Clear mental model of the bug/issue

When issues are reported they don’t have all the information from the beginning. Often, they’re written badly. It’s your job to understand the problem fully, line by line and create a solid mental model of the problem. This is better than having to visit the issue 20 times in 30 mins because you keep forgetting the details.

Simply put, you need your own version of the issue/bug. How you understand it, not how someone else is framing it. Onto next step…

3. Take a walk but know where your goal really is.

The step #2 is very important. Simply going for a walk doesn’t magically solve problems. You have to know the goal and every single detail about the bug.

Once it’s in your head you’re free to go for a walk or make yourself a coffee. With everything absorbed in your brain, let it solve the bug in more relaxed way. Chill down now.

4. Time does the trick

Very easy to get frustrated but ultimately being patient pays off, if you put in enough time to resolve a bug, you’ll likely succeed. Every developer knows this! If not today, tomorrow!

5. Code isolation

If your code is tightly coupled, you won’t be able to focus on portions of it. If you can isolate class/function from rest of the code, you’ll resolve the issue more easily. This works because instead of thinking about 50 different files you’re focused on 2-3 files.

It’s easier said than done. Writing classes in a way where it accepts other objects as dependency help a lot.

Check out my books 🙂

What do employers look for in candidate when hiring?

Sami supreme — Fri, 12 May 2023 22:01:20 +0000

Most employers that I’ve spoken say following:

People with most experience are generally the favorites. Capability is the key.

So if you have worked on complex projects over the years and dug into the details, fixed the bugs, refactored the code, made changes on regular basis, wrote unit tests, added new features then you have gained the experience and made yourself capable.

Note how I didn’t say anything about how you did that, as long as you did it.

Experience can be gained by working for yourself as long as it matches the work you’d be doing if you were working for a company.

The tricky part is finding what to work on.

Do this: Pick a project that’ll take atleast 3-4 months to complete.

This is the trick.

(If you’re beginner then you’re better off working your way through basics. Couple months in you will have to pick a project aswell)

Big projects will give you real experience.

REAL EXPERIENCE!

Download source code of an existing project written in language of your choice and make it work locally.

Make a list of features project has.

Understand each feature. Each functionality, add details to each step and create Jira ticket.

Once you’ve got the tickets ready you’re ready to build an exact same project yourself.

That’s the secret. Yup.

That’s the way to fill your CV with lots of experience.

You’ll also be able to talk about it because you actually built it all. No gimmicks.

This will teach you exactly what real life experience teaches.

This will also teach you to take accountability for your code.

Lastly you’ll learn to work on things that you don’t understand, exactly like in a real job.

If you get stuck, look at the source code, the downloaded source code will act as a Senior Dev ready to guide you, if that’s not enough use ChatGPT to explain the code.

Best of luck!