Forem: Lina Jelinčić

How I switched from PHP to Node.js

Lina Jelinčić — Mon, 10 Jan 2022 14:00:57 +0000

I've been a PHP developer for a couple of years now and I love PHP. However, I believe that learning other programming languages can only make you a better developer. That is why I decided to tackle the fun new world of Node.js. (note: maybe not so new, but bear with me, I am a PHP developer after all)

After my first 'node.js for beginners courses' google search, I realized I'm missing some basics and that there is a lot that I'll have to tackle. There are millions of tutorials out there and it all can be a bit overwhelming when you're starting to learn something new.

I wanted this to be as simple as possible so I picked my favorite for each 'category'.

JavaScript

Node.js is a JavaScript runtime. If you don't know what runtime is at the moment, just ignore it for a while.

Node.js is JavaScript [insert something]. That means you'll have to learn JavaScript.

Learn JavaScript

This was a documentation that proved as the most useful to me. It covers the basics as well as some advanced concepts. I had a hard time switching to async and in my opinion this documentation explains it so that you can sufficiently understand how JavaScript utilizes asynchronous programming.

TypeScript

Use TypeScript. I won't even explain why, just use it. TypeScript is JavaScript with some added functionalities (like, you've guessed it, types).

Learn TypeScript

Official docs are concise and they should give you an idea what are the differences between using TypeScript to JavaScript. But like I said, it's actually JavaScript so while learning JavaScript you're also learning TypeScript.

Node.js

And finally, we are here :) Now you'll learn what is a runtime or V8 and what Node.js actually is.

Learn Node.js

These are official docs and they are great. While you can find a lot of free or paid courses on the internet I really think these docs should be more than enough to understand what can be done with Node.js.

Extra

Learn a Node.js framework! I've had the opportunity to work with Nest.js and I really liked it. Lots of people use Express.js so that is another possibility.

Learn Nest.js

Nest.js also has great official docs.

Keep in mind

While writing this article I realized most of my favorites are official docs. Maybe that is something we all should remember: taking courses is great, there are a bunch of helpful resources and people out there and we should take advantage of it. However, when learning something completely new, stick to the basics and RTFM.

If you are wondering what to do next, do something that excites you with your new set of skills! If you can't come up with an idea for a personal project, google 'project ideas for backend'. Find something that sounds interesting and happy coding :)

Background jobs with Symfony messenger component

Lina Jelinčić — Mon, 09 Aug 2021 11:47:50 +0000

Let’s say your client comes up with this request: whenever an image is uploaded, do something with it. Change background color, convert it to some other format, add watermark… Whatever it is, image processing is often a slow process that will add significant time to your ‘upload image’ action.   

Do it later

But, if you were to think about it, there is no reason why it should be executed during the request. The user doesn’t really care about that. He will upload the image, continue with his day and image processing will be done somewhere.. in the background.  

Flow of any background job looks like this: create job + store necessary data somewhere so it can be executed later + execute it  

Symfony messenger component, introduced in version 4.1, handles this for you!  

Create job

Think about the data necessary for job execution. In this case, we should remember some kind of identifier that will let us fetch the image later on. Depending on your requirements, it can be id of an entity stored in the database, path to the image or something else.

In the Message folder of your project, create a class that will encapsulate that data (and do nothing else).

namespace App\Message;

class SetBackgroundColorToBlack
{
    /**
     * @var string
     */
    private $imageIdentifier;

    public function __construct(string $imageIdentifier)
    {
        $this->imageIdentifier = $imageIdentifier;
    }

    public function getImageIdentifier(): string
    {
        return $this->imageIdentifier;
    }
}

Inject MessageBusInterface into a service that handles image uploading. After the image is uploaded, create your message and dispatch it.

 public function __construct(MessageBusInterface $messageBus)
    {
        $this->messageBus = $messageBus;
    }

 $message = new SetBackgroundColorToBlack($image->getIdentifier());
 $this->messageBus->dispatch($message);

Congrats! You've just told symfony... well, nothing much.

Where do all the messages go to?

You've created your message and dispatched it. What now? Store it somewhere so the class that knows how to handle it can pick it.

In this case, it's called transport. Symfony provides multiple transport options as well as retry strategies, so read the docs and decide what's best for your case. I used doctrine transport that won't be suitable for large projects.

Two transports are defined: async, that handles messages of SetBackgroundColorToBlack type and failure transport.

framework:
    messenger:
        failure_transport: failed
        transports:
            async:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
            failed:
                dsn: 'doctrine://default?queue_name=failed'

        routing:
            'App\Message\SetBackgroundColorToBlack': async

It's best to define your transports as env variables.

###> symfony/messenger ###
MESSENGER_TRANSPORT_DSN=doctrine://default
###< symfony/messenger ###

Do the job

Someone should do the job. In MessageHandler directory of your project, create class SetBackgroundColorToBlackHandler.

This class must implement MessageHandlerInterface.

class SetBackgroundColorToBlackHandler implements MessageHandlerInterface
{
    /**
     * @var ImageProcessingService
     */
    private $imageProcessingService;

    /**
     * @var ImageRepository
     */
    private $imageRepository;

    public function __construct(ImageProcessingService $imageProcessingService, 
ImageRepository $imageRepository)
    {
        $this->imageProcessingService = $imageProcessingService;
        $this->imageRepository = $imageRepository;
    }

    public function __invoke(SetBackgroundColorToBlack $setBackgroundColorToBlack): void
    {
        $image = $this->imageRepository
                 ->get($setBackgroundColorToBlack->getImageIdentifier());

        if ($image === null) {
            return;
        }

        $this->imageProcessingService->setBackgroundColorToBlack($image);

    }

Notes:

Symfony is smart enough to connect message to the handler. It's enough to type hint variable of __invoke() method signature in the handler class.
Handlers are services which means that you can inject other services.
Maybe the image can't be fetched because someone deleted it in the meantime. Depending on your domain, maybe the image must exist and you want to throw an exception in that case.
Maybe imageProcessingService throws exception (it probably does). Remember we defined failure transport? By default, all messages will be retried 3 times before they end up in failure transport.

Work, work, work, work, work

Define worker that is gonna consume those messages.
php bin/console messenger:consume async

Install supervisor on production that will watch out for your workers.

How do you like symfony messenger component? What do you use to handle background jobs? Do you think they are necessary in the first place?

You ain't gonna need it

Lina Jelinčić — Mon, 29 Mar 2021 11:42:06 +0000

I love coming back to a feature that was developed a couple of months ago and seeing that extending it is just a walk in a park. When thinking about a solution, I always ask myself the same question: If I were to change this in a month, how hard would it be?

I find it a great way to catch flaws in my solutions very early, but it can also lead to something called overengineering. To put it simple, overengineering is the act of solving a problem that doesn’t exist anywhere besides your mind.

Overengineering leads to bad code

It took me a long time to realize that even though my code is nice, clean and easy to extend, it is still a bad code. It often introduces unnecessary complexity, being harder to maintain and harder to understand by other devs, while taking a longer time to build.

None of it is a bad thing by itself. If you were to code just to get it done, you can get by, but in a month all you would get is messy, spaghetti code that nobody wants to work with in the future. It becomes a bad thing when that price is paid for a feature that you really don’t need.

Do you actually need it?

I’m still fighting this battle myself and the thing that is helping me is a principle of extreme programming (XP) called “You ain’t gonna need it” (or simply, YAGNI). XP co-founder Ron Jeffries has written: "Always implement things when you actually need them, never when you just foresee that you need them.”

Now, whenever I start overthinking and catch myself wondering “But what if X happens” I just stop and write down my what ifs. Also, I think about what would happen if that feature is not implemented. Is the added complexity the price I’m willing to pay just now?

Making that call is not easy

It is important to differ what is needed and what is not, even though it is difficult to do that. If that is a decision you are having problems with, ask your teammates. A fresh look at the problem is something that always helps. If for whatever reason that is not possible, go with a simpler solution. Keep the list of what ifs and if they actually happen, choose the more complex solution.

This approach helped me with decision making paralysis and I believe it also made me a better developer.

How about you? Do you also sometimes overengineer? What are your tips and tricks for deciding what is needed and what is not?