Generic Services

[00:00:00]
>> Eric Reinert: So, we're gonna define generic services now, because as I said, we're gonna talk about both generic and microservices. So, generic services often refer to a component of an application that provides specific functionality to the platform. Here's the biggest thing to note about generic services, generic services could be part of a monolithic application where all services run within the same process.

[00:00:25]
Or it could be a part of a distributed system where services may run in separate processes on separate machines. So, when we talk about service, we might not necessarily just be talking about a literal running service, you might also be talking about a service design, right? Things like MVC, patterns and things like that, that exist in different types of back ends.

[00:00:47]
Where you have things like factories and other approaches in the logic that allow you to spin up a service in the monolith. Or saying that you wanted to separate that service into its own running process, it can be either of those, it doesn't really matter there. So, this is what a basic distributed generic service architecture looks like, and if we recall what we had before, right?

[00:01:17]
We had our frontend service, and our backend service in our monolith, and then that went to the database, right? Who can tell me by looking at this, what benefits we get by going to this approach from the monolith approach, of just simply separating the frontend and backend? What are some benefits we get from this?

[00:01:39]
>> Speaker 1: Scale them separately.
>> Eric Reinert: Yep.
>> Speaker 2: Fault tolerance.
>> Eric Reinert: Yep.
>> Speaker 2: An issue to deploy and manage, I guess.
>> Eric Reinert: Exactly, yeah, those are pretty much it. Yeah, so you can scale your frontend services separately, right, you can have better fault tolerance. So, for example, if your frontend only needs a couple of replicas or something like that but then your backend needs a ton more, you can have different fault requirements and things like that.

[00:02:05]
And you can now have a frontend team that works in their own world while having a backend team that works in their own world as well. And going back to the library and stuff like that, sharing it between the frontend and the backend. This approach also makes it so that you start thinking out of the box, how can we serve each other, right?

[00:02:28]
Instead of thinking, well, this just works here, you start thinking more of I'm serving or providing a service to the frontend, how do we do that as efficiently as possible, right? You don't really think about that as much when you're in a monolith because everything's tied together, it's all in one place.

[00:02:44]
And so, you really just kind of, again, going back to the Next.js example, you're literally rendering your backend logic with your frontend view, and then you show the frontend. But with this, you really do start having these teams work together and talking about, okay, well instead of it being a library, I'd rather make this be something like a restful endpoint, right?

[00:03:09]
That maybe has its own schema and its own request flow. And then that makes it so that the responsibility of controlling and maintaining that endpoint relies on the backend team, and then the frontend team just simply focuses on implementing that logic into the frontend.
>> Eric Reinert: Also, what's another thing to notice here, what's one other thing we could notice about this architecture compared to the monolith going back to the security thing?

[00:03:43]
>> Speaker 3: There's more space between the frontend where people will actually be-
>> Eric Reinert: Exactly.
>> Speaker 3: And you're fancy-
>> Eric Reinert: Exactly, yeah, so say for example, somebody decides to DDoS your frontend and they don't hit a route that potentially accesses the database. In the monolith approach, it don't matter, it's still gonna potentially exhaust those connections, it still could potentially affect other parts of the system.

[00:04:08]
Whereas this clear separation in this clear isolation, makes it so that the backend only talks to the database. The frontend doesn't need to have access to it, it can't be exploited and access through it and things like that. So, this separation here does start to even give you some of that security out of the box where you just don't have to be worried as much about, is my frontend going to give access to my database, or something like that.

[00:04:34]
This is genuinely one of the reasons why I prefer a distributed approach than a monolith, especially for frontends. Because I want to know that my frontend will never impact my backend unless I explicitly tell it it should, right? And a good example of this is login pages, right, login components, right?

[00:04:57]
You might have it so that your logins on your front frontend fail fast if you're unauthenticated. But you might need to have more logic and a monolith for them to share that, which means you're still putting stress on the database. Versus potentially just having a caching service and making that much more performant.