I’m planning a large open source project, a secure and distributed social media tool (the existing ones I know of aren’t secure). I’m looking into Meteor, have read a lot about it, and am excited to use it if it can do everything I need. I’ve looked at other cross-platform development tools, and they don’t have what I need:
open source and not corporately-controlled
HTML/CSS/JS for layout
HTML templates to separate design from code
a seemingly happy and active user community
This project would not be web-based, but would be mobile apps on Android and iPhone (desktop client app maybe later). This is needed for security, so that users don’t need to trust servers with plaintext personal information.
My questions right now are:
Can I use plain old TCP and UDP sockets in a Meteor app?
I plan to store data only on the client side, i.e. on the mobile device, not on any server. Is it possible to use Meteor this way, i.e. MongoDB or other datastore on the client? If a server/daemon is required, is it simple to have it run locally on the same device as a client, securely?
This app will have the UI process, and probably a different process to listen to an open socket for messages from the network. Is it possible to fork() a new process or thread, or alternately, does the JS event model handle this cleanly enough in the one thread?
How is app responsiveness these days when using HTML/CSS/JS? I know it used to be slower than native apps, but that was a few years ago.
I assume a Meteor app can access a device’s camera and other hardware, right?
By any chance, is it possible to link in or call Java or other libraries with Meteor code? I’d like to make using Tor an option, and Orbot (Tor proxy on Android) is written in Java. I may also want to use code from the secure messaging tool Briar. If linking or calling this way isn’t possible, I may be able to translate the Java to JS, with GWT.
Stuff I know: Web and other protocols, socket programming, *nix, client-side JavaScript, server-side programming
Stuff I don’t know yet: server-side JavaScript, NodeJS, mobile app development, GWT
I realize this is not the usual Meteor model of reactive client-server apps, but I like Meteor’s other features.
Note that the whole system will probably have servers, but they will be written separately. Servers will do little more than pass encrypted messages among clients and other servers. There may be a second kind of server: a trusted personal server to encrypt and send messages e.g. to all friends, in order to minimize battery usage and traffic on the mobile device.
Thanks so much for any answers! All relevant thoughts or advice are most welcome and appreciated. (I would have asked stackoverflow, but I believe they frown upon asking for recommendations.)
To be honest, I’m not sure meteor is a good fit for this project. If your storage is entirely client side, Meteor on the server would be monumental overkill to “just pass messages between users”. Similarly, mongo on the client side within Meteor is minimongo, and isn’t particularly efficient at “querying” (though isn’t bad with _id only lookups). If you’re looking at running a regular mongo process on mobile devices… I’m not even sure thats possible? Certainly not through meteor.
In fact, the only features of Meteor it seems you’ll be using with this setup is the build, HCP process and DDP. DDP won’t be particularly useful to you if you’re just passing messages, and in any case you can implement DDP without Meteor if you really love it (over websockets, TCP, or whatever else you fancy). Regarding the build system, if you’re only really using the build for the client, react native might be a better way to go.
That just leaves the Hot Code Push - which as far as I know (would love to find out I’m wrong) is still broken on iOS so app’s refuse to update whenever you change the static resources.
You can use workers in JS on the client side in browsers, though I’m not sure if Safari supports them (it does support service workers, but they’re a little different). If safari doesn’t support it, a cordova (for iOS) app won’t either, and thus neither will Meteor.
App responsivness is “ok” in HTML, so long as you code things carefully, and aren’t doing anything too intensive - it’s very easy to get sluggish UI’s by abusing reactivity. Native will almost always be faster.
Meteor can access the hardware through cordova plugins. Though this is not always easy.
Regarding Java libraries - if you can use it from in Cordova, you can use it with Meteor (on Android) - this won’t help you with on iOS though.
Thanks for your reply and insight, it’s very helpful. I read an assessment of Meteor that described it as a collection of powerful features that don’t all have to be used. I’m considering it mostly for cross-platform support, the HTML/CSS/JS layout, and the HTML templates, and of course because it’s open source. I probably won’t even need reactivity. The templates in my app may not be reactive, so I could roll my own simple template system if I don’t use Meteor. I’ll consider other cross-platform tools that use HTML/CSS/JS, including React Native, though I’d rather not trust a tool by facebook. Cordova is a possibility; I’m reading about it now.
I may have confused things with the mention of the message-passing server-- it’s a separate piece of software, not part of the Meteor app. So yeah, I realize this is not a standard Meteor use case. This server could be written in any language, even by a third party, if it conforms to a standard I’ll define. So Meteor would only be used for the mobile app. There would be no reactivity with the message-passing servers-- if reactivity is used, it would only be with the local (mobile-side) datastore (which would be updated by the network part of the app).
I don’t think the datastore will be very complicated, but it could hold a lot of data, and I will want to sort messages by date, sender, status, etc. It looks like minimongo doesn’t support indexes, and it’s not persistent anyway (which I need). Do you know of a client-side datastore that works well with Meteor, is persistent, and ideally supports indexes?
It sounds like responsiveness will be acceptable, since I probably won’t be using reactivity, especially as devices get faster.
My main remaining question is: Can I use normal TCP sockets in Meteor? I may or may not use UDP in the future. I searched about this, but couldn’t find any clear answers.
Certainly, Meteor is a collection of tools that can be used as much or as little as you like, but your stack doesn’t look like it nicely fits to anything that is specifically Meteor.
If you’re looking at a regular primarily client side mobile app, I’d look at raw cordova - Meteor uses it internally, however Meteor ties you to older versions of Cordova which don’t play nicely with either iOS or Androids latest required versions (true as of about 3 months ago, not sure if still true).
If you really REALLY want to use Meteor’s default rendering engine Blaze, you can just about use it without Meteor in any webpack project (which you could then build with Cordova), I worked on an extraction to NPM recently: https://www.npmjs.com/package/meteor-blaze-runtime. I love working with Blaze, but I don’t think it’s any better than either Vue.js, Angular or React - and if you’re not working with reactivity, or Meteor, one of those might be better. Honestly, just because it’s facebook created is not a good reason to not use React - it’s used in thousands of applications.
Regarding datastore, I’ve used grounddb as an offline cache for Meteor, it syncs up quite nicely. There are probably dozens of other persistent DB technologies if you dont need it to sync, even something like sqllite would work.
Regarding TCP - Meteor server doesn’t support DDP over TCP natively, but you could fairly easily implement it using existing packages to open a socket, and interpreting the DDP messages. As far as I know, there is no way to open a TCP socket from client side javascript in a browser - this might be different from Cordova though.
That all sounds good, thanks. I’m looking at Cordova, and it seems to have all I need. I’ll check out Vulcan too.
The reason I was thinking of Blaze templating instead of the others is that based on what little I’ve seen, anyway, Blaze separates out the code from the HTML/CSS more cleanly than the others. I’d like to let a designer create and manage the UI visuals knowing nothing more than HTML, CSS, and a few template commands (if/else, loops, includes). They wouldn’t need coding skills. Your NPM extraction of Blaze sounds like it would do what I need.
If I can use SQLite here, I’ll probably use that. It would do all I need.
Thanks again for all your advice, this has been immensely helpful.
Happy to help. Message me if you have any trouble with the Blaze NPM module. I’ve used it in a few projects, but the dependency chain isn’t super clean (as it depends on some other Meteor NPM extractions).