Modern Best Practices: Sounds Good To Me stack (SGTM stack)

• _{0:00 - Intro}
• _{0:01:02 - What is SGTM and how did it came about?}
• _{0:03:21 - Why do we need new modern "Best Practices"?}
• _{0:04:29 - The modern best practices "espoused"}
• _{0:06:02 - "StoryBook" [Component Libraries]}
• _{0:06:55 - How does Storybook benefit the user?}
• _{0:10:25 - Advice for those who want to use "StoryBook"}
• _{0:10:34 - Two camps when it comes to Storybook implementation}
• _{0:12:56 - "GraphQL " [Query Language]}
• _{0:14:44 - Benefits of using "GraphQL"}
• _{0:16:26 - "Reducing the number of requests is important."}
• _{0:17:15 - GraphQL in relation to HTTP2 and HTTP3}
• _{0:19:22 - "TypeScript" [Javascript on Steroids]}
• _{0:21:01 - Advice for Typescript implementation}
• _{0:21:54 - "Monorepos" [ "Code-storage" strategy]}
• _{0:22:40 - Monorepo is a way to govern all the codes relating to a Domain}
• _{0:23:15 - Benefits of "Monorepo"}
• _{0:24:53 - Advice for anyone implementing Monorepo}

Hi, welcome back to the Goodfrontend Show. Previously, we've been discussing about DXCP, Frontend-as-a-Service, and it's mostly focused on technology and also we've discussed about in-house architects and composable teams, and it's mostly focused on people. Now we're gonna be talking about the new topic, which is the Sounds Good To Me stack. And, it's partly focused on process and partly focused on technology. So, to start off, what is the Sounds Good To Me stack and how did it came about?

Yeah, Sounds Good To Me stack which is SGTM, is, Storybook, GraphQL, Typescript, Monorepo. So how it came about is that we decided as a team here at Goodfrontend, we've been operating for the past two years. We've done five projects already back to back. It's crazy <laugh>. But, uh, we've done all these five projects in parallel in the last two years, and we thought, okay, what is it from those five projects that we have done that is common and that is good, that we want to take over for our sixth project? And our engineers came up with, oh, they said, Sounds Good To Me, <laugh>. I was like, what do you mean Sounds Good To Me? Sounds Good To Me. As in SGTM, storybook, GraphQL, TypeScript, and Monorepo. And so there you have it. And I thought about it and, and I said, oh, yeah, we've used Storybook, we've used GraphQL, we've used TypeScript, and we've used Monorepo for all of those projects.

Why do you think it's important to introduce this new modern development best practices?

Yes, to be fair, we're not introducing anything new. All we're doing is looking at the last two years and what, uh, we saw in common in all our projects. And it probably is similar to other companies as well. And if you are not using it, I would encourage people to use it. I think it has been greatly beneficial to us, and this is effectively our way of giving back to the community as well. And, what I would say is that best practices in general is important because you want a way to be able to successfully replicate a project. So when you are doing a project, you want to gather the knowledge and the experience that you learned from those different projects and try to capture the things that are good and repeatable so that the risk for the future project is less. And that's what we're doing here.

Best practices in general, why do we need new modern best practices? Well, firstly, Infrastructure has changed dramatically since the dawn of cloud technologies. It's crazy for me to think that for the past two years on all five projects, they have all been in cloud native technology. We've used GCP and AWS mostly. So infrastructure has changed. A lot of Infrastructure now is done in the cloud. And I can't remember the last project that I worked on that is not cloud based. Secondly, Application Development also has changed in the days before modern development that we have now, Java and C# were the dominant languages for developing general applications. And the style of programming that would've been common was using the Model-View-Controller architecture, and Object-Oriented Programming. Today, the best practice now that is being espoused is Functional programming, Asynchronous programming and Reactive programming.

So Application Development has changed, and the darlings of programming languages that are taking this forward is Python and JavaScript. Python for data, mostly, data programming and JavaScript for General Application programming. In Frontend development also, things have changed heavily with the dawn of component based frameworks like React, Vue, Angular, Svelte, Web Components, everything is done in web components, and browsers also have changed in the last five years. So almost every single browser, Chrome, Microsoft and Safari are based in chromium, which is an open source core engine for web browsers that is developed by mostly Google. And Firefox is always moving at the same pace. So things just have changed so fast in technology that in order to support that pace of change, best practices has to be created to ensure that projects are done successfully.

Now let's take a look at the individual pieces that makes up this Sounds Good To Me Stack. Let's start off first with the Storybook. Maybe just give us an overview.

Storybook is effectively a component library, so a bit of history, those who are coming from the print world, we had this concept called style guides. And when we moved to the web, people might have heard of frameworks like Bootstrap or Foundation. In the past, you might have heard of terms like Design Systems. So these all in combination really from a development perspective, the modern term for it now is component libraries. And the component library that rules them all is Storybook. So Storybook is a component library, and what it does is that it allows you to document different components and allows you to develop components in isolation.

So what does this, how does this benefit the user?

Frameworks are built using components. We no longer build pages today. We build components. The page is just a frame, but everything else inside it are just a bunch of components. And Storybook is helpful because it facilitates component driven development. It enforces it in a way. And through this Storybook platform, you can build your, let's say, a banner component and you can create stories to say, okay, this is the story of the banner. When you have a banner and a description. This is a story of the banner when you have a banner and a description and buttons. So you can show different iterations of the components. You can show how this component would react depending on the data that is being fed to it. So other benefits in for Storybook, for example, our developers use it to develop components in isolation. For those who are coming from a back-end software engineering background, they might have heard of things like test driven
development.

This is similar to test driven development because what you do with Storybook is that you can create your mock data, you can develop your component, and then when you're extending it, you can extend it and you can easily go back to the previous stories or tests that you have created and see how your component responds to the new data. That's one benefit for developers, it's developing for isolation. The other benefit is that it enables you to have a place for documenting components, and that is also helpful for content managers. So in some of our projects we use Storybook to visualize in the Content Management System. For example, if you were, going into the Content Management System, one of the problems that people have when they go headless is that they can't see what they are, uh, the components that they're creating.

And what we do is we often, we connect Storybook into the Content Management System in order to enable the content manager to see a preview of that component. Another benefit for Storybook that we use it for is for our QAs, they often connect this to tools like Percy from BrowserStack, and it enables them to do visual regression testing. So Storybook in general gives benefits to developers, to QAs and to content managers as well. And of course, for designers, we also put in there, we document in there the basic style guides of typography, colors, core components like buttons and form inputs, error messages, and so on. And we are able to easily share a link to designers and the business, and we can use that as a tool for communication.

Is there any advice that you could give for someone who wants to get into using Storybook?

What I find is that there tends to be two camps when it comes to storybook. There is the Camp A who encourages it a lot and says, yeah, Storybook is awesome, and there is Camp B who thinks that Storybook is just an overhead. And what I would say is Storybook is great if you use it. If you think of your development process and you integrate storybook a lot like TDD, then it's incredibly helpful. If you are using Storybook not only for development, but as I mentioned for visualizations and previews for Content Management System, then it's helpful. If you implement automation testing and visual regression testing, then it is helpful. So that's camp A. So if you do those things, it's actually great. But what I often see in projects whereby people complain about Storybook is that they're just not using it properly, or at least they didn't really get a buy-in on how Storybook is used. And so what happens is that Storybook becomes unmaintained. The only ones who care about it are developers who introduced it, and people just see it as something that takes time, but has no benefits. So my key advice for anyone who wants to use Storybook is clearly understand why you want to use Storybook and go from there. Don't just introduce it for introducing its sake, actually use it.

So really, to really enjoy the benefits, you have to use every single thing that you've just
mentioned there,

<laugh>, yes, yes, exactly. So talk about it cross-functional, and if you use it, it's incredibly beneficial and the overhead is worth it, but otherwise, you know, it's, it's pointless if people don't maintain it and people don't use it for visual regression, for previews and for developer documentation and TDD.

Okay, let's jump into GraphQL. What about GraphQL, can you give us an overview?

Sure. GraphQL is a query language. So similar to say SQL. SQL is a query language for
databases where you can say, oh, select from this table, the name and the address, and it'll give you the name and addresses from that table. GraphQL is a query language for APIs. So a simple analogy that I can think of is, imagine you are watching a football match. Congratulations to Westham by the way, well done. And you wanted to order takeout for everybody in your living room who is watching the football match, but everyone has different tastes. So you might order an Indian, you might order a Chinese, you might order a pizza, but you want to eat at the same time. So if Uber Eats or Deliveroo was efficient, what they would do is take your order, collect it from the different restaurants and deliver it all at the same time. That's a bit like GraphQL. GraphQL enables you to query, to ask for data from different endpoints and make it arrive at the same time in a single delivery. So as an overview, that is effectively what GraphQL is. It's a single endpoint that you can connect to multiple endpoints so that you can retrieve data at the same time and
specific data that you want.

What about benefits? Can you talk us through the benefits of using GraphQL?

Yeah, GraphQL in terms of benefits mainly is, as I already mentioned, is the specificity of data. So the downside, if you're not using GraphQL, is that when you call an API, it has a single response. Let's say I call the product API, it will always return to me all the fields that are available for that product API. So some people, might create what I call a poor man's GraphQL, okay. And what they do is they provide you a fields query. And in there you might say, you might say, oh, give me the default data, or give me the full data, or give me the minimum data, but it's not configurable, you know, apart from those, it's not configurable. But with GraphQL you can say Exactly, I only want the name and the description, and that's it. So it provides flexibility. Flexibility is the key benefit that comes with GraphQL.

What about advice? Can you give an advice to someone who wants to implement GraphQL?

The key benefit of GraphQL in the past was actually performance GraphQL was introduced in
2012 by Facebook, and they have been using it before they introduced it. And of course, in those early days of HTTP1, when HTTP1 was common, reducing the number of requests is important. When HTTP2 came about, and now we're in HTTP3, multiplexing is a thing. So, it's really not so relevant that you have multiple requests. And many people think that because GraphQL is quite chatty, I would say. So what I mean by chatty is if you look at the network tab in your browser, because it's, it's got a lot of graphQL requests that they think it's slower, actually it's not. It's just chatty. That's all it is. So it's important to remember that GraphQL's key benefit is flexibility. So if you want to have a single call, then do so.

If you want to break it down into multiple calls because some data is lazy loaded, then do so, also. The issue that people have is they don't seem to understand this. They don't understand the idea of HTTP2 and HTTP3 in relation to GraphQL, and so they don't realize that, you can do both. You can do either a single call, which has everything in it, but the downside is that the payload would be bigger, or you can multiplex it in the sense that you can have multiple smaller calls with smaller payloads, but of course there is an additional latency.

But the other thing that people need to think about when, thinking about GraphQL is caching. So depending on the frameworks that you would use, the caching is different. So in one project we used URQL, for example. In two projects, we used Apollo and Apollo client and Apollo server. And in one project we are using AppSync from AWS. So we use different types of GraphQL servers and we use different types of GraphQL architecture because those are all different projects. One is a startup and the other one is an enterprise. And in, uh, one case we even used Federated GraphQL services. So there is so much approach available with GraphQL that you need to think through what is the best way. But one thing that I would say is when it comes to caching, different libraries cache differently and, uh, there is value in caching and understanding how the caching mechanism work. It was a pain point for us in multiple projects actually. But now we've finally solved it. But caching is definitely one thing that you need to look into a bit more deeper when you're looking into GraphQL.

Okay, let's get into TypeScript.

The way I would put TypeScript is like JavaScript on steroids. So JavaScript is a very flexible
language, which you still have when you are using TypeScript, but what TypeScript enables you to do is that it gives you the types, as per the name, which actually, if you're coming from a Java or C# background, you are quite used to types and when you're developing larger applications and enterprises, types become more helpful because code is more read than written. So TypeScript in terms of overview, it gives types to JavaScript. Types in general is actually very helpful. As I mentioned, code is more read than written, it makes reading code a lot easier. So it helps a lot with code reviews, it helps a lot with catching errors. It helps a lot with defining data. And when you have all of these, the ultimate benefit is efficiency and speed. When you're able to read code faster and review code faster and catch errors faster, then development is a lot faster. So that would, that's the key benefit that I would say when it comes to TypeScript.

What about advice in terms of implementation?

TypeScript? Yeah, it feels so strange because, um, I've been using it for such a long time that I can't imagine living without it really. Mm-hmm. <affirmative>. What I would say is be consistent when you are using TypeScript. So it's very common for those coming from the frontend realm to be loose with typing. And when you combine that with the software engineers coming from the backend realm, you know, they type everything. So there's like a clash of thinking of how to type. I personally err more to the side of typing everything as much as you can mm-hmm. <affirmative>. So yeah, be consistent and don't use any.

And lastly we have Monorepos. Maybe give us also an overview.

Monorepo is effectively a strategy of storing code in one place, even if those pieces of code are not necessarily related. For example, the opposite of monorepo would be multiple repositories. You might store your infrastructure code in one repository, you might store your storefront code in one another repository, you might store your SaaS extensions in another repository. Monorepo is a way for you to govern all the code relating to a domain. So that can be the code for the whole company, like what a lot of big tech companies do, like Microsoft Meta and so on. Or that could be a section of the code that relates to that company. So maybe that's the commerce code. And on another one would be the manufacturing code and so on. So yeah, monorepo is a way for you to govern code that could be or may not be related.

Are there other benefits that you get?

Yeah, monorepo, especially in when we talk about Microservices, when we talk about Cloud, the way I would describe fragmented programming or distributed programming, it's a bit like, it's a bit like a zoo. Monorepo is like a zoo. It's a way for you to contain the chaos. There is benefits to distribution, but imagine if you have no idea of the code that consumes your application. Sometimes that's okay. Sometimes it's not, because you might want to release code in parallel or in a synchronous manner. So what often happens with projects is that they might do things in the Cloud, but they won't stick in the repository and they will just do it there, you know, and the other pieces of code is in another repository and another piece of code is in another repository. And it's just like in terms of governance for architects, it's just impossible to know where is what. But what monorepo allows you to do is bring everything in one place for you to be able to control the chaos. Uh, that's what I would say is the key benefit is just visibility, really. Visibility of code is the key
benefit for Monorepo.

Any advice for anyone implementing it?

Yeah, sure. At Goodfrontend, we used already NX, we've used Turborepo, we've used Rush,
we've used Yarn Workspace. All of them are quite different to one another depending on what
you're trying to achieve. Rush, we use Rush and um, I have to admit it's a bit slow as it gets
bigger, but it's a lot more configurable. Yarn Workspace is is okay. It's a lot like NPM Workspace, but it's quite bare bone is what I would say. And if you want to build on top of it a bit more, it's quite custom. So, it requires a lot more documentation. Turborepo. Yeah, it's okay. Then you've got NX, you guys use Lerna I guess. I'm not a big fan of Lerna, but yeah, monorepo, I think, I would suggest that people ought to use it. I would encourage the use of Monorepo. In terms of what Monorepo we will use, what specific monorepo we will use for our next project. That's an interesting question. I'm not sure yet. Mm-hmm. Uh, actually, so we are investigating all the latest monorepo available today. Mm-hmm. To see which one is the most beneficial.