Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
Hello guys I have a question regarding state management in applications centered around events.
Let us say take a scenario in which a some one posts a tweet on twitter, so this tweet should be visible to the users in real time. So things like posting a tweet or typing a comment etc are all real time events; where as fetching data from the server on the click of a button are all Restful in nature. Real-time communication can be achieved by using either web-sockets or server-sent-events. Now the question naturally that comes in the mind is How do we manage the data (state management) for rest as well as real time communication?
Restful resources are generally fetched as a bundle of information, but server sent event or websocket send it as a packet of information, by packet what i mean is data related to the single tweet. If we were to show a list of all tweets to the user we need to update the state to previously received tweets and incoming tweets but state management here becomes very hard.
I have looked at some solutions like RxJs which typically involves observables, and redux-saga which deals with generators. So can you share your experiences and insights to managing real time data and restful data.
End goal is how to manage rest and real time data in a live feed. Please feel free to correct me for any technical inaccuracies and/ suggestions. Thank you
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I'm currently developing a side-project and trying to learn some general API things.
The user can access a list of projects by going to /projects and I'll get
all of the projects as a list. The user can also click an Edit button that goes to
edit/{project_id} and was wondering whether I should pass the project object to the component or just do a separate request to the API with the ID of the project to only get that project.
The first one is good because it's easier and also, I won't have to send all information about the project objects because I can't show all of them in the table (in /project) and this will save some data (ex. the list will show name of project and created date only). However, the second way is good because there will be less requests to the server.
My question here is, what is the preferred way?
Sidenote: I've tried searching for a question like this but didn't know how to phrase it, so this might be a duplicate.
In this situation, I would advocate for the separate API request. With a list of projects, you really don't want to include everything in your "get all" API call; just enough basic stuff to populate the list. That will make your queries faster and data transfers smaller, which is especially helpful when a large number of projects come into play. However, when you "deep dive" into a single project, then you'll want everything about that single project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am currently developing a appointment scheduler. Now I am designing my own frontend calendar (month view) and I know that I will have almost every day an appointment in the database. I had an argue about the API call structure.
He says: I should make an api call which returns a list of every day of a specific month and the days contains the respective appointments. Depending on that I should generate my Calendar.
I say: I want to generate the Structure of the Calendar independent of what i am receiving in the frontend. I will make a call that returns me all appointments of a specific month and add them to the calendar after I received it.
He says my idea has redundance and too much logic in the frontend, because it‘s recommended to keep as much logic in the backend as possible
My question is which way would have a better performance and would be the user experience affected depending on what way I take?
BTW as frontend I use React-Typescript with Redux and as backend C# Core
-
well, I think you should keep a clean separation of concerns. Your API concern is to provide scheduled appointments, which I suggest you to put out like:
[
{
"id":1234,
"datetime":"20210115T15:15:00",
"doctor":4231,
"doctorName":"Doe, John",
"patient":9999,
"patientName":"Mary"
}, ...
]
and that's it.
How this is going to be plotted on the screen is your front-end business.
I don't know who exactly im favoring here, but Keep your front-end as simple as possible is a very minimalistic point of view and likely to overburden your backend with front-end-only aspects.
He is right. Keep your front-end as simple as possible. Logic should be mainly handled by the back-end, Always remember to develop your front-end according to what you receive in your API call.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am building a quiz app with Ionic React. I want to implement some kind of quiz timer/countdown feature to limit time spent on every question. The catch is, if I implement a countdown function on client side or Front-end, I'm afraid that folks could tamper with the script and cheat by manipulating the timer to their advantage.
Therefore, I think the only way to prevent this is to implement the timer/countdown feature server side. However, I do not know the right way to go about this... Wouldn't a countdown function blocks the server? Or is there some other way that I do not know?
There are two ways to handle this:
http:
You can run a timer at frontend. Notify the backend with start / end timestamp of each question to calculate the duration taken for each question. If the duration falls within the allowed range, you are good to proceed. Here, frontend is your source of truth but you are validating it at the backend.
websocket:
Or you can implement a websocket to communicate in real time with the backend. In this case, you can run the timer at backend and show its progress at frontend in realtime. Backend will be your single source of truth.
You can check this post too.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am trying to display a bunch of statistical information in a React page. I am using MongoDb, Express.js, React and Redux. Considering that I have to display a bunch of statistical information, I can do those in two ways. The first way is by making queries to the database for each one of the statistical information that I need and store them on Redux state, or I can make few queries and from there I can derive other statistical information. Which is the best way to do that?
If I follow the first way, I end up with a complex Redux state and not reusing some of the information provided by other queries. If I follow the second way I end up deriving complex information in the client side.
Which is the preferred way?
You need to show us some examples related to your data. What information are you going to show? How related those pieces of information between them? How complex those queries? How much time does it take to show a piece of information to a user? How fast your API results? Do you want to show those pieces of information asynchronous or sync?
To define your structure you need to make sure about your user story. So it depends on Currently, users are expecting to see information separately (async) with some content loader and do some actions in the same way. So it is good to divide your components into small pieces. So each big component (organism) makes API calls and shows information to a user with small components.
When it comes to state management if pieces of information are dependent on each other it is good to use Redux and define reducers actions etc. so you can keep track of your state in a bigger scope. If those pieces of information only need and auth key or user data, you can use react hooks in your organisms to make your API calls that get auth information from ContextProviders.
If you are capable of creating microservices (or if you have them), I would recommend you to try to react hooks. If you have different API's which shows different info use redux.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a design question.
I have an app(let's call it app A) gathering statistics from a system, by regularly polling each component in the system.
I have a second app(app B) which is supposed to make some decisions and enforce them into the same system, that app B is gathering statistics from. For the decision process, app B needs some info from the statistics gathered by app A.
So, at certain moments in time(this would be 10-100s times per second) app B makes a request to app A to get some info(i.e. some up to date statistics about the system).
What's the best solution to implement this exchange of info from app A to app B?
I was thinking of 2 solutions:1) an RPC-style solution, using a message queue (RabbitMQ)
2) a database-based solution, have a table where app A publishes the most up to date info and app B reads it whenever needed.
Please provide some insight on whether any of these two would make a good solution or not. Any other suggestions are welcome.
Thanks!
Consider reversing the flow of information. Have App A tell App B when something changes, possibly via a message/event using a message queue. App B can then keep it's own highly-available version of App A's data and query it quickly and efficiently without crossing the wire or process boundaries. This highly-available store could simply be in-memory, or some sort of high-performance key-value store.