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.
Related
I'm an android developer and about two years and recently I've been thinking about building web applications. So I started researching about spring boot and everything is great. Then, I came across this thing called template engines (thymeleaf) which by definition separate your code from presentation.
What is confusing me is how can a backend server have html? should the presentation be handled by html, css and javascript in the front end? I even saw tutorials where they actually type in html code in their controller as return values.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
THank you
the frontend will manipulate this data
What front end? You mean the JavaScript code in the HTML page? Where did that come from? Oh yeah, the server.
It is the server that serves the HTML pages to the client, as well as any .js and .css files.
The server could provide static pages, and anything dynamic is handled by JavaScript. Or, the server could dynamically build the HTML page, using ... you guessed it ... a template engine.
You generally don't want JavaScript to build the page initially, just to use JavaScript for handling any dynamic behavior. Some pages don't even need any dynamic behavior.
Unless of course you're thinking about single-page applications (SPA), where there is only one root HTML page, and everything else is built client-side with JavaScript and AJAX calls, but most web applications are not SPAs.
Thymeleaf replaces JSP by providing HTML pages using a template engine. The controller requests the HTML file and Spring Boot provides that template after building it using the Model provided.
Thymeleaf is great because it allows you to rebuild templates on the fly. Lets say for example you're showing a users points to them on the front end, but maybe the points increase or decrease.
What you can do is build the template in the background using a Model. The Model reference is magically provided to the template provided which parses it.
#RequestMapping(...)
public String request(Model model) {
model.put("points", 5);
return "my-template.html"
}
Then use the Thymeleaf language to provide your object to the HTML file to be processed in the engine during runtime.
<html..>
<head>...</head>
<body>
<h1 th:text="${points}"></h1>
</html>
Spring Boots Template engine will build this in the background and present it to the user, but it will show the actual points to the end user! Hope this helps a tiny bit.
I know this question has been answered pretty effectively so far, but I want to add my two cents in as I work with Thymeleaf often.
The easiest way to think about a template engine is that it allows some dynamic development of html based on information passed to it by the controller method. This allows you to put logic in that normally wouldn't exist, or say display a certain section if a user is perhaps logged into admin.
If web pages were houses, html is the frame, css is the walls, Javascript is the lights and electricity, and a template engine would pretty much just be the architect designing the plans on the fly before the frame was built based on desires of the buyer of the house (user inputs).
OK, newer Apps and websites may just load/boot/open once and then pull or push data via AJAX requests, this is good, it saves traffic and it is fast.
But it has not always been like this and some Frameworks still don't build everything on small requests. Spring in Java or Symfony in PHP are MVC Frameworks and use template engines to build pages. This may sound a little outdated but there is still a lot of websites using this.
And if you build a web app for a customer with slow PCs or other devices and the page contents are performance heavy you might want to do as much work as possible on the server so that the user does not have to wait for long. And also you can cache the rendered pages. There is even server side rendering of react pages to e.g. make the initial page load faster...
With Java and Spring I did just use JSP I don't know thymeleaf. Just use what you like and maybe what is most supported/documented.
And building websites like this does not mean you cannot use AJAX, but if you use templates you need to think about what makes sense.
What is confusing me is how can a backend server have html?
The "back end" must have HTML, because that's what's delivered to, and rendered by, the client.
It may just be that the back end "server" is just a CDN delivering, say, an HTML/JS SPA, but there's still something delivering content to the browser.
That said: server-side rendering is still a thing, and has had a resurgence lately--a React app may have its initial rendering done on the server so again the client gets a page rendered with both HTML and associated data, and then starts acting like a normal SPA.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
Because something needs to run the JS to access those APIs.
Some history:
Browsers used to suck. JS used to be a neat add-on, sites were relatively static, and essentially all rendering was done on the server. The back end would get data from wherever it got data from and generate complete HTML pages, and there was little happening on the client side other than some form fields, maybe some validation, and that was about the extent of it.
Per default, Angular fetches the HTML templates from the server when the user navigates to a route. With that in mind, imagine this scenario:
User loads the Angular app. The main view has a subpage called "Order".
While the user is studying the main view a new version of the app is rolled out in production. The new version has a complete rewrite of the Order page with new Javscript and HTML.
The user navigates to the Order page. The Javascript is already loaded by the browser in step 1, so the user is on the old version until app is reloaded. But the new template gets fetched from the server on navigation. So now the Javascript and template are our of sync!
Is my assumption that the Javascript/HTML is out of sync, correct?
If so, are there any best practices related to this issue?
I guess one solution is the make Angular fetch all the templates on app initialization. But this could be a performance penalty if the app has hundreds of HTML views.
I've never wondered about that issue myself. One possible idea would be to reuse the pattern known as assets versioning, where upon new release, you rename all your assets.
For instance, instead of login.html you'd use login-xyz.html as a name of a template. xyz could be a random value, or a checksum of the file. Checksum might be a slightly better option because if the new release is small (i.e. you fixed just some small bug in one file), if user loads any page but the fixed one, he/she will not be bothered with a reload - all other files will have the same checksums, they'll work with no interruptions.
This way, when an outdated Anguar app tries to fetch a template, it'd get a HTTP 404 error. As an addition to that, you could write a simple $http interceptor, which would detect a 404 response, and reload page automatically (or offer user an option of doing so).
There are modules which are capable of renaming assets, such as gulp-rev - but I never heard of using that for Angular templates. You might implement something like that on your own, though.
Of course you might want to keep both the new and old versions of files to allow users to work without interrupting them with a refresh. Depends on what your requirements are. I assume you're trying to avoid that, though.
Sample 404 interceptor (CoffeScript, as I have it handy now):
m.factory 'notFoundInterceptor', ($q) ->
return {
responseError: (response) ->
if response?.status == 404
# Reload, or warn user
return $q.defer()
# Not a 404, so handle it elsewhere
$q.reject response
}
m.config ($httpProvider) ->
$httpProvider.interceptors.push 'notFoundInterceptor'
Thanks for good answers.
It turned out that this problem solved itself for us. Every time we roll out a new release all the users sessions gets deleted and users will be sent to the login page. This will trigger a page load and fresh JavaScript/HTML gets loaded.
I've read about this issue long time ago, and one option is to do versioning on changed pages and application.js file.
For example on your version 1 of your application you can on your html file use something like:
<script src="js/angular_app_v1.js"></script>
Inside your routes also version the templateURL
templateUrl: 'templates/view_product_v1.html'
So when you roll out a new version you won't be overwriting templates and users already working will have the old version until they reload the browser but won't have version inconsistences.
Versioning of the assets using the file names would become unmaintainable for even a medium sided app.
Although it is a heavy weight approach for web assets you could look into content negotiation. This is where the call for a resource, generally a REST api returns the version of the resource, Content-Type: application/vnd.contentful.delivery.v1+json.. On the client you can check that the version matches what it expects. So if the client only knows how to load v1.1 and the resource responses with v1.2 the UI would know it cannot process that and should reload the page.
Another possibility is to load all templates up front in the UI. There are build processes in Grunt you can run such as https://github.com/ericclemmons/grunt-angular-templates that will combine all of your templates into a single file for delivery and then load them into $templateCache so no requests ever get to the server.
If you have some sort of server-side language you can build a filter in (.NET, Rails, Java or whatever), and pass along a version number with your template requests. If the version requested by the client is older than what's deployed, you'd send an error to the client. Your client would watch for that error ($http interceptor) and force a page-refresh to pull down the newer javascript code. (Maybe show an alert to the user first so they know what's going on).
You can preload all your templates into a $templateCache and serve them as one templates.js file. There is a gulp task for this https://www.npmjs.com/package/gulp-angular-templatecache. Then your application will load all templates in a single request together with application scripts on start up, thus they will be in sync. Read http://www.johnpapa.net/angular-and-gulp/ for more info.
It always makes sense to have a version number and use it when syncing resources. It's not only a good practice for the use case you described, but also for other situation, such as rolling back to a specific version or having two versions live and usable (for example in order to let some users preview the next version)
My question is just conceptual.
When you use the ui-router (docs) in your application, then you have a system built of multiple views. Right?
I was thinking about that, because looking at the network log of Chrome, every change to another view, the client-side makes a request to server to get the HTML files.
Well, the definition of SPA might vary, but basically it has nothing to do with making requests to a backend. It is a matter if the browser needs to do a full page reload to make that request.
Traditionally
Fill out a form, submit it and the browser is redirected to a new url. A full page request
SPA
The application makes an AJAX request in the background. On its response it changes the URL manually and then changes the state of the application. There is no full page request, just JavaScript running in the background
But you are right about suspecting something wrong when there are lots of HTTP requests for templates. You do not want your application to do all these requests to the server. To avoid that you actually have to precompile your templates using a tool like grunt or gulp. Example: grunt-angular-templates. This will insert the templates in your JavaScript code and Angular just grabs them from there, instead of making a backend request. During development though it is no problem.
With modern frameworks you need a tool to "compile" your project for production. You want to concatenate all JavaScript files into one file, bring in precompiled templates and uglify the code. This is not something frameworks give you, you have to set it up yourself using tools like grunt or gulp.
Hope this was of help :-)
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.
So I've been doing a lot of learning on Backbone, Sass, RoR, Bootstrap, etc. and I am extremely frustrated that no sources I've found (including in Tuts+ and Code School) mention any way of putting it all together...I have no clue how to style a web page if all of the contents I want in the page are being built through backbone...so if I want to click on the "About" page on a website, have all that page's Backbone contents styled correctly when appended to the DOM.
Secondly, I'm not sure how I should be creating these web pages for a website; should I be creating the whole page in Backbone and then keep that on the server until someone clicks on, for example, that "About" page and then have the whole page loaded into the view? Or am I totally misunderstanding one of the ways you can use Backbone? Along with this then, how am I supposed to communicate Backbone to a Ruby Server? just using Ajax?
I'm looking for sources and anyone who can help me understand this stuff in clear terms!
Thanks so much,
-Stu.
Presuming that you want to build a single page app it is important to understand each one responsibilities:
Rails
Create a full stack application that runs on server
Create a consumable API
Manage assets pipeline
...
Backbone
To manage your frontend javascript application
Decouple data from the views using Models
Connect an API over a RESTful JSON interface
...
Keep in mind this is a oversimplification of both...
Rails will handle the backend, retrieving an API to be consumed by Backbone. The Rails assets pipeline will deliver all files that Backbone needs, including the css that will style you app.
It might be somehow confusing since you will hear concepts that eventually will clash between them, like in both ends will have Models, Views and Router, but they will live live independently from each other, one will work on the server-side (Rails) and the other on the client-side (Backbone).
To give an example:
Rails would render:
domain
|-index.html
|-js/*.js
|-css/*.css
`-api/*.json
Backbone would use the DOM (index.html) and the js scripts to execute logic, append the views into the DOM and Read/Write data using ajax through the API.
Another confusing thing would be views, since Rails will generate those for you, and backbone will also have their own views, so the usual setup:
In the client-side, Backbone will be have at least the following parts:
Router — it will orchestrate your app, binding an event a route, let's say /#about page and create a view and pass the respective model:
Model — it will request data from the API and dispatch an event when done
View — it will use a template to render the model data
In this case Rails would manage the page assets and provide the API, Backbone would have it own router, models, views and templates to render the page on the client-side.
This also means that the way you combine both it could be only answered regarding the project specificities, and there a lot of ways to use both.
That said, IMHO it's really important to first understand how a full Backbone app works,
then use something like backbone-rails gem, to see how both can be managed in a consistente way.
I know what you mean--there's a lot of random tutorials out there for Backbone but not a lot that put it all together. To a certain extent that's just how it is, unfortunately, but I'd say once you're past learning the basics from Code School and others, the hands down best resource for how to actually build complicated apps is:
BackboneRails: http://www.backbonerails.com/
It covers the stack you're talking about mostly. The first few screencasts are free and then subsequent ones are paid but well worth it. Building on the skills I've learned from BackboneRails and I've built several fairly complicated apps that turned out great. Good luck!