Install it using

$ pipenv install https://github.com/mattborghi/load-balancer-zmq#egg=LoadBalancer

Maybe is a better idea to create a separate repo first testing some functionalities.

Change from ZMQ implementation to RabbitMQ.

• Remove Proxy
• Migrate Ventilator
• Migrate Worker
• Migrate Sink

Also add their corresponding dependabot alert.

Decide if we deploy when we make a release.

The Julia task should use this package.

A way to implement it could be by parsing each line in a for loop and using that as a progress indicator

For React we can use the Bootstrap implementation or modify the ones provided by Material-UI.

It will be a good idea to start reading about scheduling.

And this thread.

• This can be solved maybe by automatic (re)launching of workers.

• Workers usage is based on workload.

• In case of worker failure, they are relaunched and the tasks resumed.

More info here

import uuid
from django.db import models

class MyUUIDModel(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    # other fields

Maybe we can make something like

./LOGS.prod.sh workers backend

and new tabs will be open for everyone of the arguments.

• Can I install packages?

• Run malicious code?

• etc

Right now we use the deployment scripts to deploy to heroku.

We can read this or maybe tell github to run our scripts.

If we installed a new package (or we updated something) we need to run

pipenv lock -r > requirements.txt

which will generate https://github.com/mattborghi/background-tasks-queue/blob/main/backend/requirements.txt

That's not the best idea. I think heroku detects the Python environment because of the Pipfiles, but we have to test it.

This is an interesting improvement not only to the app but to the production phase.

It would be interesting to see if the dyno workers from heroku support running more intensive functions and precompiling packages like DifferentialEquations.jl.

Being said that we can add a simple box (I could append a Monaco Editor or a lighter one) where we can type julia code.

Julia workers cant be connected yet. Opened issue here: JuliaComputing/AMQPClient.jl#37 (comment)

Use this component.

Follow up here: teambit/bit-with-github-actions#10

Check this for plans deploying RabbitMQ Server

It would be a good example that the placeholder says what kind of packages we can use and that has a simple example there

Inspect the behaviour to make the whole process more robust

• When we do a mutation we should fire a run to the servers and wait for the result from the Sink.

• When the result is obtained make an update of the results.

• Maybe we should add a new attribute that gives the status of thre result: QUEUEING, RUNNING, FAILED, FINISHED, etc.

Info here

Use Configparser for example as a guide

Wait for the official Julia Docker release.

More info docker-library/julia#51

Self descriptive

Given that DataGrid doesn't have an API as stable as MaterialTable, it should be wiser to move to the latter.

Railway seems a good alternative to Heroku.

We should migrate:

• Worker
• Sink
• Backend

Check this link for more information.