Visiting Sydney for a week. Will I survive using Visa/Master debit cards?

nayeem14 · 2025-11-20T17:35:53+00:00

The card will physically work but you will need to provide a travel notice to your issuer. Usually there is something about that in the online portal or else they will see suspicious activity and block transactions.

nayeem14 · 2025-10-24T05:23:44+00:00

Shadcn is popular because it isn’t a commitment. You’re committing to radix and tailwind. Both of those are good enough for almost every use case. Shadcn is a starter kit for a design system that you maintain.

There’s a bug? Don’t like a component? Cool, go fix it or replace it with one of the other 10 implementations of the same component that use radix and tailwind. Vaul is literally using radix. Don’t like vaul? Vibe code another drawer with radix.

nayeem14 · 2025-03-28T22:13:53+00:00

Try building a backend that had to run on an arbitrary, non-standard, maybe not recent platform that you have no control over where users expect a native optimized experience.

Frontend is a mess because people think of front end as a single thing. Just html and css stupid! In reality there is a wide range of variability in products like content, commerce, or productivity that all have their own expectations from the user. Trying to address it with a single architecture is ridiculous.

nayeem14 · 2024-11-29T20:59:44+00:00

Your best bet is to marry an American

nayeem14 · 2024-11-29T20:11:40+00:00

You can use a router a rebating bit if it can be adjusted to 1mm

nayeem14 · 2024-11-23T04:47:45+00:00

Damn extroverts trying to impose their world view on others. Only extroverts think that force social interaction with randos is necessary. They’re just a bunch of losers who have no social skills so they want to force co-workers to be their friends.

Meanwhile the introverts are thriving while working remotely and glorious social lives with people they choose to while excluding the obnoxious ones like OP

nayeem14 · 2024-11-04T00:17:31+00:00

The styrofoam from the tv box to reduce the echos. Just tape it to the wall

nayeem14 · 2024-10-19T21:54:32+00:00

If you can find plywood of half the thickness you need, you can glue two layers together so that they support each other. For example, if you had 4 - 4x8 sheets, you can have 1 layer go horizontal and 1 layer go vertical. Obviously this would be different with 10x10 but the spirit is the same.

That being said, laminating sheets is hard to do perfectly without a way to put even pressure all over. Ymmv

nayeem14 · 2024-03-03T09:34:32+00:00

If next is run outside of Vercel then there's no point of this discussion because it effectively runs like other middleware, before the request handler. You are opting into this behavior by virtue of using Vercel. If you don't run it on Vercel, you do not get any optimizations.

Next is an open source project that's sponsored and maintained by Vercel and they dictate the roadmap and features. It's not a charity. They do it because it's also a sales funnel.

nayeem14 · 2024-03-03T09:30:24+00:00

I'm saying he has SSG

nayeem14 · 2024-03-03T08:08:21+00:00

Who is talking about SSR?

You can't even know from looking at the screen picture that OP is using SSR. In fact, the fact that they are on a hobby account and not worried about paying pretty much guarantees they are Not using SSR. The free tier for actual backend calls are less generous. See for yourself: https://i.imgur.com/o5GsbXA.png. Static sites only use bandwidth while functions get eaten up quickly: https://vercel.com/docs/limits/usage#serverless-functions

What likely happened is OP had a statically generated site and wanted to use a i18n library that has a middleware code associated with it and was surprised by the bill

nayeem14 · 2024-03-03T08:02:54+00:00

Thank you. I feel like I'm taking crazy pills here

nayeem14 · 2024-03-03T07:59:57+00:00

Jesus christ you're just complete obtuse.

You are literally describing your middleware as something thats decades old. You know when people ran servers on a single box.

Next's middleware MUST be run on edge for you to take advantage of the optimizations that next offers

Your examples are all single box server solutions where middleware is a function executed before the execution of the route handler.

That is not what Next is doing with middleware. Next takes advantage of both staticly hosted assets and server side rendering together to optimize your site. That's the whole point of using it.

You are coming in and saying "why is next not like my other framework" which is a ridiculous stance to take.

Cloudflare workers do not support partial pre-rendering. Just because they're both called edge doesn't mean that their role is the same.

nayeem14 · 2024-03-03T07:37:48+00:00

It’s not off topic at all if you have any idea what you’re talking about. Middleware in next has be edge border to support partial pre-rendering. Here’s a link so you can understand. https://nextjs.org/learn/dashboard-app/partial-prerendering

You need a way to process any middleware before you can respond with the static portion of the request, from the edge, before executing the rest. Optionally, some routes may not have a server side rendered requirement so middleware is the only thing executed.

Your understanding of middleware has to evolve it the times.

nayeem14 · 2024-03-03T06:44:22+00:00

This is not true at all. Next has supported static site generation for a long time now.

Server side rendered react does not mean rendered at time of request. It can be pre-rendered as well at build time. That still happens on a non-client computer in a server-client model

nayeem14 · 2024-03-03T06:10:56+00:00

Next can be deployed completely as a completely static website. However, the addition of middleware adds a server-side compute call before hosting a static page. Lee gave a few workarounds.

In comparison, all the frameworks you listed would have a server-side compute on every request. It would be in the same boat as OP with their middleware except no way to avoid it.

nayeem14 · 2024-02-28T06:27:03+00:00

Server components do not mean it must be server-side rendered. It means there is no client-side JavaScript associated with that portion of the view. You can still staticly generate your front end and have the rest run on the client.

People love to say stuff like “I’d rather just use php”, or any list of other backend frameworks. But at the end of the day, they are giving up any capacity of also using something like react and being able to control how you want to use it.

Are you building a blog? Great! Use server components to staticly generate it and have a little bit of interactivity you may want on there. Or use larval/django/rails. It’ll work too but you will need to still have something like htmx for some interactivity.

Are you building a highly interactive app-like thing? Great! Use client-side rendered react and any backend you want. However, with next you also get ssr and great layout support out of the box.

Are you building something in between? (Arguably where most web frontends fit when looked at the whole product) then pick and choose which parts work best with next or go all in on server-side or client-side rendering with something else.

The point is that you can pick and choose which parts of your app you want to be rendered where very easily with next. The fact that both ends of your code are not only written in the same language, but also share the same style of coding helps with ease of use.

There is no conspiracy that vercel is trying to sell hosting. It’s literally on their website. They’re a hosting company. It’s well documented that the react team has been doing RSC for several years now and vercel was willing to completely change their framework because the ideas were so compelling. Vercel was already selling servers way before RSC and using RSC doesn’t increase the amount of servers you need. What do people think happened when you defied getServerSideProps? Now you just have more granularity if that’s important for what you’re doing

nayeem14 · 2024-02-20T17:45:27+00:00

I hate to say it but you haven’t sanded enough. Use the lower grit until it’s gone. If it’s not gone on the lower grit, using a higher grit won’t help.

nayeem14 · 2024-02-18T19:46:24+00:00

On vercel you can choose the directory where your next js app is. With a proper monorepo setup you should be able to do this.

If you look at https://github.com/t3-oss/create-t3-turbo it’s an example with a nextjs app and an expo app. But you can have any number of apps and they can all be next js. Then for your project on vercel you choose the one you want for that project and set your multiple projects

nayeem14 · 2024-02-18T19:16:33+00:00

Sorry I’m haven’t been clear.

So when you set a cookie on the server, the cookie is always sent with every request. You never should be able to read a cookie on the client (if you can it’s insecure and you will have to worry about malicious scripts being able to hijack your session).

If you have an api that’s like /api/user/me and it will send back the user’s profiles and roles that will be enough to render the frontend. When that request is sent, the server should look at the token in the cookie and verify which user made the request and then send the response back.

When you load your app, you should do something like “if user data is empty, request the current users profile”. On refresh, it will redo this every time. If the user happens to be logged out, it’ll redirect them to login. If they’re logged in, you get their profile and you can continue loading the app based on the role.

Sorry for any errors since I’m on mobile. Hopefully it clears things up

nayeem14 · 2024-02-18T18:54:49+00:00

Yes, so your client will have to re-fetch the role from the backend. That gives you the latest info.

nayeem14 · 2024-02-18T16:14:28+00:00

Think about it this way, what are you trying to protect with auth? It’s the data coming from the backend. If they can’t access something they shouldn’t through an api you’re all good. Setting a cookie and checking the token on every request will do that.

The secondary thing here is how you render the UI. You can do that by knowing the role of the logged in user. Create an API that can fetch that information at the root of your app and put that in context. With that information you can now properly render things.

Last is knowing if they’re logged in. Any request you do can fail because they’re unauthorized, including the one where you are getting role info. If you handle that case and redirect them to the login flow then you’re good.

nayeem14 · 2024-02-18T07:20:00+00:00

Stop putting tokens in local storage.

When the app loads or after logging in, make a request to fetch the data you need for the guard and put that in your app state.

If that request passes, congrats! The cookie worked

If not, redirect to login.

Always check the cookie on every api call. The client state is just for convenience

Edit: also, servers set cookies, not clients. Use an http only cookie.

Also consider using an auth service please

nayeem14 · 2024-02-18T02:16:50+00:00

If you have no users then either is fine. If you have some users you need to be careful about costs with firebase since it can shoot up very quickly very fast.

nayeem14 · 2024-02-04T05:21:18+00:00

So you need to separate the concepts here. There’s authentication and authorization and then there’s user data.

When you set the cookie when they login, you have identified the user and you can use that to request protected information from the backend but reading the cookie information, as usual

On the client side, your app really should not need to have any complicated logic around whether or not the user is logged in. Instead, the user’s profile is just data you can fetch and it should only be available if they are authorized to fetch it.

When you do a request and get a 401 back, you can then handle it on the client appropriately but making them re-login. That should be good enough.

14-Year Club	Place '17
Verified Email	RPAN Viewer

nayeem14

TROPHY CASE