I want to use Symfony2 as back end to create a REST API and use AngularJS as front end. The 2 are completely separated ie Symfony 2 will not render anything, it'll just send json data to AngularJS.
I'm not sure on how to configure my web server (nginx).
The Symfony documentation gives the configuration but it's intended for a site that only uses Symfony, and so everything outside of the /web/ folder is not accessible.
I can see several possibilities:
Create 2 different directories (eg /path/frontend and /path/backend) and a corresponding website for both. I would then have 2 different addresses to access the front end and the back end (eg http://myfrontend.com and http://mybackend.com). The problem I see is that I probably won't be able to directly use AJAX calls in AngularJS.
Create 2 different directories (eg /website/frontend and /website/backend) and only one website. I would then probably need to access the front end and back end with something like http://example.com/frontend and http://example.com/backend. I'm not sure how to configure the web server though (issue with root /website/backend/web).
Put the AngularJS directory inside the web folder of Symfony, but then I'd need to also change the configuration so that nginx doesn't only server app.php, app_dev.php and config.php.
Put the AngularJS directory in the src folder of Symfony, and have Symfony handle the routing. I don't know if it will mess with AngularJS' one routing. Also I will probably have a few other php that should be accessible, so I'd need to route them through Symfony also.
What would you suggest and why? Maybe I'm missing something obivous?
I guess you could accomplish your task using any of those methods. It would come down to how you want to structure you application and what it's objectives are. For large scale projects the first method (having the API separate from the AngularJS) would serve you well. Twitter really made that software model big.
So I would suggest going with method one. All you would have to do is specify an Nginx header in your server block that allows cross domain access to another domain. So you would specify the following directive in your frontendangular.com site:
add_header Access-Control-Allow-Origin backendsymfony.com;
This way every time a page request comes in on your front end app Nginx tells the browser that it is safe to access another domain (your symfony setup).
These are 2 frameworks that both have powerful routing capabilities, and it looks like you are going for a best of both worlds. There are many pros and cons to any setup, so I'll list a few that come to mind:
Angular routing / templating is great but it will leave you with SEO and meta issues to solve . It's probably better to manage your major pages with symfony2 and any routing within each page with angular. This would allow you to still make dynamic pages w/out compromising your meta and SEO control. Access Control seems flexible but probably not necessary, I would just put all calls to REST API under http://www.thesite.com/api and if I need another setup something like https://api.thesite.com, nginx can route or proxypass this without leaving the domain.
Locating partials gets a little wonky but that's probably fine for a large application. Just note that you will probably need to search the js location object for [host] / [path] /web/bundles/someBundle/public/blah.... Or you can setup a '/partials' path in nginx.
Twig and Angular tpl may end up a confusing mix as they both use {{foo}}. This alone would make me reconsider mixing the 2, and I might look to go with a frontend server, like node with ejs where I could also benefit from the streaming transfer of the data sent from the API.
You can get around it easy enough with but it's still concerning:
angular.module('myApp', []).config(function($interpolateProvider){
$interpolateProvider.startSymbol('[[').endSymbol(']]');
}
);
You do get the benefit of angular partials as symfony twig, which can be good or bad depending on how you see the flexibility being used. I have seen guys making examples of forms that fill out values with symfony data, but they are just undermining the power of angulars binding.
Don't get me wrong, I actually do really like the idea of the two harmonizing.
Just food for thought - cheers
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 am new to AngularJS.I have two questions.
Is it possible to use JSP pages instead of HTML in AngularJS.
Is it possible to create a web application using AngularJS without webservices (for fetching data from DB) and use HTTP servlet for that purpose
Is it possible to use JSP pages instead of HTML in AngularJS.
Even if you use JSP the final output will be HTML so you can use JSP in AngularJS but JSP files are mainly used to render the frontend with data that you can do using HTML only in AngularJS.
Is it possible to create a web application using AngularJS without web services (for fetching data from DB) and use HTTP servlet for that purpose
Whether you use plain Servlet or any framework that creates REST APIs, it will be HTTP calls only.
(This is a newbie question which applies equally to all front-end MVVM frameworks. I'll answer it for the general good.)
AngularJS is a front-end framework which runs in the browser. It relies on a server delivering the content (HTML templates, CSS and JS sources) to the browser.
What you use as a server, is entirely up to you. It depends on whether you need server-side dynamic content.
If none is required in that area, you can use a static HTTP server like LightHTTP, or plain old apache, or nginx, or anything else to deliver the AngularJS site to the browser.
But in most you will have some server interaction (i.e. storing / querying stuff in a database, or communication / synchronization with other users, etc). The common approach for that is to deliver HTML/CSS/JS statically and add a bunch of REST interfaces. Flask and Tornado are popular server choices for that, or stuff like spray.IO / akka.http for higher traffic volumes.
In specific cases, you may want to work with pre-rendered HTML templates (usually because you want to dynamically exclude parts of pages for security/user role reasons). Then you need a server-side framework with template rendering. Django, JSP, ASP, pick your favourite.
It seems like you are asking how to use AngularJs in a JavaEE application. And yes it is possible. Only your index.jsp will be in jsp, and all you other views will be in html.
You can then use http requests to fetch data through your servlets.
it can be useful. here are scenarios:
you want to save ram, cpu for mobile phones or machines that doesn't have lots of power. you can partially render page in jsp and keep only minimal in angular.
your team is traditionally jsp heavy and you want to use them and gradually transfer to angular. eg... for i18n rendering jsp seems far better. note that i18n may not add lots of values in angular and you may not want to throw up existing code in jsp.
I have been noticing strong views in stackoverflow and they seem to dismiss everything that doesn't fit in their utopian all new cutting edge. all the angular projects I worked had heavy dose of legacy pages using jsp and it doesn't make sense to rewrite everything from scratch or lay off whole team and start hiring from scratch. and thus, yes, jsp makes sense with angular.
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
I'm doing some due diligence on backbone for a single page app and wonder if it is possible to re-use the same views/routes from the client on the server side, so that when google visits a pushstate URL, or it is accessed directly, the server can generate the exact same HTML that would be generated by backbone in the client.
It would be a pain to have to maintain two separate sets of views/routes, one on the client and one on the server. I have seen the backnode project on github however this seems to miss the point a bit and you end up having to write the same backbone router twice.
Just wondering how people are generally handling the case when using pushstate urls in backbone and needing to serve the same view from the server? Are people duplicating code or is there a better way?
I haven't tried this yet but these ideas using node.js and backbone might help:
http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
http://bennolan.com/2010/08/13/pushstate-and-nodejs.html
Basically the only way to make it so your not writing the same thing twice is to have both your node.js server and frontend client share the same routing/model code. If you are using something else on the server side (like Ruby) you would have to place node.js in front of your app server. Then make node.js proxy for new clients (push state and client js) and do actually rendering work for old/bot clients.
The other option is doing what jQuery Mobile does which is the Hijax method. The idea to make tons of HTML5 pages (you'll have to look at its routing to see).
And for completeness you should be aware of how google crawls AJAX: http://code.google.com/web/ajaxcrawling/docs/getting-started.html
This project does exactly what you are trying to do. It might interest you to check it out.
https://github.com/developmentseed/bones