Transcript from the "Application Architecture" Lesson
[00:00:01]
>> Jem Young: All right, this is it. We're in the home stretch now. We've built our server, we just installed Node. So now we wanna get Node up and running. We wanna allow it to accept requests and handle them appropriately. And then we wanna keep it running in the background, then we wanna use some sort of version control to make sure that we can rollback at anytime if we make mistakes.
[00:00:23] Let's talk about, briefly, application architecture. If you ask me what the difference is between a senior engineer and a junior engineer, I'd say it's about architecture. It's not about code, it's about the architecture. Cuz in the long run, it's the architecture and application that will get you. It's how you arrange your files, how you arrange your code.
[00:00:42] That sort of thing is we're thinking about long-term maintainability versus just, I'm a hacker who solves bugs every day. That's more like a junior engineer, senior engineers think long-term. So when we set up an application architecture, remember, it will live for a long time, maybe years. So you want to make sure it's set up in a way that makes sense to you and everybody can agree on.
[00:01:00] Because migrating files is not fun, [LAUGH] it is painful. Actually, I just gave a talk not too long ago about using code mods, cuz I had to rewrite a bunch of JavaScript code, and using code mods is an efficient way of doing that. There's probably a class on that.
[00:01:17] If there's not a class on code mods, it's worth taking. It's more advanced, but there's a class on that and I'll link to that as well. But in terms of basic application architecture, if you're talking about your most simplest, basic architecture, this is probably a good setup. You may disagree, and that's fine.
[00:01:35] This is the one I usually use. So I use ui, and then I use css, js, html. Then outside of ui, I use helpers, utils. Maybe something for authentication. If I ever want to talk to database, I put all that outside UI. But I try to constrain it within the folders that they represent.
[00:01:50] This doesn't seem like a big deal, but in the long run, if you're making a brand new application and you turn into a business, your architecture will catch up to you. Much like Facebook depended early days on PHP, and it turns out, people don't like PHP. But now they have they created an entire compiler so people can still write PHP to compile to something else, because of these early decisions that they made early on.
[00:02:12] I worked at a startup in New York, which decided to use Google Closure. So not the J, the S, the really kind of obscure language that Google developed internally. And because this person and I worked at Google, we saw to use Google Closure. And we paid for that later because no one uses Closure, and [LAUGH] I had to look stuff up that didn't exist.
[00:02:29] So all I'm saying is part of full stack is you have to make the decision about your application. The stack that you're gonna use. The code you're gonna use. And think about, can other people use it? Or are you just using it because it's cool? Are you just using Rust or something, that not many people know?
[00:02:43] Or Haskell? Or Lisp? [LAUGH] Or some sort of list language. Which is cool to you, but if you're gonna on-board 20 people, do they know Lisp? Do they understand your application architecture? If you say, the tests are over here and the code is over here, and it all makes sense to you, think about how other people use your code.
[00:03:01] Sorry, I know I'm going on about architecture, but this stuff is really important, it's something we don't think about a lot. But set your code up in the way that you want. And you'll see it's a lot easier when you think in terms of this sort of structure.