I have one misunderstanding with Deepstream.io. It has both NodeJS SDK (which can make client for deepstreamHub from my node application) and NodeApi, which allows to install deepstreamHub as npm package. Why do we need both of this options? When should I use each of the option?
For example, I have existing realtime node app, which uses socket.io as transport layer. And I want rewrite app and migrate from socket.io. What option should I use? Install deepstream as a package in existing app and call my app logic in RPC callbacks, or install standalone server on computer, then install deepstream.io-client-js in my app and also register my app logic as RPC callbacks, using ds.rpc.provide ? I do not understand difference of two approaches
It looks like there is a misunderstanding between deepstreamHub[1] (the cloud platform) and deepstream[2] (the standalone server).
If using deepstream the server, you'll likely need to host it yourself on a cloud provider (AWS, Azure, etc). With deepstreamHub you get given an application endpoint which you can connect to and a dashboard to manage your application permissions, authentication methods and data.
Either way you'll need to install the deepstream.io-client-js module in your application, you can then connect to your server or your application endpoint (if using deepstreamHub).
After this you can register app logic as RPC endpoints and proceed to write your app logic as normal.
[1] (https://deepstreamhub.com/)
[2] (https://deepstreamhub.com/open-source/)
Related
I want to practice creating my own RESTful API service to go along with a client-side application that I've created. My plan is to use Node and Express to create a server. On my local machine, I know how to set up a local server, but I would like to be able to host my application (client and server) online as part of my portfolio.
The data that my client application would send to the server would not be significant in size, so there wouldn't be a need for a database. It would be sufficient to just have my server save received data dynamically in an array, and I wouldn't care about having that data persist if the user exits the webpage.
Is it possible to use a service like Netlify in order to host both a client and server for my purposes? I'm picturing something similar to how I can start up a local dev server on my computer so that the front-end can interface with it. Except now I want everything hosted online for others to view. I plan to create the Express server in the same repo as the front-end code.
No, Netlify doesn't allow you to run a server or backend. However, they do allow you to run serverless functions in the cloud. These can run for up to 10 sec. at a time. Furthermore Netlify also have a BETA solution called "background functions" That can run for up to 15 minutes. But honestly for a RESTful API there sure would be better solutions out there?
If you are still looking for the Netlify for Backend you can consider Qovery. They explained here why it is a good fit for their users.
I am beginner in web technologies. While studying about frontend frameworks, I came to know that we run separate application servers for frontend and backend server(API).
e.g. If I am using vue.js, I'll be running a vue server for frontend and I'll be running another MEAN stack API server separately. Now my application will need to show real-time updates, I'll have to use websocket connection between my browser and frontend server which further will need websocket/webhook connection with my backend server(API). Now I am already aware of the scalability and session management issues with websocket connection. In this scenario, how should I build my application for better scalability and with less complexity? Is it possible to create a monolithic application server for frontend and backend? Will that be a good choice?
Is it possible to create a monolithic application server for frontend and backend? Will that be a good choice?
That choice is fine; start simple and you can break into microservices in the future. Unless this is for a large production system!
If you use something like express you can serve the Vue.js files using express.static, API endpoints using express.Router() instances, and the ws or socket.io module attached to express instance for websockets.
Now my application will need to show real-time updates, I'll have to
use websocket connection between my browser and frontend server which
further will need websocket/webhook connection with my backend server
This isn't the case. You can have your frontend (the app running in a browser) connect directly to the backend via websocket if you wish, no need to proxy via a frontend server. For session management look into JWT tokens.
You can go for socket.io library in Nodejs. It's simple and easy to use, The scalability and session can be handled by introducing Redis,
check https://socket.io/docs/using-multiple-nodes/
I'm new to GraphQL, Apollo, AWS S3, and Redux. I've read the tutorials for each and I'm familiar with React Native, Node, Heroku, and Mongo. I'm having trouble understanding the following:
how a "GraphQL Server" is hosted for a mobile device using React Native?
can I create the GraphQL server with Node and host it on AWS S3?
how to grab that data by using Apollo/GraphQL in my React Native code and store that data locally using Apollo/Redux?
do I have to use Graphcool as the endpoint from the start instead? All I'm trying to do is pulling data from my database when the app loads (not looking to stream it, so that I am able to use the data offline).
Where should I look to get a better understanding?
I have a couple comments for you in your exploration of new territory.
GraphQL is simply the query language the talks to your database. So you are free to run any type of api (on a server, serverless, etc.) that will use graphql to take in a graphql query/mutation and interact with your database.
GraphCool is a "production-ready backend" basically back-end as a service. So you wouldn't worry about running a server (as I believe they run most everything on serverless infrastructure) or managing where your DB is housed.
You can run an HTTP server on AWS EC2 or serverless using AWS Lambda. (Or the same flavor with Google or Azure). Whatever you decide to use to accept requests, your endpoint will accept graphql query strings and then do stuff with the db. AWS S3 is more of static storage. You can store files there to be retrieved, or scripts that can be pulled, but S3 probably isn't where you would want any server-like code to run.
Apollo would be a tool to use on your frontend for easily interacting with your graphql server. React-Apollo
Apollo/Redux may help you then manage the state throughout the app. You'll simply be loading the data into the app state on load then interacting with that state without needing to make any more external calls it sounds like.
Hopefully this was helpful.
we are using Meteor + NodeJS application. Meteor application use for communication for client and Nodejs application for connect to DB. We gave the nodeJS application reference in meteor application.
When any un-handled error occurs in nodejs application we are not able to catch it.
We deploy the meteor and nodejs application as a package.
From Meteor we called nodejs methods using Meteor.wrapAsync(node.method1).
we are able to catch the exception in meteor till callback from node method. After callback if any exception occurs in nodejs method we are not able to handle it.
Thanks for your replay
Since there isn't any code presented here, I'm going to assume that you have the following scenario:
You have a Meteor application that calls services that are hosted in a different node server.
The node services are sharing the same database as the Meteor app.
Clients only interact with the Meteor app.
Meteor is using its own embedded node server, so service calls to the other node app is actually a communication between two different node servers, which means that they have their own call stack, hence they can't handle each other's exceptions.
The only way to communicate errors between the two is if you handle the exceptions in the node application and send error codes to the Meteor app. They can be either HTTP codes, if you're using ajax, for example, or your own kind of error codes.
Here is my set up:
Node.js server with RedisCloud, and client mobile app written in Unity C#.
I'm trying to push message from Node.js server to UnityC#.
At first, I try to get Unity access RedisDB directly but that is too dangerous having Client connecting to DB, and open the port.
So, what module works well between Node.js & Unity for message pub/sub? or 3rd party services that takes data from Redis, and push to Client?
I think socket.io will work but it seems just too much work for Client to write code handling that.
Is there something like Firebase or Photon, but instead using Firebase DB, point to my own RedisDB?
Thanks.
If your mobile client is for iOS then you should use "Apple Push Notifications", if Android, you should use "Google Cloud Messaging".
You can easily find modules for these tasks on npm, for example: https://www.npmjs.com/package/gcm
Use a Cloud service like Pusher or Realtime (the company I work for). Simply subscribe a channel on your mobile app using the Realtime Unity SDK and publish the messages from your server using the Node.js SDK. You don't need to worry about the dirty backend details (security, scalability,...)
More at http://framework.realtime.co/messaging