Tauri fullstack framework

[FrancoRATOVOSON]

Hi folks, I was thinking about creating a fullstack framework (like next.js) but for tauri. My goal is to be able to have what electron users have, an access to all node api, 1 language for the front and the back, all throught the sidecar.

This is how I imagine it and if you are interested, you can give suggestion and/or talk about how we can achieve it:

A project using this framework will have 2 directories, one for the front (let's say app) and another for back (let's say api).
The framework will build the app folder to generate an html, css and js files for the front, and for the api, it will use a file based routing with each route generating a binary that will be used as a sidecar.

The framework will use a trpc like logic for each call (calling a "route" from the front, for the user, will be like calling a function with params) and will translate it internaly to the correct call to the sidecar with params.

Like fullstack frameworks does, everything will be « magic », devs are just seeing a fullstack framework that let them use nodejs in back and web api in the front for a desktop framework.

I don't know if it's clear, let me know what you think guys.

[ezra-en]

Not sure if we're getting at the same idea here, but I've been leveraging Bun for my cross-platform usecases and integrating Tauri for the frontend across the board: https://github.com/ezra-en/bun-crossplatform-template

Re: your enthusiasm for the Node API, I believe Tauri doesn't package any JS runtime, and as of now, has no reason to. Everything is in-browser using whatever webview is available to Tauri for your operating system, so Node compat doesn't really apply to Tauri in the first place, although people keep on thinking Tauri + a packaged runtime work well together because Tauri allows web apps (which are often made with server runtimes like node/bun) to be transformed into desktop apps via SPA magic. This is one of the reasons Tauri is so efficient, AFAIK.

I agree that we need a nicer cross-platform API, but that's what we're doing with the tauri-mobile project right? mobile will probably force us to unify things a lot more between desktop and mobile, which could improve things across the board. but server-wise, I don't really know how to solve it besides utilising sidecars and the shell, like how I suggest doing in the above-linked template.

[FrancoRATOVOSON]

My concern is not the cross-platform, but the possibility to use 1 language without touching rust, but still being able to have full access to native api, like what electron provide.

With electron, I can use any web api in the frontend and ani node api in the back, so all my knowledge with node will not be thrown away. If (for example) I want to use prisma, I can. Electron doesn't feel like a new tech to learn, if you know JS, you know electron. For tauri, I have to leave the back to plugin (official or community) if I need native access and focus only on the front, but if I need more control or have a more specific use case, I have to deal with rust (and you see the problem here).

If I can ship a javascript runtime with native api (fs, network, ...), I will be able to use only js and have full access to booth front and back.

[ezra-en]

Did you know that after you install the plugin, you don't actually need to touch rust again?
Plugin install is one line of rust, one line of TOML, and you have full access to plugin capabilities in JS.

[jasongitmail]

How would this differ from using a framework like sveltekit that has what you describe?

I haven't used Tauri yet. But am starting to evaluate it for mobile development. Ccurrently using NativeScript with Svelte for mobile app development

[ezra-en]

SvelteKit is considered a metaframework, providing an interface to the server side of the client-server connection through things like .server.ts files and the like when you run it via a runtime like node or bun. Tauri is not equivalent to that at all (as Tauri explicitly requires a static adapter, removing most dynamic server-side functionality), but you can consider Tauri to be able to provide a kind of client-side runtime interface to more interesting parts of the desktop API surface?
Using plugins like Franco mentioned, requires like, one line of rust and exposes the JS API right off the bat.

[jasongitmail]

Thanks @ezra-en Just making sure I wasn't missing anything.

My interpretation is that OP's idea is status quo, given you could use a framework like SvelteKit currently with the SSG static adapter, as you describe.

So instead of reinventing the wheel with a new framework, easier to just create a monorepo containing two separate projects, likely with the same framework: one of which uses API routes only (or something like Hono instead) and will be deployed as the server backend, and one which will be the frontend with Tauri using the static adapter.

This is similar to how I structure projects for NativeScript currently, except with NativeScript, the frontend there is just Svelte (via Svelte Native) and not SvelteKit.

[thewh1teagle]

https://github.com/thewh1teagle/tauric