Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community!
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.Start your free trial
Tim Smith6,069 Points
createServer() Routing Question
I just want to check if I am understanding how the code in http.createServer is working for this example.
When a request is made to the server, will the server execute both the router.home() and router.user() requests. This doesn't seem to be a problem because only one will occur, but this seems like it would become inefficient as the number of routes grow.
Wouldn't it make more sense to have the server send the request information to the router.js file, which would then choose by way of a switch statement which routing function to use? This way, there's only one conditional statement and one function used in the routing, as opposed to going through every route, rejecting all but the matching one.
Justin Hill16,642 Points
Hi there, not sure if I have a good answer for your question, but just a few thoughts that might help you further your investigation of this issue:
As far as I can tell, you are correct in that the server request listener will execute router.home() and router.user() with every request event. As you note, this is not a very big deal right now - each function just contains a quick if statement to determine whether the request matches the conditions that determine whether or not to write anything back on the response object. You could add these router functions all day, and you probably still wouldn't hit a point where you're going to run into a performance issue. For my part, I think I'm with you in that I would prefer to create a single router module that just takes the request and response objects as parameters, and then does all of the work within that module to decide how to route the request properly - rather than calling each individual route method directly within my server request listener. This is purely a code organization preference on my part, however - you're still going to have to find a way to parse the route and figure out what to do with it, so you're still going to be executing more or less the same number of instructions, and we're talking fractions of milliseconds on the server here since you're not doing any costly operations like accessing a database or writing files to disk or whatever.
Generally speaking, I think it's a good idea to attempt to solve problems as directly as possible, and only begin to abstract away functionality once you know which problem you're trying to solve - but it's wise to keep the basic design patterns of the language you're using in mind, so you don't end up boxing yourself into a difficult implementation. Switch statements have a specific use case, and you might be asking them to do something a little too "heavy" that will lead to your code becoming very verbose and difficult to maintain. When you think about how complex your switch statement is likely to become (as you try to account for the various request.method and request.url combinations), things could start to get out of hand.
Then, if you really want to dig in to how you would solve this routing problem, check out this amazing video of a guy building out a clone of the Express.js framework (a server-side application framework that handles routing). He uses objects to build out what is essentially a routing table: you register callbacks for each route, and then when requests come in, it just looks up the correct callback and executes it. Pretty cool! https://jesse.sh/express-from-scratch/