I have more of a style question. So I have my services classes with my http calls. What would be best practice in Angular
http.get("/api/some-stuff")
or
http.get("${api.url}"/some-stuff
What would be the better approach? I noticed with the first one, I need some sort of proxy and url rewrite on my web server after I build the project.
For the second approach I need some sort of env deployment. But as said. What is best practice here?
Yes, this is just opinion question and i would like to say, that from my point of view the best practice would be to have in memory service wich will handle your rest api uri and:
http.get(urlResolver.getBase() + urlResolver.getYourEntryPoint())
I am trying to understand how to perform crud operations using AngularJs, NodeJs
add Mysql. I need to understand the approach for this. Please explain with some
basic example.
CRUD is the acronym for the set of operations Create, Read, Update and Delete.
CRUD is the basic set of operations required to use and manipulate a collection, or resource if you will.
In this setting, "performing" CRUD operations would relate to your application in the following way:
Angularjs uses $http to run http requests asynchronously against your RESTful API
Nodejs implemest the routes that makes up the API, hopefully in accordance to the best practices widely used in existing APIs (An in-depth blog can be found here. Based on the route/api-method triggered, the nodejs will also send queries to MySQL to persist the changes nessesary.
MySQL's job is to persist the data you are working with. Using SQL queries to (C)reate, (R)ead, (U)pdate and (D)elete data (CRUD operations). MySQL ofcourse has a lot of other tools as well, but in reference to the CRUD operations, these are what you need.
Now this is just the practical idea of how to implement a RESTful API with CRUD operations, persisting it with MySQL and consuming it with Angular. If you really are serious about learning more about this, you should:
Google better (Really, it's too easy to find info about the subject as people have mentioned). The terms REST, RESTful, API, CRUD are all good keywords to google, then append whatever keywords you are more interested in "Best practice REST API" for example.
Read blogposts, follow engineers on social media/blogs, read books, watch youtube etc. This information is everywhere.
One important thing that might not be obvious when starting out: Always try to find and standards or best practices for what you want to do. That means someone already has done the hard work of trying and failing, and basically serves you the best solution on a silver platter.
I'm trying to implement admin-site for commenting-system. I have REST-API with JSON. I don't want do isomorphic application. I just want feel in Single Page manner. I see there is already has some solutions:
1) Create ajax factory and send request to api methods with XmlHttpRequest, during dispatch action and handling this by hands.
2) Redux-api or redux-rest.
3) Method that used in redux real-world example.
For my job i need's stable solution. I think to choose redux-api. But i don't know which disadvantages can be in each variant.
Maybe anyone has the same problem?
There's no definitive answer to this; however I am using a variant of redux-api-middleware which allows me to keep my action creators stateless and free of side effects.
redux-api and redux-rest both look valid; if somewhat 'magic' based on the amount of configuration / convention they enforce on your app.
My understanding of angular services is that they are used to access external data sources amongst other things.
So let's assume I have a service to access feeds, that deals with the ATOM parsing, etc.
Now, let's assume a controller needs to access several feeds.
Is there a way for me to parameterize services as they are instantiated? Since services are singletons, do I need a service factory factory? Should I be using the same service and passing details of the particular feed each time? What if I need to make more than one calls to the same feed and would like a dedicated object to speak with? (think websockets instead of feeds).
Is there another approach altogether that would work for this?
Is there a way for me to parameterize services as they are instantiated?
Not really. You can inject things into a service – e.g., another service – but I don't think that will help you here.
Since services are singletons, do I need a service factory factory?
I don't know how you would write that, but again, I don't think it would help here.
Should I be using the same service and passing details of the particular feed each time?
Well, as I asked in the comments, if you are dealing with a fixed set of feeds, I would hard-code them into the service (or maybe have the service fetch them from a configuration file on the server), and allow the controller to ask for them by name or some ID.
If you need something more dynamic, then I think you'd have to pass in the feed details to the service.
In either case, I think one "atomFeed" service would be sufficient.
What if I need to make more than one call to the same feed and would like a dedicated object to speak with?
I would probably still use one service. I'm not sure what the issue is here though.
Until now I was mainly using Struts 2, Spring, JQuery technology stack for building web applications. The point is, that mentioned stack uses server side MVC pattern. The main role of web browsers was limited to a request/response cycle (+ client side validation). Data retrieval, business logic, wiring and validation were mainly responsibilities of the server side.
I have few questions regarding AngularJS framework that were inspired by following quotes I've read:
From the AngularJS tutorial:
For Angular apps, we encourage the use of the Model-View-Controller
(MVC) design pattern to decouple the code and to separate concerns.
From the Wikipedia Model–view–controller:
Model–View–Controller (MVC) is an architecture that separates the
representation of information from the user's interaction with
it. The model consists of application data and business rules,
and the controller mediates input, converting it to commands for the
model or view
AngularJS uses client side MVC pattern. So I guess there is no other option then to include validation logic also to the client side in some way?
What would be the best way to write a robust AngularJS application? MVC on client side and some kind of MC (model, controller) on server side?
Does that mean, that MODEL and CONTROLLER are in one way duplicated (client/server)?
I know my question is somehow weird, but I think the reason is, that I am somehow acustomed to traditional server side MVC pattern. I am sure there is someone, that have already done same transition.
Not at all a weird question - I've been trying to sell Angular to a lot of java developers and they ask this. I asked it myself when I was learning (I'm still learning, btw)
If you take a 'conventional' java webapp as you've described and Angular-ize it, you've got to first take your server and make it a RESTful API. Remove the JSPs, etc. This is actually the hard part, IMO, of writing an Angular app - getting the REST API right. The key for me to deciding what logic needed to go into the server was thinking of it as a pure api and forgetting for the moment that it will have a front end.
That question really helped me - if someone tries to save a given resource and that resource doesn't have valid data there's no front end to tell them - they're hitting the API directly so the API needs to reject it. So, the back end is responsible for the deep validation. This applies to your business logic as well. Assume someone is using just the API and it will become clear what your server needs to do.
The server needs also to vend data in (probably) json format (I use Spring MVC + Jackson), so it's responsible for exposing the model to Angular, and communication with the database.
So what's the MVC then on the Angular side?
Model: The data that comes from the REST API. If the API is vending JSON, then these objects will already be 1st class javascript objects.
View: HTML, and directives when you need to manipulate the DOM
Controller: (and custom services that you've factored out of your controllers..)
Queries the REST API and puts what's necessary for the View on the $scope
Provides callbacks for directives to respond to events that might then require calls back to the server.
Validation: usually via a callback to a directive. Will likely overlap some of the validation you've already put in the server, but you don't want your user to wait for the server to validate everything - the client should know something about the validation to give the user immediate feedback.
Business logic: Pretty much the same story as validation.
But why the duplication of logic in the client and in the server? Mostly because you're not writing one app, you're writing two independent things:
a REST API that needs to be robust and usable without a front end
a GUI that needs to give immediate feedback to a user and not necessarily wait for a server.
So, short answer - get the REST API right by forgetting that there will be a UI, and what goes into Angular will be much clearer.
I think the term "business logic" is a bit of a misnomer here. The "business" of a clientside app is the business of handling the user interface. It's not going to be things like security rules and proprietary logic or other sensitive intellectual property.
So in Angular the division is (generally):
Controller (controller): for manipulating the data (scope) behind your UI.
Directives : for setting up the DOM to communicate with the controller via scope, and for manipulating the DOM.
Templates (view): To assign directives to elements of the DOM.
Scope (model or viewmodel): for carrying data between all pieces of the system.
Services : Injectable, reusable bits of code. Usually for dependencies like handling Ajax, cookies, or other I/O.
It's really almost MVVM and not MVC.
As for your "business" logic or rules... anything requiring security must always be secured at the server level.
It's important to understand that in some versions of the MVC pattern, the data as well as the logic that manipulates the data both reside in the "model" layer (with the "controller" layer doing nothing but binding). In AngularJS, however, the data ($scope) alone resides in the "model" layer, while the logic that manipulates the data ($scope) resides in the "controller" layer.
I love what #Roy TrueLove says. But let me say that this is the ultimate way of using angularjs. Of course, you have to learn to do your applications this way, if you want to get the most benefit of angular. I pray to be there some day.
In the meanwhile, during your learning, and during your transition to fully using angularjs as your client side main way of doing things, you can start using it for some small mission here and there, and gradually get accustomed to it and to its way of thinking.
I encourage to gradually embracing it and to go slowly slowly, but surely, I guaranty, sure.
Angularjs is designed to serve this approach, as it can work on the smallest task as good as it can do the biggest one. For example, this first time I used angular was just to show names while the user types ids.
I agree with the answers here. Some more comments. When you write an applicacion, you first need to concentrate on the problem domain. And create a software model of some real business. For example, if your problem domain is a shopping, some requirements that you need to model might include:
The credit card should be valid.
If you pay with a credit card of brand X, you will receive a 10% of discount.
The shop cart should contain at least one item to perform the checkout
The items must have stock before allow users to add them to the shop cart
The implementation of these requirements will model your problem domain, this is your business logic.
Angular is a frontend framework and toolkit. It is a web frontend. If you implement this in a web frontend, you will miss the oportunity to reuse your model from other frontend or interface, like a mobile or a desktop application.
So, ideally, your business logic implementation needs to be decoupled from any user interface framework and decoupled from any persistent framework also. Then, you will have your interface objects that will deal with user interface problems and will comunicate with your business logic objects. This can be a Spring MVC controller, and/or an Angular controller or service.
There is a sample application you can take a look at, that follow the principles mentioned here.
I seems to be having this question as well, as some organizations just craze for new technologies - "I want cloud...wait, I want lightweight", its hard to justify whether it deserve for the switch to a lighther framework.
I develop webapplications using Spring/JBoss seam/JSF and on MVC framework all the time. Most of the time java scripts will reside for the presentation layer validations and the main action classes/entities and business logic will reside in Java code. After some basic hands-on on Angular, I started to get what they meant by MVC as they abstracted another level on the presentation layer, where we can have our own views and controllers on the front end. To answer your question, just like everyone's comment the best way is to lay it on the presentation layer.
As for security point of view, I believe heavy or sensitive business rules should reside on the server side as we do not want to expose it to the world. If the business logic is developed poorly, one can easily find the weakness on our code and exploit it.
Here's my thought for framework like Angular is like a small shop/SOHO handling customer, and they have a few people and really efficient and fast.They cater well for customers facing business and delivery/receive goods efficiently(REST, JSON). They do have designated roles and tasks, but some worker perform more than a tasks. The shop also vulnerable to thief or robbers as usually they don't emphasize heavy security.
As for server side framework like Spring/Struts 2, imagine a modern corporation(CMM Level 5) with different level of management and capable of handling bigger business(batch jobs, web services, enterprise bus). They do handle customer, but not directly, often go through brokers or even retail shops. Security wise a corporation is more robust, and often securities on the front door, or important information are protected in a safe(encryption/sign-on).
My approach is always the bottom-up approach. Starting from the Database Design, with properly constructed / related tables, stored procedures when needed, then add the Entity Framework to the solution or use ADO.Net if EF is not an option. Then develop the Business Logic, and the Models to get the data in and out the database.
With the Models established, we can now go two routes: Developing MVC Controller, and / or developing WebAPI controller. Both controllers can have access to the Models, it's just a matter of instantiating the classes and invoking the methods.
You now have the option of setting up MVC Views that are controlled by the MVC controller, or, entirely separate set of HTML pages or SPA (Single-Page Application hosted on NodeJS).
With the entirely separate set of HTML page, you will need to use WebAPI controllers, with Get, Post, Put, and Delete methods, and be sure to include token back and forth to identify your client, and enable CORS (for Cross Origin Request)
With MVC Views, you can identify your clients using the controller attributes, and / or sessions and no need to worry about CORS, and, you can even make your Views Strongly-Typed if needed. Unfortunately if you have a set of UI developers they will have to work on the same MVC solution.
In both cases, you can use AngularJS to transport data back and forth from / to the controllers.
IMHO the concept of AngularJS controller is not the same with C# MVC or C# WebAPI controller. AngularJS controller house all the javascript logic as well as the calls to endpoints via the "ApiFactory", whereas C# controllers are nothing but Endpoints in the server side that accept and respond to UI requests.