I have a node.js server which only acts as a RESTful service. I have an angular js frontend which consumes the JSONs sent by Node server. I want to integrate socket.io into this application.
I tried https://github.com/btford/angular-socket-io but get weird errors like io is not defined and Unknown provider: $animateProvider. Are there any good examples with the exact scenario?
Related
Is it best to make API calls directly to RabbitMQ from the frontend React Native app, or is it better to make an API call to a backend server endpoint, and bind/queue the messages there, in order to return a JSON response to the frontend once the message is consumed?
My plan is to make a React Native app that uploads large files to Digital Ocean Spaces, and then store other data in Firebase collections. I have a Node.JS Express server running on the backend, and I'm wondering if it's best to queue RabbitMQ messages by going through the Express server first, or if I should just queue the messages to RabbitMQ directly from the frontend React Native app?
Here's a SO post of an example fetch() API call to RabbitMQ directly from a frontend React Native app, but I'm wondering how secure this is (because you need to pass user and password credentials in a JSON object), and if it's best to just send all messages to the backend Express server first. I suppose a lot of this may depend on app architecture, but my thinking is that it's best to queue, produce, and consume messages by first going through a 3rd-party client library on the backend, using amqplib for example, especially since most RabbitMQ examples found online do this.
I know it is a very much a beginner question but I am struggling to grasp a few things when it comes to the MERN stack and GraphQL. There is this particular project on github where the web app is developed using MongoDB, Express, React and Nodejs along with GraphQL.
I do understand that MongoDB is used for data storage and React for the front end but I can't wrap my head around as for why Express and Nodejs is used if an API is created with GraphQL which POSTs and GETs data directly to/from the MongoDB database? What is the role and interconnection between nodejs, express and graphql?
This question might not make sense to you because I am missing the knowledge of basic concepts of web app development and understanding of web dev stacks such as MERN.
Node.js is a JavaScript runtime environment -- it's what actually executes all your server-side code. Express is a framework that provides basic features for developing a web application in Node.js. While Node.js is already capable of listening to requests on a port, Express makes it simpler to set up a web server by eliminating boilerplate and offering a simpler API for creating endpoints.
GraphQL is a query language. GraphQL.js is the JavaScript implementation of GraphQL. Neither is capable of creating an endpoint or web server. GraphQL itself doesn't listen to requests being made to a particular port. This is what we use Express for -- combined with another library like apollo-server-express or express-graphql, Express sets up our endpoint, listens for incoming requests to the endpoint, parses them and hands them over to GraphQL to execute. It then sends the execution result back to the client that made the request.
Similarly, GraphQL.js is not capable of directly interfacing with a database. GraphQL simply executes the code you provide in response to a request. The actual interaction with the database is typically done through a driver (like mongodb) or an ORM (like mongoose).
So a client (like your React application) makes a request to your Express application, which parses the request and hands it to GraphQL, which executes your query and in the process, calls some code that then gets data from your database. This data is formatted into a proper response and sent back to the client.
For a beginner, the missing project detail you are referencing is as follows:
Used Node.js to create an environment for the API generation or running your code. GraphQL can't do this alone.
Used Express for body parsing middleware, authentication middleware(it will authenticate every GraphQL request) and express-graphql for the integration of GraphQL with express framework(means graphQL API functions will be called after authentication middleware next() function trigger).
GraphQL to create API that needs after auth middleware will call next() function.
So the project is working like the following:
Mongoose is connected first.
Node.js starts a server.
When API calls to send to the server, then
a) They are parsed with express bodyParser
b) Headers are set on those requests.
c) auth middleware call.
d) Now it is the job of GraphQL to handle the API.
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 am currently working on an application with the current tech stack:
Backend:
Mongoose
Express
Apollo
GraphQL
Frontend:
Vuejs
Apollo
GraphQL
So since I am a beginner with GraphQL I had no idea that apollo's inbuilt subscribe PubSub cannot be used in production and has no method of scaling without using services like Redis.
That being said, I have started a local Redis server for testing it, I managed to start a Redis Client in the backend using ioredis and it connects fine to the Redis server. I have now a problem that I can't start this up on my Vue frontend in order to receive messages being published by my backend. The creator of ioredis suggested that it is only for backends and I should use something else for the frontend.
I am currently confused as to how should I go about listening or subscribing to the redis server from my Vue frontend so I can receive published messages? Maybe I am looking at this in the wrong way? Any help would be appreciated.
Note: I have already done this with apollo/graphql's inbuilt subscribe but like mentioned, it can't be scaled.
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.