NODE and CMS with angularjs: how do they cooperate - javascript

I'm thinking about making something with the MEAN stack. I need a way to edit the content of the site, like e.g. Wordpress offers (basically a CMS).
The confusing bit is how the CMS and Angular would work together. I've looked at a CMS named Keystone, and there you have to set up some routing etc. in Node. Won't this crash with the routing you set up in Angluar?
In other CMSs I've used, the creation of the views happens on the server side. In Angular, as far as I understand, you crate a HTML template, which you can populate with data in an angular controller. This also seems like something that could crash between CMSs and Angular. Is this the case?
Is there any other quirks or similar about Angular and content managment systems I should know about, or is it usually not much problems integrating the two?

meanjs.org has a pretty good approach to this. Install meanjs. It comes with a sigin/signup and even allows you to create articles from the vanilla install.
Put simply, when you are creating a web app with the MEAN stack, think of AngularJS as "THE" app, and node.js as the api.
If you approach building your web app as a javascript application (AngularJS), that happens to get its data from an server api (node.js), then you will begin to understand how to properly use the MEAN stack.
First: Angular will have the routes defined in the $routeProvider. Build the routing urls in AngularJS first. They are "THE" routes for your web app. A good way to look at it is to build the AngularJS portion with the ability to change your api server, even to another language (PHP, python, go, etc) if necessary.
Second: Build your AngularJS to communicate to the api with $resource. Essentially a $resource is an easy way to call out to an api using restful routing. This "restful routing" is now the routing that needs to be "mimicked/copied" into the routing for the node.js routes.
Often the AngularJS routes (the url) will match the $resource routing that matches the node.js routing.
Again, take a look at meanjs.org and you will have a better understanding on how to properly organize what "seems like" (and actually are) two separate apps.

Basically, you need three sets of routes (or two if you are doing it on the cheap).
Start out with a set of routes on the server that return regular webpages. Forget about JavaScript. Do not involve Angular at this stage.
Second, add another set of routes on the server which return data in a rawer form (such as JSON). This would typically be a RESTful API.
Third, add Angular to the client. When the view needs to be updated, update the URL in the browser and use Ajax to hit the RESTful API to get the data needed to populate it. (You want the URL you set the address bar to to match the URL of the page from the first set of routes that you are duplicating with JS and the data from the RESTful route).
If you are doing it on the cheap, like Gawker did, then you would skip the first set of routes and go direct to the JS+REST approach.

I think you need CMS on MEAN stack development environment.
there are some cms on mean stack you can try.
PancilBlue
Calipso
try this.

I was trying something similar, I found this link very useful AngularJsCMS It has told about free respond cms which is based on angularjs and have the ability to create pages like wordpress and manage contents.

We have been working on a project using angular and keystonejs. Simply serve the default template layout found in keystone and inject the data-ng-view tag within the body tag. Serve this template for all requests to '/'.
Then write your angular app normally to consume endpoints. These endpoints can be done in keystone using the api middleware. In the routes/index.js file add a key/value pair in the routes object with the name of your custom endpoint then import the folder containing your endpoint function definitions.
var routes = {
views: importRoutes('./views'),
api: importRoutes('./api')
};
exports = module.exports = function(app) {
app.get('/api/posts', keystone.middleware.api, routes.api.post.index);}

I recently migrated my blog over to MEANie - a lightweight custom MEAN Stack CMS that I developed.
I made it open source for anyone to use and posted details and setup instructions on my blog at http://jasonwatmore.com/meanie.

Related

Creating a front end for a nest-js API

I have a question regarding creating a front-end for a nest-js API:
Will this front-end be an entirely different project with regards to folder structure?
Will it just 'call' the services from my API?
How are my controllers of the API used, if the front-end just uses the services directly?
Also, in what order does it make sense to create the front-end prior to auth? Or should it be the other way around.
Thanks
You can create separate project for frontend app, or you could return HTML directly from nest. This depends on what you want.
https://docs.nestjs.com/techniques/mvc
If you go for server side rendering (the MVC link above), then your code will have direct access to your nest services. If you go for SPA approach (angular, react, vue, ...), then you will have to call your nest API via http, so you will have access only via your API endpoints.
I guess this one is answer already - for SSR approach, you will have endpoints that return the HTML. You could combine both approaches, having group of controllers working as REST API, and another group for SSR, that will return JSON response.
About the auth - I guess you should implement the backend first, then you can implement frontend so you can test it.

Ember best practices for loading javascript/app only after authentication

Starting a new Ember app and was prepared to follow token authentication type structure for authentication in the restricted API routes but was then told we need to not show any of the javascript (or as absolute little as possible) before authentication. This has me a little puzzled given single page javascript apps.
I'm using the, very helpful, ember-app-kit which has great tools that compile everything down to a minified and obfuscated single javascript file, which I thought was good enough for security, but apparently its not.
Having the entire app loaded once, and even in a single compiled/minified js file, what is best practice for "hiding" some of the javascript and only loading after authentication?
I had one thought of my own and have found another potential:
A ) coming from rails, I thought I could just build a very thin rails app that handles authentication in a server side view that doesnt load any of the app js. Then on successful authentication, transition the user to a view that loads all of the JS for the app and go from there.
B ) I found some talk of new functionality in ember-data that allows you to async load javascript files in the models. This seems like it could work but also seems very complex and I'm not sure if It'll totally work cause they want to hide not only models but things like app routes (basically everything but login)
I have done option A in rails: authenticate the user on the server and then forward them to a page containing the actual client Ember application. It will be far simpler than trying to dynamically load the app on the client side. Simple is usually best.

Create url in sails js node framework

In many web frameworks (I am familiar with the Yii php framework) you are able to use some application component to create urls you can then use in various places in your application. You can usually give it a controller/action or some other combination of parameters and it will return a url eg. http://mydomain.com/index.php/<controllername>/<actionname>
The main thing you gain is that the application takes care of building urls and you aren't left ever hard coding url paths around the place.
My question is, does anyone know if the node sails js framework has such a thing or, if not, perhaps someone has written a module on npm that achieves this nicely?
Sails uses blueprints that do things similar to what you want. They provide a few different blueprints, for common things like CRUD or REST but they also have "Action Blueprints"
If you have a controller foo (FooController.js) that has action bar, it will be automatically accessible via /foo/bar when action blueprints are enabled (they are enabled by default)

Components of Web Application - Express.js, Angular.js and MVC confusion?

I've come across a lot of posts on Stack Overflow about Express.js being used with Angular.js and how there are two MVC components to both the client and back-end sides of the web application, but I've just become confused now. What are the components of a web application, and what does each of these two serve? What are the MVC parts for each of the client and back-end sides exactly?
Thanks in advance for any response!
In most cases, it's pretty straight forward. In my applications, it generally works like this:
Express.js provides the backend REST API
Express.js serves up the static HTML, JavaScript, CSS and image assets.
The frontend HTML/Javascript bits are written using Angular.js.
I tend not to use any of Express.js' view capabilities (the stuff that provides functionality similar to ruby on rails or Django, with templating and all that), but instead serve up a single index.html and then let Angular.js do the rest. It's very possible/typical to make an Angular.js app which has only one main HTML file and therefore the "view" pieces of express are unneeded.
Angular.js itself is structured in an MVC fashion. You have view templates and controllers which provide data to them and handle events from user interaction. The data the controllers act on from comes from the model. The model is simply a layer providing access to the API provided by the Express.js backend. This is typically done using Angular.js resources.
RESTify is another alternative to express for apps stuctured in the way I describe.
As others have recommended, just go through the tutorials on each component's website. I also found a tutorial about integrating Anguar.js and Express.js here: http://technokayiti.blogspot.no/2013/06/lesson-5-angularjs-tutorial-backend.html

How to structure Javascript architecture to complement a PHP MVC web app?

I am working on a new JavaScript architecture for a web app iteration. The previous iteration had lots of inline code, scattered includes, no directory structure for .js files and everything was in the global namespace. I am aiming to: keep the script includes in the footer, keep everything in an application namespace/object, add organization to the .js files and minify all the application specific files in to one bundle.js
I am trying to take a modular approach based on Nicholas Zakas: “Scalable JavaScript Application Architecture” http://www.yuiblog.com/blog/2009/09/17/video-bayjax-sept-09/
the site is currently structred like so
/app
/models
/views
/home
/auth
/meta
about.tpl
contact.tpl
privacy.tpl
/controllers
home.php
auth.php
meta.php
/public
/js
core.js
/modules
module files here
/jquery
jqueryplugins here
/controllers
home.js
auth.js
meta.js
the controllers have methods which correspond to our url routing and view rendering. For example http://localhost/meta/contact would call the "contact" action on the "meta" controller and render the meta/contact template.
I am planning the js architecture around a single initialization call to the apps global object passing it the controller and method as arguments i.e.
localwebapp.init(controller, method);
At this point in the design I am struggling on inheritance and module implementation. Some modules will be global and be used throughout all the site, some modules will be used through out specific controllers, and some modules will be on controller actions only.
Modules are independent and will not communicate with each other they will need to be assigned to a "sandbox" which they will check with for event triggers
I'm thinking I will need sandbox and module classes. The controller scripts will basically be a few lines of modules being assigned to the sandbox and initialized.
Let me know if I am reinventing a wheel here. Any direction is much appreciated. I have looked in to javascript MVC frame works like JavaScriptMVC but it looks like it is not what I need
We use JavaScript MVC as well. You can use both in an application.
In our case, our application is more frontend driven and the backend side (ZF with MVC) is a REST API and JavaScript MVC makes it easy to do so. The feature set is still in the PHP part, and not client-side, we just utilize a lot of parts of JavaScript MVC to make it look snappier, etc..
In the end, I see no reason why it couldn't be the other way around though.
I think the misconception about the view part in MVC is that it's something to see in the browser. The view can be XML or JSON as well. I'm sure you know that, but I wanted to emphasize this part since it is what throws most people off.
If you generally ask about JavaScript MVC -- I don't know if it's the best MVC framework (client-side-wise), but it forces you to define models, controllers and it comes with a testing framework to make sure things go according to plan.
Let me know if this helps!

Categories