Jamaica real time feedback into the behavior of your distributed systems and observing changes exceptions errors in real time allows you to not only experiment with confidence but respond instantly to get things working again. Code hello everybody, my name is Anton Kalik, I'm software engineer from amenitiz.com and today I'd like to present my topic about translator words application on JavaScript. Literally it's a story of creating from scratch startup till the workable end solution. We're going to talk about what kind of tools it's necessary to have in order to bring up the startup with a potential scalability for the future. We check the corner cases and what kind of tool better to use in scope of JavaScript for sure. And we going to check the details of the schemas, how to connect, communicate and make alive your startup idea and example of that. I choose that project which has been created actually by my brother and I was involved with to set up the service for that and client side for desktop. And here mostly a story of creation of that project where we were started, where are we right now? And all of that development details which could be interesting for you. So first of all, let's take a look on what is the project. Is that so? My brother created that word deposit iOS application and I was thinking with him just to improve the project itself to bring this more scalable for the future, which database to use, which service we're going to use and how we're going to use the clients in our case and so on. Yeah, so server and client, this is the crucial communication between that and what I decided to choose. I decided to choose node on the server side and react on the client side. Definitely my tool is Javascript and that's why I decided to go in that way and where to start. So this is actually very important question because firstly I was thinking, okay, I need to create something like a logic algorithm to check it up, like how it could work, and up front of that algorithm to build the project. So what I mean by the logical algorithm, it means like the basic basic solution of the problem solving and then according that simple small problem solving solution to have a scalability architecture. Okay, so from the small one solution to the scalable architecture and let's go to the very basic one schema, how I was thinking how we can spread out the project. And I was thinking like okay, we have to create a database, whatever it is, postgres Mongo or something else. We communicate with database through the server and brings the data right to the client desktop and glide mobile well eventually the tools for database was MongoDB server created by node JS together with GraphQL which will show more expanded simulatedly. But the most important instruments over here mongo node react and some of the clients could be on react native or iOS or whatever it is how to store and serve that service. Because all of this could have to communicate between each other. I choose Amazon Web services instances. I split three instances between client server and database and this is the communication. So for the react native or for any other phone applications it could be Apple or Android development platform which is fine. But today we're going to talk mostly about the database server and client on react and all of them was an instance Amazon web services and communication between them through the routine 53 inside the Amazon there is a couple of rules between connections, the security part and engine setups that I will show you lightly. So for now let's take a look on the code JS server. What we have over here, as I said, we have a database MongoDB and MongoDB ODM. Actually communication with database through the models and models app and Apollo server applies as models and communication with the models through the resolvers and resolvers could be mutations, queries, in some cases it could be subscriptions. And it's like a structure of communication and manipulation with your database. So Apollo server applied that resolvers which is mutations and queries and comes right to the Apollo and there is the flow of communication and all of structured data which is going to the clients has to be alignable for the graphQL schema and everything spinning around from the code server. So launch it on the code server and that's how we are providing our data for the clients docker for sure. Locally you can use Mongo, you can use for the Docker just to use the Docker compose app to build Mongo and connect to the database. Let's take a look on the initial setup of the CoA server. I choose CoA. For the node server you can choose express and whatever you want. But in this case we consider that framework code. So from Cora I creating the application itself instance of database and connected to database couple of middlewares. For example one of the interesting graphql upload code which is handling the uploading of files listeners and open the port for our server. But it's not, that's it actually we have to set up Apollo server and in the same and the same way we're just starting our Apollo server with applied middleware for specific path we're going to listening app v one graphql in order to have our request against server. Yes. So what is the Apollo server startups over here. So this is pretty the same like it's prescribed in documents and so on. I just bring for this session the whole amount of work, what has been done in order to have a skeleton of building your startup solutions where we included GraphQL and Apollo server. So here you can see that we using the maker executable schema, which is getting the type devs, which is schema, graphql itself resolvers. As I show it in the schema, back to the schema, you can see that Apollo communication with resolvers and we're catching the years and formatting the years and also the context. So context creating the token from the context arrived right from the cora. We are getting that token from authorization header, validate that token by validation we will understand is there a session or not. So if they have session, we provide that session passing through the context or session could be a null if there is no validation has been failed. Where to go that context write to our resolvers where we can reuse our session and asking data from the sessions like email, id, whatever it is. So let's back a little bit to the database layer and let's just take a look how we communicate with database. So we have for sure some of models, in my case the models of words stacks, collections related to an end of cost user. So just a couple of models over here that for example words fema, which have a unique id creation date for sure, and translation, which has to be from tools like language is a cult of the language and value of the word itself. As I said that a multilanguages that means it could be different languages and words has to belong to the specific stack where we're training our words, which has been created by the user and for sure author who was creating that stack and that word. So how looks like the stack schema, it's build of course title, possibly subtitle, date creation and stack can consist some bunch of words. And of course that model belongs to the outro, that user who created that stack. So resolvers, as I say, those models comes right to the resolvers where we can reuse those models and communicate with database. In this case, for example, we are taking the model of words, trying to find by specific parameters, the specific word, specific words, count them, trying to find the real items, sorting them and passing to the specific function. And just to let you know that resolvers always returning some information, always the queries and mutation according schema what you describe it in your graphql schema. So cursor output will bring the object structured exactly how it's described in graphQl schema. This is the pagination part cursor output. So this is what we're expecting in the end from that get words by stack id notation is the same thing we are asking just a context, where are we expecting to get model? Because remember we're passing to the context all of our models. If we just back here, you can see models always returning from the context. So that's why we get that model over here. And access to the session user has been find for example here from the session id because we can find that user by session id if it exists there and user makes some update because it's mutation. Mutations is something what we updating, what we posting to our database queries actually what we're getting from our database. And for sure in the end of the process of mutation we are returning some get statistic stuff over here. You can see that we using get statistic really literally right from the query. Because if we go to the get statistic, we're going to see that a bunch of additional queries where we in the end from the promise returning some structured data. Exactly for GraphQl schema. How looks like the GraphQL schema. I think for most of you it's pretty familiar. It's just types where we describe our queries mutations. As I said before, subscriptions could be possible as well. And types of what we're expecting from our queries or mutations. Let's say like we have a gas stacks, we're protecting stacks type or let's say when we are update user on a mutation, we're expecting to receive user updated user with updated information and type user describe all of the fields what we are need the explanation mark here the administratory fields we should receive always that type from that field. So execute schema with resolvers. Actually that what I told before that makes us possible just to communicate with GraphQl from the client side and to use queries mutation on the client side. And we are using this graphql schema mutations or queries and we're using on the client side. So time I think to go to the client and as I said before locally for now we just using to use that local host the API Vivan Graphql what I told before when the initial entry point to the server where we started our Apollo server, we put the path API v one graphql. So v one GraphQL could be not from under local host. It could be a different Amazon web services. Through the router you can provide everything you want especially with a specific authorization part and security layer. So now we're just talking about locally connection and let's take on the react client now as I say technology a server provide to us through the local host through the road app v one GraphQl the possible of the connection to the data through the GraphQL react client making those requests to the GS server and exposing to the browser locally it's a local host 3000 but you're going to build your files and going to use your build files on other services through engines part in my case, as I told before, it's Amazon instance. So let's dive into the react client for sure it's bear schema where what I'm using the application mostly if I'm creating another application, another service on the client side mostly I'm using the same structure application applies the Apollo provider which is Apollo client. What we passing to the Apollo provider queries, mutations and fragments fragments spread using by mutations and queries and Apollo using the Apollo client and the providers comes right to the application also state management which can be created by redux or whatever you want. But I using context with read user with actions dispatchers and I have an initial store just to have everything in box. But of course you can say that we can reuse power of Apollo client because there could be some kind of Apollo state or we can reuse some other approaches to have global state management. In my case I'm usually trying to split it up between in the entities like context with the state management, Apollo with queries, mutations, style it components. It's just a feature for the styling of your components and views and other things. For example global styling of course components itself and views. Okay, so everything, all of these parts, all of application in the end goes right to the DoM system. Okay, so how looks like the providers itself. So I'm struck the application first I provide the Apollo provider to the Apollo client how it looks like Apollo client. I will show you later. But then I just go into the context provider which is a state manager and then theme provider if we have something like a dark theme or day theme, whatever it is and global styles for sure. So some generic styles team provider global styles comes from the styled component context provider. We are using the powerful of react itself and Apollo provider comes from the Apollo client. Well Apollo client is that how we are connecting to our server through the creating HTTP link we just put there that exactly that path. What I told before on the server side that we open that API graphql. That's how we are connecting to the HTTP link for sure you have to have a proxy for that with the specific for the local host and for the production one. So Apollo, before creating the Apollo client you have to bind different links. The first link you can see HTTP link which is collections one year link which is handling the errors and exposing some specific error from graphql years or some other errors forwarding the apparition itself. Then we are creating outlink which is using headers in order to provide a token to the headers which is authorization and cache. In the end we are caching our pagination part. In my case I just using the fields get stacks or get our words. When you're scrolling you can fetch more data like list of the data. In my case it was in translation application it was list of words and you can scroll and you can get the pagination that relay style pagination provides right from Apollo client and once again all of tools what I describe it here, it's like no more, no less. Exactly that amount of tools that functions, that features. I'm using exactly in scope of that tools. And in the end Apollo client with all of the links, yarrow Link, alt HTTP link and cache itself. That's how we are creating Apollo client and we providing before showing you right to the Apollo provider in Apollo client over here. Well context provider as I said before the context manager here also there is no any specific good approach like good practice or something. This is just a bare minimum to have your project up. And here for example this is the state management where we are creating the context provider. I just getting the child provide to the child that provider with the store and dispatch for the actions and creating the reducer with the initial state for sure. And across my application I have access to global state management. Whatever I have to save there. I have the next dog there to have a scalability and to not have everything in disorder. Nice to struct all of your components views in the same structure. Like to have a rule. I want to show my own personal rule how to struct independent components, atomic components which you can use across the all application on the react applications. For example let's say we have button. So always the folder button from the capital letter consists index js file with the implementation itself in the code button test where we are having our unit test for the button and styles which is styled component and you can see that views and components they are different, like they're different folders. In the source folder where we have the full of list of our components with all the time, the same structure index, the component name itself, test stylus, all of them have the same structure and the views the same, literally views the same component, but logically views it's related what we are showing in the router how it looks like inside the component. In implementation it's just like an input with styled containers, stylet elements with passing props and we are reacting on that props. So there is no any tricks. We're just using the component and style of that component and for sure in the same folder has to be a unit test. Okay, let's back to the graphql to the Apollo client site and we can see that user fragment here. It's just the same list of fields what we have seen in the graphql schema. So here the necessary fields to us on the client side which we can be used as a fragment across all of our mutations and queries in Apollo client. And for example, as you know, Apollo client has the specific hook for the query use query. We have to provide that query. For example over here it's a get session where we're using our fragment, that fragment has been created over here we're just reusing over here that fragment and that's how we can reuse that fragment across the other requests, other queries or when we don't need at all any fragments, we just can use the plain fields. In this case we have a mutation for sign up user and we are expecting just to return the token which we're going to use lately for the header and uid of course. Well also about the fragments, you can fragments creating exactly from the type. So we have type user, we can create the fragment of that type, we have type of word, we can create the fragment of the word and reuse from the sum fields. So in general, what to take to the application? This is actually a very controversial question on the beginning when you want to bring up very fast your startup, which tools to use. I suggest in this case in terms of JavaScript, who are using JavaScript to use the tools, which is really familiar and very famous and successful tools for now like graphQL style components are using everybody Amazon web services for sure now is a really big benefit to serving your data services databases, database, for example MongoDB because it's just very easy and very fast to build up your application over there. Also, as I told before, very important to keep good structure in your applications, in the folders of your components views or in your resolvers on the server side to split up like between this is mutations, this is resolvers and where's utilities and so on. So to keep everything in order and as I say, what to take and where to start and how to keep it in order, that's the approach like to have good folder structure in your applications. And in the end this is the full of the tools what I'm using for the service, it's a jot docking Graphql Apollo server which works to us for the communication with GraphQL client which is communication with the graphQL through the server. All of these tools actually this is enough to create the application till the end workable solution. On the production side it doesn't matter what you're going to choose. For example, you can choose the Amazon Web services instance or it's going to be another service, heroku for example, maybe you're going to use the postgres, but like postgres you have to use some kind of orem system in order to communicate with postgres. Almost the same, like more or less the same. It's going to be just another database. Couple of tools what I'm using here for example, why I'm using core because it's my opinion just a bit easier and much faster than exprs and consequences of middleware stays are really straightforward for me hosting it's just up to you. Not mailer for example I'm using for the handling emails to send some emails from my server, for example forgot password or whatever it is, just send email for sure. In the future you can increase and reuse some of services for the emails. It's just a bare beginning of the application for the startup PM two for example, that's just a tool when you have keep running your server instance on a production without stop. So circle CI for deployment process jest for unit tests for sure. Passively together with jest you need to have additional tools for the react for example testing library or enzyme. So that's up to you. But mostly it's everything it's unit tested, just tests very important in the beginning as well. So for the validation of fields, yes. And, and the price is actually for the starting around 65 $70 per month I think for the beginning of the application. When you create some workable solution it's not a big deal, but it's more or less that price for the month. So I would like to say thank you so much for the listening. I hope that information will help and inspire you to bring your ideas alive. I could say that my solution for the service and client side took around three months. So thank you so much. Have you seen that? In another session.