I am having a hard time deciding on how to best implement what I thought would be a simple scenario. I need to either have React poll a database or API(which seems like an in-efficient solution) or be able to "push" data from another server into a react application.
Websockets seems to be able to solve this. But to me it seems very complicated to solve something that cannot be that unique of a problem. The backend server will be a ASP.Net WebAPI and I can easily have that polling the database and therefore only dispatch/call when something needs to reach the React app. But I cannot seem to find simple implementations of this in React? Perhaps it is just my search skills that are lacking, so perhaps just pointing me in directions on what to search for would be helpful.
Related
I'm building a multiplayer card game mainly in ReactJS and want to share some state between users (players). I need each user to be able to know when it's their turn to play and see some things about other users like score and current number of cards in hand, etc. For example, when one player's turn ends, I need the next player's app to recognize it's their turn and provide the applicable options.
It seems WebSockets or something based on it would be a good option. I'm still learning React and other pieces so I'm trying to keep the number of technologies down for now. I'm considering setting up rapid polling (every 200 ms, perhaps), either to an API or maybe checking against a file on the server or database entries.
Are there especially concerning performance issues or better options to get it working? I'm also learning about AWS and Docker and intend to host on AWS, if possible.
I recommend you use firebase which is a database to send and receive data online because the states of react js are not interlaced between devices
instead of sharing state between players you should explore the possibility of players sharing an instance of game object on the server.
for example :
game={
status:'running',
players:2,
p1:{state:'waiting'},
p2:{state:'active'}
}
time complexity for common state on server will be [n]
expected time complexity for state exchange or polling is [n^2] or more.
If you want to try serverless approach, you can look at AWS Lambda and Dynamo DB.
WebSockets won't work for you as you need one fixed party in WebSocket connection.
You could share the state peer-to-peer style with a WebRTC connection and using the DataChannel in that connection, but that's not an easy task.
(see for example: https://www.html5rocks.com/en/tutorials/webrtc/basics/#toc-rtcdatachannel)
The much more common option is to use a central data storage and either sync your state with that or just store it there in the first place.
You could use Firebase (see answer by David) or any other kind of database.
Firebase is particularly easy to set up, though.
If you have/need/want to use an API-backend anyways, you can use pretty much any kind of database layer in that and just talk REST or GraphQL with the API to share your state between players.
I've used Meteor a fair bit and love it, the publish/subscribe model, the way the whole framework is thought out, the ease of writing the server-side code...and I've used React with Meteor, and that's also cool.
However I've recently done a non-Meteor project in React/Redux and there's a lot to love about Redux. It's more effort to set up but the single point Store and all the associated tools/systems are very nice.
My web app will do a lot of database interaction and needs optimistic UI.
So I'm wondering whether to use Meteor/React/Redux for my next project, especially as there are some limitations in MiniMongo (e.g. no support for arrays). However I'm not finding a lot of relevant tutorials on how to hook them together, for example this one is nearly 3 years old now. This makes me doubt whether many people are using this setup, and whether I'll be able to get it working easily: I know from past experience that I need step by step tutorials to get past the initial hurdles with a new setup, then after that I can work things out for myself.
I'll use Meteor/Redux next for sure. I know them, I like them. The question is whether adding Redux is worth the overhead? I hope this is a suitable question for StackOverflow, if not I will try posting it elsewhere.
I'd like to hear reasons to use or not use Redux with Meteor/React, and any recommendations for tutorials. Thank you.
I think Redux is applicable in the non-meteor world, although there are alternatives now with graphql local state or the use of the React context api (which, thanks to React Hooks, is no longer deprecated)
Anyway, back to the story...
I have two separate Meteor apps, one that uses Redux, and the other that doesn't.
Redux works well with Meteor, it does the async thing quite well, but it adds a whole lot of complexity for arguable benefit. In a non-meteor app where you are doing much more in the way of orchestrating asynchronous API calls, then it makes total sense, because you can effectively decouple the data handling from the UI.
But in a typical Meteor app, use of publications and subscriptions means that the data flows naturally anyway. A UI button requests a back end action. The Meteor method does the work, and updates the database, and that data is updated in the UI automatically.
Let's take a scenario that I implemented recently. Members of my app need a Working With Children Check. They are issued a number, and when we are processing membershio renewals, we need to check that the number is still valid. This is initiated by a button on the UI, which calls a Meteor method, which in turn does an API call. The method simply updates the results of the check (even if it fails) into the member's database record. A return value from the Meteor call allows us to do a toast notificaton for the user, and pub/sub looks after updating the new status in the UI.
This could also be done with Redux, but pretty much all of the above code needs to be done anyway.
My preference is away from Redux, as there are alternatives, and it feels like it is a level of engineering that takes you away from writing your app.
I built an application and I host it in a local server. I would like When multiple users open the app and someone for example modify something, the modification will be applied for all the others automatically without refreshing the page.
I found a solution, that I call the function every 5 seconds for example, but when the number of users increase, it will make the request so slow sometimes. So I think it's not the better solution. Have you please any idea about this issue, what is the best solution for this problem?
Thanks.
You could look into long polling, which is an older way of handling this case. This would still have the performance/scalability issues you mentioned but works for simpler cases. More recently the websockets API exposes an easy way to get bidirectional communication between client and server with less overhead than polling.
A popular library for doing this nowadays is socket.io, which utilizes both long-polling and websockets and lets you easily handle things like disconnections and the like.
I am working on a webapp for a client that has a cPanel virtual server, and it appears that I can only use MySQL, but I want to store the data using a json-like structure, so that I can more easily use Angular.js on the frontend.
I've looked into installing a NoSQL database, and I can't find anything viable (if you know of a way to do that, that would be my best solution), so I'm thinking of storing the data as json strings in a series of text files on the server that I would write to with php.
I'd like to hear some opinions, and if there are any better solutions of which I'm not thinking of.
Go look at firebase and thank me afterwards.
In short, firebase is a cloud real-time JSON data storage. Everything for the backend is done for you and all you need to do is the front-end. Their servers are CDNs which means it will be great if you're looking to serve the entire world. All you need to do is configure your data-structure and use it!
It also provides sockets, which is great for real-time data (used for games, chat and etc).
There is a free option. The only downside is that it is a little expensive if you want to scale it, nevertheless if your app really gets to that stage - I'm sure you'll have money to hire some people to develop a similar backend for yourself.
I am building a mobile app using AngularJS and PhoneGap. The app allows the user to access a large amount of data-items. These data-items come with the app in form of a number of .json files.
One use-case is that a user can favorite any of those data-items.
Currently, I store the (ids of) the items that have been favorited in localStorage. It works and it's great and very simple.
But now I would like create an online-backend for the app. By this I mean that the (ids of) the items that have been favorited should also be stored on a server somewhere in some form of database.
Now my question is:
How do I best do this?
How do I keep the localStorage data and online-backend data in synch?
In particular, the user might not have an internet connection at the time were he favorites a data-item. Additionally, if the user favorites x data-items in a row, I would need to make x update calls to the server db, which clearly isn't great.
So, how do people do it?
Does Angular have anything build-in for this?
Is there any plugin?
Any other framework?
This very much seems like a common problem that must have a well-known solution?
I think you've almost got the entire solution. All you need to do is periodically (on app start load the data from the service if available, otherwise use current local storage, then maybe with a timer and on app close update the data if connected) send the JSON out to a service (I generally prefer PHP, but Python, Java, Ruby, Perl, whatever floats your boat) that puts it in a database. If you're concerned with merging synchronization changes you'll need to use timestamps in the data in local storage and in the database to make the right call on what should be inserted vs what should be updated.
I don't think there's a one size fits all solution to the problem, though I imagine someone may have crafted a library that handles the different potential scenarios the configuration may be as complicated as just writing the logic yourself.