coherent application folder structure

[xoviat]

Currently, vecty doesn't make it easy to write a dynamic application. The only tool that exists is wasmserve, which only works for static apps. The dynamic web application that I have written (running on google app engine) is structured as follows:

appengine/
      main.wasm
      wasm_exec.js
      index.html
client/
      main.go
      subfolder/
           other_file.go
server/
      main.go
      subfolder/
           other_file.go

I have a tool that I have written that automatically regenerates main.wasm on file changes and starts the server. The server is able to respond to /api/* url requests; every other page is served index.html (and with it, main.wasm and wasm_exec.js). Using this method, the tool generates everything but the go files under client/ and server/.

I'm curious what others think of this. It's currently set-up for google app engine, but it could conceivably work without it. There is nothing about dynamic sites in the documentation; only static.

[pdf]

Currently, vecty doesn't make it easy to write a dynamic application

What do you mean precisely? The main use-case for Vecty is for dynamic client-side web applications.

[xoviat]

What I mean when I say 'dynamic' is that data is stored on server. For example, it would not be possible to create something like twitter, facebook, or github with just vecty and wasmserve because there is no server-side logic. In order to accomplish that, it is necessary to have another 'api' application.

For another example, you can look at this project: https://github.com/gernest/qlql. IIUC, there is an app/ and api/ folder (compare to my client/ and server/ folder) to handle the client and server applications (in qlql, the client is on :80 and the server is on :8080, which is not possible on google app engine).

What I mean precisely is not that creating this is not currently possible with vecty. What I mean is that there is no quickstart; there is no tool that will run a development server, watching for changes in both the client and server applications. There are no recommendations for how to build something like this. Rather, it is left up to the user on how to structure their project, and this is time that accomplishes nothing valuable. I think perhaps a good start would be putting a full-stack application in the wasmserve folder and then writing a tool to run it.

I hope I have communicated this clearly enough.

[pdf]

I believe that vecty should have no opinion on what your API service looks like - they may be completely separate projects, may be written in another language, use any number of different transports, or even be entirely outside the user's control, run by some third party.

AFAICT this should not be a concern of the core project, however users are of course welcome to put together examples of some possible full stack implementations, I don't believe there's any one size fits all solution here.

[xoviat]

I agree that it should not be a concern of the core project, but I disagree that it should not be a concern of the larger project: there is no guidance on what a full-stack project should look like and how it should be developed. In contrast, there are a few full-stack javascript frameworks that provide guidance on how to structure your project and what tools should be used to develop it. There is no reason to force every new user of vecty to derive their project structure from first principles every time, especially when vecty says "Share Go code between your frontend & backend." on the front page.

[slimsag]

Yes, I think there should be recommendations and tooling here. There are different layers to Vecty: its core (what exists today, and what I view @pdf as discussing above) and its supporting tooling ecosystem (which does not exist today).

In short, I want users to be able to have a highly-opinionated option or be able to fallback to just using Vecty at its core as a Go library as you can today. You can read more about this model here: #188 (comment)