 Hello. Good afternoon guys. So, I'm Ravi. I'm the co-founder of PeopleTech Ventures as well as the Philaxx company. Today I'm going to talk about how to build an application based platform along with applications from scratch. I mean, many guys must be thinking about, okay, I want to build my own chicken application. I want to build my own free data application. Anything related to location. So here I'm going to talk about based on my experience in Dunlop. Like, how can you build your own application? Basically, we're taking some examples of databases as well as technologies on the day existing. So, just to give you a brief about what I do. So, the next idea is actually a free location-based shopping application and rewards shopping and rewards application. It helps you find offers, rewards, and newer events from tourist brands and across 10,000-plus stores in the country. And we just launched two months back and we are now around 12,000-plus users on Android, Libre, and iOS. And as well as we are on SMS and also on Bebbeb. The best part about the website is it also provides real rewards for simply walking into stores, not just for purchasing. For just walking into stores, you get real rewards as well as for engaging with your favorite brands. NAScom, one of the biggest software body in the country recently, is one of the top apps. And also we got featured by Samsung App Store. So, I mean, I just want to dive into the topic. So what is geospatial location data? So, I mean, I would call it as any data which has a location associated with it. So it can be users. So most of the applications are users. So what is this location? So it can be a location which is an Android application which basically are users. So they can be a laptop associated with every user. So the data can be of local business as well. The data can be of photos where basically some applications allow users to take photos and basically associate their location with it. And there can be many possibilities with location. That basically is leading to a lot of location-based applications right now. So how do you build such kind of location-based platform in the backend as well as the applications among it? So firstly then, okay, how should I store this data? So I have these huge, I mean, I have these users as well as places of what kind of data it is. But I have locations associated with it. So how should I store this data? But the location, the data can be queried, I mean, the data can be searched, queried with a lot of different possibilities of querying. So we can use any storage medium which basically supports Geospatial Indexing. So what do you mean by Geospatial Indexing? So Geospatial Indexing is basically supports, I mean, it's basically a 2D index on the lat-long attribute which basically helps you to query different kinds of files which I'll be showing you. So first, I will use the technology of MongoDB basically to explain the queries that can be possible and also that MongoDB basically supports Geospatial Indexing out-of-the-box. And there are many advantages of MongoDB. So I just have to focus on basically to use some technology to explain how can we develop a complete platform. So here I use MongoDB because it's fast, easy to set up and run, that's diverse across all languages. The best part is it stores documents directly. Like, what are the objects you have? Like, it can be a case or a user or it can be put out. So it stores directly objects in JSON, which is a binary form of JSON. And it also supports location sharing. So I don't want to go into all that. So what is it all for? I mean, so most of the use cases are like this, right? Find all of the other users near me. Find the closest sharing museums near me. Find the closest 20 venues near me. So find the closest 20 places with the real additions of 5 kilometers from your location. So there are a lot of various which basically use cases which are required by many applications. So how do we do all that? So that's what I'm going to talk about. So MongoDB basically supports Geospatial Indexing out-of-the-box Right now it's currently limited to only Earth-like dimensions where there's less money needed in each access. So to make the map easier and to make it very faster, it assumes that the Earth is flat. What do you mean by Earth is flat? It basically assumes that one degree of flat, one degree of latitude and as well as one degree of longitude is the same distance. It assumes that. I mean, that is not a problem for most of the location-based applications unless you are very concerned about small distances. And of course it has methods to handle the coverage of it where the Earth is spherical, consider the Earth is spherical. But the performance can be a bit less. So how do you structure your data? So by the way, if you have any questions, just feel free to ask me directly. So let's say we assume that we basically store the data of businesses, local businesses. So here I'll talk about local businesses. So let's say we have an object on its place which basically has a location which is a latitude or longitude. And name is here and tax. Tax basically this category is associated with a museum or you can assume it. So you can store the location as said here, like mentioned here. You can store the location as an object like X and Y coordinates. Or you can even mention any other keys, longitude or latitude. By the way, how many of you guys know about Mongo? Oh really? Okay, so that's good. So that's easy. But you need to make sure that you always follow the same convention of ordering. So you either follow a lat long or you follow a long lat. But don't mix up some documents having lat, long and some documents with long lat. So you need to ensure that you follow the same order of consistency. And before we go about pairing, so you need to create an index on this data. So because it needs to identify that the location attribute, the location object, attributes basically except it should, I mean, if you need to identify it as a 2D object, which is basically the location, geospatial index, you need to create a geospatial index on that key location. So it's very simple. So here I'm actually showing you the JavaScript concept of Mongo. I mean, and there are different language drivers and then the queries are really similar. So I'm showing you this, this basically if you need to create a geospatial index, use a console, you basically do a dv.dev.exe index. And by default it will assume it is yet like dimension, it will create defaults as minus 180 plus 180. And if you are indexing something else, I mean, if you like something, some different application as this use case where you want to index, scale the index so that you can show the values between minus 500 and 500, you can always provide other attributes minimum and maximum. But one limitation is that you can only have one geo index by collection factor. And what if? Okay. So and the other best part about Mongo is you can create component indexes because many times in your applications you want basically, okay, I want to know the closest end museums. Okay. So it's always something like category or tags associated with it. And most of the applications will have something like this kind of queries where you basically have, you need to use two fields, two keys. So that's the reason Mongo provides, yeah, optional as component indexes so that you could, so when you basically use a, let's say you are sure that you basically use queries, most of the queries are with location and tags keys. Okay. Then you create a component index so that the, so that the performance of the queries will be much faster. It creates a component index as if, okay, it will automatically make the performance faster when you're pairing with the two fields, two keys. What if you're, I mean, yeah. And MongoDB has much more complex scenarios it can support where you basically have not only, okay, you not only have one location object, you have multiple area of location objects in a document. It's a, for example, I need to store all the paths between multiple places. I have 100 places. I need to store different paths between these places, like let's say map directions. Okay. So how do you store it? So I, and then you can store something like this, db.path.insert, name. So let's say na of a places q and na of a places i, both, yeah, both that would be a long bit of q and i. And then you can, you can basically store, structure the data in this format, like na qi and places, and na of places, we have na q2i. And similarly you can have a path, I want to say na qi n, and then have a place as an area of three locations. Okay. But then even also, see, these are, Mongo actually, these we call, actually as an embedded documents. So these are actually embedded document, say document inside a document, that's what you call it as embedded document. You can even have an area of embedded documents, that's what we are seeing here. Okay. And then you can create index here also, like that's a place dot location 2D. So then you can actually make queries saying that, okay, I want to know all the paths starting from q, or like I want to know all the paths where q is actually present. So something like this. I'll go with the queries now, start with the basic geospatial queries. Next, I want to find the closest 20 places to a given location. So it's very simple, you can say, you can find location near the given latrons from which location you want to be, and then give a limit of 20. And similarly if you want to know the, and this is the most common use case for most of the location applications. Let's see if you want to know the common, like finally it also depends to a given location that actually goes to one degree of the given location. Then you could do it, do the standard queries. And we use most of, we use these as the basic queries to develop our application, and there are much more complex queries we use. But this is the most basic for most of the common application. Let's say I want to... So when you do a linear application search, you know a latron search in MongoDB, it's a linear search, right? It does not understand the geometry of the... Yeah, it's a flag. It has a flag. It's a flag. It means again that we cannot use this as a very accurate way of getting distance, but not as a very approximate search. Yes, exactly. Most of the applications will not have a problem unless you are very critical, but it's not necessary. Unless you're doing something that's not for a software. Yeah, and there's not a good search. Exactly. This query is a latitude, not a design. No, the thing is, it's a latron thing, but inside MongoDB, all it does is the linear comparison. It's just X, Y. It just X, Y, exactly. So this means that if your permissive is fairly high, like when you have fairly high latitudes or fairly low latitudes, it doesn't work well. Yeah, but it has support for those queries, actually. Spatial queries also. So it's got proper spatial queries also? Yeah, it has proper spatial queries. You're near and spoken. So does it have a spatial engine? Yeah. Exactly. Or do you have to... So how does a spatial query run? I mean, like, how does it support time? I mean, it has basically... it has this hash map on... hash map, how do you... something like that. How does it actually work inside? You mean the spatial queries or the general queries? There's spatial queries. Like, how is it... I mean, when you look at it, compared to, like, the postgres spatial engine, like, how do you compare the accuracy of the query that you're getting back? Okay, I mean, as far as I know, these queries are not so accurate. Basically, that's which way they assume the latitudes flag. But when they assume the latitudes basically they consider, those queries are fairly accurate. Yeah, because... but the point is like this, I mean, these... the performance of these queries is much faster when compared to them. So the postgres is this, right? This is how they... most of the location pages use this itself. I mean, because that's... I mean, you don't need, generally, in most of the cases. And... And then, you know, how a complex query is like, let's say if I want to bond, let's say I want to know the closest places within the addition of five kilometers. So those are possible because, let's say, maximum dollar-max distance is five. And something which specific to us, basically, we, you know, after each of these, you basically search for Samsung and Galaxy Note or something. I want to know the... offers near this location, near my location, which place they are, or Samsung and Galaxy Note, Samsung and Galaxy Note. So I can basically do... So that's what... So I created a Compole Index before, because then this query should be much faster. If you don't create a Compole Index, then this query should not be faster, but it will just take this as the index and then make the query, and then again, it does again the second query. So... So you need to have this Compole GSP index, different on both, each together for better performance. And you can have, there are much more possibilities that are like, bounded to a specific place. Like, let's say, I want to know all the places in this... in this attack. Okay. So that is also fairly possible. It's simple. It's basically, say, the location is in box 10, 10, 10, 10, 10. So you basically... So then you get the places, all the places, which are basically within this attack. Yeah. And simply you can do this center problem. You want to know all the places. It was just to... I mean, from this center, there are additions of 5... 5 kilometers. But the point is, dollar meter is much more powerful and then as well as useful than the thing. So that's... And the performance of dollar meter is much faster than the thing. So that is the reason many people use that dollar meter. And there are many more queries, which are more like, as I said, like special queries and all which I'm not going to insert into... because I want to go to the front end part of the application. Yeah. So here it's talked about proximity. But let's say, I want to create something which is more related to things I would sell at the data. Okay. I sell carrots. So is another store. I want to find the cheapest... about from carrots, I sell many other things. Okay. So if I want to do such a query, which is... Maish, I can't hear you. Sorry. Is the mic there? Thanks. Yeah. So the thing I'm more trying to get at is, one is... I got two geo points and I'm trying to find what is closest better or not easy out of the box queries. But now, in a given point, there are multiple things I as a retailer sell. I want to bring out what pricing I have for each of the products that I'm selling. If I were to take a textbook example, okay, I got mangoes, I got tomatoes, carrots. So is the neighboring store two kilometers away. But I want to, you know, bring out all these prices, put it on the website and... See, I mean... So who would that have who would acquire... Does it support? See, it's all about stretching your data. That's what I call it. Okay. So basically, I'll take your example. So basically, I have all the products in the collection. And then each product I give you a pricing. Okay. So then you basically, and then I say that these products are specifically present at these locations. So I can have an area of stores, so I want to know, basically, something that's in note is present at these all locations. You can basically have an array of, which I showed you, array of places. And you basically have each place as a laptop. And then... Okay, but you mentioned the price of each store is different at each store. The cheapest one will do I get. Which is the first one that came up. Who's... the latest one, things like that. Would it support? I'm not trying to get it. How would I do? Yeah, yeah, exactly. It supports everything. I'm doing a place, place down something which is inside, as against comparing two things with the natural leader. Yes, yes, exactly. So that's what we do. We actually do a lot of fairly complex stuff in our application. So that's the thing. So you'll have to structure the data such that depending upon what you want to pay. So at the end of the day you're just not just making it work. You need to make it work within the best performance way. You'll have to structure your data. And in Mongo, what happens is that it's not a problem of duplication. In this database you can, the main consumption duplicates your data. In Mongo, you do duplicate your data as long as the performance is good. So for duplicate your data, keep the same thing like let's say mango at some store one at this price. Mango at store two at the other price. Then I basically say that DB Road is fine in the mangoes and which is the cheapest price. Like price less than this much. So give me all the results. So it also gives me the stores which at which this price, at which this price are present. So you could do all that. You'll have to structure your data in that way. I mean, I want to go to the front end now. I mean, so since I want to cover the both parts. So these are our cases we basically have a back end which basically a pyramid-based back end and we basically have a rest area which front ends all the front ends can do. And yeah, I just wanted to say like how the Android location is obtained. Because many people actually make some mistakes and then also like I just want to make it clear to everyone about it. So Android location is obtained through wireless networks and GPS. So the pros and cons of each are like wireless networks are very fast and accuracy depends upon the area center or you know, Bi-Fi hub hub. So it basically varies from 100 meters to multiple million. GPS takes a lot of time initially for the first time for the initial fix. It's like maximum one minute. After that it takes 10 seconds to basically get a fix. And GPS is fairly accurate but it's not practically you people don't want to have it. So how to write your course as you may know take the best possible I mean you want to write the battery less you want to obtain the location faster you want to provide the best experience to your users how to do all this. So this is the way we can do it. So whenever you basically start application you say and Android generally what it does is basically whenever let's say some expanded application called for location whenever it got the location it will store itself in there basically Android itself stores it and when my application actually asked Android it towards the case location and I can see okay and it also tells me when it is actually found that location and I can see okay the case location is too old I don't want to use that location then I ask it to phone so then I basically since the wireless networks location is very fast so I get the location from wireless networks either from cell or Wi-Fi which is available okay and and then once I get the location and most of the application don't do it but it's better to okay take the location provide the results to the user because you don't want to show the user loading for a lot of long term until you get the most accurate results to the user and then and then in the background and then as well of course you will be getting the GTS space which is one way or depending on how much time so once you get the GTS location update the existing Android update the existing location and then use this new location to basically do the next results so what we do actually we actually showed the location share difference and use it when we are making API calls like I showed in the front end and yeah especially it's easy and fun on Mongo you can now build your own checking application on Android you can also build your own field or any other photos application on your next Instagram so and running Mongo on any cloud is fairly easy as long as you are developing something very complex and you are at a very production space then you basically will have to go to Ritika's search and other stuff yeah so we are hiring those who will keep us not at all yeah do you consider Mashi to be special about this so okay we started developing last June last year so at that point of time we basically looked at technology stacks of I mean all the second money startups as well and then I am actually not interested in MySQL lot because the the programming objects directly basically are similar to the data objects which we store in the Mongo and then it out of the box supports you and we and we always use the latest stuff we are ready to take this so that's what we do I thought of graph data Neo4j yeah so many problems can be solved see we use to all the users and walkings and all the interactions everything main data source so Mongo suits our needs as a primary data store as well as it also allows to do that Neo4j so if I use Neo4j I don't know whether I can use up it as a primary data store as well then I use two data stores separately so that Neo4j is nothing but a deployment store so when you want to navigate your data which is the case with geospatial usually typically you would want to navigate the data so graphs are what you need there so that is when you could use so there's nothing which Mongo can do and Neo4j can't do so you could actually model the documents it's all about can do and not can do okay I'll tell you the point is this is suited out it's so database I think people should choose database because of the requirements I think we felt Mongo is a better is a better because one thing is we want to be very fast we don't and then we and then I was also used to Mongo like just two months back that time and then and then I so as the really increases as a number of users increase I don't need to look into a new stack or something so that's so that's where Mongo helps and as well as I can start I can if I have a lot of data so then I can start across medical machines so that's where so the which part of Mongo is that I can increase my machines as well as I increase the infrastructure based on the number of users and number of data supports replication and redundancy in HA the high availability cluster uses zookeeper for replication and redundancy one year back of course yes Sharding Sharding is not there with Neo4j but sharding is there with some orthographic psychoneum of you orient dp is one Titan is another which supports HBase and Kasanda out of the box so your document store requirements get satisfied with those stores also those are key value we are looking towards because we want to make our search better oh yeah Neo4j comes with Lucy one thing that we noticed when we explore Neo4j was there are two versions of it and some HA and monitoring features HGPR what's kind of about the production products I think if any of you guys are interested in Mongo actually we have a MongoDB user too thank you MongoDB I actually am one of the founders of this I think