Architecture blueprint review

Since Lovable had no further questions, it generated the architecture blueprint. It is important to review it and make sure that there are no obvious mistakes. To do that, we can simply click on the Edit button and expand the view. Let's look at the architecture diagram first. You can see the post office layout here. With the counter at the top, this is our front end. there is also the authentication with the ID check. The main warehouse containing our data with all the edge functions. And there is also the external vendor, Spoonacular API, which will call to get our data. Now, let's talk about the databases. The database schema describes all the database columns. Think of it like a big Excel spreadsheet. For example, we see here the database that stores user profiles, including user ID, the display name, and the creation time. The pantry items table stores ingredient ID, the name, the image, and assigns it for each user. We've included a handout with the most common data types and their explanations. Now, let's talk about Row-Level Security, or RLS for short. By default, a database is a giant open room where anyone inside can read any letter. By enabling strict RLS policies, we lock every single drawer. The policies tell us who holds the key to these drawers. It is usually the admin of the account, or in our case, it's our user. When talking about RLS policies, it's important to cover CRUD operations in the database. The policies are defined around these four operations inside each database table. And they explain who is allowed to perform them. Create means adding a new row to the table, like adding a new ingredient to the pantry. Read is just looking at what is available, like seeing a list of pantry items without the ability to change anything. Update is for fixing things, for example, when the user wants to change their address in the profile table. Finally, delete removes the raw from the table. Say when the user wants to remove an ingredient from the pantry. The security guard is trained on all the CRUD operations and has the RLS security handbook to ensure they never allow unauthorized action. We already covered how authentication works on a high level, so let's now go over our example. Imagine a customer arrives at the counter and wants to create a PO box. This is equivalent to the sign up flow when you first create a new account in the app. The clerk will have to check your ID and enter it into the system to verify you aren't already there and that you also have no outstanding fines. Then they will create an account for you. They track this with an account number. Now they can request access to your PO box. Each time they do, the clerk will check your ID and send it to the PO system. The PO system validates that the account number has access to your PO box and then returns the response. Depending on the role level security policies in place, the user will be able to perform all or some current operations. Web apps work the same way as the post office example. When a new user creates an account, they receive a temporary token that serves as a proof of identity. It is called a JSON web token or JWT for short. Now when the user asks to do things, the front end sends that token along with the request so the backend can do security checks. That is how authentication works. React hooks are our self-service screens that live in the front-end. Now, let's jump to the edge functions. As we already learned, the edge functions are on-demand specialist workers that wake up, do a secure job like calling external API with a secret key, and disappear. In our case, we have two edge functions and both require calling our Spoonacular API. RecipeSearch, which finds the matching recipes based on selected ingredients, and RecipeDetail, that retrieves the full recipe card. One thing that is not part of this plan, but you might want to add, is caching. It's really important that you are aware of different policies that every external API vendor has around caching. For example, Spoonacular API only allows for maximum of one-hour caching of their data. And here is a question that most beginners don't know to ask. What happens if a user makes hundreds of API calls in a day? Every Spoonacular call costs money. There is nothing in here that stops a single user from running up your bill. We are going to decline this plan and add lovable to add rate limiting. It asked a question, what do we want to change? I would call it a technical concern. I will add here my request. Now that we understand the overall architecture, let's move on to the implementation plan. Lovable just added rate limiting. Let's take a look. You can see that it global and per user rate limits, which is what we wanted. We are ready to approve this plan. This is what reviewing the architecture design actually means. Not just reading it and saying, it looks good, but asking, what is missing? Now that we understand the overall architecture, let's move on to the implementation plan.