I have a front-end written using angular, grunt, and bower. And I have a backend, which is mostly just a REST API (Spring application).
Building them separately as two different wars(web.war & service.war).I strictly need only static files inside web.war
My question is, to make front and back end communicate, where should I place the controller(inside web or service war). Is it good to have controller at service side itself? What is the proper way?
I should suggest you to add controllers in web.war, IMHO, it makes no sense to add a controller class in a service.war, maybe you have a specific requirements, but I do not understand why you have a war for service module, I should merge two wars in only war.
regards
Related
I've a Java developer who's begun working in the Javascript enterprise domain. Specifically I've begun working with Strongloop/Loopback API and AngularJS in the client.
I'm creating entities with ease with Strongloop and am very impressed with how quickly I can generate an expanded model. When it comes to the client however things appear to slow down as I have to manually create the Angular Controllers, Services and the crud template views.
I've used reflection in Java considerably in the past and I found it to be very effective. I was hoping someone might be able to let me know if there's either a reflective way to initialise Controllers so that I could have one EntityController if you like that would export the CRUD methods. Alternatively if there's a tool that might be able to access the restful api and generate generic templates, controllers and services for the restful API?
Thanks in advance for any help!
Mark.
I believe that you are looking for loopback angularjs SDK.
It will not generate views and controllers but you will have angularJS services generated that contains all the LoopBack models and methods you have defined. You have to register the AngularJS module lbServices as a dependency of your app.
Documentation covers this very well with step-by-step instructions how to setup client application.
After you setup loopback angular client, then it is easy to use models in your controllers. All you have to do is to add your model as a dependency in your controller.
If you want to avoid manual work of generating angular controllers, routes, views etc then you should consider using one of the angular application generators ( i.e. yeoman generator-angular ).
To make long story short:
use angular generator to generate angular application.
generate angular services using loopback angularjs SDK.
add loopback model as dependency to your controller or service
See also Angular SDK built-in models API
In a recent project, we opted for johnpapa angularjs framework for a web app. Now, we want our pages to interact with web api located on the server. So, for this I have googled a bit and found that there are two approaches one is factory and other is service. And the datacontext located in johnpapa angularjs framework is a factory. So, now it looks like that all the calls we going to make to our webapi's needs to be implemented in teh datacontext factory. Which seems little messy imo. And what I want is to create a seperate file for each service/factory i.e. userSvc.js, orderSvc.js
So, is it a good approach to split the functions in different service/factory according to their logical separation. And, second thing is that do i need to create service or factory for calling webapis.
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 feel like both Express' and any MEAN stack tutorials gloss over this, so I decided to ask here.
See also these similar SO posts:
Why would one want to use Express instead of AngularJS?
Angular and Express routing
Using plain HTML with Angular directives/attributes as the view engine in Express, what's the best practice for rendering page partials in a single layout template with regards to routes?
How do you do this with HTML/Angular as your view engine?
In Jade, you'd do something like block content.
Do you use the Angular Router, ng-view and use directives?
If so, what's the point of Express? Just a server? Why not just use Connect?
P.S. If you're wondering about Jade or EJS, I'm just learning Express, and Angular, so I'm trying to keep language abstractions to a minimum.
I guess my confusion originates from the overlaps between Express and Angular in regards to templating and routing, but Express focuses on the server-side, and Angular, the client. For someone just learning these, it's tough to know how to implement when everything is so wide open.
I'm looking for detailed, specific implementation code examples that use best practices when it comes to separation of concerns. Seeing it and having it explained in context is how I learn best from others.
Check out angular-blocks if you want jade-like blocks:
https://github.com/wmluke/angular-blocks
It's important to understand that Angular and YOUR_SERVER is generally irrelevant. It's a matter of "where do my files go". As single-page application suggests, it is a single static route. I'm sure Connect would handle this just fine, but the server portion of your application likely has more concerns than simply serving a static page. Authentication, business logic, API routes and other concerns come into the picture at some point, so Express (and its ecosystem) makes a lot of sense.
Your single-page application will definitely have its own routes. These are unrelated to your servers routes, which will include the static route to the Angular application page, and also any routing for API calls that the Angular app will be making.
It's important to understand that you are writing two distinct and separate applications, connect via an API. The fact that your Node server is delivering the static HTML and JS is, for the most part, coincidental. The Angular application should be considered, and developed, in an isolated, decoupled way for best results.
Express and angular serve totally different purposes.
In most MEAN-like stacs situation (for example just express-angular), express acts as server PLUS API provider.
You use app.get('/') with any server side templating like jade (just to have cleaner html files...), then You use app.get('/partial/:name') to handle all partials with same template language.
then, You use app.get('/api/anyapi1'), app.get('/api/anyapi2') to provide whole api to angular - no matter what it will be - some mongo or postgres handling, or just Your static json files.
In new express4 You can also create dedicated api route with:
var api = express.Router();
api.get('/somget', function(req, res) {
res.send('some json');
});
// init api route. all api routes will begin with /api
//(like above api.get will be at /api/somget)
app.use('/api', api);
You can also deal with sessions and authorization on express side, and whole awful lot of stuff, that shouldnt or cant be done on client side.
Hope it helped.
EDIT: speaking shortly: express is backend with http server, other services and api, and angular is whole frontend which consumes what backends provides.
Having such separation You can even provide that backend api to others, or build different services on top of it.
Correct, the MEAN stack puts an emphasis on making most of your logic on the front end. Your express server will act as a mule to save, read, validate, and delete data based on the get and post request you make from the front end.
The idea is to have all your front end code in a public folder of your express app.
`app.use(express.static(__dirname + '/public'));`
Then simply make a route that renders the index file as such
`app.get('/',function(req,res){
res.render('index')
})`
With this in mind you may we wondering if there is a solution that can generate an api for you so that you just name your models and the rest is done via angularjs services. There is.. http://loopback.io/ just name your models, relationships and restrictions. It will generate an enteprise level api for you to play with.
For a complete working example on how routing is done and how to model your app check out this tutorial: http://www.ibm.com/developerworks/library/wa-nodejs-polling-app/
When I first looked at Play and went through all the samples, I was pretty excited by the zentasks sample and the fluid, clean, effortless Javascript routing that left the work of rendering things to Play. But we decided instead to go with Angular.
Upon going down that road, I thought that Angular would control all aspects of rendering.
However, we have a page that has to get a socket. We were having the socket made on the server, so for now, we still have a Play (Scala) template doing that. We have pared it down to pretty much nothing: create the socket and then inject it into the Angular context.
But we are also trying to do Protractor tests and that is made uglier by having to figure out how to accommodate the Scala template.
Question: should we just ditch the scala template and have the Angular controller call the server and get the socket? That was my favored approach to begin with.
I'm currently working on two Play apps with Angular and in both we decided to have one single main.scala.html file that load all the necessary controllers,services,directives, etc from angular using of require.js.
The goal with Angular is to create a single page app and therefore you should avoid to mix it with server side templates.
You must see your main.scala.html template as the entry point of your single page application. There you generate and load all the pieces you need and give the hand to angular to manage the rest.
I agree with Renato. It's probably better to have a single controller and template that sets up the single page app with angular. Then use AJAX to send requests from the browser to other controllers (see http://www.playframework.com/documentation/2.2.x/JavaJsonRequests).
If want to to avoid Scala templates completely, you can put your web pages and javascript in the public directory and only use AJAX.