added nuxt-bridge

[wommy]

followed the steps here

https://nuxt.com/docs/bridge/overview

[advplyr]

I think there are breaking changes with some of the dependencies we use when switching to nuxt-bridge. This transition was attempted here. The breaking issues could be due to using nitro in that PR but either way I don't see an advantage to going to nuxt bridge.

After reading through peoples experiences using bridge to migrate to nuxt3 it seems like bridge does not simplify the migration to nuxt3.

Since nuxt 3 requires a full rewrite of the client I think it's worth exploring other options, like React Remix

[wommy]

oh yeah i saw that

but i gathered that alot of the pushback was more related to the messy git history,
and confusion with migrating towards ssr,
and not so much towards nuxt-bridge itself

i dont think migrating to bridge necessarily facilitates a migration to nuxt3,
and i agree that something other than nuxt3 might be alot more wise,
but i think nitro at very least provides a very capable stop gap towards a migration.

with nitro you could transition alot of different aspects of the app forwards,
you could incrementally migrate towards ssr, removing alot of the express/server code
you could update the css pipeline, like using a more modern tailwind,
you could remove the socket and cron plugins, bc nitro has that built in,
while updating others, im thinking marked,
you could remove dependencies like axios, replacing with a modern fetch,
you could work on removing the webpack dependencies to replace with vite,
so something like remix is just a hop, skip, and a jump away
and update others to something more modern,
i think a newer pwa implementation could remove the other half of the express code

i got nitro building, with almost full functionality,
still working on epubjs, the bump to 0.5 changed the api,
and if anything i could use some help changing some vars in the config
not 100% sure itll be 1-to-1,
but thats perhaps where a separate esbuild/vite config if anything,
could drag other parts of the app forward

but yeah,

i think theres many benefits to nuxt-bridge w/o planning on moving to nuxt3

[wommy]

@advplyr

[wommy]

i got audiobookshelf to build on nuxt-bridge's nitro with some tweaks to epubjs,
its not 100% right now, some error around epubjs's allow-scripts on the injected iframe
im not sure if its bc of @nuxtjs/axios or @nuxtjs/proxy or maybe both
but im going to tinker with both nuxt-bridge's native fetch and native proxy and report back

its kind of a complicated git commit history, and im curious as to whats the best way to proceed,

[advplyr]

I don't see how migrating to nuxt-bridge would be useful if we are looking at changing frameworks or even if we go to nuxt3. I'm looking at react remix right now which would be a complete re-write. If we go to nuxt3 we would salvage some components but still mostly a re-write.

[wommy]

i thought i explained pretty thoroughly in my above post

oh yeah i saw that

but i gathered that alot of the pushback was more related to the messy git history, and confusion with migrating towards ssr, and not so much towards nuxt-bridge itself

i dont think migrating to bridge necessarily facilitates a migration to nuxt3, and i agree that something other than nuxt3 might be alot more wise, but i think nitro at very least provides a very capable stop gap towards a migration.

with nitro you could transition alot of different aspects of the app forwards, you could incrementally migrate towards ssr, removing alot of the express/server code you could update the css pipeline, like using a more modern tailwind, you could remove the socket and cron plugins, bc nitro has that built in, while updating others, im thinking marked, you could remove dependencies like axios, replacing with a modern fetch, you could work on removing the webpack dependencies to replace with vite, so something like remix is just a hop, skip, and a jump away and update others to something more modern, i think a newer pwa implementation could remove the other half of the express code

i got nitro building, with almost full functionality, still working on epubjs, the bump to 0.5 changed the api, and if anything i could use some help changing some vars in the config not 100% sure itll be 1-to-1, but thats perhaps where a separate esbuild/vite config if anything, could drag other parts of the app forward

but yeah,

i think theres many benefits to nuxt-bridge w/o planning on moving to nuxt3

remix is build on top of vite
https://remix.run/blog/remix-heart-vite
https://remix.run/blog/remix-vite-stable

nuxt-bridge has a vite integration
https://nuxt.com/docs/bridge/vite

to get nuxt-bridge to work with vite, you must first enable nitro,
and i currently have a 95% stable nitro build, see my other post

i got audiobookshelf to build on nuxt-bridge's nitro with some tweaks to epubjs, its not 100% right now, some error around epubjs's allow-scripts on the injected iframe im not sure if its bc of @nuxtjs/axios or @nuxtjs/proxy or maybe both but im going to tinker with both nuxt-bridge's native fetch and native proxy and report back

its kind of a complicated git commit history, and im curious as to whats the best way to proceed,

i havent looked much into remix tbh, but as i previously mentioned,
i do think looking into a more modern framework is extremely wise.

the reason i started contributing is because
i dont really see the need for a traditional dynamic server at all.
with current ssr capabilites and capable service-worker, i believe you could statically serve audiobookshelf, vastly reducing the ram needed for the docker container
( or competely removing the docker dependency altogether )

as a rule, i tend to avoid complete rewrites.
i feel that even incremental rewrites have large swaths of problems,
but if it needs to happen, it needs to happen

i just think using nuxt-bridge and some nitro / vite configuration,
would allow to implement some more modern javascript features,
which you could then drop into a newer, different framework
without even using any Nuxt3 functionality
if anything i see at least migrating to nitro, if not vite,
as vastly reducing the rewrite overhead

a nitro migration is needed for vite, and vite is needed for remix,
the nitro migration enables removal of most of the nuxt2 dependencies
and after that, a migration to remix could be seen as incremental

and thats only speaking from the client perspective,
i believe a nitro migration could remove half of the server dependencies too,
tho i have spent considerably less time in the server directory

i do think migrating to at least vite is extremely wise.
from there, swapping in remix, or the dozens of other frameworks built upon vite,
would be extremely simple.
and nuxt-bridge provides a clear incremental path to that,
but first a simple migration to nitro would be needed,
which i pretty much have already done

[wommy]

ive been looking more into remix,

https://remix.run/blog/incremental-path-to-react-19#remix-became-a-wrapper

At this point, Remix is just a Vite plugin that makes React Router more convenient to use and deploy. Outside of the plugin, Remix pretty much just re-exports React Router.

[advplyr]

The first thing I want to look at is if the folder structure can be kept the same as it is now with the client inside /client. While also allowing HMR when running the server from the root directory.
The /api/* and some other routes would stay as it is and all other would go to the clients request handler

[wommy]

i believe that even thinking about a framework shift / complete rewrite is expensive from a technical debt perspective

while i completely agree that it would be extremely nice to clean house,
and while digging thru the nuxt-bridge docs / doing my own research on places such as reddit,
the common feedback was that nuxt-bridge kind of did a poor job in so far as it didnt really "bridge" nuxt2 to nuxt3, often people said that it was actually just easier to set up a new nuxt3 project and migrate a component over at a time.
and that sounds like a herculean effort,
and thats extremely depressing,
and a migration to / rewrite in remix sounds exactly like that

im curious as to what has influenced your decision and pushed you towards the remix route ( pun intended )

i actually dont hate that idea at all, i just dont have much experience in that area,
as remix as a framework i feel would be more suitable for larger, more interactive sites, if that makes sense?

i feel like the spectrum that kind of exists today is, to state it plainly, Next at one end, and Remix on the other

and from my perspective,
i feel like the SSR and build step of Next and Nuxt, technically would be the best fit,

i was actually extremely surprised to have seen that,
and thats what lead me to try to even submit a patch,
lo and behold, i didnt know what mess i was getting into

webpack 4 really hurts,
and most of the problems with the migration stem from the lack of established patterns back in 2017

when i started, my goal was to try to get a vite build working,
so i totally agree that vite should be the goal.

and all my experience in the last month,
i believe that nuxt-bridge isnt a bridge to nuxt3,
but rather a bridge to vite

but to get that to work, you gotta go thru nitro

i havent even heard of nitro before this project,
but the more im looking into it, its actually extremely capable

https://nitro.unjs.io/

the parent organization, unjs, seems hella dedicated to web standards,
which i believe should be the largest focus
( especially when thinking about migrating frameworks )

https://unjs.io/

alot of the headache of getting AudioBookShelf to build using nuxt-bridge,
came from obscure packages, requiring even more obscure dependencies
hence my opening emphasis on technical debt,
and it seems unjs is on the good side of that fight

now that ABS builds, i need some feedback as to if there are buggy edge cases, if that makes sense?

and while it builds, it is extremely hacky,
i need to write some other PRs to fix some things,
and i shall get to that soon,

but i believe it is done,
and like the migration to vite seems actually like mt everest rn
and im actually extremely happy with the nitro and unjs ecosystem,
and nitro provides alot of tools which could further reduce aging dependencies!
im looking at @nuxtjs/axios, @nuxtjs/proxy, cron-parser, nuxt-socket-io,
alot of these are kind of standards now, and provided my nitro

and thats not even mentioning unjs helpful tools,

ok cheers, this rambling rant has gone on long enough

[wommy]

sorry, i just saw your response,

i think alot of the benefits of stuff like SSR is that you dont need to maintain both a frontend and a backend,
you should be able to run both out of one package.json

as previously mentioned, i feel like alot of code can be "deduped" reduced removed

and i think itll build faster, serve at a higher volume, and use less memory when running

and i think bridge really is the first step

also have you looked into server migrations?
ive been looking at hono alot for another project,
it seems like a much better express
and it has jsx cooked in
it could replace /server and /client

🙏🙏🙏

[advplyr]

I definitely want to go with SSR this time around and I understand what you are saying with having 1 package.json for the client and server in the case.
I like the idea of keeping the client and server separate. I'm not decided on anything and still exploring at this point.

My original thought was to have all the requests pass through to the client unless they are API, Auth or some others. So it is still SSR.

I don't like how many dependencies that are used for these js frameworks. I like that we can keep the server dependencies clean since every js framework will use thousands of dependencies.

[wommy]

this video from awesome explaining the MPA -> SPA -> SSR progression kind of inspired this reply
and while it was mostly recap, i thought itd be better to include it

---

i totally understand your wanting to keep the /client and /server separate
refactoring two both at once leads to a much greater chance of buggy edge cases

but i believe the true value of SSR
is the streamlining / simplifying of more complex server-side logic
thru more modern paradigms, think event handlers
while absorbing the client-side logic back where it should be

right now, the client performs alot of traditional server-side logic
im not as fluent in the codebase as you are,
but im guessing its a pain hoping back and forth

right now, ABS's client requires a build step,
and i think common sense would be removing / simplifying that would be the upgrade,
but i think the best way to think of SSR is moving that build step to the server,
which allows for reunifying alot of the client-side logic back into the server
while at the same time simplifying alot of the server code / logic with a prerender

most, if not all of the routing logic could be statically built,
and with a robust service worker, removing the server altogether could very well be possible
that would astronomically reduce both build times, as well as resources required to run the app

service workers also come with the added benefit of PWA functionality,
which could very possibly remove the need for a separate app build for iphone, android, and desktop
as well as docker, tho for distribution reasons you might want to keep

---

sidenote:
have you considered astro?
it would allow a multitude of frontends to be used within the client
also would enable alot of modern features,
but sadly i still think a migration to vite first would be required

---

p.p.s.

quick little video that has some good visualizations of under the hood processes - nitro vs nuxt

[mikiher]

I am also intested in this discussion. @advplyr can you share somewhere (maybe in a discussion page) what you've learnt about other frameworks and what are the pros and cons? This is a decision for years, and a huge rewrite project.

[advplyr]

Yeah I haven't done more testing on how Remix would/should integrate with Abs but I have some experience with Remix now.
An internal website for work that is about 10% the size of Abs was also using nuxt2 and I re-built it with Remix in a few weeks.

Once I got the hang of it I found it to be a much better developer experience than nuxt2. I built one tiny internal website with nuxt3 so don't have as much experience with that.

I'd be really interested if you have any initial thoughts @mikiher and if you have experience working with other frameworks.

[mikiher]

Unfortunately I don't have any experience with frontend frameworks besides Nuxt and Vue2, which were self-taught for the purpose of making changes in ABS...

Nevertheless I would advise the following general approaches:

• Prefer community adoption almost on top of everything else
• Prefer development simplicity
• Think hard about what framework features we really need. More specifically, do we really need SSR? The app seems quite snappy today. I admit I don't know how much SSR is complicating things, but I'd recommend giving this a hard scrutiny.

[wommy]

ive been a full time web developer since 2015, i just got back from a web dev conference in SF last week

• Think hard about what framework features we really need. More specifically, do we really need SSR? The app seems quite snappy today. I admit I don't know how much SSR is complicating things, but I'd recommend giving this a hard scrutiny.

vue2 came out in 2016 and was EOL dec 31, 2023. some transition needs to happen.
the app currently has a build step plus a running server.

SSR would

• removed the need for a separate directories and the two different npm installs improving DX
• reduce required memory of the running application
• reduce build times by moving to a modern bundler
• allow to upgrade dependencies and plugins, some of these are frightenly outdated

but also its not even necessarily SSR, i can imagine a SSG version with all the above benefits, which would remove the need to run a server at all

[mikiher]

ive been a full time web developer since 2015, i just got back from a web dev conference in SF last week

• Think hard about what framework features we really need. More specifically, do we really need SSR? The app seems quite snappy today. I admit I don't know how much SSR is complicating things, but I'd recommend giving this a hard scrutiny.

vue2 came out in 2016 and was EOL dec 31, 2023. some transition needs to happen. the app currently has a build step plus a running server.

I agree that some transition needs to happen.

SSR would

• removed the need for a separate directories and the two different npm installs improving DX

I think we would still need a separate server, since Audiobookshelf provides an API, which we have to keep maintaining (and which numerous clients use extensively, including the web client). It's true that the server currently also serves the nuxt bundle but I don't think it necessarily has to do that. The API serving part, though, has to remain separate IMO.

• reduce required memory of the running application

I am not sure why that would necessarily be the case (I assume you meant memory on the client). There are hydration overheads for SSR, for example. I think this depends a lot on how dynamic the app is, and ABS is very dynamic.

• reduce build times by moving to a modern bundler

I might be wrong, but this doesn't seem to be directly related to SSR, but rather on the framework being used.

• allow to upgrade dependencies and plugins, some of these are frightenly outdated

Again, not sure if this has to do with directly with using SSR or not. @advplyr knows much more about this than me, but there are probably various good reasons why it was hard to upgrade. Probably an important one is that Vue (and Nuxt) changed very significantly from version 2 to 3

but also its not even necessarily SSR, i can imagine a SSG version with all the above benefits, which would remove the need to run a server at all

So I'm confused - are you advocating for SSR or not? Right now the way we're using nuxt is essentially SSG.

[advplyr]

I agree about continuing to keep the client and server separate even if moving to SSR. In this case the API is being intentionally built to allow other clients to be made including other web clients.

The Abs web client would still be served from the server alongside the API. The frontend frameworks come with a lot of dependencies and to me it is just cleaner to keep them separated.

There is one issue open that I believe requires SSR to resolve or a hacky workaround. I haven't looked at this in a while so maybe it is a non-issue #1399

Then there is allowing a subfolder path. #385

So I'm confused - are you advocating for SSR or not? Right now the way we're using nuxt is essentially SSG.

Yep

[mikiher]

I need to read more deeply into the issues you mentioned, but at a shallow glance, they seem kind-of tangential to the reasons I often see quoted in various places for using SSR, e.g. improving rendering speed, or making the app more SEO friendly. I guess my question is, what are the main objectives of introducing SSR? If it is to solve this or that feature request, it is a fine answer, but if there's a more fundamental objective, I'd be more satisfied (perhaps when I understand the issues better, I'll also understand what that objective is).

…

On Tue, Oct 8, 2024, 00:27 advplyr ***@***.***> wrote: I agree about continuing to keep the client and server separate even if moving to SSR. In this case the API is being intentionally built to allow other clients to be made including other web clients. The Abs web client would still be served from the server alongside the API. The frontend frameworks come with a lot of dependencies and to me it is just cleaner to keep them separated. There is one issue open that I believe requires SSR to resolve or a hacky workaround. I haven't looked at this in a while so maybe it is a non-issue #1399 <#1399> Then there is allowing a subfolder path. #385 <#385> So I'm confused - are you advocating for SSR or not? Right now the way we're using nuxt is essentially SSG. Yep — Reply to this email directly, view it on GitHub <#3426 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFMDFVS6QBTULZCSYBJ46XDZ2L4CHAVCNFSM6AAAAABOIHKTAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJXHEZDSNZVG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nichwall]

Another related issue that SSR might help with is devices/browsers without good JavaScript support like tablets, but I don't know how all of the dynamic stuff would work. I could see a "consumption focused" web client that only allows for browsing and downloads, but that feels more like a 3rd party client instead of the official web client.

#2243

[wommy]

I agree that some transition needs to happen.

SSR would

• removed the need for a separate directories and the two different npm installs improving DX

I think we would still need a separate server, since Audiobookshelf provides an API, which we have to keep maintaining (and which numerous clients use extensively, including the web client). It's true that the server currently also serves the nuxt bundle but I don't think it necessarily has to do that. The API serving part, though, has to remain separate IMO.

• reduce required memory of the running application

I am not sure why that would necessarily be the case (I assume you meant memory on the client). There are hydration overheads for SSR, for example. I think this depends a lot on how dynamic the app is, and ABS is very dynamic.

• reduce build times by moving to a modern bundler

I might be wrong, but this doesn't seem to be directly related to SSR, but rather on the framework being used.

• allow to upgrade dependencies and plugins, some of these are frightenly outdated

Again, not sure if this has to do with directly with using SSR or not. @advplyr knows much more about this than me, but there are probably various good reasons why it was hard to upgrade. Probably an important one is that Vue (and Nuxt) changed very significantly from version 2 to 3

but also its not even necessarily SSR, i can imagine a SSG version with all the above benefits, which would remove the need to run a server at all

So I'm confused - are you advocating for SSR or not? Right now the way we're using nuxt is essentially SSG.

@mikiher

below are some good explanations on render modes from nuxt3 and astro

https://nuxt.com/docs/guide/concepts/rendering
https://docs.astro.build/en/basics/rendering-modes/

i dont see why there cant be a static build installable from github pages

https://nuxt.com/docs/getting-started/deployment#static-hosting
https://nuxt.com/deploy/github-pages

heres an overview of nuxt3's server structure, notice the api route

https://nuxt.com/docs/guide/directory-structure/server

i apologize for the confusion, SSR has gone thru a few interations in the past few years
modern SSR frameworks all incorporate serving APIs statically with event handlers

currently ABS's express server is used to serve an API,
but nuxt3 does this by default without a running server

[wommy]

Then there is allowing a subfolder path. #385

https://nuxt.com/docs/api/nuxt-config#baseurl

[nichwall]

i dont see why there cant be a static build installable from github pages

But doesn't there still needs to be a server for the API and the database with user information, media info, file paths, etc?

[wommy]

i dont see why there cant be a static build installable from github pages

But doesn't there still needs to be a server for the API and the database with user information, media info, file paths, etc?

not at all, that's the benefit of SSR,
ABS already uses local storage, even sqlite is already on every phone already

yeah you need network to fetch the updated bundle,
but even service workers can act as a network proxy for offline mode
and ABS already has one but all that functionality is disabled

audiobookshelf/client/nuxt.config.js

Lines 121 to 126 in dd87268

	workbox: {
	offline: false,
	cacheAssets: false,
	preCaching: [],
	runtimeCaching: []
	}

im telling you, all yall are still living in 2018

[apiweb]

i dont see why there cant be a static build installable from github pages

But doesn't there still needs to be a server for the API and the database with user information, media info, file paths, etc?

not at all, that's the benefit of SSR, ABS already uses local storage, even sqlite is already on every phone already

yeah you need network to fetch the updated bundle, but even service workers can act as a network proxy for offline mode and ABS already has one but all that functionality is disabled

audiobookshelf/client/nuxt.config.js

Lines 121 to 126 in dd87268

	workbox: {
	offline: false,
	cacheAssets: false,
	preCaching: [],
	runtimeCaching: []
	}

im telling you, all yall are still living in 2018

It seems there's some confusion between SSR, SSG, and the need for a backend.

SSR (Server-Side Rendering) involves a server that processes requests, handles logic, and accesses databases or APIs to fetch and render data. Even if we migrate to SSR, hosting the project on GitHub Pages wouldn't be possible since we still need a server to handle requests, process logic, and access the backend database or APIs.

While service workers can cache files and proxy requests for offline usage, they can't fully replace a serverside API. Also, the sqlite on phones is different from the sqlite database on the backend, sometimes on the phone they have limits.
The Server side SQite stores media information, file data and paths, which can't be securely or scalably moved to the client. Local storage solutions in phones or browsers (like IndexedDB or WebSQL) are entirely separate from the backend database and don’t provide centralized access to media and user info across devices or multiple users.

All modern frameworks that support SSR (like Angular, Nuxt 3, or Next.js for example) still require a server.
If you want to remove the need for a server, you'd need to use SSG (Static Site Generation), but this would severely limit how the application works, especially for dynamic tasks like handling requests for media files or RSS feeds, autpmatic episode download, etc...

[wommy]

@apiweb as per my previous post

below are some good explanations on render modes from nuxt3 and astro

https://nuxt.com/docs/guide/concepts/rendering
https://docs.astro.build/en/basics/rendering-modes/

i dont see why there cant be a static build installable from github pages

https://nuxt.com/docs/getting-started/deployment#static-hosting
https://nuxt.com/deploy/github-pages

heres an overview of nuxt3's server structure, notice the api route

https://nuxt.com/docs/guide/directory-structure/server

i apologize for the confusion, SSR has gone thru a few interations in the past few years modern SSR frameworks all incorporate serving APIs statically with event handlers

currently ABS's express server is used to serve an API, but nuxt3 does this by default without a running server

so im pretty sure any edge function ( netlify, vercel, cloudflare ) are technically ran on the worker api
and im pretty sure service workers use the same API - or 90% similar
https://www.w3.org/TR/service-workers/#execution-context-events
https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope#events

so yeah i think i think it could

also i dont see why i can like, explore my file tree on my phone,
or like share the .epub / .m4b to the app
bc PWA's can do that
https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/How_to/Associate_files_with_your_PWA
https://app.flowoss.com/
https://webbrowsertools.com/audiobook-reader/

like yeah, split off the server
but with the app, which already statically prerendered, and already has a service worker
should at least be functional offline with a local file,
like i should be able to read an .epub or listen to an .m4b on the train,
theyre literally already on my phone
and then im back on my network, i should be able to cache locally for the next time ,
like how does spotify download for offline? just a cache
my static pre rendered local first client side single page progressive web app shouldnt need docker

if i wanted to run a docker sqlite instance why wouldnt you go with something like turso
https://turso.tech/

they even have a docker container, if you wanna run your own
https://docs.turso.tech/local-development#libsql-server
https://github.com/tursodatabase/libsql
https://github.com/tursodatabase/libsql/blob/main/docs/DOCKER.md

and then alot of the ORM logic could be moved into the

heres an overview of nuxt3's server structure, notice the api route

https://nuxt.com/docs/guide/directory-structure/server

[wommy]

and im not even saying get rid of the server

all im saying is my pull here got nuxtBridge to work
#3450

and i dont know how far away from nuxt3 that is,
maybe a plugin or two?

script setup and the composition api would help migrate away from vue2,
but i think the options api is still valid in vue3

so literally drag and drop

composition api would really help breathe some life into these components

alot of code could be deduped,
i see alot alot alot of methods that are rewritten in each component instead of pulled from some util lib

[wommy]

also if you like the look of remix,
i talked with tanner the other week,
it said it was heavily influenced by remix
https://tanstack.com/router/latest

i just watched this blue collar coder from earlier this year
https://www.youtube.com/watch?v=qOwnQJOClrw

like some of the best framework authors in the world are using the vite + nitro stack or vinxi
https://github.com/nksaraf/vinxi
https://m.youtube.com/watch?v=S0-fhGskPYA

I had to patch and vendor a dependency to get it to migrate
and has anyone even pulled it? it works in my machine

I have vite fully running for weeks now,
I've even started taking a crack at nuxt3
I've converted a good chunk of components to use the composition api
I've touched every file file in client, minus /lib /static and some others

what's the hold up
what do I gotta do
🤷‍♂️🤷‍♂️

[wommy]

the answer is join the discord 🤦

youtube -- Mathias Biilman | From Frameworks to Primitives | ViteConf 2024

this really speaks to exactly the architecture i have in mind