If you put an index on the UUID field (because you have an API where you can retrieve objects with UUID) you have kind of the same problem, at least in Postgres where a primary key index or a secondary index are more or less the same (to the point is perfectly valid in pgsql to not have any primary key defined for the table, because storage on disk is done trough an internal ID and the indexes, being primary or not, just reference to the rowId in memory). Plus the waste of space of having 2 indexes for the same table.
Of course this is not always the case that is bad, for example if you have a lot of relations you can have only one table where you have the UUID field (and thus expensive index), and then the relations could use the more efficient int key for relations (for example you have an user entity with both int and uuid keys, and user attribute references the user with the int key, of course at the expense of a join if you need to retrieve one user attribute when retrieving the user is not needed).
*edit: sorry, misread that. My answer is not valid to your question.
original answer: because if you dont come up with these ints randomly they are sequential which can cause many unwanted situations where people can guess valid IDs and deduce things from that data. See https://en.wikipedia.org/wiki/German_tank_problem
Hence the presumed implication behind the public_id field in GP's comment: anywhere identifiers are exposed, you use the public_id field, thereby preventing ID guessing while still retaining the benefits of ordered IDs where internal lookups are concerned.
Edit: just saw your edit, sounds like we're on the same page!
Decades of security vulnerabilities and compromises because of sequential/guessable PKs is (only!) part of the reason we're here. Miss an authorization check anywhere in the application and you're spoon-feeding entire tables to anyone with the inclination to ask for it.
I also think we can use a combination of a PID - persistent ID (I always thought it was public) and an auto-increment integer ID. Having a unique key helps when migrating data between systems or referencing a piece of data in a different system. Also, using serial IDs in URLs and APIs can reveal sensitive information, e.g. how many items there are in the database.
Always try to avoid having two services using the same DB. Only way I'd ever consider sharing a DB is if only one service will ever modify it and all others only read.
Yup - an important distinction that wasn't obvious to me when I first jumped in. LiveViews are very opinionated and generate a ton of boilerplate. Not always a bad thing, but Elixir is elegant because of how spartan and expressive the code is - LiveView is kind of the opposite IMO.
I have only good things to say about TanStack start. I know there's some fatigue when it comes to full-stack JS/TS frameworks, since they re-invent ways to do data fetching, but are not in any way batteries-included.
I prefer it over Next.js and the whole RSC story, and it has sensible features that I missed in Remix (server functions from everywhere [1], middleware, type safety)
I wouldn't pick it as a full-stack framework, I will always keep my backend separate, but for a SSR-capable TypeScript framework it's amazing.
Try having a healthy relationship, kids, responsibilities, work, and some form of hobbies. If I don't write my thoughts, ideas, whatever, I lose the ball.
Oof. I'm sure Vercel might patch this issue. But I had had enough of these little annoyances. For example, the documented way to identify prefetches in the middleware has been broken for weeks (months?).
A lot of small issues that keep adding up. I'm not going to shill something else here, but I have a bit of Next.js fatigue lately. Still love the JS ecosystem though.
I moved away from Next.js, and switched to Astro. Originally I just wanted to go back to basics, but didn't want to bother with having to set up all my routes, templating, serving static assets, build tasks. Astro just handles all that, and it's SSR by default.
I also feel that Astro uses React/Vue as it was intended, as an interactive layer on top of HTML. It also made me realize how little I needed JS frameworks to begin with.
Next just started to feel like to much magic, the server actions felt weird, and just lots of things that required the "NextJS way".
Now:
1. There's a flicker in the content where the sidebar moves on the left
2. The title displays `docs.astro.build` for a split second before it says "Routing | Docs"
Especially the second is quite annoying. I see it in every Astro site.
I'm still using Next.js in my work and projects because I still think it may be the best way to ship React to production, but it used to be something fun, enjoyable and productive. sometimes I feel a bit sad about the direction it's going in since the move from pages to the app router.
The best way to ship React to production is with Vite. It opens up tons of options (Tanstack, RR, Simple SPA, whatever) and you don't even bring the hosting provider into the discussion.
This - I spent quite some time fighting the new Next.js conventions not working for me making a legit web app instead of traditional site, switched to vite and was like yay, things work again and so fast. Normally I am all about embracing the framework, but kept thinking for what was happening I could use PHP instead and host anywhere.
Another follow-up. Some libraries[1] started to break from 15.1.8 onwards, so you had to downgrade to the vulnerable versions the author mentioned as well.
reply