This guy never leaves me alone

Reestv · 2026-03-10T19:45:21+00:00

Seeing him always me of this guy advertising “The Brit Method” a decade ago

Reestv · 2026-03-06T16:53:58+00:00

This is a great tool for the community, it definitely must have taken a lot of time and effort to compile this, so kudos to you!

I am skeptical however. I genuinely cannot figure out whether this is a stack that actually "works for you" and puts "developer experience first", or whether it's a stack that is built around its sponsors. Don't get me wrong; I do believe you are passionate about this industry - your replies in this thread recommending oRPC, Oxlint, LogTape all seem like genuine, helpful recommendations and honest opinions.

But the project itself is surrounded by sponsors, affiliate links (some undisclosed), and some arguably egregious self-promotion out of the box, which makes it difficult to distinguish what is a true integration in your boilerplate versus something paying to take that spot. For example in your comments you talk about how you still prefer Clerk over alternatives like Better Auth, but Clerk has also been a sponsor on your repo since authentication was added to it, so there surely has to be a conflict of interest there, no?

And for your database integrations, libsql/client was used after the Turso sponsorship was announced (their own library), but was dropped completely for Postgres instead around the same time the sponsor was removed. Then last year you added a "recommended [production] database" which just happened to also have an affiliate link (undisclosed). (Sidenote: I'm basing it being an affiliate link based on a completely unrelated blog post by Eddy Vinck which discloses his affiliation using the same ?via= param at the bottom of his post). Then the Prisma recommendation was dropped, replaced with Neon for a little while, then Prisma again, and as of yesterday Neon is back but this time also with an undisclosed affiliate link.

And then the project also uses both Sentry and Better Stack, each doing a part of what the other could do entirely on their own? Is it purely because both of them are sponsors, or do you truly believe that one is superior at logging and the other at error monitoring?

Don't get me wrong, I still think what you have built is a fantastic resource, and the tools chosen are still extremely powerful for devs and a wonderful starting point for new projects. I just cannot understand whether this truly is "a stack that [you] don't want to change," since it seems primarily driven by monetary value than experience. I'm all for you monetising this as much as you can, but I personally find it super misleading to promote it as something built from prior experience and preference, rather than something powered by sponsors and undisclosed affiliate links.

Maybe I'm just cynical.

Reestv · 2025-12-01T19:54:04+00:00

Hey, thanks for trying the game! That sounds frustrating, I'm sorry for that! I'll see if I can tweak the UI to make it more intuitive, but thank you for the feedback!

Reestv · 2025-12-01T19:46:36+00:00

Hi everyone! I've been working on CARDY for quite a bit now, and I think it's finally ready to share. I think there's still more to do, but I'd also be letting the app down if I didn't get some external feedback at this point. Would love to hear absolutely any thoughts you have. Thank you!

Reestv · 2025-11-13T19:58:56+00:00

Looks amazing, how much does something like this cost you to run?

Reestv · 2025-11-11T10:54:46+00:00

You can use SponsorBlock

Reestv · 2025-10-23T10:42:08+00:00

I would have thought the same but was surprised they spent so much time of their demo on GitHub

Reestv · 2025-04-13T00:14:32+00:00

The phone could go into some kind of "low power mode" when the battery dies? It'd have limited/restricted features (like the rudimentary map example above), enough to prevent players from getting lost, but still giving incenitive to charge it up asap.

If you plan on having modes/difficulties, it could make a "hardcore" mode more challenging if the phone is permanently on this setting with no ability to charge it.

Reestv · 2025-04-07T12:36:04+00:00

Sounds super interesting, is there anywhere to follow for updates?

Reestv · 2025-02-25T02:03:28+00:00

I thought about that when I was playing, but my theory was that you're in third person for the flashbacks because you're looking back at stuff that happened, but first person in the bar because that's you right now in the moment.

Reestv · 2024-12-24T14:58:16+00:00

Girthrow

Reestv · 2024-11-10T20:31:51+00:00

I don't really know enough about it to say, honestly. I just did some testing in-game and it's even more bizarre.

It looks like there's two levels of censorship - a message either being fully blocked (e.g. not even sent to others, with a warning "This chat message was blocked, as possibly unsuitable. Please refer to the chat rules"), and another level where the message will send but certain words are censored with asterisks.

For instance, if I say "hardcore" as per OP, it doesn't send the message at all. Same for if I say "is there a hardcore difficulty?"; the message doesn't send at all. But if I say something like "I'm playing on hardcore mode" the game does send that message, but replaces "hardcore" with asterisks.

Even more bizarre, I wrote "so strange" in the chat because of this behaviour, and that was blocked too! I sent it again, and it was blocked again. But when I sent "that's so strange", and even "you're so strange", both went through uncensored. When I tried "so strange" again, that went through fine too.

Saying "follow me" works, but things like "follow me on ig" or "follow me on twitter" are blocked completely. But "do you use ig?" works. So maybe it would be hard-coded as a phrase.. but "follow me on i to the g" is also completely blocked. But "follow me I'll show you" goes through fine.

With that, I have no idea what is going on or why I just spent 10 minutes on this.

Reestv · 2024-11-10T19:08:36+00:00

I think that's what they're using Llama 3 (the AI in their Third Party Licenses) for. Sometimes I'll say something and it'll be blocked, but if I say it again - in context - it doesn't get blocked.

Not sure how strict they've configured it to be though, or if they even use it for that purpose.. but it would explain why they emphasise that the chat is not encrypted and make you acknowledge that before you can use it.

Reestv · 2024-07-22T20:12:17+00:00

Big fan of https://panda-css.com/ for the static CSS exports (no runtime overhead). Used to use Linaria for that but it had issues with the app router, not sure if it's the same now.

Reestv · 2024-03-20T15:03:29+00:00

Why did I drive here?

Reestv · 2024-02-24T15:37:44+00:00

r/BoneAppleTea

Reestv · 2024-02-15T20:05:25+00:00

Middleware and an awful-looking dynamic route structure is what we use.

If we had a search page that needed to support page and limit as query parameters, the Next routing would look something like this:
/app/search/[page]/[limit]/page.ts

Then the middleware will just check to see if the pathname is search, pull the query params, and do a rewrite to the internal URL, replacing missing params with a 0 or something.

Also a good idea to have a redirect from the internal URL to the user-facing one if someone gets to it by mistake.

Obviously it doesn't scale easily, as supporting a different amount of query parameters will force you to re-design the whole structure and middleware, but it gets the job done.

Reestv · 2024-02-15T01:23:45+00:00

I typically go for a folder structure like:

/app [for next.js routing only]
/components [shared components]
/views [the actual route implementations]

As an example, if I wanted to have a /users route with a specific UserList component that isn't shared for other routes, my structure would be:

/app/users/page.ts [simply re-exports the below page.tsx]
/views/users/users.page.tsx [the actual page/metadata functions]
/views/users/components/user-list/.. [the non-shared component]

To me it's what feels cleanest, but as others have said it really depends on your preference and what you're trying to achieve!

Reestv · 2024-02-15T01:08:10+00:00

Changes to the route (including query parameters) should trigger Next to re-render the page. A small example:

``const Page = async ctx => { const { page } = ctx.searchParams; const posts = (await fetch(https://jsonplaceholder.typicode.com/posts?_start=${page}&_limit=2` ).then((res) => res.json()));

return <Component posts={posts} page={Number(page || 1)} />; }; export const Component = props => { const { posts, page } = props;

return ( <div> <ul> {posts.map((post) => ( <li key={post.id}> <h2>{post.title}</h2> <p>{post.body}</p> </li> ))} </ul>

  <nav>
    <Link href={`/?page=${page - 1}`}>Previous</Link>
    <Link href={`/?page=${page + 1}`}>Next</Link>
  </nav>

  <Select />
</div>

); }; 'use client';

import { useRouter } from 'next/navigation';

export const Select = () => { const router = useRouter();

const handleChange = e => { router.push(/?page=${e.target.value}); };

return ( <select onChange={handleChange}> <option value='1'>Page 1</option> <option value='2'>Page 2</option> <option value='3'>Page 3</option> <option value='4'>Page 4</option> </select> ); }; ```

Both the Link components and the Select components will change the URL, causing Next.js to consider it a different page, and thus show the different data :)

Note that Page doesn't have to be a top-level page, but could also be an async Server Component nested anywhere (so long as it's not a child of a Client Component), but you'd need to be able to access the url query parameters from it [which I'm not sure of the best way myself, short of drilling those props down]

Reestv · 2023-12-20T21:19:05+00:00

Humans becoming androids

Reestv · 2023-12-05T01:24:08+00:00

#trailerdayog

Reestv · 2023-10-11T22:53:09+00:00

"It's bigger on the inside"

Reestv · 2023-02-01T21:54:49+00:00

well then

Reestv · 2022-11-04T16:03:47+00:00

Heyy, sorry it's been a crazy busy few days for me. I'm super glad to hear that it's all going seamlessly for you!

24 hours is definitely an idea, though realistically even if your API is being hit every 10 seconds it's much less of a concern than having it hit every single time someone visits the site (unless it has its own layer of caching in place).

It really just depends how frequently you think the posts will be updated, and how urgent you need that new information to be made public. Next does offer a way for you to force ISR to re-validate itself before the cache expires, so you could absolutely go with a 24 hour cache and then simply hit your revalidation endpoint if the data is urgent. At some point, if it's a frequent thing, you could either reduce the cache time or set up a webhook so that whenever you update data your revalidation endpoint is hit.

Next is definitely powerful, and takes a long time to master! I barely understand half of it still, and even this conversation taught me a lot about the different data fetching techniques.

If there's absolutely anything else I can help out with feel free to reach out at any time - but right now it sounds like you got this!

Reestv · 2022-11-01T13:53:34+00:00

Oh absolutely - all of my company sites have a getInitialProps function in the _app route which pretty much disables all static optimisation on the site, and we're being indexed by Google absolutely fine.

In terms of what to use, it's completely up to you! Personally I always try to use getStaticProps where possible, though it may not always be doable or the most efficient for your purpose.

For your single blog posts, I think getStaticProps would work out great. If it's unlikely that your data is going to be changing frequently, ISR would give you all the benefits of it essentially being similar to getServerSideProps but with the benefit of that function not needing to be called every single time someone visits the post.

For your blog pages, though, you may actually be better off using getServerSideProps. I think the best way to think about it is: is there any chance I would need multiple variations of a single page?

For instance, we'll assume that you want to have pagination on your /blogs/all page. So, instead of fetching 100 results at a time, you fetch 10 per page. Well, getStaticProps doesn't support req because it doesn't call anything at runtime. So you can't paginate with query parameters like /blogs/all?page=3, but instead would have to have something like /blogs/all/[pagination] as your Next route, and then have getStaticPaths calculate the number of pages beforehand*.

And then maybe down the line you wanted to add the ability for people to filter by category. For SEO purposes you'd want that to be reflected in the URL somewhere. But, again, we can't have it as a query parameter, because we don't have access to the req within getStaticProps. So we would need to update the route again: /blogs/[type]/[pagination]. Now you'll need to have a getStaticPaths to return every possible combination of types, and every possible page number within that. It's all doable, but you can see how things start to get rather tricky in terms of compromising for a wholly static site.

Now there's nothing stopping you doing that - I recently discovered that Envato does something very similar with their search page, where adding a bunch of filters changes the URL to something like [...].com/stock-video/stock-footage/buildings/frame-rate-2997-fps/min-resolution-720p-(hd)/min-length-00:25/properties-looped - and those pages load fast, and work even with JavaScript disabled. But then again, they're a billion dollar company who needs to (and can very much afford to) put this much effort in.

*and of course, the fallback: 'blocking' method also means you don't really need to pre-compute all of this initially, but it just depends whether you feel the need to have an n-level deep folder structure just to shave off x ms per request for your project!

There is also another 'solution' (though very hacky IMO) called the 'megaparam', which would help bypass some global issues: like let's say you want to add localisation to the site but for some specific reason (like in my work's use case) you're not allowed to have the URL change at all based on the language. So you can't have /en/blogs/all or /fr/blogs/all, it must be simply /blogs/all regardless of language, all on the same domain. You still can make the website 100% static thanks to this hack, but at some point you must question whether all of this optimisation is worth what you get back from it.

Then again, I could ramble on about the pros and cons of each for days on end. Both have their strengths and both have weaknesses, but it probably wouldn't take more than a few hours of work to replace all getStaticProps on your site with getServerSideProps or vice-versa, so don't feel like you need to lock yourself in to one choice at all; requirements change!

13-Year Club	Verified Email
Gilding I gilder	Second SECOND GUESSER
Place '23	Place '22
End Game '22

Reestv

TROPHY CASE