Subscribe to access the entire course.
🌶️ tip: unsubscribe at any time.
Ah, that's a great question!
Frontend at Scale is a bi-weekly newsletter (as in, once every two weeks) that is all about software design and architecture for frontend engineers.
Subscribing to the newsletter is the best way to support my work and encourage me to keep making free resources like this one.
I probably don't need to say this, but I would never ever spam you—and you can unsubscribe with a single click at any time.
Already subscribed? Don't worry, you won't get double-subscribed. Nobody deserves to read my terrible jokes twice.
Module 2: Understanding
[00:03] Alright, friends. Welcome to the second exercise in the course. And this time we’re going to put together a list of our influential functional requirements, now, as a reminder These are the requirements, the functional requirements that are only architecturally significant that may influence the architecture somehow. So again, for these, you don’t have to make anything up because we have their full list of functional requirements in the in the project spec. So if you go, if you scroll down here, you will find a section with functional requirements and these are essentially all of the features of the app, all of the things that the app can do at a high level.
[00:39] And the exercise for you will be to find out or try to figure out which one of these might influence the architecture somehow which are influential functional requirements. So I’ll give you one example. For example, this first one that is about the customers that can browse the app without being authenticated. There’s another related one here that says that customers can add food items to a shopping cart with or without authentication. Now this to me. But while both of these are influential because they mean that we are going to have to keep track of some of the actions that customers do, even if are unauthenticated, which means that we might have to create a concept of an anonymous user entity somehow or something like that. That may also mean that we have to sync their actions whenever they either create an account or they authenticate to their existing account.
[01:30] So all of those things might might come into my mind, come into play once we start designing the architecture. This doesn’t mean that we have to solve how we’re going to actually work around these problems right now. The point of putting together these this list now is just to keep a filter list of only the functional requirements that we think might be important by the time we start designing the architecture that is the exercise.
[01:53] In a nutshell, just, you know, copy and paste and put them together in a different list and maybe a little description about why you think that particular that particular requirement is influential or architecturally significant. Now, there is no wrong or right answer here. Your answer was my block, completely different than mine. And that’s okay. This all comes comes down to perspective and as well to experience. We have different experience. We are different people. So your list will look very different than mine. Probably.
[02:23] I’ll show you my list on the next video. I’ll show you what I could come up with. And yeah, I hope you give this a try and I’ll see you in the next video.