 about two months ago I have a short five-minute talk about has announcement that I health is coming to Singapore and now I got a new title like this one CEO of some Singapore I was a CTO of I'm currently have two title and not alone I'm not coming along actually a whole team coming from California we are here today like a mark Chris Jason Annie and a lot of people coming from California we are here to set up the company I health Singapore so that's a dream come true and I've spent some time to talk about why we're here and what do we do and what technologies that we are using and why we use this technology stack and we're using like a react redux graph QL Docker a lot of new stuff kind of fancy stuff and my team member Jason Chris will talk about some detail about why we need to use that so I'm talking about why we're here so I will I've been in internet industry for a long time starting from 1995 I believe some of a member here maybe was not born as a year and that is a year JavaScript was invented a long time ago I can see a lot of a change during the 21 years a lot of change a lot of industry actually change a lot for example we buy things from Amazon we call taxi now Uber and we don't have an international phone call we just use a WhatsApp a lot of things we changed and every industry as long as it was changed by internet it can reduce the cost a lot we can we can see the international phone call for example you really I remember 20 years ago when I call my my friends overseas that's a lot but now I can actually call my wife every day she's in California with zero cost because every time internet go to some industry it change a lot everybody agree but there is one huge industry in the world a huge not small huge much much bigger than like online shopping bigger than tax industry but still not significantly changed by internet this is house care I got a picture today since 1995 to two years ago the GDP the house care cost on about presented on GDP so it's it's increased a lot not decreased and you can see I got two countries like USA and Singapore say like USA now two years ago the cost of the house care is about 17% of the GDP Singapore is less 5% about but Singapore increased a lot more than US yeah but the absolute value is lower maybe Singapore government should spend more money to the small Singaporeans or Singapore people is the more healthy than the US people so this industry didn't change a lot but based on why and standing the internet changed so fast nowadays the house care industry shoot something like this all modern technology very cool but unfortunately the reality is this we're running late so I'm not sure in Singapore but in US I'm not I'm not very surprised if you go to there somehow hospital or doctor clinic I can see the doctor still using the windows SP with IE 6 I'm not surprised at all because it's reality they are very slow and also this is an opportunity for everybody in this room so this is an interest industry currently is on the disruption very quick very fast that's why we are here so I have actually a company I like last time I have a very quick in the interaction but then now I'm not going to spend too much time because today is a talk is a tech talk I just say why we were here what we do is we have the hardware software and service so provide to the house care industry and we actually starting six years ago in Silicon Valley and this is a picture I got from the famous TV show I like the show very much did you ever seen that yes pretty interesting and we grew so fast and two years ago three years ago we started have a Paris company and last year China and this year actually two weeks ago we have a Singapore company now we are very new and what do we do is a work actually we combine the hardware software and the service together we provide currently we have a project in Singapore and that's why we are here we set up a team here and that we currently growing very fast so I'm talking about why we choose okay I think of this way what is the difficult way our currently facing is no matter what kind of industry you're looking at you're always a balance between product is quality is good how fast you can develop it and the cost so always there is a balance so in this industry particular is how we can save the cost but also makes things fast I can give you an example one of my out maybe all the client not only one of them they actually they want to spend three years talking about the do we need to do this or do we want to do that and what are we supposed to do and the ones you decide to do it just give us three months to finish it right very common right very common but how we can make it fast so that's why we're looking for some technology some tech stack we can do the very good balance between the three so that's why we think of how we can do this as a modular like building a house we have the house building in the factory and we assembly them together at the site so that's the idea I come from so what we can't be using is we're using this kind of this tech stack so we use red and red native at the front-end web app and mobile app we usually does as a user logic and the GraphQL is a between the client-side and server-side doing query and the Docker is our hosting so after my quick talk Chris will be talking about the Docker and all the general Node.js hosting and the Jason will come in talked about the GraphQL I believe you already very familiar about the red and red native or Redux so we just going to skip the first to about the second this a certain the fourth today to save some time so the reason we choose them is we want the the software building is like the modular house we have a team global team headquarters in US we built the modules using like a red red native with you know red red X we build module modules and the modules will be used in different country single for example we have a local engineer just hook them up together to based on the customer needs so in this case we can reduce the cost and make building the application super fast and as those technology stack is based on our research is the best so far so we can make software really fast that's the reason we choose that and believe those two guys can give you more introduction I will leave more time for them so I just want to make sure that we are can create hiring people now that's why we are here we are looking for the talent from single to join us and I believe you are one of the can so after the talk our team member will be there in the corner so if you want talk to us just come to us we really hope to know you and have chance to work together so this is my email and I'll be here after the talk okay so next will be Chris Chris is talking about the general node as hosting come on all right this is good everyone hear me all right cool my name is Chris I'm gonna talk about JavaScript hosting easy uptime and all that other good stuff so I'm the ops guy I don't know if anyone here has to deal with like DevOps or anything like that but I usually go between two states of either being really bored or having my whole life on fire so I try to keep my life not on fire as much as I can so that brings us to Docker I'm a huge fan of Docker I don't know if anyone here is use Docker or I'm not sure if anyone here like provides oh yeah good Docker's like my favorite thing ever I'm not sure if anyone here has to provide their own hosting or if you use things like Nodechef or Heroku or things like that however since we're a health company we have to own all of our data so we have to provide all of our own infrastructure I'll get back to Docker in a second so when I joined the company over a year ago we originally written in Meteor and Meteor is actually one of my favorite JavaScript frameworks and actually Evan you used to work for Meteor back in like a while ago but Meteor is really cool because it allows you to like do easy microservices which is really like the hot topic nowadays because they have DDP which stands for distributed data protocol so you can communicate between your web apps pretty effortlessly but the thing is Meteor has some problems when it comes to hosting it requires sticky sessions web sockets and obviously since we're a secure company we have to have SSL so all three of those things in combination with each other provide for some pretty tricky things as well as like a lack of the ability to scale horizontally with real ease so what we decided to do was move away from Meteor and go into GraphQL and the cool thing about this is that we get to separate our client side and our server side code again because if anyone here's ever written Meteor you know that it pretty much gets bundled all together you can wrap it around in cloud front serve the static assets through a CDN or anything like that but for the most part you get one executable so client server separated is a really good thing because you can take web pack which is what we use create a nice bundle JS and then you can throw it up into an S3 bucket for some static hosting and when you do that you get 99.99% uptime guaranteed as well as 99.999's durability so it's a pretty it's a very good solution it's a very easy solution and that is been saving me a lot of time and the reason being is that with since we have a lot of microservices running in the back Netflix has come out with something called Chaos Monkey I don't know if anyone knows about it basically it's the idea that they built this themselves we don't run it but they built this thing that will turn off their servers just randomly throughout the day and the point of it is that if any one of your services goes down it shouldn't affect the user experience on the front end and that's something that we take to heart because health is or health tech is a very like important field and something that needs to have a very high service like uptime so we build all of our services with the idea that if any one of them goes down by themselves which is almost guaranteed to happen that it won't affect the user at the end so that's the reason why so engine X and Docker is the best thing ever because all you have to do is run engine X and then you can have we use console as a key value store in the back and that will work as our service registry so then as services get brought up and taken down they automatically register with the console cluster and that console cluster will then in turn update our engine X config file so that way if our front end servers go down then they'll just reroute them to other front end services if our back end servers go down then they'll just get taken out there and engine X and microservices it's really it's really a solid match made in heaven if you ask me and the reason I know that is because right now I'm the only ops guy and I'm able to manage it all by myself so it's it's pretty awesome that's basically all I have I like microservices I like Docker if you like microservices or Docker any of the above feel free to talk to me I'm willing to talk to anybody about it forever so that's all I got for you thanks and now Jason will be coming up now to talk about graph QL oh thanks and then can I get out some like a clicker you want to okay I'll be fast but he wanted to talk to after is that okay one of my corkers wanted to also talk is that okay yep no not me but him okay no no after me probably not so maybe not mark yeah mark I don't I don't know if it's possible yeah maybe I can go fast okay so I did click this okay okay this is okay hello my name is Jason I am an engineer at I help I'm mostly okay I'm pretty versatile in front and back in right now my responsibilities are on the server side and the graph QL so I'm going to be talking to you about graph QL I chose this topic because I think grab kills still something that's very new in the world so so yeah okay hopefully after I talk you guys have an understanding of what graph kill is like and hopefully when you see it you can recognize that stuff okay so an introduction to our current use case in our company today we use graph QL and socket IO react and react native to power our B2B enterprise applications a lot of our application range from like real-time communication apps various Internet of Things app we have a lot of devices like Kevin mentioned Internet of IoT devices like blood pressure blood glucose pulse pulse socks activity monitor etc so make we make IOT apps for all those devices that we saw for our enterprise customers okay so first what is graph QL graph QL is a query language it's a type-based query language meaning everything is driven by a type system like everything is a type of something and everything resolves in thunder type etc it's very easy to understand and it's very easy to know the expected result of the query that you're writing or looking at it's most frequently compared to a rest API because it's just like the rest API you how you send post-request and you retrieve data so here is an example of a graph QL query here on the left you have your query and on the right you have the expected you have the result it's pretty much like you can pretty much look at this and know what you're going to get this is a query these are the types that you're going to get and if this is a type inside this type and etc and you can tell that first name Jason last name Lee and an address it's very easy to understand it's one of the main benefits of graph QL sorry oops okay so if you look at the how the schema is designed you have the query very at the top where it says it's get user return it's a query that accepts a parameter of ID and then it gives you the user type and then if you look at the user type it's basically an ID first name last name address which is a another type and then an address is the type of this and then a country is an enum enum type with Singapore US and Canada as an option okay so pretty easy to understand okay so first thing that you should know about graph QL is that graph QL is a map of relationships it's not a map of your database or your data it's a map of relationships for example it's a friend of a get get it get your profile and your friends profile and a friend of a friend or get an get an event and then get the creator of that event okay so here's an example of a map of relationship here I'm getting a program and I'm actually getting the creator and I'm actually getting the organization who hosted this program and then the representative from that organization so that's what I mean by map of relationships graph QL is flexible for example graph QL has interface type so you can you can have one data set and then like route them to different kind of data sets maybe maybe if you have measurements data maybe you want to go through blood pressure and et cetera et cetera and then there's scalar types that you could take a value and then resolve into another value a good example of that is a date because instead of passing it because because you cannot pass like an object to a post request because it has to be string so that you can take a scalar type and then resolve it into a time stamp for example here's an example I'm getting all measurements and under so this query would return a measurement type and the measurement type could be a blood pressure or above glucose so that these are the common fields that they both would have and then if the measurement the list of measurement in a hat that that row is actually a blood pressure then it would go here if a bug with glucose you go here so so graph QL is very flexible as you can see so if you're getting a list of two here's a blood pressure here's a glucose here's an example of a scalar so I have an event and I have a schedule and then I haven't repeat on what days you repeat and then and then on the so how I did this one is basically under service side I use a bit mask a bit wise logic and then using the bit my bit bit wise logic I which is just a regular integer it gets converted into an array of days that I repeat this event which is an example of a scalar type so another benefit of why we chose to use a graph QL is because it allows us to move fast basically the front and our front and engineers don't have to wait for me because without me actually finishing the server side that the back end we can just mock everything and then mocking literally takes a few hours at most for the entire end points once we know all the end points so the front end engineers can work with the quarries even though I actually haven't actually finished it and the automatic documentation feature makes it very easy to understand the the end points in the graph QL API that I wrote so that the other engineers can go through the documentation which is automatically created to understand the API that they're going to use for example so here's a documentation explorer feature of which is part of graphical so here is that at the very root I have a query mutation a subscription and then and then you go you trickle down the list and then you will find like get user query returns the user type and this is this is what the user type returns so other reasons why we chose graph QL is it's it's it's very the version control is not an issue so in graph QL I can literally sorry oh okay sorry okay so in graph QL I can change the back end however many times I want I can't even change the database if I want I can change the design of the database or any back end infrastructure and the front end won't be affected the end points can stay the same and the engineers will never know that I made such a big change so again so we wouldn't be stuck into a ecosystem either because of the thanks to this benefit so yeah and the ability to duplicate add and update the API without impacting the my users the API users okay so so far if anyone here has played with the graph QL or even read about it they may you may have already like no most of this because at the at the end of it graph QL is actually a very simple simple tool because in graph QL there's really only two main abstractions which are resolvers and your schemas graph QL has schemas that define how you query and the data you get and the resolvers pretty much do your function so that that tells you how you resolve your queries right so most people know that about graph QL but graph QL is actually there's a lot more to it so to really use graph QL properly you need more abstractions on top of it and that's these are not like abstractions that graph QL comes with these are abstractions that you you create to add a layer of business logic example or like a ACL layer like a control layer traditionally in rest API you would use like you would have some kind of ACL package or ACL layer where that actually protects the end point in graph QL there's many in points so that's actually very different it's because of that reason then the the excess control actually has to happen in resolvers and the best way to do that is to introduce another abstraction for models models is actually the best way to fully utilize graph QL so I talked about that connectors and the connectors lastly is that it's basically a database connector you could actually it's actually possible to use both like no sequel and my sequel at the same time by having two connectors and then calling the data from other places and in your resolvers you just use a data together okay the last thing I was going to talk about model is actually the more advanced idea and the most important thing in my opinion in graph QL I was actually going to go through this article which actually explains it pretty well but I think I'm running out of time okay so I this the problem with graph QL is that it's so new it's actually hard to find everything about the best example for example I don't think I found a good example of how to properly create a graph kill model I found like snippets I found this article very useful it talks about how Facebook uses a graph kill and this conference was actually very useful because Facebook created graph kill in case you didn't know some models are basically things like like you know defining things like this to do I can only be seen by creator and here I'm talking I talked earlier about business logic layer and storage layer you want to create your own abstractions to fully your life graph kill and here's a simple example of a model that they created where you have a to do item that's a model there you would not we would want to have a model for every data type for example yeah okay should I keep going or no yeah okay so that's graph kill