Sails: SailsJS starts up *way* too slow

[dbkaplun]

When I restart sails lift and refresh the page in my browser, I get 404s for all of my static assets. That means they were deleted. That needs to not happen. Instead sails should use rsync-like behavior to synchronize only changed assets.

[sgress454]

This tends to only be an issue if you're saving large uploaded files to your assets folder (not recommended), but in any case you are free to fool around with the Grunt tasks as you like, perhaps by replacing the copy:dev task in tasks/register/compileAssets.js with sync:dev (which is what is used to sync assets while your app is lifted).

[dbkaplun]

Since this is tagged needs complete example, see https://github.com/secrettriangle/nodegolf.

@sgress454 this is not the case in the project I'm working on. I don't have many files in my assets folder. The biggest thing is probably a symlink to ../node_modules. Maybe we should change this ticket/file a new ticket for respecting symlinks in assets?

[brandtheisey]

By any chance if you up the logging level, can you see where the pause occurs during the lift? We had a similar slowness for a while and the culprit was migrate: alter and the blob storage of our uploaded files (avatar images, pictures and documents). The behavior we saw was a long pause/freeze at the loading ORM stage. This was due to the migrate: alter converting our blob data to json encoded binary every time we lifted. Anything stored that way was unusable after any given lift.

[dbkaplun]

The sails lift is not the slow part. It lifts almost instantly. (Though I have had problems with migrate: alter in the past.) The problem is that fetching assets on a lifted server returns 404s for almost 5 minutes until they're copied to .tmp.

[richdunajewski]

Not to dig up an old issue, but I think there's still an issue here (feel free to point me to an existing issue, I couldn't find one).

It looks like when we do a sails lift grunt is kicked off to start running the pipeline tasks. However, to me, it looks like grunt is either spawning off in its own thread or it's running asynchronously from the rest of sails. If you rely on a lot of assets, grunt may still be busy running tasks by the time a client makes a successful request against the server. In that case, the page loads but some or all of the assets that grunt is building/copying will return 404s. Usually if you refresh the page again the files will be in .tmp/public in time, and everything is good. It's kind of nasty, though, because I'd prefer to wait for the grunt tasks to complete before allowing the server to listen.

I get this quite consistently, using bootstrap and a handful of other libraries. It's more of a nuisance in development where sails may be restarted often, and my client-side code redirects the user to the login page but some or all of the assets are missing, and the page has no styling, for example. When QA gets a hold of the code and starts putting it through its paces, this is flagged as being a defect.

I'd love to see a way to block the lift until the build tasks complete, but rather than change default behavior I'd like to see this as a configuration option if possible.

For now, I'm just going to muck around with the grunt tasks to mitigate the race condition, but there has to be another way.

[fernandolguevara]

+1
regrettably this is still happening, re-open please

[codygman]

+1, Also seem affected by this please re-open.

[p-g-krish]

+1, Still exist, please re-open.

[rodzod]

+1 still exist, too slows cold starts in Cloud Run