I work for a medium sized company that has an application used by a few thousand people and is built primarily with HTML,Javascript, aspx, xml, xsl, and runs on IE 11. This application is proprietary and not designed in house but we have access to the code for possible modifications and its just sitting out there on the server(s). A new project has come down the pipline for an enhancement\adjustment to be made to a particular area of the application and I'm wondering what kind of web framework I could use to do this work. I am really just needing to call an enterprise service and get data back, display it, and that's about it, so its not incredibly hard. I am worried though about how to integrate it with the existing application.
I am not sure how this scenario would go:
User navigates to page A inputs data, I want that data to go to a controller or something I built, fetch info and send it back to page A. I was thinking of using Spring MVC but not sure. Any feed back or suggestions would be greatly appreciated! I know this question doesn't include code, so please don't hate me.
Thank you.
From a very high point of view and with no knowledge about any specific requirement.
If you have already an application developed in ASP.NET, it's better that you continue the development of the new module of the application on the same platform.
If you want to develop a new module (actually a new web app) that looks like the old application but with a totally different platform like Spring MVC (could use any other), you can reuse the existing css styles and databases.
For integration purpose you could modify the original application in the menu(or links) that redirects you to the new module and implement a single sign on server (this will required work on both applications) to made the transitions smoothly between both applications (something like a portal style). Note that they will have a different context application path.
Related
I would like to start looking into Angular or React, but I'm having a hard time at the minute figuring out where they fit in?
I currently build all our sites using PHP based Expression Engine or Craft CMS. Is it possible to use Angular or React with these? Would I be correct in thinking they act as the whole front-end?
So for example, would I use EE/Craft to just create the API's to fetch/post data, and then Angular/React would generate the pages using the data from these calls?
That is exactly what I would do. I am not overly familiar with the CMS frameworks you are using, but do have a good bit of experience with CMS development. Typically I leverage the provided APIs to bring the data to the presentation layer, and then use a JavaScript framework such as Angular to create my UI.
This approach will work great if you can get away with not using any of the CMS server controls, and perform all data operations through API calls.
Using a CMS for your data as an API is fine, but you might be better off with something custom made (like a rails or nodejs project). CMS's are not ideal if you're are building just an API. Typically, you'd built your React/Angular website as a static website that you can deploy to a hosting provider (like S3 or Github Pages), this gives the immediate benefit of improved security, speed and scalability. From your static React or Angular site you then leverage your server-api's to fetch the data.
However, this only fixes the data problem, not the content management problem. Since you have a static site, there is no way for your content editor or marketers to be able to change the content on your website. Everything has to be done in the source code - by a developer. You can fix this by adding a drop-in content management solution like INSTANT on top of your static website. Without any coding, it allows anyone with an account to change content directly on the website.
So I'm afraid I might be missing something pretty fundamental here, but I really can't get my head around this - Why? Why would we want to use those JS MVC frameworks, instead of sticking with Rails, Django, PHP and so on?
What do these JS frameworks give us that can't be achieved by the old web frameworks? I read about SPA, and there's nothing I couldn't do there with ASP.NET MVC, right?
I'm really baffled by hearing all the people at work wanting to leave our current framework for these new ones, and it's much more than just for the sake of learning something new.
I am totally up for that, and I've always tried playing around with other frameworks to see what I'm missing, but perhaps these new technologies have something really big to offer that I simply cannot see?
Single page applications provide a better experience by having all page transitions be seamless. This means you never see the "page flash" between user actions, in addition to a few other user experience improvements.
Front-end frameworks also generally provide a common way to interface with APIs. So instead of writing an AJAX wrapper for every page in your site, you just say 'This page has this route (path), hooks data with this schema from that API endpoint and presents it with these templates and helpers.' There are many proponents of APIs, because there are many good reason to write you applications from a service standpoint. This talk sums up a lot of the points in favor of APIs. To summarize:
Orchestrating your web offerings as services makes them inherently decoupled. This means they are easily changed out. All the reasons behind strong Object Oriented design principles apply equally to the larger parts of an application. Treat each piece as an independent part, like a car, and the whole platform is more robust and healthy. That way, a defect in the headlights doesn't cause the motor to blow up.
This is very similar to how a SOAP WSDL works, except you have the auto creation tools right out of the box.
Having well defined touch points for each part of your application makes it easier for others to interface with. This may not ever factor into your specific business, but a number of very successful web companies (Google/Yahoo, Amazon AWS) have created very lucrative markets on this principle. In this way, you can have multiple products supported by the same touch points, which cuts a lot of the work out of product development.
As other point out, the front end framework is not a replacement for the backend, server technologies. How could it be? While this may seem like a hindrance ("Great, now we have two products to support!"), it is actually a great boon. Now your front and back ends can be changed and version with much less concern over inadvertently breaking one or the other. As long as you stick to the contract, things will "Just WorkTM".
To answer your additional question in the comment, that is exactly correct. You use a front end framework for handling all the customer interaction and a completely separate back-end technology stack to support it.
I'm forgetting a few good ones...
Angular, Ember, and Backbone are client-side JavaScript frameworks. They could be used interchangeably with a Rails, Django, or PHP backend. These JavaScript MVCs are only responsible for organizing JavaScript code in the browser and don't really care how their data is handled or persisted server-side.
Django/Rails etc are server-side MVC frameworks. Angular/Backbone etc are client-side Javascript MVC frameworks. Django/Rails and Angular/Backbone work together - in a single-page app, usually the server-side MVC will serve the initial HTML/JS/static assets once, and then once that is done, the client-side router will take over and handle all subsequent navigations/interactions with your app.
The difference here lies in the concept of what a "single-page application" is. Think about how a "regular" web Django/Rails website works. A user enters your app, the backend fetches data and serves a page. A user clicks on a link, which triggers the server to serve a new page, which causes the entire page to reload. These traditional types of websites are basically stateless, except for things like cookies/sessions etc.
In contrast, a single-page application is a stateful Javascript application that runs in the browser and appears to act like a traditional webapp in that you can click on things and navigate around as usual, but the page never reloads, instead, specific DOM nodes have their contents refreshed according to the logic of your application. To achieve a pure Javascript client-side experience like this in a maintainable fashion really requires that you start organizing your Javascript code for the same reasons you do on the server - you have a router which takes a URL path and interacts with a controller that often contains the logic for showing/hiding views for a particular URL, you have a model which encapsulates your data (think of a model as roughly one "row" of a database result) which your views consume. And because it's Javascript there are events going on, so you can have your view listen for changes in it's associated model and automatically re-render itself when the data is updated.
Also keep in mind that you don't just have one view on the client side, there are usually many separate views that make up a page and these views are often nested, not only for organizational purposes but because we want the ability to only refresh the parts of the UI that need to be refreshed.
The intro to Backbone is probably a good starter on the topic: http://backbonejs.org/#introduction
Check this article, there is well explained how a modern web application should looks like in the client side, server side and the communication between them.
By the way:
Client side -> Ember, Angular, Backbone, Knockout.
Server side -> Django, Node, Rails
I just recently got introduced to MV* frameworks and have taken a chance to try out Ember.js with the TodoMVC app tutorial they have on their site.
I was considering using Ember for one of my upcoming projects (a Ruby on Rails CRUD app, similar to Twitter in some of the functionality), but I'm still a bit confused and before I take a final decision I would love it if somebody could clear the following concerns:
Is it a good idea to use such an advanced framework as Ember for a medium-sized multi-page CRUD app? Will it improve development time and maintenance compared to an interactivity layer built with jQuery's DOM manipulation and AJAX capabilities? Or is using Ember (and the like) only good when developing complex single-page apps (e.g.: Grooveshark)?
Considering the app will be developed using Rails, and assuming Ember will be used, is it going to be possible to offer a fallback with basic functionality for browsers with JavaScript disabled and/or for search engine crawlers? Will it require code duplication or other dirty tricks? Do you know of any technique that can be used to achieve it?
Will it be possible to adapt the website for mobile browsing (using only CSS) with valid results, or will the overhead imposed by running Ember on the phone make it hard for the device to render the website in a way that keeps it responsive?
We're in the middle of a pretty big Ember project right now, so here are my thoughts on your questions.
We've found Ember to be really productive for creating rich UIs for our single page app, but I don't know that it's going to be that much more helpful if you're creating an app designed for traditional multi-page (viewing pages, submitting forms, etc) layout.
I think this is the clincher - Ember is completely JS-based, so if you need to support browsers without JS, you'd basically have to write a parallel application. If this is a hard requirement for your app, I think Ember (or any MV* JS framework) would be out of the question
We've had very few performance issues on mobile - our site is fully responsive and renders on everything from Blackberries to the latest Chrome on desktop with good performance.
#Scott Rankin, has addressed most of the concerns with going with the Pure Ember approach. I'll add one quick way to make this decision.
Go with Ember/MVVM if the application is behind a login. Then you don't have to consider search engines, as the content is generally private and not supposed to be indexed.
For SEO you have to build atleast part of your content such that it is indexable. A good example of this is the Discourse application. They use Ember but also send down some generated html along with the app html slugs, so that search engines can index them. You can read about their approach here.
We have a different approach which can be seen as a fall back: We pre-render a static version of each page in the application (daily scheduled task). This static version is stored on the server as HTML file. Whenever we sniff as spider/ robot user agent, we deliver that version.
I'm looking to create a cross platform Mobile App and have been looking into Developing using PhoneGap. I'm an amateur programmer and most of my knowledge is in ASP.Net and C#.
Will only being able to use HTML, CSS and Javascript with PhoneGap limit me to specific functionality of my App? and would migrating to HTML5 help in adding more functionality to an App?
I'm looking to be able to Populate Drop-Downs from a Database, Add/Edit/Delete Items from a Database, Create Reports Ect...
Your only real limitation as far as data access goes is that you're limited to an SQLite database, which to be honest isn't much of a limitation since it performs great for single-user access.
The short of it is that you have access to a database from within your app, so you can do whatever you need to. The tools are HTML & JS as opposed to C# with some graphics layer, so doing things like creating graphs is quite different, but it's all possible.
Also note that depending on what your app is doing, PhoneGap is one of several solutions. If you want a "native" look/feel, consider TitaniumUI -- it takes common code (still JS) and pushes it through some translation layers to create native UI components.
I often find myself wondering what is the best way to do a JavaScript based web application. The server may be PHP, Perl or whatever -- but when the client-side is ExtJS or something similar, how do you construct your application? What is the work flow exactly?
For example, how is the authentication handled? In a current application I am developing, I have an ExtJS viewport with a login screen component in it, when the app is being run, it does an AJAX callback to the server to find out whether it's authenticated. If not, I show the login part -- else I show the application viewport. And then depending on the URI hash (e.g. #page=settings&subpage=ui) I run automatically certain components and events in my system.
And what do you do with the back-button. Currently I have a timer that checks if the hash has changed, and if so, I run the new action based on the new hash.
I am interested in any application work flow or logic that you have to share with me -- or any resources you got. I feel like JavaScript based application development has not matured enough yet, because there is almost zero blogs, tutorials, articles, whatsoever talking about this kind of stuff.
One option would be to leverage some of the capabilities of popular frameworks such as Spring MVC. Spring has the ability to handle workflows.
Spring Webflow Introduction
The whole point of a web application is to have your business logic happen on the server-side and not the client. JavaScript can be pesky enough to debug on it's own. Things that are business-logic heavy is best encapsulated in it's own tier of your application.