Your Next.js Project Doesn't Need Auth

It doesn't matter if you're building an app for money or for yourself, you should always be focusing on building the most important and most valuable features. In the early stages, login is not an important feature, and it can make initial development slower, so put off login.
Once you're ready to implement login, check out my video on using next auth with next 14 • Your Next.js Project D...
Chapters:
0:00​ Intro
1:14 App without auth
2:24 Fake auth
12:26 Conclusion
🔗Moar Links
My Website: www.sammeechward.com
Instagram: / meech_ward
Twitter: / meech_ward
Github: github.com/orgs/Sam-Meech-Ward

[@user-ty6di6ky2o]

Great video and theory. Always fantastic content and ideas. Glad to see you are back

[@SamMeechWard]

Thank you 🤗 I always love the comments

[@developerpranav]

This is a good mockup auth system, and now I'd want to implement this "fake" system in other places when I'm just testing something :) Great video! However, I do find that implementing Clerk Auth is much quicker and simpler (they have a signin with google button) Having a real auth will also protect your APIs!

[@SamMeechWard]

I really like clerk and i've had a lot of success using clerk in production applications, but I have one minor and one major issue with using clerk: ## Major Issue To use clerk, you'll end up using their library which forces you to use the ClerkProvider which wraps everything in a client component and forces all your pages to be dynamic with no option for static rendering. This is mainly an issue because it doesn't align with modern next where we're preparing for partial static rendering coming soon. Clerk will probably change this at some point, but i want to wait to find out if they do and I don't want to write my code around their current library if it's all going to change. ## Minor Issue It's still slightly more complex than a fake login system and I find myself thinking about too many auth things when i use clerk, like trying to reason about the UI and login flow. ## Another Issue You can't easily manage users in your database. I end up setting up webhooks to get a notification when a new user is created then i have a server side route insert that user into the database. It's not super difficult, but more work than I should reasonably be putting in at the start of development.

[@milkmyshake]

Great approach! Any chance to showcase a Pages Router version?

[@rezastella777]

Hey Sam great vid. just a minor point, the sound level seems a bit low.

[@SamMeechWard]

Thank you, i'm still trying to get the sound settings right on this new microphone. It might take a few videos for me to get it right. Let me know when I get it right.

[@adibk]

Could you implement Clerk or NextAuth in the same amount of time? Both of those provide all the login screens you need assuming you don't decide to build custom versions.

[@SamMeechWard]

This is a really good question and I would love people to try and implement my example with next auth and clerk and tell me what they think. I've done this exact scenario with next auth in a different video. It's only available to channel members right now but i'll make it public early next week. The video is more than twice as long as this one and there's much more complex code: kzbin.info/www/bejne/Y3vRdqishdKnY7M The short answer to your question is that it's more difficult with next auth and clerk for many many reasons. For example, how do you manage user data in your own database? In next auth you need to use a database adapter, in clerk you need to use webhooks. Clerk also has an outdated way of managing auth using a Session Provider. They will probably change this in the future and you'll have to change all your code along with it. Next auth is migrating their docs right now so it's hard to find all the information you need and something simple like a user_id doesn't exist in the session object returned by calling auth() so you need to figure out a nice way around this. There are more reasons but this reply is already too long

[@undefindjs2419]

I couldn't not disagree more. I am working on a project where the main focus is to have a user and create objects for the DB. And the absolute first thing to get working is the Auth/Token handle. If this doesn't work, the app is simply useless. You must have a working Auth/Token so you can check that API/DB access is working properly. And with Next 14 and RSC, it is very important that you only fetch content that you are allowed to see and that the cache control is correct. And with any kind of app that has Auth, you need to test the page in incognito mode with more than 1 user, so you can see that there are no problems. To solve Auth problems later in a project, you will only make ad-hoc solutions that will not be as good as if you did the Auth well in the beginning. If you have Auth in your app/web. Get it working the first thing you do and make sure the data/structure is correct.

[@SamMeechWard]

The fake login solves these problems by using cookies. It sets you up well for streaming and partial pre rendering. I could drop in next auth later on with minimal changes. Unless your backend is somewhere else or you’re using some session provider but that goes against modern next and is outdated for next 14