Research vike.dev and see if it's a good idea to migrate to it

[Enjoy2Live]

DevLaunchers is looking into reducing the costs of hosting the apps and considering the growth we're at it's time to consider hosting each app to Serverless environment.

We're currently using next.js which doesn't give full control over your server and the ability to use any deployment strategy making it hard to use anything but vercel if you want to go serverless, we found a tool that might replace next.js called Vike.

Vike promises a lot of things but we're mostly interested in its ability to work in any environment (Node.js, AWS, Cloudflare, Vercel, Deno, Bun, Lagon) making it possible to be deployed anywhere while providing specific render to domains/pages.

In the comments we'll be discussing the pros and cons while trying to migrating one of the internal apps and ultimately consider using it or not!

[alexanderyanthar]

Hey, @Enjoy2Live ! Hope you're doing well. I got the bare bones vike app running, but I have a nagging question. I'm trying to wrap my head around how we will migrate the app to Vike. How exactly do we want to approach this? If I understand correctly, vike is essentially a highly customizable framework builder that'll allow dev launchers to have the freedom to have any frontend, backend, and deployment server of choice. And as you mentioned, an issue with next.js was the problem of not being able to go serverless without some weird workarounds. So I guess my question is what exactly needs to change from our current app to this?

One more question I just thought about, would Vike act as a replacement for Next.js? From the introduction docs I'm currently reading, it's setting itself up as a replacement for it (there's a whole section called Next.js comparison). Another reason I suppose you're even considering using Vike.

I suppose that might be the actual task you've given me, but I wanted to just touch base with you to see if you already had some insight/plan/direction you wanted to go. Thanks!

[Enjoy2Live]

Hi @alexanderyanthar, Since next.js is mostly react code with a little bit of next.js specific APIs for you to opt in to like next/image and next/link. We have to start removing those imports and replace them with Vike specific APIs from Vike/react plugin if possible or if not we'd fallback to the primitives coming from HTML5 example: instead of

import Image from 'next/image'

export default function Page() {
  return (
    <Image
      src="/profile.png"
      width={500}
      height={500}
      alt="Picture of the author"
    />
  )

we can just use

export default function Page() {
  return (
    <img
      src="/profile.png"
      width={500}
      height={500}
      alt="Picture of the author"
    />
  )

or better still one of these Image Optimizing solutions. And of course same thing applies to next/link getting changed to <a> otherwise our vike app will be having issues!

Unfortunately next/link has interesting features built in like prefetching on hover which promises to make the experience navigating the website seem snappy unlike the regular <a> which doesn't do anything like that by default.

Good news is we have the ability to make our own next/link using Vike! something beneficial to Vike users as the current Vike/react plugin doesn't export such a component and that's a good opportunity to payback to the maintainers of this library by making a pull request on Vike/react repo but it's too early now :smile:

That's the first step.

Second step would be making it compatible with styled-components because all the legacy components we have are written in styled-components but any new app shouldn't need these configurations as we're now fully using tailwind.

Third step is making sure the authentication flow is still working and user data can easily be passed to components using a context.

Fourth step is writing documentation for internal teams on how they can use Vike with a side by side comparisons of how they used to do things with next.js

tl;dr

• [ ] Remove next.js specific APIs and replace them with something that can be recognized by Vike
• [x] Make the app compatible with styled-components (done in #1690)
• [ ] Ensure authentication flow is still working and the data of the authenticated user can easily be accessed by components, maybe through a context?
• [ ] Some basic documentation in case we actually create "our own framework" rather than using Vike/react plugin

To answer your second question I would probably say no, Vike itself doesn't act as a replacement for next.js as next.js already has alot of features baked in unlike Vike where you have to build those yourself or integrate external tools. Advantage:

• You're closer to the react core team and what they release rather than waiting for next.js to implement their own wrappers around the same features, example of this is streaming which took months if not a year to be implemented in next.js after react core team announced it

Disadvantage:

• You have to build these wrappers yourself if Vike/react plugin doesn't support them

Vike/react plugin is considered a replacement of next.js because it provides alot of solutions out of the box with much more flexibility.

I hope that answers the question, let me know when you're ready to start migrating apps!

[alexanderyanthar]

@Enjoy2Live Thank you so much for the detailed response! It really helps me get a better understanding of how I should approach studying and understanding Vike.

Firstly, everything you said makes a ton of sense and from my initial read over, I did pick up on the changes with the next/image and next/link. I'm going to continue reading through the docs today to familiarize myself some more, but I think I'll be ready to start Monday or early this week to migrating apps!

Thanks again for the great answer!

[Enjoy2Live]

@alexanderyanthar sure, I have appointment slots on my calendar (can be found on my discord profile). feel free to book a meeting whenever you're ready, Thanks for keeping me in the loop Alex!

[alexanderyanthar]

@Enjoy2Live Just booked a meeting with you for tomorrow!

[Enjoy2Live]

@alexanderyanthar I found a solution to the issues we're having at commit 26dbfdba with styled-components not reading theme values properly!

Issue

styled-components needs to be a singleton and stationed right inside the root node_modules folder. this is not the case because each app is using a different version of styled-components which makes yarn not hoist the different version and only let it be at the workspace/app level node_modules.

Example:

• UI has has explicitly requested "styled-components": "5.3.0" in its package.json
• app1 has explicitly requested "styled-components": "5.3.0" and UI in its package.json
• app2 has explicitly requested "styled-components": "5.3.5" and UI in its package.json
• app3 has explicitly requested "styled-components": "5.3.0" and UI in its package.json

In this case yarn will hoist styled-components": "5.3.0 to the highest node_modules folder in the workspaces tree which a nice feature to reduce installation size and to reduce download numbers so let's have a look at how the tree looks like in this case.

./
├── apps
│   ├── app1
│   ├── app2
│   │   └── node_modules
│   │       └── styled-components@5.3.5
│   └── app3
├── node_modules
│   └── styled-components@5.3.0
└── packages
    └── UI

now app2 won't work exactly how its maintainer expected because styled-components needs to have one instance running on your app but in this case two instances are running on app2

• styled-components@5.3.5 used by app2 located in ./apps/app2/node_modules
• styled-components@5.3.0 used by UI package located in ./node_modules

Solution

Easiest solution is to make sure that all styled-components dependencies have the same version across package.json files in the monorepo.

Another solution is to make your app bundler target the specific path of styled-components lib you're trying to use to be coming from the root node_modules folder like we did here with webpack but with vite as the bundler.

tl;dr

All styled-components dependencies should have the same version across package.json files in the monorepo I fixed that in this PR that goes to community/try-vike, would love to hear your thoughts on that PR page and your reasoning for approving or disapproving the PR!

[alexanderyanthar]

Hey @Enjoy2Live firstly, I think this PR seems like an excellent solution. It solves the problem in question and in a manner that'll likely help us avoid other problems with versioning! Great job!

I have a question about Authentication. It's more clarification for me, but here goes! I understand the PR you linked me focuses on dealing with a local authentication with strapi and that a solution was found. I'm assuming that users are logged into the strapi database when they either create an account or log in, so I'm guessing that's what we're going to be focusing on.

Please correct me if I'm wrong, as I just want to make sure I'm on the same page so we can work more smoothly! I'll do some research into the strapi docs to better understand authentication on their end, but if you have any immediate resources that are easy to find or a direction I should move toward that would be much appreciated!

Thanks so much and hope you're having a lovely day!

[Enjoy2Live]

@alexanderyanthar That's right, Authentication is through Strapi which actually uses google as the provider for the Auth service. The flow is very similar to how it's done in https://staging.devlaunchers.org you click on create an account or login and see google auth page and proceed to pick your account then an http only cookie named "token" appears in your dev tools which is used in every request made to https://apiv4-staging.devlaunchers.org .

The PR I mentioned you at has a markdown file that explains the process how to authenticate successfully in dev mode, let me know if struggle with anything and let's book a meeting these days to get this working together if possible!

[alexanderyanthar]

@Enjoy2Live I'm going to go over the markdown and attempt to get it to work and I'll follow up with a meeting. My mom and brother are coming over this weekend, so I'll likely schedule a meeting with you early next week!

[Enjoy2Live]

@alexanderyanthar I've got some news from Platform Enablement, @lamodots is going to help us with migration!

I think it's fair to split tasks between you both, one is focusing on auth and the other is focusing on deployment.

Something to be discussed further in our next meeting, for now @lamodots I'd recommend that you go over the docs of vike.dev and learn how it works with your own app using vike-react extension then checking our current progress at community/try-vike branch. Glad to have to more neutral participants to the process of migration

[alexanderyanthar]

@Enjoy2Live Awesome! I hope to find some time on Tuesday for a short session, but if not then Wednesday! It's a bit of a busy week, but I'll do my best to find some time.

[lamodots]

Have read through your conversations great job so far.

[lamodots]

Why going through the Vike docs i found out this resources on migrating from Nextjs to Vike . Maybe it can help in some way in achieving our aim. https://github.com/vikejs/vike/discussions/1460

[dbradham]

@Enjoy2Live are we still planning to migrate to a serverless environment? If so, I am wondering if you have a particular hosting provider and severless framework in mind to use. I can see a few different frameworks and hosting providers listed in the summary here-Node.js, AWS, Cloudflare, Vercel, Deno, Bun, Lagon. Fully defining a cost reduction plan would be a great use of our time here.

I know we are currently using Azure with a budget for nonprofits. Azure has Function Apps which are Severless, but not sure if Vike is compatible.

CC: @chungthuang

[Enjoy2Live]

@dbradham vike is compatible with them all even on most of edge runtimes but my concern with vike is how teams will adapt to it, if we choose to go this route we have to make sure tech leads are aligned and comfortable taking this forward.

[dbradham]

@chungthuang @Enjoy2Live circling back here, is there still a strong need or desire to go serverless? If yes, what are the main benefits you see?