I'm developing a small data-crunching / visualization app in Sinatra, and am split between two options.
The functionality is that you:
Upload a file to the app.
See a nice visualization of its contents.
Maybe start over with a new file.
So my choices are:
Letting both views (upload and results) be managed by the same template, thus creating a single-page app.
Splitting uploads and the visualization between two pages. You upload a file to '/', then are redirected to that file's URL which displays the results.
Which one is better? The advantage of the first is that I can manage it all within the same page, by passing some local vars between the two views.
On the other hand, the second seems like the more RESTful option - because each uploaded file gets its own URL and can be treated as a resource (more fine-grained control).
So, if you want to provide a RESTful API as well along with the web application, it is good idea to have tow different routes.
If you are planning to have just a web UI, it depends on how much control you want to give to the end-user.
Nothing is wrong with either of the approach. It depends on how much ease you can provide.
Related
I am starting to write my first web app with Node.js and Express. I have two approaches in mind.
Create two sets of routes. One that sends JSON, one that renders the page using a templating engine
Create a static website that makes API calls to the backend using AJAX, and have only routes for the API.
I understand that approach #2 depends on AJAX support in the browser, but if this was your project, based on the advantages and disadvantages of each approach, which would you choose and why?
If I am reading it right, both options #1 and #2 first set of routes is an API that returns JSON rather than sends it.
Assuming that in #2 you wouldn't create static pages with JavaScript doing AJAX calls, but rather still use express static routing like app.use('/', express.static(path.join(__dirname, 'dist'))); the difference between 2 approaches isn't that big.
Unless you already know some supported template language, such as mustache the cons are that you have to learn one and before that pick one (which isn't always an easy task from my experience!).
If you don't know one, depending on your application, you might still benefit from learning and using one. As an example you can think of a very generic UI where a single template could be reused very many times - like a generic database UI similar to, say well known phpmyadmin.
In case of static routing, you can achieve similar results by using a JavaScript framework which has components or templates, such as angular. If you aren't planning to use one, that could result in a lot of code duplication of otherwise re-usable widgets. And even when using one I can imagine a case when template engine would result in less code (or less files in your project at the very least). Not sure though if it's going to be easier to navigate and moreover to cover with tests when the project grows.
Without knowing more about your project it is hard to give more advice.
If the product you're developing is primarily static content with some dynamic pieces here and there, I'd recommend serving HTML from your backend via a templating system. A good example of this would be a blog. You'll end up with better SEO and there are less moving pieces to grok in this approach.
However, if you want to develop a single page application, I recommend using your backend entirely as an api, and writing your client side logic entirely in React/Vue/Angular/whatever. Single page applications have their front ends written entirely in javascript, and are best suited to highly dynamic, "app like" experiences online. Think gmail or facebook.
In my current project we use both approaches. Many views are static and data is obtained from API calls (we just use angular) or bootstrapped values (we load some objects with template, like user roles etc.)
However, some views are rendered on server site, because it easily allow us to dynamically inject values, tokens or other supporting data without making extra requests.
So, I vote for flexibility
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.
I used to utilize MVC 3 Razor engine to render pages. Sometimes I had to use AJAX calls to transfer Razor-rendered HTML and inserting it into the page using JQuery. As new project is starting, we do consider to utilize MVC 4 Single Page Application framework which is new to us. I took the first glance at it which left me with mixed feelings:
On the one hand it implies all your data are transferred by JSON and client does all the job to render them and encode some UI-related logic which is great for server and network performance. On the other hand the client (HTML+JavaScript) becomes much more heavy with a bunch of magic strings and hidden relations inside it which seems to be hard to maintain. We got used to VS intellisense, type-safed .NET server code to render pages which we have to exchange for client scripts and Knockout binding statements in case of SPA.
I wonder are any prons and cons of using SPA comparing to Razor, other that this obvious one I've mentioned here? Thanks
Razor is a server based technology where SPA (Single Page Application) is an architecture approach used on the client (web browser). Both can be used together.
From a high level, SPA moves the rendering and data retrieval to the client. The web server becomes a services tier sitting in front of the database. An MVC pattern works best when using SPA. Frameworks like Knockout.js and Backbone.js can be used for this. The net results is a rich responsive desktop like experience.
To achieve this you'll need to be a descent javascript programmer or be willing to learn javascript.
Yes it's moving business requirements from C# into javascript. In Visual Studio there is limited intelli-sense for javascript. To have confidence in your javascript you'll need to lean on unit testing. The up side is the rich user experience (think gmail or google maps).
I think it sounds like you are already fairly well apprised of most of the trade-offs here; you'll have reduced network load with SPA, and will shift a measure of the processing to the client. You will, however, increase the complexity of your code, and make it slightly harder to easily maintain the system (simply because of the increased complexity - not due to any architectural problems inherent in SPA).
Another thing to keep in mind is compatibility. The reason I mentioned a "false choice" in my comment to your question is that to keep the site usable for folks with Javascript disabled, you will still need to provide regular, whole-page views. This is also a good idea to do for the sake of SEO; a crawler will browse your site as a user with JS disabled, and can then index your site. The site should then handle such incoming URLs properly so that those with JS enabled will find themselves in your SPA looking at the same content (as opposed to being dumped in the "no JS" view unnecessarily).
There's something else I'll mention as a possibility that might help with the above, but it breaks the ideals of an SPA; that is, using Ajax-loaded partials in some places, rather than JSON data. For example, say you have a typical "Contact EMail" form on the site; you want that to load within the context of the SPA, but it's probably easier to do so by loading the partial via AJAX. (Though certainly, yes; you could do it with a JSON object describing the fields to display in the e-mail form).
There will also likely be content that is more "content" than "data", which you may still wish to load via partials and Ajax.
An SPA is definitely an interesting project, and I'm about to deploy one myself. I've used a mix of JSON and partials in it, but that may not be your own choice.
We are developing a web application with ExtJs 4 and Microsoft RIA services + MS SQL Server on the back end. Currently some of the records we store in the DB have attached images to them. Images are stored in binary format in the DB.
What would be the best approach to:
Display them within ExtJs framework
Allow users to upload images via same ExtJs front end
I looked through ExtJs docs and looks like we would need to provide images as basically individual files and use simple img tag for that. Is that correct assumption? Are there other approaches to render images from binary data (which we currently serve via JSON endpoints)?
Is there samples handy for image upload logic?
ExtJS will give you a framework for getting the images via forms to your back end, but what you do with the images from there is completely ExtJS independent. Displaying them within ExtJS is completely independent of the back end logic as well. It's just a matter of finding a way to pipe the data up to the browser just as you would if you were writing a normal HTML page.
I'll take the answer one step further and mention: Storing images in the database is generally a bad idea. At least, storing them in a relational database is generally not a great plan. If I couldn't use a database like Riak (or Amazon's S3) for storing the images, I would probably follow Diodeus' comment and put them directly in the filesystem.
I don't even know if this is even possible, but I thought I'd ask.
I am creating a small CRUD application but I have multiple sites. Each site would use the CRUD. The application would have common CRUD methods and style, but each individual site would apply different forms. I want to avoid creating multiple CRUD applications that varied only in specific content (just different forms).
I want to have something like this:
mycrud.website1.com
mycrud.website2.com
mycrud.website3.com
I can create a subdomain for each individual site no problem. But is it feasible to point all the subdomains to one MVC application directory? And if it is possible any suggestions for how I might go about restricting users from website1 from seeing website2 or website3 content? Is that something "roles" could take care of (after authenticating user)?
Thanks.
There are a lot of websites that do this, not just with MVC. Some content farms point *.mydomain.com to a single IP and have a wild card mapping in IIS.
From there, your application should look at the URL to determine what it should be doing. Some CMS systems operate in this manner, using the domain as a key to deciding what pages to load.
I've built a private labelable SAS application (Software as a Service) that allows us to host all of our clients in a single application. Some clients have customizations to pages or features. We are able to handle that by creating custom plugins for each client that over-ride the Controllers or Views when needed.
All clients share a common code base and aside from each clients custom theme/template they are the same. Only when a client had us customize one feature did we need to build out their plugin DLL. Now, this is advanced stuff so it would require heavy modifications to your code base but in the end if it's what your application needs it is 100% possible.
First - the easy part is having one web site for all three domains. You can do that simply with DNS entries. No problem. All three domains should point at the same ip.
As far as the content, you could do that in a number of ways. I think your idea of roles is pretty solid. It also leaves open the possible of a given user seeing content from both site1 and site2, if that would ever be necessary.
If you don't want to force users to authenticate, you should look at other options. You could wrap your CRUD logic and data access logic into separate libraries and use them across three different sites in IIS. You could have one site and display content based on the request URL. There's probably a lot of other options too.