My team has developed an iOS and Android App for our project while we use node and socket.io for back-end. We want to move to meteor so we can have a front-end with Angular 2 easily connected with the back-end.
But we want to rewrite the back-end with Meteor so our Apps can use it. And after this create the front-end.
My question is easy, in Meteor front-end and back-end are done at the same time? Or can we first build the back-end and after this the front-end?
Yes, this is possible although it would feel a bit awkward to an experienced Meteor developer.
The Meteor "back-end" exposes the following:
managed collections: these are the definitions of the mongodb collections that will be used by your app to persist data. Note that some of these can be private to the back end, i.e. not exposed to the front end at all.
publications: these are the filtered/projected "views" of the collection data that the back-end will share with the front end on request (the form of the request is a subscription). Published data is synchronized bidirectionally with the front end asynchronously over WebSocket. This is the magic of Meteor's DDP which IMO is Meteor's core innovation.
methods: these follow a more traditional request-response pattern. You can have as many of these as you want and each can accept any number of parameters including objects. Meteor can also do latency compensation for methods which means that the method is first simulated on the client and the UI updated while waiting for the server to come back with an authoritative result. If the server result differs then the UI is patched up with the authoritative result. This makes database updates appear instantaneous to the user while providing eventual consistency.
If you like you can even build traditional REST endpoints with Meteor but then you would be missing out on the reactive sugar. These can of course be useful for other integrations however.
Like nodejs, Meteor encourages developers to tackle the full-stack. You're less likely to segregate developers into back-end and front-end functions which gives you a lot more flexibility.
Related
I'm new to Node JS development. As an ASP.NET MVC developer, I normally use Repository Design Pattern where I have separate projects for Front-End and Database access in one solution. In addition, when creating a REST api, this can be added to the existing solution. So when publish, it api and front-end is separated by a different route.
I've just created a REST Service in Node JS and it's really simple and I like it. However, when it comes to Front-end I was looking at ReactJS, I've seen a blog (unfortunately, I can't find the link) where it separates the process between the REST service and react front end. I'm just wondering if this is a common design pattern in nodeJS using ReactJS. And if there's a benefit on doing this. Specially nowadays, Full Stack developers are a common thing. I can see the benefit of it from a maintenance stand point but I'm just wondering if there's a benefit in terms of server resources i.e. memory, cpu. Should the OS handle 1 vs 2 nodejs process? Will this differ from using linux vs windows?
I see a huge benefit of separating the frontend from the backend so I would propose you to have your Node backend running in its own project and let's say a React solution running on its own. The React client can then consume that API together with other APIs later. By separating you have the benefit of scaling later.
If you've already built the REST service in node, you can access it via proxy in the React project's package.json by adding
"proxy": "http://127.0.0.1:5001/"
It helps manage CORS issues.
I have decided on a stack for a web app project. Its as follows.
Express JS + Knex + postgresql backend as a Web API layer.
VUE JS as the front end.
I have completed rough design of the whole system. I am stuck with the implementation part. Do I build the UI first and flesh out the API, or vice versa.
Usually you build both at the same time - preferably by two different teams to minimize tight coupling and leaky abstractions. Sometimes the API is build first and then the web or mobile or some other frontends are built for that. Sometimes a frontend is build first as if the API already existed and it results in a solid specification for the API to get built later. Sometimes the specification is created first and then both backend and frontend(s) are built to follow the spec. It all depends on the specific work style and requirements. It's more important how you to it than when.
I'm working alone on a personal project and my approach have been to work only at the frontend then mock the http part with a realistic mock that emulates a real api behaviour and only at the end moving at the api development.
I decided to use this apporach because in my experience no matter how the model and functional specifications are clear, they will always be subject to change request and you can prevent the side effects on your development workflow by testing and interacting with the actual UI.
Then you will find that the api developemnt will be completed in a matter of weeks not months with a better clear understanding of what are your (or your client's) needs.
Hope this could help you
I have an existing web application. It uses Spring MVC on Tomcat and MySQL at the back end with transactions (multi table updates). I am also using spring security for role based authorization. This is very typical website without any real time notification, chat etc.
Now my client wants to add real time notifications like Facebook, chat module etc. Typically on front end some action will be taken, and all or specific logged in users need to get notified. After receiving notification, I need to update some <div> content. Frequency would be high. (Currently user needs to refresh browser.)
I completed POCs using Node.js/Express and looks like it's easy to accomplish these 2 things with Node.js.
I have 3 options:
Move front end to Node.js and may be Angular.js. Manage form validations / security through Node.js/Angular.js but all database calls are still managed by my old website (in a RESTful manner) as I can reuse my existing stuff. Most of the method calls return to a tile but we can easily convert to return JSON object.
Keep existing website as it is and plug in Node.js into it just for real time notification / chat etc.
Scrap existing website and redo everything including security, transactions using Node.js. There are many posts saying as Node.js is kind of new, not preferable for enterprise application and also this might be too much.
Approach 2 would be my preferred approach as we have expertise in Spring, Node would be completely new for us but I don't know whether it's practical & doable approach, what kind of issues I might be facing. I am also not sure how to integrate Spring MVC running on Tomcat and Node.js together.
Please could anybody help me in deciding, out of the three what's the best way to go? Any other approach which might be easier?
You already have an existing Spring MVC codebase and you can reuse it. However you can go ahead with AngularJS for your front-end technology. Your front-end AngularJS code can talk to your existing Spring MVC via REST api and to NodeJS for real-time features which you plan to develop.
You need to use Socket.io within NodeJS which will provide the features you are looking for.
One major problem you might face is related to session when talking to two different backend stack.
I am implementing a product that will be accessible via web and mobile clients, and am doing thorough research to make sure that I have chosen a good set of tools before I begin. For front-end, I am using AngularJS (Angularjs + angular-ui on web, ionic + cordova on mobile), and because I want to have a single backend serving all types of clients, I plan on implementing a RESTful service (likely one that accepts and returns JSON data). I am leaning towards using Mongo, Node, and Express to create this RESTful API, but am open to suggestions on that front.
But the sticking point for me right now is this: certain parts of the application (including, for example, a live chat/messaging section) need to be real-time. I am aware of the various technologies and protocols for implementing real-time web services (webhooks, websockets, long polling, etc.) and the libraries and frameworks that implement them and expose that functionality (SockJS, Socket.io, etc.) and I want to be clear that I am not asking one of those "what is the best framework" types of questions.
My question is rather about the correct way to implement these two kinds of services side-by-side. Should I be serving the chat separately from the rest of the application? Or is there a clean way to integrate these two different protocols into the same application?
The express framework is quite modular so it can sit side by side with a websocket module if you so wish. The most common reason for doing this is to share authentication routines across http and websockets by using the same session store in both modules.
For example you would authenticate a user by http with the express framework when they login, which will allow access to your chat application. From then on you would take advantage of the realtime and speedy protocol of websockets and on your server code you will check the cookie that the client sends with the socket message and check that the request corresponds to an authenticated session from before.
Many websites use websockets for chat or other push updates, and a separate RESTful API over AJAX, delivered to the same page. There are great reasons to leave RESTful things as they are, particularly if caching is an issue--websockets won't benefit from web caches outside your servers. Websockets are better suited for chat on any modern browser, which trades a small keep-alive for a reconnecting long-poll. So two separate interfaces adds a little complexity that you may benefit from, when scaling and cost-per-user are considered.
If your app grows enough to require this scaling, you'll find this actually simplifies things greatly--clients in the same chat groups can map to the same server, and a load balancer can distribute RESTful calls appropriately.
If you are looking for one communication protocol to serve both needs (calling the server from the client, as well as pushing data from the server), you might have a look at WAMP.
WAMP is an open WebSocket subprotocol that provides two application
messaging patterns in one unified protocol: Remote Procedure Calls +
Publish & Subscribe.
If you want to dig a little deeper, this describes the why, the motivation and the design. WAMP has multiple implementations in different languages.
Now, if you want to stick to REST, then you cannot integrate push at the protocol level (since REST simply does not have that), but only at "framework level". You need a 2nd protocol. The options are:
WebSocket
Server Sent Events (SSE)
HTTP Long-Poll
SSE in a way could be a good complement to REST. However, it's unsupported on IE (not even IE11), and it's unclear if it ever will be.
WebSocket obviously works, but then why not have it all running over WebSocket? (This line of thinking leads to WAMP).
So IMO the natural complement for REST would be some HTTP Long-poll based mechanism for simulating push. You can make HTTP Long-poll work robustly. You'll have to live with the inefficiencies and limitations of HTTP (for use cases like this) with this solution then.
You could use a hosted real-time messaging (and even storage) service and integrate it into your frontend apps (web and mobile). These services leverage the websocket protocol and normally include HTTP Comet fallbacks.
The cool thing is that you don't need to manage the underlying infrastructure in terms of high-availability and unlimited scalability and focus only on developing a great app.
I work for Realtime so i'm a bit biased but I think the Realtime Framework could help you. More at http://framework.realtime.co
I am going to build a web application to manage notes (think of something similar to Evernote). I have decided to use Backbone.js+JQuery client side.
Server-side, I haven't decided yet: either pure PHP (that I know very well) or Node.js+Socket.io (completely new to me).
I am considering Node.js+Socket.io because I would like to have my web application being real-time (i.e: if a user updates a note, that note gets updated instantly for a collaborator who shares that note, without reloading the page).
I was also considering, as a third alternative, to use Node.js and Socket.io for the UI and PHP for the REST API (I feel more comfortable to build an API with PHP). The PHP and Javascript code will share the MongoDB database.
My question is this: if I develop the REST API for my web application with PHP and a new note for the user gets created through the API (i.e.: the Android app sends an API request to create that note), will Node.js, Socket.it and Backbone.js be able to instantly update the UI of the user and show the new note on their screen? I think that can be called "push notification".
I hope I was clear enough.
Also, is there any alternative outstanding technology to build real time web applications?
Yes Node.js + Socket.IO will do a very good job of this. Node uses an event-loop, this means upon a request it is entered into a queue. Node deals with these requests one-by-one. Traditional web servers deal with a 'Thread-per-request' approach where a thread is created to handle that requests.
The benefit of Node here is that it doesn't need to context switch so often, this means it can deal with these requests very quickly... most likely faster than your PHP server. However Node runs as a single process, on a single CPU core. If your application is CPU intensive it could be that it blocks, meaning the time for each requests will be slower.
However it sounds to me like your application isn't CPU intensive, meaning Node.js will work well.
Decision
If your time is limited, and you don't want to learn a new skill (Node), PHP will be fine. If you have the time I recommend learning Node.js, as it is very strong when it comes to I/O intensive tasks such as a REST API for creating Notes.
Updating the UI
If your intended use is through a mobile device, I recommend using WebSockets but having a fallback such as long-polling. It is possible to update the Client UI using either Node or PHP. However from my experience it is much easier to do so using Socket.IO on Node.js.
Example Updating the client using Node.js / Socket.io
Client-side
socket.on('new-note', function (data) {
placeNewNote(data);
});
Server-side
socket.emit('new-note', data);
Getting Started With Node:
How do I get started with Node.js
Please also note, if you want to build a native Android mobile app which uses WebSockets... you will need to use: Java socket.io client
Using Node.js for both web server and push server is of course the best way. Especially since if you are going to use Node.js anyway then you have to learn it, so learning how to make a web server is only natural (I advice using the most famous Express framework).
Now you can use PHP for web server and Node.js for push server. To make them communicate with each other you would probably want to add Redis to your application. Redis will allow you to push notifications to any client connected to it, like PHP server or Node.js push server (and it scales well). From that point push server will push the data further to the client's browser.
Alternative technology would be for example Twisted server. Of course you'll need to learn Python in order to use it. And I don't know whether it supports WebSockets correctly. I think you should stick with Node.js + socket.io.