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, folks. Let me show you my version of the solution for this exercise. And remember that your solution and mine may look completely different. And that’s absolutely fine.
[00:14] So the first two influential requirements that I have here are the ones from the example we saw earlier about having to keep track of or having to be aware that we can’t assume that we have a logged in customer at all times. So we might need to come up with the concept of a visitor customer and maybe seeing the actions. I have a follow up question here about whether we need to persist the contents of the shopping cart when a visitor becomes an authenticated user. Is there some thinking that we need to do at that point?
[00:46] Then we have a couple of requirements that are about searching, and here I just have a couple of questions about whether we have an auto-complete UI. And if so, do we have the API endpoint for the auto-complete feature? So these may come into play once we start building these features. So I just want to call that out. And also these might bring up the question for the development team later on about whether to want to design a more generic autocomplete functionality, depending on how many pieces of the application use that functionality.
[01:20] Then we have a couple of requirements about a real time, so customers seeing a real time tracker of the order status and also being able to see a real time map showing the drivers location after the order is out for delivery. So any time I see real time in a requirements list a little alarm in my head starts to go off and tells you that this is probably something that we should pay special attention attention to. Which is why I have this follow up question about are there any other features that need real time functionality because this will help us determine how global or how local their real time functionality should be.
[01:59] And finally, I have this one about customers viewing ratings and reviews from other users. And I just noted that one because I just wanted to to add a note about fetching reviews should not block the rendering of the restaurant page, which might come into play. Maybe an additional point of information when it’s time to develop the restaurant page just to comply with our quality attributes are on performance that we have, and that is my list of influential functional requirements.
[02:28] Your list will look different than mine. You may have things that are even more influential or architecturally significant than the things that we have here. And if that’s the case, please, please let me know. But the point of this exercise was to just have you thinking about what things might influence the architecture from a feature or functional requirement standpoint. So I really hope you gave this one to try.