It is not clear to me how to use Polymer for implementing the backend. What is the natural way to process the backend for Polymer? Please show brief sample code to be clear.
As mentioned, Polymer.js is a front end library, specially to provide access to Web Components APIs as they are called.
There is no particular way to make a web request, in fact, though there are elements (iron-ajax) that can help, really you are on your own.
Given that polymer is mostly here to provide early access to Web Component development (and use), personally I decided to use fetch, the coming (low level, at least) standard for AJAX in Javascript.
Here is a link to a polyfill for the fetch API.
https://github.com/github/fetch
IOW: you are on your own making an ajax request, use the Fetch API or some other library of your choosing.
Then you build a RESTful back end and it doesn't matter what sort, though it's common to use Node.js with Express.
Related
I'm new to Node so maybe someone can help me in this decision, I want to create RESTFul API that are accessible from a web site and from mobile application returning JSON response.
I have decided to use the same API for the website and for the mobile applications for a maintain purpose, I went from a disastrous platform where the two logic part were separated. Also I want to use only RESTFul API without session for a scalability purpose, using an OAuth2 authentication and maybe Memcache to serve same JSON response thanks to the hash algorithm used.
I begin with Node+Express.js+MongoDB for the backend, but I have noticed that Express come with a lot of package to control and use cookie, template engine and so on...
So my question is: Express.js is the right package for my purpose? Or is better to not use this Framework? In your opinion what is the best way to achieve speed of access and speed of serving without any type of session and without any type of cookie?
I developed some RESTful APIs with Express. The good thing about Express is that you don`t need to use all the additional stuff like session handling and template engines.
In addition there are some really good modules that enables you to set up an API very fast.
For example if you are using mongoose have a look at Baucis.
If you still feel uncomfortable with Express, there are many other node.js frameworks for building RESTful APIs. Maybe give Restify a try?
Restify is somehow like a specialized version of Express, so it is really easy to migrate existing code.
You can go for Strongloop as well. Strongloop is a wrapper on express, but it has many features which makes it very powerful for building RESTful APIs.Please check this link https://strongloop.com/
I'm wondering when it is useful to use moustache.js (or something similar which do js templating), and when I can use backbone.js (which uses js templating inside it)
I've a web app with multiple pages, a json app, and the pages data are loaded via api calls, so I've tought about using moustache to clean up the rendering, but I'm wondering if backbone will improve something in my case
As already mentioned, they do serve completely difference purposes. Moustache being a templating engine, and Backbone bringing the MVC paradigm to Javascript. To quote from the Backbone homepage
When working on a web application that involves a lot of JavaScript, one of the first things you learn is to stop tying your data to the DOM. It's all too easy to create JavaScript applications that end up as tangled piles of jQuery selectors and callbacks, all trying frantically to keep data in sync between the HTML UI, your JavaScript logic, and the database on your server. For rich client-side applications, a more structured approach is often helpful.
So, if you find yourself writing a load of DOM manipulation calls etc. Or you simply prefer a structured approach to your code - you will find Backbone a godsend.
It is of course possible to use other templating solutions (other than the one bundled with Underscore) and integrate it into a client-side application created with Backbone.
Both cam be use together,
To build web application architecture you can use backbonejs.
and to render templates you can use mustachejs.
First of study basic knowledge about both.
You will well understand when to use what.
I'm building an ASP.NET MVC application that is client-script heavy, it will use JSON and jQuery to manipulate the DOM.
My understanding is both Web API Controller and MVC Controller can return JSON.
Given my scenario, should I use a Web API Controller or an MVC Controller?
Web API Controllers can be created and hosted in any ASP.NET Application, not just MVC applications. Thus, an obvious reason to create a Web API is if you do not have an MVC front-end (e.g. classic, RESTful web-services hosted by your company/organization.)
MVC Controllers typically rely on the MVC Framework, if you look at default templates and most of the work done by the community and your peers you will notice that almost all MVC Controllers are implemented with the View in mind.
Personally, I use MVC Controllers when I intend to respond with a View(), and I'll use a Web API for anything that isn't dependent on a particular view.
There are caveats, of course, but generally speaking if you don't require the Model Binding behavior of MVC, your service is data-centric, and operations are Data-centric (e.g. CRUD operations) then you likely want a 'Web API Controller' instead of a 'Model-View Controller'. Conversely, if your operations are View-centric (e.g. delivering a user admin page to the user), or you need MVC's Model Binding to generate 'ajax partials' (very unlikely), then you will want an MVC Controller instead.
Personally, I use Web API controllers for driving JSON-based RESTful clients, I use MVC controllers for handling basic browser routing and delivery of the SPA.
WebAPI is for making an API. If you want someone to be able to consume your API in XML, JSON, etc. You can make a web api.
In your case you only need to talk to client in JSON.
Even though your website is mostly client script driven you would still be using ASP.NET MVC Controller right? And since you may have already logically divided your controllers based on entities then it make sense to add those json serving methods in it as opposed to making another class specifically for web api.
So for your particular situation (if i understand correctly), I would stick with Controllers.
The answer boils down to separation of concerns, fasten the creation of services and to rely on convention rather than configuration.
Controllers main responsibility is to work as a coordinator between view and your model but where as API's main responsibility is to work on data. In the case of API's conventions make it really easy to perform CRUD operations. Below is the mapping between CRUD operation and HTTP actions
GET : Read
POST: Create
PUT: Update
DELETE: Delete
So with APIs you do not have to create separate actions and attribute them with HTTP actions.
The only concern I have with ApiController is that it is site-based not area-based.
One site can only have one apicontroller subfolder for you to name your controller methods.
There are situations you might want to duplicate controller name in different areas :
domain.com/api/area1/controller1/
domain.com/api/area2/controller1/
I remember there are some custom code settings to be able to do this but it does not work by default.
I agree with Shaun Wilson's (top answer) answer but not sure why as I am just a bit confused and still trying to understand with the following (probably incorrect) premonition -
Use WebAPI Controller to deliver JSON data to the client so that the client can handle the view manipulation. This process doe NOT require a view but rather just a response back to whatever called the method (i.e. a javascript request) so that the client can handle any client-side manipulation.
Use MVC controller when you need to use the data to manipulate a view during or right after page_load (i.e. not for SPA apps).
You see, I just don't know how I am incorrect here and am confused because the last line of Shaun's answer states "I use MVC controllers for handling basic browser routing and delivery of the SPA."
- perhaps I do not fully know what a restful client is when I assumed it could be JavaScript method that receives an response in JSON form. this is the closest post in Stackoverflow that was remotely related as an answer to my question so I'm answering this post instead of possibly duplicating questions.
In this scenario, I would recommend WebApi as it's perfect for transferring data such as this based upon Javascript requests. I will usually develop my WebApi controllers so that they return a JSON friendly object that can then be parsed easily by my Javascript.
The only real time where you would want to use an action on an MVC controller for this sort of thing would be if you wanted to generate some HTML and replace segments of your page with Javascript calls.
For example:
You have a JQuery UI Datepicker that upon selection generates a list of radio buttons that represent events on the chosen day.
In this scenario, you could use WebApi to return some JSON and then generate the necessary HTML using Javascript but generally it's bad practise to create a lot of HTML using Javascript. It would be much better to have C# build up the HTML and then return it via a partial view as this way you are less likely to encounter errors with Javascript parsing. Not to mention it makes the HTML a lot easier to write.
In one of my projects, I have a very active classic ASP site with a requirement to integrate live event-based feeds as part of the existing UI. There is a plan to upgrade the site architecture to either MVC or MVP in the future, but this new feature must be implemented in the meanwhile.
I have decided to go with a WebSocket approach for this, as this is ultimately what we will want to use in the future, and rebuilding this doesn't make sense. The question is, how to integrate this with the classic ASP "architecture"?
The site already implements the jQuery library, and was hoping to leverage jQuery's capabilities to create those streamed sections on a given page.
The current req's ask for this news feed to exist on every page. Thus, loading a new page will re-render the news feed, and should kick of from where it left on the last page. For this, I'm guessing a position indicator will need to be read (session variable I'm guessing).
Anyhow, those are the requirements. I was thinking of wrapping the the entire existing classic ASP site inside a MVC or MVP (C#/.Net) project to allow us to begin swapping out legacy features as they are developed, such as this one.
I would like to get some advice on some recommended approaches for this scenario.
Thanks.
I would do a SignalR app and integrate it in you old app.
It's easy to integrate ASP classic with ASP.net MVC. Just mix the projects and exclude *.asp from the routes
routes.IgnoreRoute("{resource}.asp/{*pathInfo}");
You will have some trouble in the root (/), but you can sort it with a redirect.
For a mixed authentication (if you need it) you will need to write your own authentication in MVC to use the same auth cookie that you use in Classic ASP. I've done this in the past with success.
I would like to know, what are the ways a web framework may be suitable for designing a RESTful app, in general.
One goal is for example to provide http request routing, so they are automatically sent to appropriate controllers. From architectural point of view, web framework based on MVC pattern are more suitable for REST.
What other features of web frameworks are helpful by building apps satisfying the REST constraints?
Is there any reason why you consider certain languages(python/java) or web frameworks(django/turbogears/jersey/restlets/...) as the most applicable ones?
I think the best way for a web framework to support a RESTful style is to automatically map the different HTTP verbs (GET, POST, PUT, DELETE, etc.) to corresponding methods on its controllers/request handlers. Most modern Python web frameworks do this out of the box, with the notable exception of Django (unless I missed a dramatic change).
a) You need very flexible routing.
b) You need to be able to easily generate links that correlate to resource controllers using templates and parameters.
c) The server should help you to parse all the http headers. e.g. Authorization headers, Accept headers, language headers, cookies, etags.
d) It should support serializing and deserializing all the commonly used mime types.
e) It should help parsing parameters from incoming URLs
f) It should help resolving relative urls based on the request url and any available BaseURL.
There are few ways that a web framework can NOT support REST. Its basically written with the HTTP model in mind; so just about any web framework works. The automatic routing you mention is a common expectation, but not strictly required for REST.
I would stress the ability to directly support definition of resources. In Ruby on RAils you can define a resource through scaffolding and you get a model with controller with restful verbs implemented also with views and support for different formats and readily avalaible views and routing with ids.
Aside from that having access to HTTP and supporting principles of HTTP is what you need.
I am not experienced enough to know about support in frameworks, but it would be also nice to have support for the caching and other request options.
On the “specific software recommendation” front, I've had people recommend Apache CXF as a framework for building RESTful services with Java. It appears to be even able to simultaneously support SOAP (which happens to be very useful for helping some of our customer base adopt the software). I'm still in the experimenting-with-it stage though, so you may be able to do better.