Day -4 of learning Web Dev #Backend-Engineering Day-4 → In simple setups everything comes from one origin (one server), so their was no issue of trust for the browser. → In modern setups we have separate servers for frontend and backend, which makes the browser to treat them as different places → When the frontend tries to talk to the backend, the browser blocks the request by default → Here confusion comes that we control both sides, but the browser doesn’t know that. →The browser here cares about protection from dangerous websites, → The browser decides what is same or different origins using protocol, domain, and port.Even a small change like a different port makes the browser think it’s a new origin, →because of this, the browser assumes cross-origin requests maybe dangerous → for safety purposes ,the browser applies a strict rule that blocks cross-origin access. This safety rule is called the Same Origin Policy → CORS exists only to handle this rule among the trusted origins. → The real problem happens when the backend does not clearly tell the browser that the frontend is allowed → The browser only listens when permission is given through special HTTP headers.These permission headers and rules together are called CORS → CORS is enforced by the browser itself, which is why tools like Postman work without issues. → Express fixes the problem by adding CORS early using middleware → Sometimes the browser sends an OPTIONS request first to ask what is allowed. After getting clear permission, the browser allows the real request to go through, →Access-Control-Allow-Origin tells the browser who is allowed to talk to the backend. #Day4 #WebDev #BackendEngineering #HTTP #CORS #HTTPS #APIs #SoftwareLearning #CodingJourney #DevLife

Day -3 of learning Web Dev Today I stuided and practise middleware, summarizing all the concepts: →A request does not go straight to the route,it passes through some functions first. These functions are called middleware. →Middleware is like a gatekeeper,it checks the request, stops it, or lets it go forward,next() means move ahead. →If a middleware sends a response, it should not call next(). →Auth middleware decides early whether the user is allowed or not. →req.body and req.query are just data sent by the client, not arguments or parameters. →Express does not read JSON body automatically. →If we don’t use express.json(), req.body becomes undefined. →“Cannot read property of undefined” means the data never arrived because the data were never parsed. ##Backend_Engineering Day-3 #Day3 #WebDev #BackendEngineering #HTTP #CORS #HTTPS #APIs #SoftwareLearning #CodingJourney #DevLife

Day -2 of learning Web Dev #Backend-Engineering Day-2 First practise some tasks related to http to implement what i have stuided yesterday , then studied Routing and here is summary of it : HTTP is about : WHAT you want to do(PUT,POST,GET,DELETE etc) →while Routing is about: WHERE you want to do it →routing is basically mapping URL parameters to a server side logic → static routing: address does not change →But a limitation arises in static routes that we can’t create a separate URL for every user, so the route needs dynamic parts that change based on which user is requested. Here dynamic route come into the field →Dynamic routes use placeholders like /users/:id so one route can handle unlimited users by reading the actual value (like 92) from the URL and fetching the correct data. → Here another point arises that when we need to send extra details like filters or page numbers not a specific identity, we can’t put them in the body because GET requests don’t allow a body, and using path parameters for this would be confusing. →Query parameters exist to send extra instructions like search, filters, or page numbers in GET requests, because they describe how to get the data, not which data. → Nested routes are used to show relationships clearly: for example, users have posts, so /users/123/posts means “all posts of user 123,” and /users/123/posts/456 means “post 456 of user 123.”it makes the URL match real-world relationships. → Versioning solves a real problem: when an API changes, it can break existing clients. By adding versions like /api/v1/products and /api/v2/products, old clients keep working, new clients can use the updated API, and you can safely update or deprecate features without breaking anything. → Catch-all routes handle any URL the server doesn’t recognize, so instead of confusing behavior or errors, the server responds with “Route not found,” making the API predictable, user-friendly, and easier to debug.

#Backend Engineering Day-1 ----------------------------------- 1st Topic ---> The Big Picture of Backend ------------------------ summarized in the picture below . And we have the same backend shape everywhere Doesn’t matter : Node,Java,Go,Python All follow the same flow. ----------------------------------- 2nd Topic ---> The Transport Layer -------------------------------- Here just summarizing what i stuided today: HTTP A lang client and server use to communicate. Everything starts with HTTP. A client sends a request. A server sends a response. A request has a method, a URL, some headers, and sometimes a body. A response has a status code, headers, and a body. HTTP methods GET is for reading data. POST is for creating something new. PUT replaces existing data. PATCH updates part of it. DELETE removes it. OPTIONS is not an action. It’s a question. It asks what is allowed. Status codes Status codes are just outcomes. 2xx -->things worked. 3xx --> resource rediraction. 4xx --> the client messed up. 5xx --> the server failed. Browser security and same-origin policy Browsers add another rule called same-origin policy. By default, JavaScript is not allowed to read responses from other domains. This exists for safety. CORS and controlled access CORS exists to relax that rule, but only when the server agrees. The browser asks. The server answers. The browser enforces. If the server allows the origin, the browser lets JavaScript see the response. If not, the response still arrives, but JavaScript is blocked from reading it. Simple requests vs risky requests Some requests are considered safe and simple, so they are sent directly. Others are risky, like PUT, DELETE, JSON data, or custom headers. For those, the browser sends an OPTIONS request first. This is a permission check, not a real action. Preflight caching To avoid repeating this check every time, the server can say how long the permission is valid. The browser caches that decision. HTTP caching Caching exists to avoid asking for the same data again and again.

The Project I did was for @Abdul Muqeet , Great 3D Animator!