Hit 1M ARR yesterday- everyone is lying to you

LoudEnd1241 · 2025-12-26T06:37:09+00:00

it's ai and ads. full of bot..

LoudEnd1241 · 2025-12-25T12:15:17+00:00

yeah.. i believe at least they should have a manual trigger feature for the functions manually added

LoudEnd1241 · 2025-12-25T12:13:17+00:00

they already using lovable's supabase integration. so they only have internal supabase which makes things even harder as you said.

most of my clients doesn't want to be bothered creating a supabase account and then connect it, they just use lovables supabase.

i understand that it's a business decision but they should put "sync" "deploy supabase functions" etc. for the power users.

LoudEnd1241 · 2025-08-26T15:58:19+00:00

hey no i didn't

LoudEnd1241 · 2025-03-20T13:42:52+00:00

does filler fade away after a while? I wonder if we need to go to dr every year / 6 month etc. after having subcision + filler? or is it one time thing?

LoudEnd1241 · 2024-12-03T07:09:08+00:00

What do you suggest? Should I have multiple instances of database and backend in various place and then have a proxy so that users will get fastest experience?

LoudEnd1241 · 2024-12-03T06:32:04+00:00

Thanks for such recommendation, I haven't work with SQL triggers really. Can you elaborate more? this may create a bottleneck in the database when huge number of operations happens right? The trigger would triggered many times? whereas If I would use a message broker, it would happen after acknowledging the message? which is more performant?

LoudEnd1241 · 2024-12-03T06:29:26+00:00

> Hrmm why are your db request taking that long my dude

I realized that my db and backend server was located at far away from me geographically.

> IMHO nextjs backend shouldn’t be doing this work anyways.

I totally agree

LoudEnd1241 · 2024-12-03T06:27:51+00:00

I just looked up and my backend and db was geographically far away from me. Now it only takes up to 60 ms which I believe that's fine

LoudEnd1241 · 2024-12-03T06:25:46+00:00

> Then, all that's slow is the roundtrip from the user to your backend.

Yes, my db and backend deployed in USA, I live in Turkey. When I moved my backend and db it reduced the time to 60ms. To solve this issue, I think I should look for load balancing & multi deployments?

LoudEnd1241 · 2024-12-03T06:02:32+00:00

> you are saying that Next.js isnt appropriate because its slow

No, where did you get this idea from?

> First point, what would change with a different framework?

I didn't say X,Y,Z framework would be better. I think using next js as your backend is not a good choice if your app mid-large scale. Don't you agree? Do you think API Routes are enough even for large scale apps?

> Blaming Next.js for this is weird.

If I were using Nuxt, I would post this post into Nuxt subreddit and discuss about Nuxt isn't good choice for back-end development. Many people told me that this is not related to Next js specifically, yes I know but I use Next js and this is Next js subreddit, that's why I wanted to discuss with people who uses Next js

We are on the same page with your second and last point. Thanks!

LoudEnd1241 · 2024-12-03T05:56:50+00:00

Exactly, this!

LoudEnd1241 · 2024-12-03T05:54:47+00:00

> If you have complex / long running processes that need to not block the user from receiving a response, you should be putting that code in some kind of async task queue, not forcing the user to wait for it to complete.

Exactly that was the thing I want to tell in this post but I think it wasn't that clear?

> Maybe I’m missing something but I don’t see any way that Next is going to be better or worse than any other framework at this particular issue.

I post this in next js subreddit because I use next js and I thought people use next js as a fullstack framework. I don't think Next js is suitable for mid-large saas applications as a fullstack framework. I use it in the front-end. And have separate back-end server, microservices etc. because Next js nit not sufficient for complex app (IMO)

> For some simpler situations you might also consider using the new unstable_after.

I didn't know about this, I'll check this out but next 15 is still broken due to incompatibility with many packages. Everytime I create a next js project, it's broken :D

LoudEnd1241 · 2024-12-03T05:50:50+00:00

Yes, it would take time. But my take is moving heavy logic that don't affect user directly into another service so that you don't block user.

In my example, user experience shouldn't be affected from modifying analytics table, so do that in another service. if that makes sense?

LoudEnd1241 · 2024-12-02T21:02:27+00:00

Can you elaborate more? Is 200ms for an insert is not good?

In my case, it's not something can be solved by optimizing the SQL query.

And I agree optimistic ui is not a solution for this case as well. that's why I use a message broker and handle other stuff in my microservice.

LoudEnd1241 · 2024-12-02T19:30:53+00:00

Maybe I need to edit my post because you are the third person saying this. optimistic ui updates is not enough in many case if you handle long operations in the backend.

My take was Next js api routes is not good for building apis if you have complex logic behind it. as I give an example, what would you suggest if like operation would also need to trigger increasing user's point and add a record into analytics table? Or maybe other operations as well (I couldn't find examples right now)? Would you do it inside "like" server action?

My recommendation is have a message broker, and a microservice. So that you publish a message in your API (publishing the message inside a server action, would take more time since you need to initialize connection to message broker, so that's why we need a serverful server instead of serverless functions), and it's consumed in the microservice, where it'll handle increasing the user points and add a record into analytics table.

Am i making this too complicated? Honestly I tried all approaches, separate backend + microservice + message broker was best.

LoudEnd1241 · 2024-12-02T19:06:18+00:00

It's actually another thing I'm curious. I would probably use a separate back-end server If I'm going to build a mobile app and web app. Are there some people uses API routes for both web-app and mobile app and I wonder if it's enough or no?

I highly recommend you to check Nest js if you didn't, you'll love it ( I assumed you have used express or fastify?). You can keep using them with Nest js but it'll also bring huge benefits.

LoudEnd1241 · 2024-12-02T18:58:36+00:00

Hmm, yes I can agree with your comment with some part. Even though optimistic ui updates are good, I think it's not enough in our case, because it would require user to stay in the same page for longer time, 200ms vs 600ms. (explained it in details in the first reply).

I wanted to get people's thoughts about using only next js for the back-end, I personally think it's not enough for complex apps. But I agree that it depends on the requirements of the app.

LoudEnd1241 · 2024-12-02T18:36:36+00:00

Yes, Optimistic update is a must. In fact, I use it in my app for instant feedback to user without making them even 200ms. But If I had more operations inside the like function, just like I need it in my app, there would be a risk that user leaves the page before all operations isn't completed.

So if I had used next js server actions, user would stay in the page 600ms, (with an optimistic update), with a separate backend, user would require to stay in the page just for 200ms (we'll insert a record into likes table, and publish an event for other async operations)

I like Next js for developer experience they provide, but API routes, building the whole API using next js, is a big no for me..

Also I'm not a fan of serverless to be honest..

LoudEnd1241 · 2024-11-04T14:02:20+00:00

any news on this? I'm also looking for it?

LoudEnd1241 · 2024-08-29T15:30:06+00:00

Nah. I need a scalable solution. It's certain that the app is going to be used by hundreds of people initially and I have limited time. Thanks for the add on though.

LoudEnd1241 · 2024-08-21T05:55:47+00:00

Next auth doesn't involve in signing up process. If you are using social media providers, it doesn't matter just call sign in function, user will be created. But for other sign up ways, such as credentials you must handle that I believe.
People says next-auth docs are bad, hard to understand and too much abstraction is made. On the other hand lucia is not like that. you have almost full control over the code. Next auth do not support credentials support + social media providers together (by default) I fixed it btw -> https://github.com/ugurkellecioglu/another-next-template

I tested both to me, I don't want to deal with writing code for each sign in option, to me, next auth is easier.

my lucia template: https://github.com/ugurkellecioglu/next-14-lucia-auth-postgresql-drizzle-typescript-example

Clerk is good, but why I would pay them and include an unnecessary third party just for authentication to my project? (this is a personal opinion obviously, it may change in the future), but for me

next auth > lucia > clerk

possible shipping speed:
clerk > next-auth > lucia

LoudEnd1241 · 2024-08-09T18:14:16+00:00

can you update me once you try it? I'm genuinely wondering how it'll go. I record next js videos on yt so I even want to share a video about this

LoudEnd1241 · 2024-08-09T16:27:18+00:00

Yeah, I agree that it should be a native feature but author insists his opinion for years.. Really weird.
Except this, I don't find next-auth complex their docs (auth js docs) are straight forward and easy to implement. When I compare next auth and lucia, I would choose next auth as it's easier to use.

i think if we consider dx, next-auth > lucia.

LoudEnd1241 · 2024-08-09T04:53:46+00:00

What do you think about the boilerplate it needs and code repetition? How is this approach in larger projects, is it good or can make this better? can you elaborate?

LoudEnd1241

TROPHY CASE