I'm building an app that receives updates from an external source. (Let's say the updates are stock quotes, that come in sporadically, every 10-60 seconds.)
Each client page might display the full list of interesting stocks, or focus on a single stock. Components on any page should update as the server receives new data for stocks displayed on that page.
My questions:
Will react, react, react-redux modules handle the communication between the server-side updates and the client components in the browser out-of-the-box? (Obviously I will have to write the actions/reducers/etc.) Or will I also need to write code that communicates those updates from the server to the clients?
I envision starting up the server-side process that receives stock updates from the main server.js code that also fires off the listen(3000) call. How could that stock-update process get access to the redux store? (My confusion comes because in most of the Express examples I've read, the createStore() call is within the app.use('/', ...) so the store gets generated each time a new web request comes in.)
Any pointers to projects similar to what I want to do? Thanks.
You will have to write code that communicates updates from server to the clients. The best way to do this would be use websockets. You can use frameworks like http://socket.io/ etc.
The Express samples that you have come across that use createStore on the server side are for server side rendering. Accessing store here to push stock updates is not preferred.
In Brief, what you need to do is ,
Set up socket io or websocket server
On the client, set up a socket-io client. It waits for messages from server.
Whenever you get stock updates, send the data from server to client through socket io.
When the client receives the message, dispatch an action with the data and let redux flow handle the state/store.
nope neither react no redux handles communication between serverside and react components (clientside)
react works as an ui view
redux manages application state
communication between server and client fall into actions and action creators in this case you could make an ajax call to server (by polling) and the state could be a boolean fetching, fetched,faliure all of which need to be managed in the store together with the response object.
Regarding the issue of serverside stock-update process,it doesn't matter since only the implementors understant what the initial state is hence the question to ask is does it matter to you that the createstore() is being called and what is it's initial state of the application.
on your case the createStore could be configured in such a case that its an reducer that fetches the stock at the point in time from the main server.js
you may also want to check
relay and graphql which comes with networking layer for communication to server by default all of which try to manage application state
[Answering my own question] The responses from various contributors above are correct and quite useful, but I have been (re)learning how to structure apps with react and redux. I wanted to share my new knowledge:
Christophe Coenraets wrote a blog posting that exactly matches my use-case: Real Time Trader Desktop with React, Node.js, and Socket.io
I write a blog posting that summarizes what I have learned about getting started with React programming in mid-2016: Getting Started with React Development
Related
There are many ways to fetch data from apis in next.js.
getServerSideProps,getStaticPaths,getStaticProps,Incremental Static
Regeneration and client side rendering.
If I have to make requests to backend on the change of any state, can I use other methods of data fetching apart from client side rendering?
I am from React.js background where client side rendering is mostly used.
What are the specific use cases of different fetching methods?
Can I always use client side rendering only in Next.js also.
Server-side rendering is good for SEO. You can check this, if you view the page source of a react app you won't get much HTML, this is the problem next.js fixes. With getServerSideProps and getStaticProps you can make calls to your API(such as DB back-end) to get your data and server-side render your page. Now when you have to update state of your page you can simply fetch as you normally would, since it doesn't matter because it is triggered by some action anyway.
Can I always use client side rendering only in next.js also.
Yes you can, but you want search engines to index your site and/or display relevant data such as review and preview text, right?
If I have to make requests to backend on the change of any state, Can I use other methods of data fetching apart from client side rendering
When the state is changed you will fetch new information just like you normally did in react.
GetServerSideProps and GetStaticProps only run once when the user visits the page(or reloads etc ofc). You can get the latest data by fetching and updating state with that.
Next.js is much more than react, it can be used as a back-end too i.e. creating APIs for saving data to db, handle authentication etc. Explaining it all is beyond the scope of this answer.
As for when to use what you can read more about it here, or search about it I'm sure SO has many questions about this.
One situation where you can be forced to use next.js features is when you want to consume an old API that does not implement CORS, here you can't control the dev on the other side so you can create an API on next.js which you fetch on your react code like: /getinfo. Now write code on your back-end to handle this which will delegate the result of that third-party API back to you, pretty neat right
I know about ssr (server side rendering) in Vue, such as nuxt. It grabs data in serverPrefetch() function and renders content on server side, only after then the request is returning data to user and he is starting to download app.js.
But can we start loading data from backend immediatelly after user request, not waiting for download of vue script, and not stalling request before all data is loaded. So user is downloading app.js, while our server is doing work with sql requests and forming response.
As long as Nuxt is concerned - you can find a pretty good summary on the SSR (and client-side) options available in the following article. Spoiler alert - I think SSR is still the best shot with what you are trying to achieve. In the Nuxt world - NuxtServerInit and AsyncData are the men for the job.
Say you decided to stay away from SSR - what options do you have?
Have some super lightweight js loaded and ran before the Vue application that would fetch the data and share it with the app somehow (e.g. - saving it to the local storage). Would it really provide a speed advantage? I really doubt it, especially considering how fast the Vue app could load when cached in the client browser.
Dump the backend data into the server response itself. I mean, you could prefetch all the heavy stuff and stick it into your page as a json encoded object. That would save some time for initial requests for sure, but then - how large is that data chunk? Wouldn't it make the initial load too heavy, destroying the initial purpose? Those are the questions you should answer based on your particular use case.
I was watching this video and wanted to understand how the state for a component during the first page load is set to the component. Does the component already get built out with the state set on the server side and then get sent down to the client as HTML OR does the component get built out on the server side, get sent down to the client as HTML, and then run bundle.js to get the data?
Around the 8 minute mark in the video, the speaker talks about the window state needing to be set and be synced with the React state. What is that about? Why does there need to be state on the window if it's already set on the server side? Is it because it's not being set yet, and it's sent down separately from the server and the client component has to grab it off the window?
When using React with server rendering, we must also send the state of our app along in our response, so the client can use it as the initial state. This is important because, if we preload any data before generating the HTML, we want the client to also have access to this data. Otherwise, the markup generated on the client won't match the server markup, and the client would have to load the data again.
To send the data down to the client, we need to:
create a fresh, new React store instance on every request;
optionally dispatch some actions;
pull the state out of store;
and then pass the state along to the client.
On the client side, a new React store will be created and initialized with the state provided from the server.
React's only job on the server side is to provide the initial state of our app.
I have a React/Redux/SSR app. Right now my app works as follows:
A user visits some url, browser sends request to Frontend server (Node.js)
Frontend server gets all necessary data for this url from Backend server (Ruby) and build html then responds to user's browser with filled window._PRELOADED_STATE_ with appropriated Redux store's state
User's browser renders received html and runs bundle.js script which is React app. It uses filled before window._PRELOADED_STATE_ to initialize app (at this time actions run again)
I want to prevent Redux actions performance on the first rendering on client because all is done on the server already.
What I have tried: on client after the first rendering I delete window._PRELOADED_STATE_ and run actions if window._PRELOADED_STATE_ exists only. But deleting of window._PRELOADED_STATE_ performs before app initialization so actions run anyway.
How can I get desired behaviour? Any ideas are appreciated.
Do you have the opportunity to use React in dev mode?
In dev mode React will complain if it's not able to match the SSR code with the front-end code. It looks to me that you can have a similar situation.
If that's not the case, which are the actions that run at the beginning?
The main interface app will return variables based on those initially POSTED by the client, and subsequent database calculations performed in real time by a dedicated engine.
In Sails can we plug the engine into a Controller used for returning the calculated variable?
What would be the best way to implement a real time link between the client and the engine ?
Sails comes with sockets support built in. You can transmit the data out of your controller back to the client via sockets to keep everything in sync.
Reference this page for sockets in sails:
https://gist.github.com/mikermcneil/6598661
As an aside, you could do everything using sockets, including the posting.
What is this 'dedicated engine'? Is this a separate service running somewhere else, or is it just logic for processing this data and handing it back to the controller?
If you want to put the data processing logic in the same app you can create a service which exports whatever data processing functions you need. Then in your controller that is handling the POST requests you can call on those services as needed, process the data, and emit it back to the client. All your sockets logic can go in that same controller since it is for communicating with the client interface. I would consider just moving all of it to sockets. If you look at the sails docs you will see that it has a similar interface with sockets where you can do standard CRUD operations: sockets.PUT, etc.
Sails.js WebSockets
No framework other than Sails, unless necessary for security purpose
Minimalist architecture implemented in Sails
1 POST API
1 POST Model
1 POST Controller
1 Socket per processing method
1 Socket switch within the Controller
Now if a secured framework integrates socket switching within controllers, that would come useful.
We may add middleware to the POST Model for the purpose of filtering text input data...