[✨] Qwikify for NextJS through proxy

[mhevery]

Is your feature request related to a problem?

I would like to try using Qwik in my existing NextJS project in an incremental way.

Describe the solution you'd like

1. Create NextJS project.
2. Create a Qwik project inside the NextJS project.
3. Choose an existing NextJS route and include a Qwik route inside that location by proxying the response.
4. Ability to use React components inside the Qwik routes through React Qwikfy

See this loom for more background:

File: pages/test-page.tsx

// Helper library which allows fetching HTML from Qwik URL
import { getQwikRoute } from "@builder.io/qwik-react/proxy";

export async function getStaticProps(context) {
  return {
    props: {
      qwikHtml: await getQwikRoute("/test-page"), // Fetch HTML from Qwik
    },
  };
}

// Render NextJS page with Qwik HTML
export default function Home({ qwikHtml }: { qwikHtml: string }) {
  return <div dangerouslySetInnerHTML={{ __html: qwikHtml }} />;
}

File: qwik-app/src/routes/test-page/index.tsx

import { component$ } from "@builder.io/qwik";
import { ReactComp } from "./qwikify";

export default component$(() => {
  return (
    <>
      <span>Hello Qwik</span>
      <ReactComp />
    </>
  );
});

Describe alternatives you've considered

n/a

Additional context

No response

[almilo]

@shairez pointed me at this issue which I find very interesting as I was recently myself working on a proposal to incrementally migrate a big SPA to Qwik. While this issue is focused on NextJS, I was wondering how the migration patterns would like like in a more broader scope so posting this here in case it helps.

Some scenarios:

• company X has a NextJS website with React components that can be leveraged in both Qwik and React and wants to either, add new pages with Qwik, or already migrate existing pages (no need for exploratory phase or PoC) => the proposed solution seems ideal as at that point a slight modification of the NextJS application should not be an issue.
• company X has a NextJS website with React components that can be leveraged in both Qwik and React and wants to explore feasibility (ie: PoC) => the proposed solution seems ideal as at that point modifying the NextJS application can easily be done in a branch and be deployed to a stage environment.
• company X has a website in a React stack different from NextJS and wants to explore a migration to Qwik => instead of proxying from the web application to Qwik, what about proxying through the Qwik City server a letting Qwik City intercept the migrated routes? This could be probably done with the Qwik City express adapter by adding the express proxy middleware. If the application is a MPA, navigation should work seamlessly. If the application is a SPA, navigating to migrated routes in the SPA would need to do a location reload to force the browser do a server request that the Qwik City proxy can then intercept.

The last proposal (proxying through Qwik) sounds more brittle and maybe more suited for a research phase, but it would IMO cover many more tech stacks than just adding NextJS support. Big companies tend also to have front servers like Nginx or Cloudflare where the selective proxying can be done and the Qwik city express adapter would not be necessary.
This approach is also less intrusive as it would avoid any changes to the production NextJS app and allows for A/B testing managed externally (ie: in some scenarios, easier to turn on and off the Qwik pages by changing the proxy configuration).

Once the infrastructure part is solved, the other issue that seemed instrumental to me was how to share the components as source code (ie: monorepo with npm workspaces and Turborepo containing the two applications as packages and a third package with the React components) so that pages from both applications would look identical by using the same React components and styles / design system (ie: React components styled with Tailwind). When I tried this approach a while ago, I faced some weird issues which I don't remember at the moment.

[steve8708]

One idea too to make this even easier in the short term - just create a doc on basic migration strategies, like if you use Cloudflare how to do it with an edge worker, how to configure Cloudfront to point some URLs to a qwik city site (on a new host) vs your current one, how to do this with Vercel and Netlify, etc

cc @hamatoyogi as this was an idea of his

[gioboa]

Hi @thejackshelton, are you working on this? 🤔

[gioboa]

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.