Hello, very good guide! However i have a question, lets say that there is a page to view the resturant menu and the client does the required requests to the api to render data... lets also suppose that there is a dashboard for the owner of the resturant in which he can view, add and edit more sensitive data like suppliers for a certain product. I would like that that kind of data is visible only if the GET request is made from the owner of the resturant (logged in obviously). Is it a good idea to check for auth inside a GET request and eventually add more sensitive data? There is a better way to do this?
Adding the Authentication to each route works, but if you ever forget to add that auth check you could potentially leak information. If you need to progressively enhance responses then you could always return the "basic" information and then if they have permission, augment the response with more data that is sensitive. If the admin needs different routes to CRUD all those resources, consider using Middleware and put the role check there. Then you can check all the requests in the same place and have some logic that says "If admin, you can see/edit these resources, otherwise you can only read them". Having all that logic in the same place will be make it easier to understand what's happening and to update it later.
Is the app dir ready for production at all yet? Really informative video - I want to get setup using supabase + prisma + next for my next project so I'll def be watching some more of your videos! Great job!
The Next.js team says it's still in Beta -- and it is. But it's gotten a lot more stable in 13.3. I think for any small app, it's basically ready to go. If you were building an enterprise app that needs stability, I'd hold for for a little longer. I think it'll come out of beta in the next couple of months.
@@ethan_mick Ah thats awesome and bad at the same time. I'm in the middle of building a large headless blog to replace my main website. Should I be building in tandom lol. I don't think I can have the app dir enabled and still use pages as I migrate over slowly...
@@spencerbigum1309 First, don't panic! The most important thing is building something, and I highly recommend you keep on your path and get your blog done. Once you've gotten your new version out, you can start migrating to the App Dir. There's no rush to do so, the `pages` directory isn't going anywhere. You can slowly migrate (page by page) in the future, so you can wrap your head around the new structure. And hopefully my videos will help! Keep it up :)
@@ethan_mick You make a really good point. Shipped is better than perfect, in this case, better than the latest update. Thanks a ton - will def be watching more and pobly more questions lol.
please Ethan what is the difference between working with api in the frontend and working directly with db with prisma? to be more clear what difference between data=await fetch('/api/restaurants) vs data=await prisma.restaurants.findMany() based on what we go for one or another?
In the first example you are making an HTTP request from the client to a server, which then (most likely) needs to query the database for the data. client -> server -> database In the second example, using Prisma, you are querying the database directly. client -> database. Fewer hops are better. When you can do the latter, you should. However this depends on *what* the client is and where it's located. If the client is a mobile app or a client side web app, it has NO access to the database. Therefore, it needs to go through the API server, and that usually happens with the fetch request. If the client is server side, then it can query the database directly and return the results (hydrating a page normally).
would it be possible for you to do a video about authentication where you implement verification by email using next auth credential not the magic link and go into details about different forms of authentication in next js
NextResponse extends the Response class (developer.mozilla.org/en-US/docs/Web/API/Response). It's an actual class, not a function, so you need to instantiate it when you use it. That's what the keyword `new` does here.
Nice work… a small detail but I would have made menu items a many-to-many relationship to menu since menu items might be able to exist in multiple menus. To get around the floating point issue for price, I always store prices in cents therefore as an integer. E.g. $20.99 is stored as 2099
You know... yeah, MenuItems being many-to-many is a great idea. I was thinking too much about the API structure when I put this together but if you were to build it, you would definitely want that. Mind if I put that into the write up? For money, that's definitely a viable strategy. I'd also take a look at things like www.postgresql.org/docs/15/datatype-money.html for whatever database you're using.
If I use server components how can I wrap my application with a client side state management like RTK or react context and still have my app take advantage of server componts, I'm not good at this new mental model, was wondering for things like state for things like dark mode toggling for tailwind
This won't work the way you want it to. The server components run on the server and won't share the client state. You can lookup information about the request (like cookies/headers) and use that to know some details about the request.
I am very new to backend stuff, if I end up using supabase with prisma as the ORM will the steps you provided on your videos work? I was working with others and they were having a lot of trouble with authentication, since they were not able to figure it out I am trying to connect the dots, or find resources that might be able to help me finish my app. Thank you for your videos they are amazing
I suggest passing an API Key in the header, like: Authorization: Bearer api_key_here Or a custom header X-API-KEY: api_key_herer And then read it from the headers. Or, if you pass it in the URL, use a query parameter and read it out that way.
Can you please also make a video where how we can seprate the business logic from the routes, so that like creating a service folder that serves the logic. This can create the functions in route.ts files like only barely 2 lines. I have been rejected from a job just as I did not create a service abstraction.
Interesting -- I would only recommend doing that if you are using the logic in multiple places. Otherwise it's an unnecessary abstraction, which is worse than no abstraction. However, this is a common request when building an API with React Server Components, since both will want to fetch the same data. I could whip something together around that.
@@ethan_mick Exactly! I tried to explain this in kind way. Anyways I'm upto the other interviews now. In terms, of next.js and server components a common fetcher does make sense though that only server frontend focused components and I'm sure can't be utilised on the API. Thank you for the response. Appreciate your videos and looking forward to learn more from you :)
I was getting errors on the api calls not working for me but when I change the returns like this they work now, return new NextResponse(JSON.stringify(restaurant), { status: 200 })
