Okay, let's move on. So again, as we seen, another way you get server side props to let this piece of code running on the server on demand, whenever a new URL is accessed. Basically it's some caching mechanism involved. So not every time this path is executed, this function runs basically also the outcome of this service like rendered document is cached with the time to live, it's kind of performance. If you'd like to do it on the client side, again, you just access the ID itself, which comes directly, sorry, you use ID for example, I just use traditionally we use query on the front end.
One thing worth to mention, if you do it on the server side, accessing the GraphQL API on the server, you won't see anything here. You won't see anything here or active queries, not no queries at all, because what we see here are the queries in the front end application in the React context. So we, Apollo client is provided by the Apollo client provider. And but here we execute the query on the server on demand. So no queries shown here. Okay, cool.
I think basically, that's the first part of this workshop. I told you somehow, F is code up and running, get some basic understanding, what's actually going on in the front end. From now on, we'd like to implement our very simple micro events applications. So basically, we'd like to extend our GraphQL schema on the API side. And we'd like to introduce some queries in order to access all the micro events. We'd like to introduce a mutation for creating micro service. And we also need to do some work on the API as well. Actually one thing I forgot to do with you so far to take a look on the API code. So a backend code behind it. So let's do it first before we go to micro events application. So on the API, on project here, we have a foo module. All right, so each module in an sj applications has a module file. You're just export class foo module, that's a TypeScript decorator with exactly one parameter. And this one perimeter is an object literal or an object general with some setups. And some key values, right? So usually the key is on the left side, of course, and over the right side we have usually the value given as an array. Not always, but in most cases for most keys, most are arrays. Here we have some providers. Providers right here, I don't want to be talked about the dependency injection in general, but basically we have this inversion of control approach.
So the NestJS application is a running application, a running container without your code, without your actually code artifacts, given it already runs, but you provide some code artifacts by fulfilling a kind of contracts. And NestJS, whenever it sees some of your... when it sees some of your provider artifacts, maybe your full service, at a given moment on time it creates an instance for you, it provides all the dependencies for you. So basically, the instance of this full service is an object, a so-called managed object which is maintained by the framework and not by yourself. So you're not creating full service instances on your own but NestJS is doing it for them. I don't really go too deep into the idea of dependency injection. Basically, we need to fill a complete workshop with it to get some understanding for it. But the way how it works is that we have this one module for this full feature with some code artifacts inside it. NestJS has this very fancy naming convention here in that finance. You see.reserver TS,.service TS,.module TS. Technically, those are all classes, right? TypeScript classes. But in order to get some understanding what role this class has in your application, we give them stereotypes to identify for us as programmers so that we can identify the role of this artifact, this code artifact, usually a class, in our application, in our code base, sorry. So we know this full service, which is basically a class, right, is of stereotype service. So in a multi-tier application, usually having some consistence layer, and we have some domain layer, and then we have maybe an API layer, which exposes the domain somehow to the public. All right, services are somehow located in the domain layer. So by dealing with so-called entities, so here we have our full entity. All right, a regular class, which extends a public object. Before we go into the details of this full class, of this full entity, let's discuss the public object first. What is a public object? Basically, it's just an idea, how to extract some commonalities in our code base and into a base class. Basically, this public object is an abstract class, so generic abstract class. It has this id and life. The idea is that every entity which is exposed or is a candidate to be exposed to the public is a GraphQL thing. It's a public object. As you can imagine, in our relational database, in our relational database schema, let's say it like this, we have some entities that shouldn't be exposed to be public. We need them maybe for technical reasons, so they have some relations maybe between different kinds of entities, but they aren't a candidate to be exposed to the public. But we identified in our application that public objects, so those objects which are a candidate to be exposed to the public, have some commonalities, basically an ID. All the public objects we're dealing with have an ID. We also have this fancy life object, life means we have this created at timestamp, updated at timestamp, and deactivated timestamp. As we'll learn in a second or so, those fields aren't really, there's no need for us to manage them on our own because we are auto-filled filled using this TypeORM capabilities. So this created date column, decorator, and the update date column decorator come from the TypeORM packages or provided by TypeORM. So we don't really have to care about this, the values of this created end timestamp and update at timestamp. Whenever we update or create an entity using the so-called entity manager in the TypeORM world, those fields for this instance are updated automatically for us. Deactivated add field, not really. So that's a strategy which is very common in application development in general. Maybe for... Legal reasons. So as you know, today we can't really, we're not really allowed, even if we want to do so. Delete data, we have to keep them still in our database somehow for some reason. If some criminal activity happens, we have to keep still have to them. So and also deleting instances out of our relational database usually leads to a lot of problems. Because as the name suggests, it's a relational database.
Comments