RFC for builders #25
RFC for builders #25
Conversation
| and include examples of how the feature is used. Any new terminology should be | ||
| defined here. | ||
|
|
||
| * Client-side bundle goes into static dir (SPA) |
There was a problem hiding this comment.
When you say "static dir" I'm guessing you mean __sapper__/build/client/ and not static/?
There was a problem hiding this comment.
That is my understanding.
There is additional complexity here. We obviously need this information in the server builder as well, but if we are moving towards facilitating 'faas' deployment then we might want to consider greater support for plopping your assets on a CDN, there have been some issues about this in the past. I think this is quite difficult right now, if it is possible at all.
There was a problem hiding this comment.
The main difficulty right now that I'm aware of is that the images don't have hashes in their names, so they're not cacheable. I sent a PR to the template to address this: sveltejs/sapper-template#248
There was a problem hiding this comment.
Re "if it is possible at all": Right now I'm deploying my sapper app to a CDN by parsing the routes directly out of manifest source code and generating CDN configuration for it.
| defined here. | ||
|
|
||
| * Client-side bundle goes into static dir (SPA) | ||
| * Individual modules built for each route |
There was a problem hiding this comment.
What do you mean by "modules" here? An npm module? Or just a file or collection of files?
There was a problem hiding this comment.
I think this is the per route code-splitting part, essentially having distinct individually deployable pieces of code for each route. There are benefits to this approach but it might also not be necessary, we'd need to validate. It could be that it becomes more significant over a certain size.
There was a problem hiding this comment.
My instinct here is that there are at least 2 reasons to put things into the same function bundle:
- they always change together (less risk of them getting out of sync during deployment)
- they use the same set of (third party) dependencies
Along these lines, there are at least 2 reasons to put things in different bundles:
- they use different secrets (e.g. one has a secret token for Stripe, the other has a secret token for AWS)
- avoid loading unnecessary code to keep cold starts as fast as possible
|
|
||
| To define: | ||
|
|
||
| SSG: Server-side generated pages |
There was a problem hiding this comment.
Should this be statically generated? (i.e. at compile time)
There was a problem hiding this comment.
Is this leaning towards https://nextjs.org/blog/next-9-5#stable-incremental-static-regeneration ?
| SPA: Single-page App | ||
| SSR: Server-side Rendering | ||
|
|
||
| ## Drawbacks |
There was a problem hiding this comment.
One of the major questions this might raise is whether to keep support Webpack. Depending on the implementation, we may decide it's not worth implementing for Webpack (at least until someone from the community contributes a new Webpack implemention)
I think about 2/3 of our users use Rollup based on the numbers from the plugins:
There was a problem hiding this comment.
I would ditch webpack entirely. We don't have the resource to support multiple bundlers, and 5 is probably different enough to require a re-implementation anyway. Rollup is fast becoming the preferred choice for other projects anyway, and we have a distinct advantage in having a certain project author on our team.
I am very much in favour of abstracting the build, I wouldn't build it for any specific bundler, but I also wouldn't go too deep in abstracting it.
There was a problem hiding this comment.
I am in favor of only focusing on rollup in the near-term, although I don't think we should allow any rollup-specific abstractions into the core algorithms of this stuff. This will: reduce the total amount of knowledge someone will need to understand the core algorithms, insulate us from changes to rollup, and make it easier to support other bundlers
|
|
||
| Deploying this is relatively simple, but certainly not optimised for certain deployment strategies such as serverless (lambda), and often relies on third-party, platform-specific builders. | ||
|
|
||
| If Sapper were to produce its output in a more modular fashion, it would facilitate the creation of a number of officially supported "builders" for major platforms, as well as opening the doors for third parties to easily produce builders which targetted other platforms. |
There was a problem hiding this comment.
One way to think about this is that there should be no __sapper__/build/index.js.
Instead, we should emit enough information for someone to run a completely separate tool against the sapper build output. Something like sapper serve ...
This command would read the routes from the given directory and serve them directly. This would also make it straightforward for others to write deploy commands that can package things up for various hosting providers.
|
|
||
| Additionally, it would ease the creation of some desirable features: | ||
|
|
||
| 1. Per-route bundle splitting |
There was a problem hiding this comment.
@pngwn pointed out that you might want the splitting to happen for both the server-side and client-side code: sveltejs/sapper#1346 (comment)
|
I'm going to go ahead and close this since SvelteKit has adapters which sound pretty similar. If there's anything missing from SvelteKit's adapters then we can take a look at closing whatever gap remains |
A WIP on creating builders for sapper routes, to aid deployment across a variety of platforms