Any issues putting worker and service api in the same project/pod?

[abratv]

To put into context, we are using aspnet core for micro service like everybody else in kubernetes and we kinda of running out of memory within the cluster...
At this moment we have service api and worker running on its own pod even they are in the same "domain" by design.

I'm thinking to put the service api and worker running in same project, thus it will run in the same pod.
Any issues that I need to be aware of?

[gfoidl]

Can you illustrate a bit what the worker does? E.g. is it cpu-bound work or IO (like DB, other HTTP-calls), etc.
Given the info right now it's hard to give concrete advices or point out any potential issues that may arise.

[abratv]

in general the worker will

• retrieve value from message queue
• process the message queue (can be http call or db call)
• then put back value to message queue

i also see some sample use worker to initiate "async" connection

[gfoidl]

I'd start with the API + worker combined. It's easier to develop, deploy, etc. But monitor the things, and if API responses -- or what your measure is -- start taking too long, then split it.
Just keep in mind that everything should be async, so that no blocking of threads occur, as that would be a killer.

[abratv]

make sense, one more question if you don't mind

The worker (BackgroundService) have overrides over
StartAsync and ExecuteAsync

Connection to the queue and event handler that message received is registered in StartAsync
That leave ExecuteAsync doing nothing or i just put a heart beat logging within ExecuteAsync

public override async Task StartAsync(CancellationToken cancellationToken)
        {       
            _client.Connect("worker");

            _client.ListenAsyncMode<TMessage, TResult>(Queue, async (channel, eventArgs, parameter) =>
            {
                _logger.LogInformation("Got queue message");               

                return new TResult();        
            });
            await base.StartAsync(cancellationToken);
        }
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            while (!stoppingToken.IsCancellationRequested)
            {
                _logger.LogInformation("$Heatbeat worker running at: {time}", DateTimeOffset.Now);
                await Task.Delay(60000, stoppingToken);
            }
        }

Is this approach correct?

[gfoidl]

In StopAsync you could disconnect from the queue.
Otherwise it looks good.

For ExecuteAsync -- where basically nothing is to do here, as you also pointed out -- I'd use PeriodicTimer instead:

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    using PeriodicTimer ticker = new(TimeSpan.FromMinutes(1));
        
    while (await ticker.WaitForNextTickAsync(cancellationToken))
    {
        // Log, etc. ...
    }
}

This avoids the repeated allocation of the task in Task.Delay, thus puts less pressure on the GC. Well, here this shouldn't really matter as done only once a minute, but the code is as readable (at least), so that change is just for goodness.

Depending on the queue that you use, in ExecuteAsync you could check if still connected, otherwise re-connect, to be resilient.

[abratv]

Thank you!