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