I have a mobile App, done with Xamarin and I'm looking to implement the backend, but I'm lost because I have a specific need.
My app. should be able to do some "geolocalized" queries, by example :
SELECT * FROM MyProducts Where Category = "Fashion" ORDER BY Distance(Item.Position, Me.Position)
Do you see ?
Is it the way it works? For example, a famous mobile app. like Tinder are looking for peoples around you, is it the way they do that?
But so, for this, I need a database that supports such queries!
About performance, is there a difference with SQL and NoSQL database, pro & cons?
I was looking for Azure, because it seems to be the standard tool for Xamarin, but can't find any information about that kind of queries!
About other possibilities, I have seen... Firebase, etc... I don't know at all!
Any help is welcome
Thanks
From experience I can tell you that Azure does provide a few options that would allow you to work with geospatial data.
The first is Cosmos DB (DocumentDB) and it nicely integrates with Xamarin (https://learn.microsoft.com/en-us/azure/cosmos-db/mobile-apps-with-xamarin)
The second would be Azure Search. The advantage here is that you can use different types of data-sources to work with. (https://azure.microsoft.com/en-gb/resources/videos/azure-search-and-geospatial-data/)
I hope that helps.
Related
My team is working on implementing Azure Cognitive Search on one of our websites. We notice that there are 2 ways to set it up: one way is using Azure Portal to import the data, create the index, and expose the APIs that do not require coding at all; another way is to use the #azure/search-documents library which requires a lot of coding to make the search happen.
We don't know for sure which way is better. We notice some aspects as followings:
Using portal: the process of setting up the search is easy and quick.
Using #azure/search-documents: it is a bit more tedious to set up the search, but it gives us the flexibility to the index definition and rules when to update the index.
Other than the above points, we don't know what are the other pros/cons of those 2 ways?
Any insight on this would be very appreciated!
Thank you!
While it's subjective based on the use case what the 'better' way is, typically for minimal business logic and simple data sources, you can use the Portal quickly to index and enrich documents.
You can check out the React Template we have that once you have an index you can seamlessly display UI elements like searching, filtering, sorting, and faceting documents.
https://github.com/dereklegenzoff/azure-search-react-template
You can also check out the Knowledge Mining Accelerator to show a step-by-step process on how to build a Cognitive Search solution.
https://learn.microsoft.com/en-us/samples/azure-samples/azure-search-knowledge-mining/azure-search-knowledge-mining/
I want to write a series of small apps for myself as micro services. This is for practicality and self learning. I want these apps to be able to work independently, but build a separate frontend client that has a search bar that can find data across all of the services. I wanted to implement a live autocomplete with search results as the user is typing that will search across multiple databases.
My current approach was to split each app into two apps, backend API, and a frontend client. Have a common auth service that all of the apps utilize for authorization.
I think this approach would work fine except for speed and performance, which I am not sure about. It is a personal requirement of mine to be able to implement this search bar with autocomplete search results. This means it will have to make API requests to each service to get those results, it just feels like it might be too slow.
Also, in case anyone is wondering, I was planning on using node, express, and mongodb for backend. Probably go with node, express, vue or something for the front end.
Q. Does anyone have personal experience with the performance aspect of working with multiple APIs?
Q. If this approach is too slow, is there a better approach that still allows for a separation of the applications?
The performance will be depending on so many other factors before/with the number of rest calls. It is really hard to say anything beforehand.
But according to my previous experience if you need to provide such a search functionality for a autocomplete feature you may most likely need elastic search for that.
That means instead of sending a request to each and every service for each autocomplete request you should have an index to search in (partial or maybe all data you need to show in your frontend) and search that index first to find the corresponding items then ask for the remaining/full data to other services if necessary. Details are totally depends on your requirements.
Of course if you go that way you should also implement a data population/syncronization mechanism to elastic search.
I'm looking to utilise the speed of Exasolution with the mapping capabilities of ArcGIS.
Exasolution is an extremely fast database. It has spatial support, but I'd like to be able to render spatial features inside a map. So it could be via some kind of API from Esri, or maybe a third party mapping engine and use WMS/WFS etc.
Anyone had any joy with these products?
Cheers
You will likely have some joy with EXASolution's JDBC driver - EXASolution's Geospatial libraries are built on OpenGIS using the libGEOS libraries, so everything you can do with Postgres should be possible on EXASolution.
I did an introductory Geospatial-on-EXASOL video a while back which may be of interest https://www.youtube.com/watch?v=f6Erp1WWLHw
I would say that your question would get a better response in EXASOL's community section where EXASOL customers and techies can answer specific EXASOL questions. Go to exasol.com/community for more details.
Good luck - and do let me know how you get on
Graham Mossman
Solution Engineer
EXASOL A.G.
I just finished a short knowledge base article which shows you how to connect to ESRI's ArcGIS from within an EXASolution database:
https://www.exasol.com/support/browse/SOL-211
The approach is different from what Graham suggested, as it uses Esri's REST API in combination with Python scripts called from SQL. So, the database connects directly and in parallel to the REST API service, not involving the client at all when it comes to data enrichment.
Hope that helps,
Franz
I am fairly new to Azure and mobile services, and all the examples and tutorials I can find for the table and API scripts are fairly simplistic.
If I have some processes that are fairly complex and rely on pulling information from many different tables and processing contingent on that data, should I be doing that somewhere other than the API scripts? I am new to node.js as well so maybe that's the problem but I was wondering if there is a more appropriate place for business logic, such as some bridge I need to add to my stack?
There are a lot of examples of how to use MSSql object which is used to query tables and Node in general available. A healthy search will reveal just about anything you need. Since you said you are new to Node.js consider using the .NET backend instead. It is based on Entity Framework and there are lots of Entity framework examples out there for you too. Finally, there are some really good examples of complex logic being used in the back ends in the sample code available: http://azure.microsoft.com/en-us/develop/mobile/ios-samples/ (pick your client OS) and here: http://azure.microsoft.com/blog/topics/mobile/ and here: http://blogs.msdn.com/b/azuremobile/
Let us know if you have specific questions!
I have an app that I would like to create. But I am not sure how to go about it. I am using node.js and would like to use couchdb, but if something like mongodb or riak would be a better choice them im willing to hear ideas. But, i have a site, say
cool.com
and on there is a couchdb instance, as well as a site to manage a store. say a shopping cart. the db houses all the store's items and data. The app itself has an admin backend to manage that data and can change items. What i would like to be able to do, is have the ability to have the user be disconnected from the internet, and still have the admin backend work. I realize for this to work I need to use a client side framework with my models/routes/controllers/whatever. But what I am not sure of, is how to let the site function while offline. couchdb if installed locally can sync the data from local to remote when back online, and if the admin user is on the computer, i could have them install couch. but that could be messy.
Also, what if the admin user is on a tablet or a phone? Would I need to have an actual mobile app and a desktop app to do this? is there some way I can set this up so it is seamless the the end user. I would also like this to be offline for end users too, but the bigger audience is the admin.
Another use case, instore POS system. and the power goes out. But the POS system can be loaded from the web onto a tablet and they can still make card based sales if the wifi is out, because the app is available offline.
Im just not sure how to do this. lets assume i need a client framrwork that can handle the data as well as the backend. something like ember, or angular. theres also all in one stacks like meteor and derby js, but those arent fully offline,but are for the appearance of real time. though meteor does have mini mongo so it might be worth looking into.
I was hoping someone could help me figure out how I would get this setup to work, preferrably with couch, but other nosql's would work too if I can have a way to sync the data.
I'm not sure if it would work for you, but I have been thinking of such an application for quite a long time now and been doing some research on what's possible. The best solution I could come up with is using a server with a couchdb and writing the application clientside based. Then for the data storage use pouchdb and synchronize the pouchdb regularly with your serverside couchdb if the app is online. I know pouch is in an early stage and not production ready but if you are willing to put some work into it I'd say it's doable.
If you want clients that work seemless as they go offline and come online (like a POS with the power out) then I would recommend making the app primarily work off local storage with a background publishing or synchronization to the cloud.
Local storage options could be everything from something light like sqlite, sqlexpress, firebird to no sql options like mongo, couchdb etc...
But for the client or device, consider the ease of configuration and weight of the option. You also need to consider the type of clients - do you have many platforms varying from devices to PCs? You don't want something that has a heavy config and runtime footprint. That's fine on the service side.
On the service side, consider the nature of your data and whether it's fitted better for transactional/relational systems (banking etc...) or eventually consistent/non transactional (no-sql) documents. Don't forget hybrid as an option. Also consider the service platform - for example, node goes well with mongodb (json objects front to back) ...
The device and service storage options can be different (and likely should be) separate by service interfaces (soap, rest/http, sockets etc...).
It's hard to have a one size fits all solution but often something light weight like sqlite on the device or client makes for ease of installation/config while scalability on the service side with something like sqlserver/mysql or couchdb/mongodb makes sense.
Some links to read:
http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB
http://www.sqlite.org/
http://blogs.msdn.com/b/sqlexpress/archive/2011/07/12/introducing-localdb-a-better-sql-express.aspx
You're question is pretty wide open and there's no one size fits all solution. Hopefully I provided some options to think about.
There's an interesting project out there called AppJs (http://appjs.com/), which packages Node.JS and Chrominium as a desktop environment. It's currently very fresh (very little documentation), but it appears to be straight forward enough (you'll be using the same tools as you would for your online application).
As for synchronising the offline and online environments. I doubt you can rely on CouchDB in the way that you envisage. CouchDB mobile support is not as comprehensive as some of the documentation suggests. So in this sense, it would be no different to using SQL/Mongo/Punchcards.
You might have more luck with designing a suitable serialisation scheme based on XML or JSON (or just plain text), and passing files between the online and offline installations.
Edit - Since writing this, Node Webkit - http://nwjs.io/ - is clearly the most obvious replacement for App.js. It has a very simple API, and some great features.