I am developing a site that can be broken down to a handful of main pages. These pages can be thought as isolated from each other, except they share the session data (ie. session id and logged-in username).
Initially, I was gonna build the site as a SPA using ng-view (ie. make the pages into AngularJS views). But then, I don't see any benefits for my site to be implemented in that way. And it would require extra time and efforts to make it support SEO (Making AJAX Applications Crawlable).
Going with an approach that does not provide any benefits and even creates extra workload doesn't seem to be too smart. So I thought to myself, why don't I make the main pages of my site into individual AngularJS apps. The parts of the site that need to be indexed by search engines are simply the initial screens of some of those apps, so I wouldn't need to do extra work for SEO. (Note: The initial screens are rendered by the Django server with data for search engines to crawl, so they are non-blank.)
For each of the apps, it may or may not have its own set of partials, depending on the requirements on it.
Example:
mydomain.com/item_page/1234 (load "item" app)
mydomain.com/dashboard (load "dashboard" app)
mydomain.com/account (load "account" app and default to "tab_1" view)
mydomain.com/account#tab_1 (load "tab_1" view of "account" app)
mydomain.com/account#tab_2 (load "tab_2" view of "account" app)
mydomain.com/post_item (load "post" app)
This is solely my random thought and I haven't seen any AngularJS examples that are comprised of multiple AngularJS apps. I would like to know:
Is the multiple-AngularJS-apps for one site approach feasible? What are some caveats that I should be aware of? Are there any example site out there in the wild that's taking this approach?
If feasible, how do I share the session data between the apps?
Note this post is about multiple AngularJS apps for one site, not multiple AngularJS apps on the same page.
There is nothing wrong with such approach, as long as you keep the size of downloaded JS script small enough, and ensure good caching. One of examples of such applications can be GitHub (they are not using angular, but approach is the same). When you go Issues page on GitHub, it loads an html page, common Github JS libraries and page specific JS code. Navigation and actions inside page, are handled by that single page specific script. If you go to other section (like Code) a new page with new page specific JS code will be loaded. Another example is Amazon AWS console, they even use different frameworks for different pages. (both GitHub and Amazon don't use Angular, but this approach works for any JS based framework, even for GWT).
As for sharing some session data between pages, you can embed this info directly in the page itself, using inline scripts or hidden elements. E.g. when your server is generating page, it should also generate some session information into the page. Another approach is to download session data once, and store them in local storage/session storage.
Related
I've been studying the difference between single page apps and multi page apps, and I think I have good view how they differ. Single page app starts by loading a single html page, and then it does never again fully refresh the page or override the original, unless the application is otherwise refreshed (browser refresh etc.) For example, the angularJS seed project: angular-seed has an index.html file. This file is the single page, that the server would send to front-end, and after that, all the other (possible) pages will be send asynchronously under the hood by using AJAX. So if you create app just with the angularjs seed, it is always going to be just a SPA application, am I right?
How in practice would you then create a multipage application with angularjs? Wouldn't you need multiple angularJS applications then? Would you have to have a separate routing for each of those angularJS applications? And why would one want to make multipage application for angularJS? Because one could always use the first index.html just as a shell, without real content, and then have separate container-pages for different pages. Could it be said that angularJS multipage app would be an application, that would just contain many SPA angularJS applications? In SPA, can you use the browsers' back-button, in order to go back to last view?
Yes, you've got the idea of SPA and MPA right.
Angular.js enables you to create SPAs but does not force you. In an MPA, I would not speak of multiple Angular applications since you would have just spread Angular.js modules over multiple HTML pages. The page flow or routing logic would then be in Angular.js controllers, in plain hyperlinks or in the backend on the server.
There might be reasons to not put a whole application under Angular.js. Maybe the authentication part of a web application might be Held separately for some reasons...
In SPAs you definitely can use the browser's back button. You just have to implement that somehow. Twitter solves this Problem by coding the state of its web application into the URL - if you're using Twitter, you might have noticed the symbols (#!) in the address bar.
We are trying to create a portal type application with multiple / independent "sub-apps". Assuming that all sub-apps are written in Angular what is a good pattern to achieve the following goals.
Each app can be developed and deployed independent of each other.
They share a common authentication service, they can share common libraries (directives, filters etc).
Only one app will be visible and active at any given time. The scope of each sub-app is isolated from each other.
When the users goes between the sub-apps, the state is maintained as long as the user does not refresh the page or visit another static link. (I think this is built into Angular and no special effort maybe needed)
Each sub-app will have more than one views (it will have its own menu). There will be a top menu based on what sub-apps are available. Ideally the top menu is dynamically build based on what sub-apps are deployed. Maybe there is a server side component to this (the server detects the folder structure etc and determines what apps are deployed and injects the necessary js code into the page).
Given the fact that AngularJs does not have multi-level view structure, I was thinking of using multiple ng-app declarations on different divs and then using $window scope to store the key of the active app and hide the ones which are not active.
There is no easy answer to your (rather open) question, but regarding the $route and ngView limitations, I have been having great success employing a technique derived from this: http://www.bennadel.com/blog/2420-Mapping-AngularJS-Routes-Onto-URL-Parameters-And-Client-Side-Events.htm
This is something that I also have been thinking of trying to implement. While I don't have a complete working solution, I believe that this type of portal app would consist of multiple angular apps on the same page.
The portal app would be the traditional ng-app directive on the main page and the "portlets" would be dynamically created and manually bootstrapped angular apps on a sub view div. You can share data, state, authentication, personalization, etc from injecting the portal services (contained in their own module) that provide these features into the manually bootstrapped portlet apps.
The tricky part is how the portal app would discover the portlet apps and serve up their angular modules knowing that these apps would be independently deployed web apps with their own urls.
I still have some questions around if the service data would be common between the apps or if you would need to try and leverage HTML5 local storage via the portal service (like a data manager).
I am currently designing an application that will have a few different pages, and each page will have components that update through AJAX. The layout is similar to the new Twitter design where 'Home', 'Discover', and 'Connect' are separate pages, but interacting within the page (such as clicking 'Followers' or 'Following') uses AJAX.
Since the design requires an initial page load with several components (in the context of Twitter: tweets, followers, following), each of which can be updated individually through AJAX, I thought it'd be best to have a default controller for serving pages, and other controllers with actions that, rather than serving full pages, strictly handle querying the database and returning JSON objects. This way, on initial page load several HMVC requests can be made to gather the data for each component, and AJAX calls can also be made to update each component individually.
My idea is to have a Controller_Default that handles serving pages. In the context of Twitter, Controller_Default would contain:
action_home()
action_connect()
action_discover()
I would then have other Controllers that don't deal with serving full pages, but rather components of pages. For instance, in the context of Twitter Controller_Tweet may have:
action_get()
which returns a JSON object containing tweets for a specific user. Action_home() could then make several HMVC requests to get the data for the several different components of the page (i.e. make requests to 'tweet/get', 'followers/get', 'following/get'). While on the page, however, AJAX calls could be made to the function specific controllers (i.e. 'tweet/get') to update the content.
My question: is this a good design? Does it make sense to have the pages served through a default controller, with page components served (in JSON format) through other function specific controllers?
If there is any confusion regarding the question please feel free to ask for clarification!
One of the strengths of the HMVC pattern is that employing this type of layered application doesn't lock you into a workflow that might be difficult to change later on.
From what you've indicated above, this would be perfectly acceptable as a way of serving content to a client; the default controller wraps sub-requests, which avoids multiple AJAX calls from the client to achieve the same goal.
Two suggestions I might make:
Ensure that your Twitter back-end requests are abstracted out and managed in a library to make the application DRY'er and easier to maintain.
Consider whether the default controller is making only the absolutely necessary calls on each request. Employ caching to avoid pulling infrequently changed data on every request (e.g., followers might only be updated every 30 seconds). This of course depends entirely on your application requirements, but if you get heavily loaded you could quickly find your Twitter API request limit being reached.
One final observation: if you do find the server is experiencing high load and Twitter API requests are taking a long time to return, consider provisioning another server and installing a copy of your application. You can then "point" sub-requests from the default gateway application to your second application server, which should help improve response times if the two servers are connected by a high-speed link.
We have web applications elgifto.com, roadbrake.com in which we used AJAX at many places, especially to update major portions of a page. All the important functionality of elgifto.com was implemented using AJAX. Now we realize a few issues due to AJAX implementation.
All the content implemented using
AJAX is not available to the SEO
bots and it is hurting the page rank
of our site.
Users will not be able to bookmark
some of the pages as they are always
available through AJAX.
When we want to direct the user from
one page through an anchor link to
another page having AJAX, we find it
difficult.
So now we are thinking of removing AJAX for these pages and use it only for small functionality such as something similar to marking a question as favorite in SO. So before going ahead and removing, we want to know expert's opinion on this. Thanks.
The problem is not "AJAX" per se, but your implementation of it. Just as a for instance, you can fix the 'bookmark' problem like google maps does it: provide a generated link for each state of your webapp.
SEO can befixed by supplying various of these state-links to the crawlers, either organically trough links in your site, or by supplying a list (sitemap).
If you implement 2, you can fix 1 and 3 with those links.
In the end you must figure out if the effort is worth it, and if you are not overusing AJAX ofcourse, but the statements you've made are not set in stone at all.
I'm costantly developing ajax based websites, with no problems for SEO at all. You just have to use it in the best possible way.
For example, I have a website with normal links pointing to normal webpages (PHP pages), this for normal navigation if a user doesn't have JS enabled. But if a user has JS enabled, a script will change the links behavior, only fetching the content of the page needed.
This way you still have phisycal separated webpages with all their content, which will be indexed as normal.
I am new in building web apps and just begun learning and setting up Grails. I am planning to build an app which has a flow of 4 to 5 pages. Since HTTP is a stateless protocol, how is the state between the pages maintained usually. I am curious what is the accepted standard here, should I create session scoped objects and use them between pages or keep passing around the values between pages (not sure if it is effective if I have a large number of items on a page). Or instead of using 4 to 5 pages should I just use one page with multiple divs and show/hide based on the user clicks?
I think using domain objects in Grails would help here but I dont have a DB backing the UI and only some webservices which will do the UI actions so I cant use domain objects.
A Grails specific solution would be good but also wanted to know how this is handled in web development in general.
Without using a DB, there are a few options you could use:
Use POST/GET variables to pass info from page to page.
Use the session to store information.
Use cookies to store information.
Using POST/GET is usually best if you just have one page "talking" to one other page (e.g. submission of a form). If you have a bunch of data that will be shared by several pages, the best way to do it would probably be to put them in the session. If you need those values to stick around after the user leaves your site and comes back later, then you might want to use cookies.
You may want to look into WebFlow (Spring WebFlow) in Grails. I find it helpful in wizard like or shopping cart like applications where you want to hold on to the data between a group of pages (ie: Page 1, Page 2... Page 4) and then at the end submit the data somewhere etc.