Answering questions

[cecton]

cc @fstephany

Q: What are the available CLI commands by default? serve and build? The --help output is a bit sparsed.

basic 0.1.0

USAGE:
    basic [SUBCOMMAND]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

SUBCOMMANDS:
    build    Build arguments
    help     Prints this message or the help of the given subcommand(s)
    serve    Build arguments

The doc string for build and serve are duplicated and wrong. There is already a ticket for it: #39

Q: I can't find in the doc the order of execution for stuff. I see the doc for the main macro. Are the named arguments that I pass to the macro 'hooks'? What is the order of execution?

• pre_build, post_build are pretty obvious on their own.
• watch is to change the watching behavior, it's not linked to an order of execution. serve is to change the serving behavior, again it's not particularly linked to an order.
• run_server is to change the behavior when the serve feature is disabled. The serve feature provide a small HTTP server to serve the files. Without it, you need to configure your own server.
• default_build_path is to override the default build path, it's not related to an order of execution either.
• other_cli_commands is to handle the other (not build or serve) cli commands, it's not related to an order of execution though I think it should be the very first thing executed

Q: I see that I can add new custom commands? How does that look like?

This is an example of custom command that builds a Docker image https://github.com/IMI-eRnD-Be/wasm-run/blob/main/examples/backend-and-frontend/frontend/src/main.rs#L11

Q: In the case of a pure WASM project, build and serve makes sense on their own. When there other components, like this example with a backend, SCSS and frontend, what do they mean? Is build for the three components? How should I express that I only want to rebuild the backend (e.g., if a file changes for example?).

wasm-run builds the frontend so it rebuilds only the frontend components by default.

You can use the full-restart feature to trigger a full rebuild (backend and anything else). It's done in the example: https://github.com/IMI-eRnD-Be/wasm-run/blob/main/examples/backend-and-frontend/frontend/Cargo.toml#L16

There is no way to rebuild only the backend as wasm-run is not intended to assist backend development but frontend development (or the interactions between the two as a whole).

Q: There's no mention in the README of the watcher. In the main macro documentation we see
"a function that is called when the watcher is being initialized (allowing you to add extra things to watch for example)"
How is this working? Does wasm-run always initialize a watcher? What does it watch?

Yes. Everything* is watched by default. wasm-run intend is to assist frontend development as a whole.

Q: How does sass/scss building works? It seems to be part of the post_build hook step. Will the sass/scss still be transpiled if I provide a post_build hook? Why isn't this addivitive?

Yes if you override post_build you need to setup your own sass/scss generation. It isn't additive because it's a one-size-fit-all by default hook configuration which you can entirely override if you wish.

We could provide a separate "css" hook. It's an idea.

Q: How do I prevent the generation of the index.html without overriding the post_build hook? I don't need it as HTML is generated by my backend server.

You can't prevent it without overriding the post_build hook. We could add a flag to customize that in particular... I think the problem we have here in general is that there are too many things in the post_build hook and it makes it cumbersome when you only want to override one small behavior.

Q: Oh! its the post_build step that writes the wasm+js to disk.

Yes, you can totally change that the way you want by overriding post_build. I personally do that to embed the JS in the index.html.

Q: Is the anyhow requirement appropriate? I guess we can afford it as the scope is quite reduced?

Anyhow is useful for binaries. It's an opinionated and pragmatic choice as you usually don't want to make error enums in script that just build the frontend.

Q: Oh ok, in the backend example in wasm-run, the binary (let's call it main) is dependent on the backend and runs it from there. This means

1. the backend must be startable from outside its main (what about dotenv for example?)
2. it can be started without using an external process. As it is the running process.

1. You can load your configuration in an entrypoint function in the backend then just call it from main.rs. So the behavior will be shared for both.
2. It can be started without using an external process indeed as it needs to go into production without wasm-run

[fstephany]

Oh! Those were mostly questions and remarks I had in my brain while writing https://github.com/fstephany/fullstack
I didn't expect answer for each of them. Thanks a lot for answering them!

You can't prevent it without overriding the post_build hook. We could add a flag to customize that in particular... I think the problem we have here in general is that there are too many things in the post_build hook and it makes it cumbersome when you only want to override one small behavior.

Yep, that's my feeling as well. It's probably super hard to find a nice balance between feature and configuration.

I think most of my questions are maybe the result of a mismatch between our respective goals. You are focused on the frontend/wasm part while I'm trying to handle all the pieces (backend+frontend+css) with wasm-run in the fullstack example.

[cecton]

Thanks a lot for answering them!

Thanks to you. I really want to see this project getting better. I believe it has great potential. But I won't be sad if it turns out to be useless/a bad idea.

I think most of my questions are maybe the result of a mismatch between our respective goals. You are focused on the frontend/wasm part while I'm trying to handle all the pieces (backend+frontend+css) with wasm-run in the fullstack example.

I think we should debate a lot more on that because I believe it is the source of our misunderstandings on this project. So if you don't mind I will challenge here your ideas and develop mine better. If you do the same, hopefully we will reach a better understanding and a common vision.

You are focused on the frontend/wasm part.

This is definitely true. I built wasm-run almost based on wasm-pack. I didn't have a focus at all on the backend. Though I've figured it would be extremely useful so the backend+frontend scenario has been added on a later stage of this project.

I still think that it could be valuable to support the main three components of a webapp: frontend, backend and css. I
(from #47)

wasm-run doesn't provide build and support for the three components separately. Well, slightly. Let's try to break this out:

• It provides it as a whole frontend+(backend)+css but only for development purpose (frontend+css is the default, while frontend+backend+css is done via the customizing the serve command)
• It provides frontend+css build for delivery purpose (production)

This is because in the real world the backend and the frontend are rarely served together. The frontend is usually served by a content delivery service while the backend is running on a container or a vm somewhere. Therefore you rarely deliver backend+frontend together. You usually deliver them separately.

I consider the CSS part of the frontend. I don't even imagine "css build" as I don't see a use for this. Except for designers maybe... but this is out of our usage. That is why the "serve" and "build" commands always build and serve the css. (Maybe I should consider it more)

wasm-run doesn't tackle at all the backend delivery for production purpose because this is something done "normally" by cargo and other tools. In other words: you usually need to do cargo build --release to make a release of your backend application.

wasm-run most important concerns are:

1. providing a development environment easy to start (cargo serve) which must suits the scenario frontend-only but also backend+frontend
2. providing a build command to ship a frontend app (cargo build) which only suits the scenario frontend-only because the backend is supposed to be handled separately

Nevertheless. wasm-run provides a great deal of customization. For example, in the backend-and-frontend example I added a third command that provides backend build+frontend build+containerization.

This was my own vision but I would like you to challenge it. The better the critics, the better the product.

[fstephany]

As usual, I think we agree on almost everything but we put it differently into words 😅

This is because in the real world the backend and the frontend are rarely served together. The frontend is usually served by a content delivery service while the backend is running on a container or a vm somewhere. Therefore you rarely deliver backend+frontend together. You usually deliver them separately.

Yep. The only time when it makes sense to have all of them together is during development.

1. providing a development environment easy to start (cargo serve) which must suits the scenario frontend-only but also backend+frontend
2. providing a build command to ship a frontend app (cargo build) which only suits the scenario frontend-only because the backend is supposed to be handled separately

I agree as well. For the first point, that's where I think it would be useful to have a sensible default that will work for the 2 (or 3 depending how we count CSS) components.

When working with a project like fullstack, I would imagine the following flow when I develop:

(general idea)

cargo run --bin run  -- serve
- (backend) Watching '/crates/backend/'
- (frontend) Watching '/crates/frontend/'
- (stylesheets) Watching '/assets/css' 
- Building backend
- Building frontend
- Building Sass
- Starting backend with $ cargo run --bin backend
....
* (backend) files have changed.
- Building backend
- Starting backend with $ cargo run --bin backend
.....
* (stylesheets) files have changed
- Building SASS from '/assets/css/app.scss'

This would start 3 watchers. One for the WASM frontend, one for the backend code and one for the sass.
As soon as a file changes in the wasm frontend, it would rebuild it (like it does now). But it would do the same with the backend code as well. So I can start to work on all the components and they are rebuilt when something is changed.

As you said it is possible to do that now with the custom hooks but a default mechanism could be useful. We would then have pre/post_build hooks for all the components (frontend, backend and sass). We could generalize this with something like entrypoints in webpack. Each entry point would have its own sequences of steps/hooks with sensible defaults.

When come the time to build for production, I fully agree with you that the backend should be built as a separate entity.

[cecton]

As soon as a file changes in the wasm frontend, it would rebuild it (like it does now). But it would do the same with the backend code as well. So I can start to work on all the components and they are rebuilt when something is changed.

This is done by the feature full-restart at the moment (which is not the default).

As usual, I think we agree on almost everything but we put it differently into words sweat_smile
Yep. The only time when it makes sense to have all of them together is during development.

I think we agree just on that but not on the way to do it. 🤔 In the current settings, you need to add an entrypoint for the backend so the serve command can restart the backend when changes are detected.

But after looking at web-bundler I wonder if it wouldn't be simpler to have the frontend built on the build.rs so you would run the backend "normally" and the frontend would be built while the backend is built. It would probably easier on some aspects (and probably less on other aspects...).

[fstephany]

But full-restart will re-run everything without any consideration of what has changed, right?

I'm not fond of the build.rs way because we tie the backend and frontend together even during development. I think the web-bundler use case is great when it comes to ship an executable that has everything built in. When iterating on a web project I don't want to rebuild/restart the backend when I make changes to the frontend.

Why don't we consider the three components like separate entities in development and provide the plumbing to hook them together when generating a release build? The use case of pure frontend development could be handled like it is now ie., a minimalistic tide add that serve the generated files while developing.

[cecton]

I already answered this in the ticket in web-bundler.

There would be the use cases:

• everything built together: cargo build (--release)
• frontend only: cargo run -- build and cargo run -- serve
• frontend+backend in background (normal serve but it doesnt rebuild the backend when something change, only the frontend): cargo run -- serve with backend="backend_crate_name" in the macro

(If you don't mind I think we should continue the conversation there. panoptix-za/web-bundler#6)