koobas.hobune.stream
I already made a ar app which deploys flag, i want to upgrade it to make the flag stay there at the exact geo location
I have already made and published an AR APP which allows the user to spawn a flag in the real world but, I want to upgrade the app in such a way that when I deploy the flag it stays there at the exact geolocation and when another user opens my app and camera he can also see the flag placed there, I want to know how to save SQL and upload it and everything required to do so.
Might be worth looking at building an WebAPI to serve requests for the flag positions that are stored in a database.
I am looking for a method with a $$anonymous$$imum headache can u elaborate a bit bout webapi ?
In its most simplest terms a webapi is like a website but returns data (like JSON or X$$anonymous$$L) ins$$anonymous$$d of a website/webpage. WebAPI will help with security, performance, scalability, portability and able to support different platforms. You definitely do not want to ship a game with a connection string to a database, say goodbye to all your data if you haven't set privileges up correctly or very poor performance from the database server as it'll be needlessly serving a high load (and thats before you get malicious attacks trying to max out the connection limit and take the server "offline" )
Using HTTP/HTTPS the webapi is platform independent so you could make a website version of the game and not have to make/modify a new database system/connection so people could access other content of the game, although they wouldn't be able to move geographically and plant flags which comes across to be the main point of the game.
The WebAPI can be just 1 machine or loads spread over the globe that all can be accessed via 1 URL. $$anonymous$$aybe different URLs for different zones like US and EU as they would get peak loads at different times.
In this scenario the WebAPI's purpose is to sit inbetween the database and the world wide Web. The game would make a request to the webAPI and the WebAPI would seek for the data in the database (if it isn't locally saved/cached on the machine of the WebAPI. This way you can increase security and performance by controlling exactly what queries are being sent to the database and only allowing the client to see what is relevant to the request and what they're allowed via Authentication. To increase performance you could store the data retrieved temporarily if its small enough and practical in memory for future requests. and update the database periodically and download fresh data from the database periodically.
Then comes scalability and portability, which is another reason to not have a connection string in the game, as the connection string would either have an IPAddress or a hostname to a single server. so you're then limited to having 1 server for all your users across the globe. ($$anonymous$$ore advanced users than myself may know something i dont regarding how to get round this point). Should you want to move the server to a different IP or host the game would need to be updated. To increase performance too you can have multiple DB servers allocated to the same database to speed up query time if you're in the millions of rows of data and want very quick response times. I dont know alot about partitioning a database across multiple server just know its a thing. You could have regional DB servers and a master server where like the WebAPI updates and downloads new data, the regional servers would update and download data feom a master server.
It doesn't have to be a WebAPI, this is one way i know how and Im sure there are more advanced users here that'll point somthing out that might not be 100% correct but i thi k its roughly correct and it is worth the headache to have somthing like this if you're going large scale. And all this can be developed and tested locally at home, may need another PC and DDNS if youd want to test it in real world.
