Currently I have an application built with Angular 2 (all the front-end side) and Symfony 3 (web framework) . I have defined each view as an Angular application.
I think it's the time to migrate to a Single App but I have some questions before I venture into the lion's den.
If a user change manually the URL, of course, they, should enter to the requested URL, but how can angular know which url is trying to open?
I should create multiple controllers or only one that catch all the requests?
If none of above are the right way, please, can you suggest any way to do it?
Thank you so much.
If you're trying to build a Single Page application, it means that your routes will be managed by your front-end, here by Angular 2 via #angular/router.
Symfony can then be only used as a back-end web service (i.e. a Restful API) that will answer to your front-end calls via JSON responses. Depending on the size of your API, you may wish to use FOSRestBundle for that purpose.
So you don't have to worry about Symfony routing interpretation since your urls will be managed by Angular router. Symfony routes will be called directly by your Angular application to get/post/put/delete/patch your back-end data.
UPDATE
To answer you comment, a user who directly enters a URL will simply see the page you linked to this url via Angular routing, there is (almost) no difference between front-end and back-end routing.
If you want to dive deeply in how hash routing works in javascript, you can check this article.
To see a real-life example of a SPA with full Angular routing, ga.me is a good start.
Related
As far as I know the hash symbol(#) is the key when implementing routing in Angular. The web server only takes care about the part of the URL which is before the hash, and Angular takes care of the rest.
I´ve read some articles that explain how to remove the hash from URL. But if I remove the hash(#) from URL: Which routing works first?
OK, it is MVC. In that case we have to edit the MVC Route in order the server to understand the URL. But we are at the beginning again. Does it make any sense to use Angular Routing and MVC together ? Is not enough with MVC Routing?
Maybe I´m missing something. I hope you can help me.
Does it make any sense to use Angular Routing and MVC together ? Is
not enough with MVC Routing?
TL;DR;
I've rarely use both. The only time I use both is when I need to authenticate the user for some routes.
Long answer
1. Authentication
As you already figured out, Angular routing is great when you want to navigate to another page without the roundtrip to the server. It's usually a SPA. But there might be a scenario when you need to authenticate the user before sending the HTML, then MVC routing will be handy. I wrote an answer about it here. Note the difference between sending HTML and sending DATA to to the client. If you have no server routes the html-pages (or templates) will be fully accessible (unless you limit access in web.config or some other way). Some times the HTML-pages can contain some sensitive information as well...
The most common scenario is if you have a public site with an admin-part. But in my experience you can handle this on client side with client-side-routing only. It's usually the data that is sensitive, not the templates.
2. Server-side logging
The other scenario is when you want to do some logging on server side. For example if you want to log every page request. This can often be done on the client as well... Look at Google Analytics. But you might want to log the request even if the browser has javascript turned off.
3. SEO
There might be some SEO-issues when using client-side-routing. But this is only when we render the html with client side templates and if we compare to completely rendered views with MVC.Net. Do not confuse me posting the link with me actually agreeing with the content...
4. WCAG
In my country all government sites need to follow WCAG. One of the rules are - no javascript. Or at least that the site should be fully accessible without javascript. Without javascript client-side-routes are simply very difficult. ;)
These are some examples when you might need both server-side and client-side routes. But to sum up, in most cases client-side is enough.
I am developing an app with an AngularJS front end and a Laravel API backend. The Laravel backend just listens for requests, process them and returns an answer. Front and back end are different independent apps... so far. I did it in such a way in order to be able to develop a mobile app later on which could consume the API. Im using also JWT to authenticate users, so Im not using Laravel's sessions at all. At this point I only require a webapp. I built a webapp which uses angular ui-router.
So far so good. The front end and the back end work well. However some of the front end views will be public and require share buttons, they also require to be indexable by Google.
I've read there are some alternatives.
Make some hack using the apache mod_rewrite in order to serve the angular app for people and a static version of it served directly by the backend. I think this would not be very difficult using Laravel.
Using Prerender.js. Which as far as Im concerned does pretty much the same job than option 1 but in a more complete manner.
However I am thinking about using a third alternative. Given that I only require the webapp now and the API is working I am thinking about using Laravel's built-in webapp functionality. I can use the controllers, directives and factories from angular and let Laravel handle the webapp routing.
An advantage of this is that I can render the meta tags using Blade (this fixes completely the SEO issues) and serve the rest of the contents using angular and the API.
Do anyone of you can see drawacks of such a solution or do you know a better way to accomplish SEO purposes using angular and Laravel?
Render Site :
You will have to render the pages from server side if you want to make it SEO friendly. But yes, what if you serve the server rendered pages to bots only. And for real users client side rendering will work.
Read about the Rendertron which will detect the user agent and accordingly serve the html.
Meta Tags :
Use Sluggable and replace id with slug in urls. You can follow https://oodavid.com/article/angularjs-meta-tags-management/
I'm struggling about Angular and Express Routing (by the way, i'm somehow new to Express), i've been handling routes with Angular — with ui-router — but now that i'm starting to build a MEAN.js Application i notice that i can handle server-side routing and client-side routing... and that's what makes me get confused, here are some of my questions:
How are they different?
If i switch to Express routing will i still have a SPA?
Can i use both at same time? How? Is it good practice? Does it has any benefit?
When should i use only one of them?
How will i handle route parameters?
etc...
If someone can explain with detail these questions, and other extra things people need to know i'll be totally thankful.
Also, something that i want to know is: Do i only have to setup server things in Express or do i need to code in Node?
Routing in Express is sightly different then what it is in angular
In express
Routing refers to the definition of end points (URIs) to an
application and how it responds to client requests.
So if you are doing the routing using angularjs then you do not need to set the route for your html template using express.
you simply use express in a way to create your RESTAPI and then consume those API using angularjs $http or $resource
Summary:
Routing in Angular supports the idea behind a SPA. Ultimately you want to handle UI based route changes (i.e. no server call/logic needed) via Angular. Any route change that hits the backend, and ultimately requires server logic, should use Express routing.
Example
This is express routing to create rest API.
app = express();
app.get('/dowork',function(res,req){
console.log(req.params.msg);
/... code to do your work .../
});
now in angularjs call do work
$http.get('http://localhost:8080/dowork',{"msg":"hi"}).success(function(data){
console.log(data);
});
Just two cents here. Other expert should correct me and explain further :
Routing at frontend usually means routing management in url after #.
This is because anything after # is ignored by browser. So this is utilized by angular to make on the fly ajax calls and fetch resources depending on route path after #.
What express handles is url before #. This is used to make actual request from browser to server.
How are they different : answered
If i switch to Express routing will i still have a SPA :
You can always have SPA if you manage urls manually at front end side while making ajax calls to populate your single page. managing urls at front end should be with intention of readability.
Can i use both at same time? How? :
Everyone uses both. A SPA also uses both. Usually authentication based thing is handled by express routing while authorization and other routing based interaction like requesting for resources and others, front end routing is used. Even if you use front end routing, for ajax request behind the scene, you are still relying on express's routing.
Is it good practice? Does it has any benefit? :
Using express's routing for authentication and providing resources AND using angular routing for front end to keep SPA in action is always a good practice.
When should i use only one of them? : answered
How will i handle route parameters? :
There are parameters handling both for front end side using route params ( if using ng-route) and at the back end using slug, bodyparser and others.
You need to spare some time learning those.
Can we use both
of-course you can use both. Depending on your application requirement, what portion of your app need to be spa for better user experience and what portion views need to be render by your express app.
If i switch to Express routing will i still have a SPA?
if a particular routing is not handled by angular and you want to generate a view by express app you can do that. if you want to develop a complete spa then you need to develop a api (http end points) in you express app to respond to AJAX requests of your angular app. Angular routing is all bout clint side routing that is used to generate template and fetch data from server (in your case express) and render a view. Over all your angular routing calls to your express routing to fetch json data or any template to give the impression of a spa
example
in express we have
app.get("/", function (req, res) {
res.render("home");
});
you home page must include all the angular script files to initialize the angular app
in clint side code you can have
var app = angular.module("myApp", ["ui.router"])
.config(function ($stateProvider, ) {
$stateProvider.state("home", {
url: "/"
})
.state("manas", {
url: "/manas",
templateUrl: "/templates/manas.html"
// when the state or url is manas its fetch the static manas.html from server and inject that to ui view
})
// i am using angular UI router here
Can i use both at same time? How? Is it good practice? Does it has any benefit?
Ya we can use both at same time. It depends on your application logic their is no harm or benefit of using both.
When should i use only one of them?
Go with express routing only if you are more concerned about search engine optimization. Because SPA are not by-default search engine friendly you need to take some extra action to make it search engine friendly.
How will i handle route parameters?
it depends on what angular routing you are using. I mean vanilla angular routing or UI routing. But the concept is same for both
passing parameters
For passing parameters to server with UI routing go through
https://github.com/angular-ui/ui-router/wiki/URL-Routing#url-parameters
for UI routing follow this link
https://github.com/angular-ui/ui-router/wiki
if you app is not more complex you don't care about nested views child views etc
my suggetion go with angular plain routing.
No doubt UI router gives more advance routing concepts but learning curve is steep as well. if you app is simple in nature go with angular routing
This is not a question I've really seen answered on SO. Most of the tutorials on building RESTful API's using node/express focus on a single technology stack. What my team is having trouble with is building a single Node API that serves multiple stacks, specifically both Angular and Scala but with perhaps more to come later.
In most of the examples I've seen with Angular (for instance), the routing code that Angular uses to set up its MVC goes right into the "app.js" which it seems would not then scale at all to other platforms. My suspicion is that the "trick" is to break the routing out into a separate file in order to set up multiple routing schema using route separation. And then set up routes that go /angular/foo or /scala/bar, etc., on top of which these platforms can be built.
I'm not looking for a "best" way, I'm looking for specific high-level examples of how this problem can be solved, with direct correlation to the node/express stack at the base of the architecture.
From your comments, it appears that there was a bit of confusion and you were trying to fudge Scala and Angular together in an app, and you wanted to have separate endpoints for each one to serve for routing.
Generally speaking, Angular applications are typically SPAs. They don't change page (At least not in the traditional page-per-request sense), and all routing is handled on the client side. They just consume RESTful APIs in the background. The RESTful API typically is a JSON, language independent, endpoint. Angular apps are then served from a static file server.. this can be node but could also be Nginx (or similar).
Now, some angular applications will have all of the routes for their endpoints rewritten to their app.js from the server side. In other words, you may see an Angular application redirect all requests to it's app.js so the client side can handle the routing. This is useful in case someone on an Angular application refreshes the page for example. This is only necessary however if you're using the HTML5 history API - hashbangs don't need this rewriting.
Scala and Angular don't need to have different endpoints for data - only for their file serving. The REST endpoints could be exactly the same as long as they output a format both languages understand (typically JSON).
I don't know why you would want two different APIs for different stacks. Why aren't you able to use one API for both Angular and Scala?
But if you want to split up your API into multiple files, I suggest to use express.Router: http://expressjs.com/4x/api.html#router
Routing functionality is defined in both ExpressJS thru app.get('/*') and in AngularJS thru
$routeProvider.
when('/*
What is the case scenario for needing to define routes thru both?
Part 2.
Server and Client Communication in AngularJS takes place thru REST API ? ( can it be handled thru socket.io?)
Part 1
Angular is only on the front end, so if you need to make calls to your database (getting data or posting data), it'll likely go through a route that the backend (Express) created (app.get, app.post).
If all your data is coming from someone else's site (API) and you don't need to store anything, then in that case you might not need any routes on the back end.
It really depends on what you're building. If I build a 'to do' list, I can have a 'Tasks' and 'Completed Tasks' page using Angular routes and then post and get routes in ExpressJS. You can also have multiple SPA (single page applications) on Express in turn you may need another Angular module that will have it's own routes.
Answer to your Part 2.
AngularJS using SocketIO
AngularJS is an SPA (Single Page Application) framework. For SPAs which need pages to be loaded can be used to route thru Angular so
when('SPA1/...
to define particular SPA which may be subset of your total app can be routed thru Angular. Where as your regular routes app.get('/home ... can be done thru ExpressJS.