We are looking at creating a native client for the Surface (and similar) for our SaaS product. Is it straightforward to create a "Metro" app that can talk to a local instance of MongoDb on that device? I sort of get the distinction between WinRT (which I'm assuming we can't/won't support) and Win 8.x proper. I guess what I'm looking for is confirmation that a "hybrid" app is possible, and that it can be delivered in a reasonable fashion via the app store or similar. Hybrid as in a Windows Store type app, with the database being a mongo as a windows service.
Bonus question: What about Windows Phone (is it a completely different beast?)
I've read a fair amount of documentation but still can't fully grok all this.
You can't deliver a native application via the Windows Store. Windows Store applications must use the WinRT (reference). You'd need to find another (more traditional) mechanism for distributing your application.
What you're describing is just a Windows 32/64 application written in a variety of programming languages that has a style of a "modern" application. The most common for Windows is very likely the .NET MongoDB driver. There is also a C++ driver that will work on Windows, but it's a lot of effort to get it to compile successfully (been there, tried it).
Further, be sure you understand the licensing for MongoDB before including MongoDB in the distribution of your application (it is AGPL).
Most importantly though, MongoDB is not designed or intended to be distributed to end users as it is a server product, not a product for workstations. It doesn't come with an installer, and is designed to be installed by administrators (as it would require port selection, path selection for the DB files, etc.).
I'm not sure why a SaaS application (which I'd think was a web site/cloud/style application that might have a locally installed application) would require a local database like MongoDB. I'd recommend you investigate DB options like SQL compact or Sqlite that could be fully embedded into an application without additional installations if possible.
Regarding your "bonus" question -- MongoDB can't be installed on a Windows Phone. I'd suggest just creating a REST API to wrap usage of MongoDB (or any other DB) and using that API to access a database.
Metro style apps are designed for work on Windows 8 and Windows 8 RT, so I think requeriments are the same.
The problem is you will not be able to use the Mongo Driver because it is not a PCL (Portable Class Library). If I'm not wrong the same is applicated for Windows Phone.
So you would have to develop your own PCL Driver or wait for one driver developed by MongoDB people.
EDIT
About #WiredPrairie's advice and MongoDB distribution, if you need a NoSQL database included with your application, you can try with RavenDB. It has an Embedded version.
Related
I've been looking all over the web for a solution to a client problem. They refuse to retire their 16-bit dbase database, but still want us to development real-time PWA web applications to read/write to the dbase system.
If it is even possible to get a RESTful API server working with 16-bit dBase?
Yes. You can create a PWA app with dBase or any DB, which has option to communicate to modern programming languages via APIs like JDBC, ODBC. Then that programming language of your choice, say JAVA talking to dBase via JDBC, can expose the functionality via RESTFul service.
For a PWA app, underlying back-end service tech stack is masked over plain HTTP requests. So it doesn't matter what back-end service you use and what DB that talks to in turn, for a PWA
As an update on your “real time “ need, not sure what kind of real-time functionality you are planning and on expecting what ETA/SLA. While no doubt you can build a PWA with any dB as stated above, it can certainly impact its performance. If you need something like googles auto suggest which pulls up results as you type, you need something like “in-memory” DB.
So the question is more of what performance your DB can support and what is expected. I do not see any feasibility challenge with respect to PWA.
We have a python based server that uses mongodb database. Our server programs uses RabbitMQ to exchange request/reply packets with many Android apps and perform actions accordingly. In addition to this, now we also need to create a web portal for the admin staff to let them manipulate the database, upload/download files, view data/statistics and trigger actions for android clients. So, the database is going to be common for the portal and the existing server programs.
For the web portal development, I got a recommendation for using Plone. We are comfortable in using traditional Node.js. Could anybody guide me on the use of Plone within this context. Is plone able to communicate with mongodb and existing server side programs?
Plone is a CMS designed around managing web based content and is tightly integrated for storage of its data in the ZODB, a NoSQL database. If data is very custom and isn't all about webpages and website nagivation etc, or if you have a need for the data to live in a different kind of DB then Plone probably isn't the right tool for you. This isn't to say it can't be made to do these these things but you would have to learn a lot about it's internals to make it do these things.
We are working on an application that will be offered both as a web-based and as a cross-platform desktop solution by means of Electron.
Due to customer requirements, the desktop client cannot make use of "the cloud" to store data; all data should be stored in the local machine or, even better, the user should have the option to keep the database/data file on an external HDD so that another user on the same local network can use the same data file.
We've been looking at NeDB, PouchDB, etc, but all these use either Web SQL or IndexedDB on the browser itself to store the data.
NeDB can theoretically use the file system but that seems only possible for Node Webkit apps.
Another option is of course MongoDB, but it requires setting up a site on a web server. Seeing as how our users will set that up in on their own machines, that will work for one user only but would make it very hard for them to share the data (note: assume users with little technical know-how).
Is there a way to force NeDB to persist data in a file instead of the in-browser database?
Alternatively, does any one know of a file-based, compact database that plays well with electron/node?
We'd preferably like to use a NoSQL database, but options of file-based SQL databases will be considered as well.
I have some experience with NeDB in an Electron app and I can say it will definitely work on the filesystem.
How are you initializing NeDB (or whatever your database choice is)? Also, are you initializing it in the main or renderer process? If you can share that, I think we could trace the issue to a configuration issue.
This is how you start NeDB with a persistent data-store that saves to disk.
var Datastore = require('nedb')
, db = new Datastore({ filename: 'path/to/datafile', autoload: true });
I think MongoDB is going to be overkill for an Electron app (it's meant to be really a high performance, distributed database running in the cloud).
Another option you could consider is LevelDB (a key/value store that can persist to the filesystem) which is popular in the node community. (EDIT 4/17/17 IndexedDB uses LevelDB underneath the hood, so if you go that route, may as well just use that)
One aspect I would definitely evaluate carefully is: How difficult is this database going to be to package and distribute? How do I integrate it into my build system? Level and NeDB can be included simply via npm install and any native code compiling is handled seamlessly with node-gyp, which is as simple as it gets. However, bundling Mongo, for example, will require some work to get a working build for each different platform.
Im new to Microsoft entity framework and wonders if it's possible to use this framework with a DB2 iSeries AS/400? Are there any problems at all when working with this kind of "legacy systems"? and the EF framework?
You can use Entity Framework to connect to an ISeries DB2 database one of three ways:
1. If you purchase the license to IBM's DB2 Connect product. The license is around $12,000 which is outrageous. Also, there is not enough good documentation for how the DB2 Connect product actually works, how it installs, or its possible benefits. I've contacted one of their resellers to get a test install and it was not an intuitive process so we never purchased the product. Likewise, there doesn't appear to be any demos. I don't understand how IBM can have one of the best servers available but don't bend over backwards to leverage their product to Microsoft developers.
That said, if you research this topic you will find much information saying that you can use Entity Framework using their ADO.Net data server provider. I went down this path but I will warn you that their data server provider only works when DB2 connect is installed. This is confusing because IBM advertises this ability but doesn't often show the direct correlation between the two products so you're often left thinking that it will work without db2 connect which it will not at this time.
2. Purchase a third party data provider designed for Entity Framework. Progress software's Data Direct is super easy to use. I don't like how their server licensing works though because their server license is per core processor for your app server. This is flawed because this assumes you only have one app server when in reality, people regularly need to have different app servers for load balancing. I would prefer they just license per one ISeries server. However, you can purchase the licenses for each individual user if you decide to do that.
3. Write your own data provider. This is possible but there are obvious drawbacks.
It sort of looks like it is - see here:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.swg.im.dbclient.adonet.doc/doc/c0054118.html?resultof=%22%65%6e%74%69%74%79%22%20%22%65%6e%74%69%74%69%22%20%22%66%72%61%6d%65%77%6f%72%6b%22%20
but quite honestly, I'm not 100% sure - especially not if it supports EF 4.0 (yet).
Or check out the IBM DB2Connect site and search from there...
We're currently using the SSO component of Oracle 10g App Server to authenticate users on our external / internet facing client "portal" (think similar to online banking)
SSO uses Oracle Internet Directory to store it's data, and we've been able to use PL/SQL and Java to access and modify the data held in OID (e.g create/drop users, change/verify passwords etc)
With the advent of 11g, Oracle appears to have "orphaned" SSO… it is available, but only as an add-on, and it appears to have been superseded by Oracle Access Manager. I'm guessing that it will have been dropped together by 12g. Plus it looks pretty difficult to install and get running correctly.
So, I'm wondering if anyone has any experience of having had the same migration problem as us? If so, what did you do?
Alternatively, does anyone have any experience of doing something similar using Oracle Access Manager? Do you think it will do what we want?
Or is there a better road to go down? Is there something else I should be considering?
Sorry for the very broad question, but it's one of those situations where a person's experience of what does + doesn’t work can make an enormous difference to us making some progress in a timely fashion. Thanks.
From my knowledge, Oracle Internet Directory (OID) is an LDAP compliant directory whereas Oracle Access Manager (OAM) is much more complex and consists of two main systems:
Identity System (users, groups,
workflows)
Access System (single/multi domain
SSO solution for Web and non-Web
based applications).
Access Manager relies on an Identity Server which is a stand-alone server process that communicates with any Directory Server (AD, OID, Sun Directory server..).
So you can use the new OAM and link it with your existing OID... to retrieve users/groups and metadata. All that you could do with OID will be doable with OAM as it brings more abstraction layers.
But in my opinion, and considering your case, directly accessing LDAP servers (OID, AD, etc) and using a light and "home made" SSO system is cheaper than relying on those big systems.... I think OAM is a usefull solution when you have lots of heterogeneous applications (web, non web, mobile, ...) and/or multiple organizations/domains with links and/or you need a very scalable approach.