Sessions is temporarily moving to YouTube, check out all our new videos here.

Javascript Enterprise Architecture

Florian Bauer speaking at viennaJS in August, 2017
189Views
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Hands-on approach on how to shift an organization to modern Javascript architecture, including a deep dive into project management, technical decisions and architectural challenges explained by code, components and task runner configurations.


Transcript


- Hello, everybody. I'm Florian and today I talk about JavaScript Enterprise Architecture. This per definition is a little bit more high level. But I try to go to the end to go a little bit down and also show some code. So that, you know, we have a dive from quite top to the quite bottom. So, first of all, I'm part of MoonShiner, we are a team here in Vienna. We are since two and a half years on the market. We are around 24 team members, and we help companies in the digitalization process. Especially when it comes to technical challenges. And we sometimes have quite an unconventional way. So, this is the reason why we are here in Vienna and working with different companies all over the world. We also have offices in Chandigarh, which is in India. In Zagreb and in Munich. And yes, I was an enterprise architect before. I was a technical coordinator before, I am also a full stack developer, so, all those kind of perspectives come into place for this talk. One thing, with that I like to start is that there is often this thing in companies, in bigger companies, that they compare architecture to cars, to housing, to kinda you count by house, involve the fundament and all those, with all the foundation, all those things. So in those cases I really want to place the thought, I usually do it for every talk, that programming is gardening, not engineering. This is very important because people tend to think once it's done, it kinda never changes, you don't have to touch it again, but this is basically not the case. It's actually the opposite. So, you have a garden, you can plan it very exact, you can make it wild, there are different approaches, but you have to care about it, there may be some stuff swimming around, maybe some plants that won't survive the winter, especially in JavaScript. But you know, it's a full time job and it's something, to have a good product and have a good architecture, it's something that has to evolve and has to grow and has to be kinda, look nice, but also be kinda stable, and work on the surface as well as down. And so when we come to enterprise architecture, it's a very, it's big, and enterprise architecture is actually, I think, the way that IT sees a company, not the company just from a software perspective or from an architecture perspective, but also from the processes and the organisation itself. So this is kinda the way of the idea, okay, there's this big organisation, how can we kinda manage the organisation? Because we're getting more and more important. This should be a really cool thing but it also has its downsides and this is also the reason why enterprises, we're not talking about green field new enterprises. They also have similar challenges and some of them as well, but we talk about enterprises that we're not faced with all those digitalization stuff that is happening right now. They are more kinda like, okay, we now have to do it as well. And so what's happened is they find this framework, they call it, so it's a framework, it kinda shows them how can we organise our enterprise architecture in a way that we can kinda change maybe the organisation to be more effective and be more efficient and make stuff more controlled, etc, etc. This is the Business Process Framework from the TM forum for tech rules, like can or should you structure your organisation that it can face future challenges, and then they kinda, so with this, we also, software architecture has to kinda mirror the organisation, so it's kinda vice versa. So the organisation kinda defines how software architecture, or enterprise architecture, is looking like. And it's the other way around and that's the reason why micro services are so popular, because you kinda can connect everything together, and if done right, everything kinda works, but you have all different kinds of stuff, because as well as in the organisation, if everybody talks to each other, there's maybe place for misunderstanding, etc, etc. So this is a general perspective on enterprise architecture, so let's go a little bit down, because this is about JavaScript enterprise architecture, so it's basically about frontend. I mean, of course there's JavaScript in the backend, you all know that, and this is also, but you know like, kinda, like older companies, they don't have that much JavaScript in the backend. They'd rather have PL/II and mainframe and other cool stuff, but not so much JavaScript, but they're getting there more and more, but today we're kinda more like frontend, so like userfacing applications. Yeah, so we go to JavaScript, and JavaScript, there is a lot of cool plants, and you don't really know is it weed or is it something else, is it a flower that looks nice? Which one is growing faster than the other, which one will survive the winter. So it's really, it's tough for enterprises that are used to plan years ahead, it's a very tough environment, because they don't know if you put on the wrong technology it all will kinda fail, so they are in these processes of talking about it a very long time, and after they come to the end, I don't know, Webpack comes and changes everything again. So this is kinda the situation the companies are in. So, to kinda, so, one thing is to explain the whole thing to management, to IT in companies, to quality assurance, data protection people, other offices in companies. So one thing I like to do is first of all explain what all this JavaScript thing is changing in web. And one thing is the classic approach, how websites always worked and also still work and this is still a valid place, just the classic approach, is that you have a computer, you type in a URL, you send a request to the server, and the server responds with HTML, sends it back to the computer, and the computer kind of shows what happened, and then you click a button, and the new request comes to the server, and the server kinda gives you back some mark up again and shows you the page. And maybe there's some JavaScript that is doing some little stuff, but you know, in general, request to the server, server provides HTML. This is the way websites work. So... What happens with JavaScript, or what is different when it comes to JavaScript? I mean, in a good case, you send a request to the server, the server renders the page, sends it back, but also gives a JavaScript file or a bundle, or there are different ways depending on which technology, but in general some JavaScript logic that is running on the computer itself and when you click on a button, you're not automatically just send a request, you're kinda like, the JavaScript decides what's happening. Change the page, maybe send a request, get some chase back, show the chase in a creative way, and you have this reactiveness and responsiveness, and this is something that kinda makes an application or a website or whatever feel a little bit more like that it's already kinda on your computer and you save also a little bit of bandwidth. So that's a kinda modern approach and I know you guys all know that, but for us it's so natural. It's important to kinda display it in a way that people understand, okay, why do we need all this kinda JavaScript frontend technology and frameworks. So, um... An example process that I know from former times and still know is you know, a few developers start a new application, it's defined, everybody kinda knows what to do, and the client is kinda super exciting and wants to do something, and so you kinda set up, do some, use some maybe framework to set it all up, it's working pretty nice. And so because it's working nice maybe, new features come and you're like, hey cool, I know where to put them, and I put it there, and I put it here, and then you know, management, maybe there was some change as well in management, they want something, like, super, they heard about it, like, maybe some consultant told them this is the super cool stuff so we really, and you're kinda like, okay, I can add that, and maybe I have to remove something, but it's okay, I just do some refactoring, there's time. So it's okay, and it works. Maybe you know, you kinda start having a little bit of technical debt, and then there's another feature that changes and you remove something again, and suddenly you're not so consistent with your structure and you're kinda like, the junior is doing something, and he's not using the right structure, but you don't have time, you can't care about it right now, so you kinda, you know, you kinda just allow it in a way, and, but you know, it all kinda works out, and the application grows, and then there's Webpack 2.0, or React Router 2.0, or React 0.14, I don't know if anybody had to transition from 0.13 to 0.14. It was a really tough thing, like, it was refactoring of Angular 2, maybe this is more, you know like, Angular 1, Angular 2 transition, it's not an easy task, especially if it's a big application. So and then you know, Gulp suddenly is as cool as Grunt, and you kinda missed that moment where Gulp was not the coolest thing out there anymore and you kind of have to think now in Webpack-y ways. So this is just kinda like, you know, this is just the environment changes really, when you think about it, how you wrote JavaScript two years ago, and how you write it now, and now they want to bring out a new JavaScript version every year, so it's gonna, at least it's gonna be still dynamic, which is a cool thing, but you know, for enterprises, this is like, oh know, how do we know if it's still like, actual next year? Yeah, probably you don't, but you know, it doesn't help, you need to do it. So, you have to work in that environment, I guess, most of you, every day, so you are, you can't really, what should you do? You can't tell 'em, nah, don't use JavaScript, because you're a JavaScript developer, you need a reason for your job, so... Our approach was pretty strong, hmm, strong? Pretty simple. Just kind of figure, like, the architecture needs to be kinda conservative but kinda flexible. So you kinda, you can't always be super leading-edge, but you should be flexible to kinda edit to your architecture, to your application. And we see here a lot of flowers, I hope you guys can see that. and it's about, basically you, okay, it's, I wanted to symbolise components. So components, they came out really strong. They're actually, this concept is pretty old, but this kinda centricity on components. This is still pretty fresh, I would say, because now everybody has, it's very component focused, these MVC patterns get, you know, they're MVC but in components. And you have different approaches but components, in Ember, in Angular, in React, in JavaScript itself, you have a very strong component-centric approach. Sometimes they are very functional and pure, sometimes they're just very kinda object-oriented, but... Components. And the good thing about components is that you kinda can, when one component is not cool anymore, you just kinda put it away and get a new component and add components to components and make pages to components and put everything into components and this is kinda a flexible way to kinda structure applications and make sure that the frontend is really reusable and you can reuse stuff. So we, kinda to make a smaller deep dive, this is a kinda React example, so it's very React-centric, and we were kinda like, okay, components, how can a folder structure look for components. And this is a very, there are different opinions out there, and basically what we did, we collected them all, kinda checked also for the client, and what we thought, like, it's actually pretty cool to put everything in a component. Sometimes we were, at one point we even thought about state handling, everything into the component, whatever is out there, but you know, it doesn't necessarily always have to be everything, but you know it should be a big thing. So you should be able to kinda stack the components also in a folder-y way, so that you have folders stacked in each other that kinda show, display, also the kinda complexity of the application. So what you see here is the index.jsx, that is basically kinda the entry point of the component. I kinda disliked the index thing because I like to do file search, but on the other hand, you could see it basically as an application. The application also has a very defined entry point and .exe that is triggered in the beginning, and the index.jsx is just a .exe of components. And you can put basically readme files in there, you can put tests in there, you can put styles in there, you can put all different kinds of things in there. You can also, if the logic is bigger, different kind of JavaScript files and you have it pretty much focused within the component. So this was kinda one thing that we liked, and I was thinking, what is actually the main reason why we like it? And the one thing, as soon as people understood the concept of components, and with people I mean design, product management, juniors, seniors, they kinda, it's kinda feasible, it's a software structure that is understandable for design because if you tell them this component is something you can cut out from a page and put it somewhere else, and then put it back again, kinda stick it together, you can create new pages. So they understand this concept and it makes a lot of things easier when you communicate about it, because in comparison to atomic design, it doesn't have a lot of complicated vocabulary. And... This leads to something more. Empower colleagues. We often face the situation that, you know, there was a couple of very good developers and some that were not so strong yet because they were new or they come from backend, or they were only HTML design, or CSS kinda designers, so, you have to have, you have a lot of work if they can't contribute to your code base, if you have to be the one that is always kinda putting everything together. So Eslint and Prettier for formatting and linting helps a lot, because it kinda, it enables you to make sure at least everybody's writing the same style of code and also make sure that you provide information for new people, that they can spend a week without you without asking you every second time how about this, vs. that, vs. this? So, kinda makes sure that you have the documentation. And juniors should be able to do stuff without the seniors. I always dislike the situation where a junior is sitting next to a senior developer, the full week the senior developer's kinda edgy because he has a lot of work and the junior is kinda not getting, you know, he's scared to ask stuff. So this is, they should be able to do stuff themselves, and make sure business development and design knows what components are, for example, so that they understand it. So for one project, we did basically a tutorial, and the tutorial was a step-by-step guide to set up your JavaScript stack. There's a very good example from who did a kinda tutorial where you kinda start with package chase, and we all know this long package chase, and so we really don't really know how it works, so we clone it, and then we do some kind of reverse engineering to see, okay, what actually happens when I press, like, npm start or yarn start, what actually happens, and then you have to figure out in code. So a tutorial is always good to kinda explain them at least the core concepts of Webpack, Babel, those things, what are they doing. So... The next one is discipline. Discipline means that you avoid technical debt and that you're not kinda, you're not getting lazy in doing things. This is a very, probably the most difficult thing at all. It always helps when you have a lot of people in a team that are really serious about it. This sometimes is not so fun, but it's really necessary because, if you're kinda getting lazy on one thing, the broken window concept. It means that when there's a house and one window is broken it's more likely that another window is also broken because it's already broken anyway so if I do this quick fix here, I'm rather willing to do a quick fix somewhere else, so this is something that kinda should be avoided. And decide maybe on technologies, especially for enterprise, for applications for enterprises that need kinda a life cycle, maybe don't use a super leading edge, where you know the next version that comes out will change everything, so when you, and there are a couple of technologies that are kinda stable. When you go, I mean, React 16.0, it's not gonna be so tough to adapt to React 16.0. You have a little bit of the error handling and you don't have the downsides of the route objects. So this is something that, you know, you don't have to refactor everything. Webpack. Webpack 2.0 to 3.0 was also kinda, you know, you could see that there's a kind of stability in the whole thing. So maybe decide on technologies that are, that kinda feel a little bit settled. I mean, you never know for sure, but you have to start thinking somewhere. And make sure technically that this is just one of the, it's even more important when you're in such a fast-pacing environment. And... To the end, I want to present you some stuff that we did with xxxlutz. They are focusing very strong on new technologies, especially in a JavaScript stack, and they're also doing a lot of in-sourcing to have the capacity in-house and be able to kinda control things that are happening. So what we kinda did was kinda an experimental project to see how a modern stack for a traditional business could look like, and what I'm doing is kinda show you a little bit of the codes that we were thinking about and kinda deciding on, and I want to explain basically some concepts. One concept that was very important, and I guess most of you guys, I don't have to tell, but this is JavaScript, so maybe I have. It's server site rendering. When you have an application that is facing to the customer, publicly available, without an authentication barrier. Server site rendering, there's really no way around it, you really need to support that. Google is getting better in indexing, but still, I mean, we heard it before, performance is everything. And if you are able to serve everything in the initial request, this is just a big performance factor. So this is our simple package, You could just download it and instal it and everything works magically, but, this is basically kinda a development platform for the internal team to kinda playground, to play with. And what we did is you see the component structure that we have here, we currently don't use Flow yet, we use proc types, even though proc types, they put it out of React, so they probably remove it, but refactoring was kinda like, okay, we stay with it for a moment, and we use SCSS, SCSS, because they already, yeah? - Can you increase the... - Ah sorry, of course. No, too much? So we use SCSS with CSS modules. Why do we use SCSS? It feels a little bit, you know, redundant in a way. Because SCSS is very understood by the internal team, just a simple reason, it's very, so SCSS won't change that much in the future as well and the CSS state of JavaScript is a really crazy place. You don't know what's happening. Like next year, you don't know, JSS, CSS, NJS-style components, CSS modules, plain CSS, post CSS. So, SCSS feels a little bit at least kind of stable. Yeah, so... One thing I want to show is that, let's see if I find the file, what we did very strongly is we used, we used absolute... We used kinda, we tried to use a lot of absolute paths. Absolute paths kinda means that you don't have to put ./ so those things you see here are not node modules, but they are absolute paths that kinda allow you to do a little bit of name spacing in a way, so that you are not, because, the bigger the architecture grows, the more you have ../ ../ ../ ../ especially when you have a very nested architecture. And with this you always have a way to kinda top-down paths, and kinda make sure that you have, even if you kinda change the position, that you can still use the absolute paths, you don't have to change the paths at all, and to do this, we did something in, what we did in Webpack, was we used... Let me check, there. We used resolve modules that basically allows you, in the Webpack bundling process, to kinda make a pipe that says, first look into source, if you don't find it there, look into node modules. Of course you're not allowed to add a component that is called React in, you know, source, but that's the reason why we always have, kinda, clients over shared, so you always have this kinda prefix that you see that is these node modules. And so we use, we use resolve modules in the build process and I think this contributes a lot to code readability. On the other hand, in .babelrc, because we use Babel for the server site rendering on the server, so we use the same code base for the server, of course the same code base for the server site rendering. And there we use module resolver. That is basically doing the same thing, but just as a kinda, just on the server in the Babel runtime, if you're used to Babel runtime, or in the compile process when you use Babel as compiling it. So every time a request hits the server and it has to kinda get all the stuff together, it uses to Babel to kinda, Babel module resolver, to have the functionality on the server, as well as in the Webpack bundle. So this is one thing that we kind of figured out is a strong asset. We used chest and enzyme for testing. I mean, this is I think not a really good test, but it kinda shows the idea, and um, yeah. And we also used testing in a snapshot way, the snapshot testing, that allows you to kinda compare the result to a snapshot that is committed to the repository. This is a kinda feature that was implemented during the process, and helps a lot to kinda keep the tests fast. And we used a lot of readme to kinda explain the whole thing and what we basically also did was a tutorial that kinda enabled you to build, step-by-step-by-step, the whole platform, so in the end, we have something for the juniors who are starting new, we have something to give them in their hand to work with. So when somebody new comes, he just plays the tutorial, and he's basically up to speed. So no senior developers are necessary to kinda help them and this is a one-time effort that helps to keep everybody on the same technologies there, kinda to the same situation. I mean there's of course more to tell, but I think time is quite over, so thank you for your attention, and... And maybe we still have time for questions. Thank you.