Long launch time

[aminlatifi]

Impact-graph service launch time is too long, about 5 minutes if I am not mistaken. This causes long service downtime on each restart that is necessary after each update or configuration change. Mohammad says it's mostly because of the running of the database migration process at the beginning.

query: SELECT * FROM current_schema()
query: SELECT * FROM "information_schema"."tables" WHERE "table_schema" = 'public' AND "table_name" = 'migrations'
query: SELECT * FROM "migrations" "migrations" ORDER BY "id" DESC

Three potential solutions for this problem are:

1. @mohammadranjbarz Thinks it's because the database migration files are in TypeScript format and we don't run transpiled javascript files. So we need to investigate how we can transpile them and how much it reduces the database migration time.
2. Make running the database migration optional (config in configuration). We must find a way to make migration run mandatory when a new version is deployed by CI/CD
3. Keep track of run migration in a local file to make the start time lower.

[aminlatifi]

@CarlosQ96 @mohammadranjbarz What do you think? Do you have any better idea?

[mohammadranjbarz]

@CarlosQ96 @mohammadranjbarz What do you think? Do you have any better idea?

I agree, we can jump on this after finishing notification-center stuff

[CarlosQ96]

One absolute way that we can improve this, that I have seen on other frameworks and deployments is:

1. Is that we can have a testing persistent database hosted somewhere like our main db!!!

   and avoid rebuilding it from cero always and re-migrating it. The only initial step is to delete data before running the test suit (and when it finish running). Ruby on rails deployments I did before on amazon did this.

This way we don't need any local file to keep track the migrations because the db does that for us, and each time we do run the script to execute migrations he knows which he hasn't ran yet, and skips this step.

Side note to speed up testing locally:

We can also apply the same logic locally and have a db for tests always ready. Ruby on rails framework does this by default, it created a development and a test local db.

After notification center, let's do this!!!

What do you think @aminlatifi @mohammadranjbarz ???

[CarlosQ96]

I also agree we should compile migrations to js.

But in my opinion, the performance boost won't be huge, the overhead is mostly in the execution of database commands + latency that take time.

So I think a hosted test database will allow keeping track of migrations and skip them all if no new migration. Instant big performance boost.

[aminlatifi]

@CarlosQ96 It's not about testing run duration, the main server spends lots of time on running/checking migrations on every restart.

[CarlosQ96]

Ah my bad, I was thinking about the deployment steps. So speeding up the testing phase for faster deploy.

I'll investigate on this issue on the main server. (aside from compiling migrations to js)

[divine-comedian]

@aminlatifi - Is this issue still relevant? Should it be added to the tech debts?

[aminlatifi]

@aminlatifi - Is this issue still relevant? Should it be added to the tech debts?

@jainkrati