I've been mostly a LAMP stack dev but recently I wanted to get into the new stuff like MEAN stacks but all the stuff I'm running into are getting confusing, can someone help me clear it up?
So I've played around with a Node.js server with Express, Jade, and a mySQL DB. So from what I've read, Node operates the backend, Express does the front end rendering and Jade... does front end as well?
Also, for a MEAN stack. Angular does front end right? So what does Express do in that situation and does it need something like Jade?
All this new stuff is so much overload, I'm still reading up on docs about Amber, React, Meteor, Firebase, etc. Is there a site that documents these all together and how they fit together?
Express doesn't do front end. Express is a framework which sits on top of Node.js and makes it easy for you to build websites. Node wasn't originally created to build websites, you see. You can consider Express to be a web framework for Node, just like Flask and Django are for Python. There are other web frameworks for Node too, like Sails and Koa. In the MEAN stack, Express generally does the routing and handles different routes in your application while Angular handles the frontend.
Also if you're just starting out with the MEAN stack, then you don't need things like Ember, React, Meteor, Firebase, etc. They're all different things for different purposes and my suggestion would be to not overdo yourself and take things one step at a time.
Here is a short description of what you are searching :
'M' for [MONGODB]
MongoDB is documented oriented database, its very easy to use and works very good with javascript. you insert JSON data and get JSON data in response from it.
'E' for [Express]
Express is Node.js framework with http verb (GET, POST, PUT DELETE) and middleware support.
It supports routing with http and middlewares.
'A' for [Angularjs]
AngularJS is a front-end web framework that nicely hooks up with you nodesjs application. You can consume RESTful services from Backend data sources and build interactive single page applications(SPA) using angularjs.
'N' for [Node.js]
Node.js is a server-side javascript environent based on google's V8 engine. It is purely javascript environment. you can code in javascript and node takes care of it and run on web server.
Regarding [Jade] , it is a templating engine which compiles to HTML plus it is rendered from your server.
Related
My website will perform CRUD operations and will work with MongoDB and Firebase storage+auth.
What are the reasons / advantages to developing a separate Express server instead of integrating everything in my next.js app?
As far as I have seen, it can all be done in my next.js app, but I still see many projects working with a separate server.
Depends on what your app does and how you are hosting it.
Running Next.Js on a standard server will be of little difference whether you are using nextjs's /api or expressjs.
However if you are hosting on serverless (e.g. Vercel), I would recommend using a separate express server if you have alot of CRUD operations because the warming up of serverless is really bad user experience.
Build and Deployment
Next/JS - If you want to edit something on the backend, and push the changes, it will require you to build the entire JS app, and depending on how big is your app, it can take alot of time (especially if alot of static generated pages).
Express - If you running express separately, you can build and deploy front end and backend separately. It's time saving, and you can also better organise your codes frontend/backend.
Choice of deployment
I have a choice to take advantage of Vercel to host my frontend, with static generated pages and some server side generated pages (automatic scaling, caching, CDN etc), and host my backend with a separate cluster of servers.
PS: I moved from single Next.JS app to NextJs+Express
I can think of a few things why they would have a different server from the one NextJS provides:
Familiarity with Express, Koa, etc. All next-connect helps with this
There is an already existing API in PHP, Express, Flask, etc.
It is literally based on what you would want to do, the extra interactions with MongoDB & Firebase would be same on both the technologies, unless you want to isolate respective things separately, I don't see any harm in doing everything together on next.
Given that the idea of using next.js, as per my understanding would be to utilise server side rendering.
I've been using Next.js with Typescript for quite a while now and I, as of now, have found one reason not to include express.js in my project. And the reason is Vercel.
Since I use Vercel for continuous deployment of my projects, and Vercel Not supporting any custom server as of there Docs here, I refrain from using Express or any other custom servers.
I didn't face any problem performing CRUD operations with MongoDB, can't say about firebase.
On Next.js Docs, I found these points to be considered:
A custom server can not be deployed on Vercel, the platform Next.js was made for.
A custom server will remove important performance optimizations, like serverless functions and Automatic Static Optimization.
But at the end of the day it very personal opinion weather to use a custom server or not. It might depend on a very specific use case you might be looking for.
Personally, I try to keep it to just NextJS, but if I have to manage real-time data with Socket.io, I get a separate server because other than WebSockets, serverless functions can do everything else.
We are 2 students studying web development.
Right now we are researching and trying to figure out a solution for an ionic app.
the app will have a lot of data content (video, image, music etc)
The questions are: should the APP be developed with a REST api? (seems like the only/best way to connect to a database with ionic?)
or can you build the app with a cloud-based-database without the REST-api (any suggestion for the database?)
and last should we use LocalStorage as our database?
Let me go from bottom to top; if you said you'll use a lot of content in your database - don't even think about local storage. If you really must have a local database as well, consider looking into SQLite (https://github.com/litehelpers/Cordova-sqlite-storage).
The sentence "cloudbased-database without the REST api" honestly makes no sense in Ionic. Let me explain; Ionic uses Angular as its front-end framework. And, front-end is the key word here. You can take any front end framework, or pure vanilla JavaScript for that matter and you will not be able to connect to any database (be it in the cloud, locally, or whereever). It's just not how that's suppose to work.
So, finally, to confirm - yes, you will have to create a (REST) API for your database which will then allow you to "talk to" the database with Ionic.
Hope this clears things up a bit.
I'd like to build a new single page app using Rails 4 and Angular and Capistrano for deployment process.
I want all the front end to be a static app on Amazon S3, but I'm openminded for other suggestions.
What's important to me is a fast developing process with the ability to scale up easily.
I was wondering what is the best structure I should use:
keep all assets in app/assets and set Bower path to vender directory.
that way i can use rails precompile methods and enjoying Rails html tags for index.html, but i'm sure it will be easy to upload it to S3 and keep it separated.
keep all assets including Bower components in public/app directory, which will keep it as a complete separate application, but then i need to use Grunt or any other service for precompiling assets.
any other idea?
From my experience, I found this approach to work really well:
API app (Rails/Sinatra/Grape/Node/whatever) serves only JSON APIs. Deploys to a server, say api.yourapp.com. Serves Access-Control headers.
Static web app: started by generating with yeoman an AngularJS, Gulp, Bower app. Deploys using gulp aws deploy module to S3.
There's no real reason to have both views and apis in the same app or built with the same technology (as in Rails).
Now there are issues:
S3 doesn't support nicely Angular's HTML5 mode URLs. So pure S3 website isn't an option.
Facebook doesn't read OpenGraph tags that are not in the source of the page.
Couldn't figure out the state of Google/SEO and Angular apps. I didn't see the content in the search results.
So as a solution I introduced another web server app. Can be based on anything - pure rack, node etc. I chose rack.
Solutions to the problems:
Web server app was hosted on www.yourapp.com and proxied (and cached) requests to S3. It supported all URLs (html5Mode) - just proxied to index.html.
OpenGraph meta tags - the API had an endpoint that gets a URL or ID of an object and returns meta tags information. Web server issues a request to API once per URL (caches the response) and injects it in the served index.html.
SEO - as a middleware, used prerender for rack that rendered pages on the server.
As a bonus -
Most apps today have a landing page/marketing site and the actual app. Sometimes it's better to maintain these separately. The web sever knows according to a cookie which app to present on www.yourapp.com - actual app or marketing site. On sign in - set a cookie on client side and voila.
First, I think there's a bit of a confusion here, let me try to clear it up.
There are a couple of ways for achieving this
Pure client -> API
When you have a static application, there's no need to go through the Rails asset pipeline, there are far better ways to manage assets when you are using the tooling for client side applications.
For example, your client application will be an Angular application and you will manage assets with a combination of bower (dependencies) and grunt (build and distribution).
There's no point of deploying to S3 with Capistrano, if it's a pure static application, you can use aws CLI in order to just upload your content.
I'd go through a CDN as well. Something like Fastly works really well over Amazon S3.
I have a Rake task that uploads to S3 and then clears the cache on Fastly (if I need to).
As for your Rails application, it would act as an API, it should not have any assets
Combined
If you have a combined application, some of the actions are served by the server (Rails) and just invokes some client side code (Angular).
If this is the case, I would go through Rails asset pipeline and just keep everything as Rails best practice with compilation pre-deploy etc...
It's one of those questions where "it depends" is the answer really, it all depends on what you want to achieve.
When I have a client application, I try to have a pure client and have the server only as an API, with no assets at all, this way, I separate the concerns.
EDIT 9/9/15
I'd have to say that as long as you can, I'd keep the apps separate.
It's not always possible, especially with more complex apps.
Most apps I have seen in the recent months have kept the client side and the server side code separate, I have seen less use of rails and more use of rails-api because of that (some even ditched rails completely for thinner solutions).
I have used django for few projects and used heroku to deploy. I have been looking into front-end frameworks such as Ember, Angular and was confused as to how it will integrate with a django project. Reading some Docs, it appears i need to have developed a REST api for my app using the backend framework in order for Javascript framework to communicate with the database. In this case the backend mostly works as a thin layer that provides access to the database. But what if I use something like parse and their Javascript API, would I even need a Backend Framework like Django?
How frameworks like Django will work with frameworks like Angular or Ember depends a lot on what you want to do with it and what your view on architecture is in general, so it's hard to give a one true answer. But in general no, you don't need one, but you still might want one.
You don't need one because as you surmised frameworks like this want a REST API (although it doesn't have to be specifically REST-like that is definitely the most common way of doing it), so you wouldn't be using Django templating or anything like that.
But one of the good part of using these frameworks, and the part that makes the question impossibly to answer, is that they don't care about the backend!
Why does this matter?
When backend and frontend is properly separated you get a great deal more flexibility on both ends. As long as they work with the API you can build them however you see fit. If you find Djangos ORM nice to work with you can use it to create the API. If you feel like using something super lightweight like Flask you can do that. If you want to host a Java app on AWS you can do that, etc, etc.
The key is that you can let your backend needs determine how you build the backend, and your frontend needs determine how you build the frontend. That's why the question can't be answered. You strictly speaking don't need Django or any smilar framework but depending on what the backend is going to do you might want some of the features from them, like the ORM or the general structure.
So look at what your backend needs to do in order to serve the API and choose based on that.
Context: I'm a beginner programmer, self taught in the hope of making a SPA. I've started with JavaScript, Jquery, PHP and MySQL, and now feel pretty confident with all. I've started with Ember, and am now moving away from having a PHP API to Node. Which has then brought me closer to Meteor... I'm aware I'll need to use Mongo instead, but having an integrated front and back seems to be sensible and have some advantages.
So my question is what are the advantages of having a separate REST backend API (eg Express) rather than an integrated front/back (eg Meteor).
One that springs to mind is that my app will be tablet/pc based, but in future I'll want a different mobile version, so I'd be able to use just use the same API. I'm conscious that the above question is the main concern with this stack question, but perhaps if a meteor developer could clarify whether this is indeed a concern.
Thanks in advance!
well for me you'll get a lot of advantages using a rest API, they are lightweight, extensible and overall reusable.
today it's a trend to use a vertical architecture that means having a RestFul service with a single responsibility, why because it scale better and it's easier to assign a team to an api, so that way you'll be able to manage several teams and apis in a very ordered way. This is probably how Twitter, wunderlist and other companies works, because it's a solution to scale better.
take a look to this talk by Raffi Krikorian he was the head of architecture of Twitter for a while is a little bit old but it worth every minute and to illustrate some of the advantages.
Also you can look at the diagram below, I did while ago it explains the differences between the MVC and API first type of architecture.
I've authored one rest app using angular and rest services and it has been a very nice experience to me there's no way back.
good luck
Meteor doesn't really "integrate" the front (client) and backend (server) as you describe. It still maintains them as two separate layers. The beauty of meteor (aside from the insanely awesome reactivity) is that it uses Javascript everywhere, instead of using JS on the client and some other language on the server, so you can use the same APIs on both the front and backend. Although Meteor does snazzy things like let you write client and server code in the same file, it still requires you to distinguish between the two, and server code is still stored only on the server and client-side code is still served down to the client.
Meteor is still young, but the developers and community are very active, and everything you described can be achieved with it at this point. I've been working with Meteor for about 6 months now, and it hasn't let me down yet. I'm working on a production-level application that also requires exposing a REST API for consumption in mobile apps, which I'm doing quite successfully with Meteor (I just updated a user profile using a REST endpoint from an Android device and watched it change in the Meteor app in realtime. So cool!).
I was using this great package, RestStop2, for building REST APIs in meteor, but it was unfortunately deprecated, so I released an updated version. Check it out for an example of building REST APIs in Meteor. It's available through the Meteor package manager: https://atmospherejs.com/nimble/restivus
So to answer your question, you always want to separate the REST API into it's own layer, but that is entirely possible with Meteor. To make it clear, you would never consume this REST API from within your Meteor app. Meteor uses DDP (not HTTP), which gives you a much more direct connection with your server, so you're doing something wrong if you're accessing data on your Meteor server from a Meteor client via HTTP. Of course, with Meteor, you have the advantage of being able to use existing code from your REST API.
There's a really good write-up that explains some of the considerations of writing a REST API in Meteor: http://www.meteorpedia.com/read/REST_API.
The design of a architecture separated in layers like frontend, backend (Rest Api) and DB, is for obtain a better a scalability, reusability and logic separator of features of the application. For example:
Today make a web applications separated in 3 layer (frontend, backend,
and databases), if tomorrow you wanna do a mobile application you can
develop the application like a extra project in the frontend layer,
but use all the features developed in backend. Then the frontend
application not need servers why run inside every device, but maybe
the load in the backend servers increase, and you only need add 1 more
server in the backend layer.
Its a little example, but is the most common case in this new era of mobile applications.
Remember always this in MVC architectures:
Frontend: Always call services from the backend, render the view, and capture data. Sometimes make a litle logic.
Backend: Receive the request, apply all the business logic, read and write operations in databases, and return a response preferred in json format.
Model: store data, backups, slaves, etc.
PD: If you use meteor in this example you gonna need to make a api Rest to develop the mobile application.