Pre-build and caching requires some more investigation

[patrick-steele-idem]

From @ianvonholt 12:26

@patrick-steele-idem As a follow up to Lasso caches, I’ve been down a deep rabbit hole and have made some headway. Heroku slug compilation runs all “build” type scripts from a temporary directory structure /tmp//. However, due to the way that Lasso creates the .cache and key from a Lasso context, there was no efficient way to pre-build a container ready cache. So, ditcing that route I’ve set up some Docker containers that build the Lasso cache. I’m able to control the directory structure and the caches match up from build to runtime. Good news! However, it appears that Lasso is still building the .cache on the first pass of hitting a page. On simple pages with a couple components, it’s about a second or two on the initial server response. On more complex pages with a number of components the response time is around 8 to 10 seconds.

[ianvonholt]

From a couple of different approaches that I've taken for an actual build step, nothing seems to fully stick from a Lasso build environment to the next instance of Lasso being used within the context of a runtime environment.

This is all being done to Docker containers and is being tested on some Heroku-16 stack.

1) The LassoAPI is properly building asset files and bundles 2) The lassoPageResults/cache, lasso-require/inspect/cache will often have a majority of the same material. However, runtime production will contain Marko components that are missing from the build cache files. 3) The same key is being used, so the configuration objects are exactly the same.

I've taken the following approaches:

1) Find all lasso pages, compile the .marko file, and use the API to create a Lasso.lassoPage

The container will build properly, assets are generated, etc. However the first visit on a server will generate this response time spike:

2) Use a warmup approach where the Express server is run, and all routes are visited with request objects. This builds assets, but leaves a huge difference gap in the contents of lassoPageResults/cache and lasso-require/inspect/cache.

3) Use a combination of 1 and 2.

These are the response spikes for both a deploy for approach 2 and 3.

The first spike around 12:15 is as a user is navigating through the site with approach 2 and the spike at 12:35 is with approach 3.

This isn't to say everything is doom and gloom. Once a site is up and running, the response time, even on Heroku dynos, will sit under 300ms.

The only thing that I can attribute this to, is Lasso simply not getting the same information during build for the lassoPage function as the <lasso-page> tag during runtime.

Any ideas or direction on generating a consistent .cache during build time for runtime lasso to pick up and run with?

[ianvonholt]

@austinkelleher Any update on pre-build support with https://github.com/lasso-js/lasso/commit/4d1d8881775f8eb9aa738fe7c292de129e442179 ?

[mufumbo]

hey @ianvonholt I have created #299 that should help you out with your lassoPage build times. I think the lasso idea of pre-build might be different than what you need.