Still quite new to meteor/coding and I have a question on how to connect meteor to a live api that uses websocket.
The api is from bittrex (exchange for cryptocurrency) and there is a node js package that gives a "subscribtion" to the api in order to get live data:
https://github.com/dparlevliet/node.bittrex.api
I manage to have it run with node with no problem but I would ideally like to connect it to Meteor in order to present the data nicely. The props should be updated live with the data received. (nb: there is a lot of data, it is continuously coming).
Is there a good way to do this or is meteor not suitable for this. It means the props would change continuously.
Would a node/react solution only be better ?
This question might get closed because it's a bit opinion based but...
You have a streaming data source providing data over ws. You could:
(a) have all your clients subscribe directly to that source and not involve your server at all. In this case you'd be just using React on the client and basically ignoring Meteor (even though you'd be building the UI in a Meteor app). I don't know how bitrex charges for access or how they scale across many connections so that may be an issue if there are many connections.
(b) use your Meteor app to proxy then fan-out the bitrex data. In this case you would:
subscribe to the bitrex data source from your server
copy the data into a mongo collection
publish that data using a Meteor publication.
Your clients would subscribe to the Meteor publication and on the front end you would get reactive data updates like any other Meteor app.
The benefits of (b) are that bitrex only sees one subscriber and your app looks like a pretty vanilla Meteor app. Also if you have to use any kind of api key or secret to access bitrex then that key doesn't need to be shared with the client side.
Related
The problem
I am following a Vue.js 3 tutorial on youtube and I tried to implement the app shown in this video.
Then I started improving it a bit at a time. You can view my project here.
One of the main features I am trying to add is a Hall of Fame component in which you can view the best ten scores of anyone who plays. You can submit your score just after finishing the game. I decided to use Firestore to hold the data.
However, suppose I build the app for production and host it in a server. Then, I can download the whole project on my laptop, change a little bit the logic, and then play it locally on my computer. That way, I can send any type of data to my firestore database (because my credentials are injected in the javascript by Vue). I can then just send the ideal score of 1 ms to hack the game (this is indeed what a friend of mine managed to do).
The question(s)
The question is: how can I prevent this from happening?
Should I make a few changes in the code about the firebase configuration?
Should I use some other way to store the data, and not firestore?
Should I config properly the firestore security rules?
Also, what are the best security practices in JS frameworks like Vue.js (or React, in general) to prevent the insertion of non-wanted data on the client side? How do I manage the connection to a cloud database from such front-end frameworks?
Disclaimer
I learn everything about programming on my own, by watching youtube videos or googling and so on. I am new not only to Vue and Firebase, but to web development in general. Please consider this when answering.
TL;DR;
If the score is calculated on client-side (in browser) you can't secure it.
Anyone can just see the API call being made from the app to the server and replicate that with rest API tool like postman, so you wouldn't even need to download it locally to make changes.
If your game relies on client-side as a source of data, there is no way for the server to ensure that it is un-tampered.
You can try obfuscating the source code and doing client-side data encription, but it's all in javascript so everything is readable.
If you were to implement it in a more secure way, you would have the server trigger an action (as opposed to the script) but then the times would end up being longer because of the data turn-around time. Since the event fired from server to client and back would be reflected, but even then the automated response can be hacked by handling it with a script.
I'm building an app which uses user contributed content.
The contribution by each user should be available to all others in real time.
I was looking into firebase Realtime database for this.
However, when a user contributes content, there are quite heavy validations and calculations (read server side) to be done on the data before making it available to others.
Is it possible to have a server side validation in firebase ? Or should I look for alternatives ?
Initially, Firebase did not have a feature to implement server-side processing/calculations. All your processing had to be done on the client side.
Now, they've recently introduced a new feature called Cloud Functions For Firebase. Its a really useful new addition where you can write server-side code without the hassles of managing servers or instances. Read up more about it from the above link.
Also, this Youtube playlist by Jen Person is a great start. And, you can find examples similar to your use case here.
We currently designing a mobile app and the client has requested we have the ability to work offline and sync data when online again. I'm looking at using realm as it seems to make having an offline state really easy, however I'm a bit confused about where any server side logic would live. Am I right in that realm isn't really designed to have server side logic? You are just persisting data to the cloud when the cloud is available but you aren't actually in charge of building an API with and logic behind it?
Edit.
Reading further maybe Azure offline data sync is a better option because you can write the server side code? Am I correct in this decision that if I want server side code I can't use realm?
Thansk Michael
Realm Mobile Platform is designed for offline data access since it uses the full power of Realm Mobile Database as the client data store. However, that doesn't mean you are limited to only client-side interactions. We offer a Node.js SDK in the Professional and Enterprise editions where you can work with the same copy of Realm data from the mobile clients in a Linux environment.
The Node.js SDK offers the ability to open any Realm, query or perform write transactions on the server which will push data out to the client(s). In addition, it has event-handling capabilities, where you can register callbacks to perform logic in response to data changes performed on client devices.
To make it easier to get started with the event-handling functionality, we launched Realm Functions which allows you to create Javascript functions through the Realm Object Server dashboard, which will then run in response to data changes. Underneath the hood this uses the Node.js SDK to power it.
The sum total of all of this is that you should be able to build any server-side business logic that you need. By using Realm's sync as the transport layer, your mobile development can focus on the application logic versus networking and data transformation. Likewise, your server has an exact copy of the data to perform logic as well. Both sides operate independently, so offline changes will always sync back up!
I'm just getting into using Meteor, and yesterday I managed to get a leaflet map running with custom tiles. My goal is to get player positional data from a game and send it to a Meteor server to distribute to other players viewing the map in real time.
The data is available to a small desktop application on the player's machine and Meteor can easily handle the distribution part, so all I'm missing is getting the desktop application to talk to the Meteor server. What would be the best way to go about this? Is there a way to get Meteor to listen for incoming data from an external source?
You can communicate directly with a meteor server using its native Distributed Data Protocol (DDP). You can find the specification document here, and an up-to-date node driver here. Some searching may turn up implementations in other languages.
Alternatively, you could use server-side-routing in iron router to allow clients to use HTTP to POST/PUT their positions. The drawback of this solution is that you may need to come up with some way for clients to uniquely identify themselves (e.g. using a unique key) so you don't get bogus data.
I am trying to evaluate whether Meteor JS would be suitable for a future project that would incorporate live chat, and may need to be scalable.
It certainly can perform the chat functions, but I don't want to paint myself into a corner if traffic spikes and we need to provision the app with more resources in the form of drones/dynos/instances. I have read that a Meteor app on Heroku won't easily scale (perhaps not at all?). I am not clear on whether this is a Heroku issue, or more to do with the current state of Meteor JS (0.6.2.1 at this time). I've not found much more related to Nodejitsu or AppFog.
Can anyone clarify whether a Meteor JS app can currently be deployed on a PaaS such that resources (drones/dynos/instances) can be easily scaled up to meet demand? If so, which Paas? If not, what is the explanation (for a 5-year-old), and is there a roadmap?
Personally I've set myself up with an AWS load balancer and EC2 instances, with my DB over at MongoHQ.
The load balancer setup was made that much easier by following these instructions:
http://www.ripariandata.com/blog/creating-an-aws-elastic-load-balancer
I wrote a script to deploy to a single EC2 instance. It wouldn't be much work to add additional remotes in case you have multiple instances:
https://github.com/matb33/meteor-ec2-install
The best I would recommend is Meteor.com hosting (via meteor deploy).
This is because they would incorporate the ddp-proxy solution within their architecture. Its not as simple as just proxying between two meteors and using a dynamo because each user's session might be on the other server & it might cause a bit of trouble when switching over to another dynamo.
For now its free & it looks like they scale it fairly well too. I think they're also going to introduce a nicer hosting solution soon & who better to host meteor apps than meteor themselves.
If you want to deploy on your own infrastructure (EC2 for instance) you could scale up vertically for the moment until the DDP proxy is released (DDP is what meteor uses to communicate between the server and client (and soon between servers too) to make sure the state can be relayed across multiple 'dynamos'.
This answer is Heroku specific.
As far as I understand meteor application can't be scaled on Heroku on more than one dyno. The reason is that the meteor server instance holds a state for every client. This way it knows what updates to send to the client every time. Meaning that the client has to talk with the same server every time. The Heroku proxy layer doesn't provide this kind of communication and can route client request to a different dyno which does't hold client state.
So now the server has to get all client data from the db and send everything back to the client. The server gets loaded and the client gets updated. So we have two dynos, we do twice the work and add lots of noise to the client.
I hope it is clear enough.