How i could bind Spring DATA REST which outputs HAL, with ExtJS (v4.1) client, ExtJS do not have support for HAL, but how i could integrate libraries like Hyperagent.js or any JS library supporting HAL, with Extjs data model, to link Stores with the server through HAL.
Whats are the pros and cons of a such architecture ?
This is a very interesting question. There is not much information about how to connect ExtJs to a backend. I didn't find myself the information I was looking for when I started to develop a custom backend for an ajax proxy. I can only write from my limited experience a certainly biased answer, and I hope you will get other answers from different point of views.
I started with the idea to write a generic, standards compliant, client agnostic, RESTful API that exposes the tables in the database as they are. Finally, I ended up with a highly ExtJs specific backend, that implements many features that I perceive as they'd rather belong to the frontend.
What ExtJs imposes on the backend
ExtJs has a rigid relationship between the views and the stores. A view is bound to a store that is directly tied to a backend. That requires that the backend has to serve the data as it will be displayed in the grid. What really misses ( and this has been alleviated to some extent by ExtJs 5 ) is the ability to create a store out of the data of another store. This leads to an obligation to expose the data in a customized way related to the final view ( we already loose separation of concerns between the API and the application ).
This goes further when you want to use features like paging, remote filtering or sorting. If you have extensive data at some point you will have to because of performance issues. The way ExtJs sends the parameters for paging ( by the way this is enabled by default ), sorting and filtering looks peculiar to me, and I think this will require you to adapt your backend for ExtJs at this point. If you use filters alot, you will even need to configure them in the backend, because filter properties like starts with vs contains and case sensitivity make unfortunately not their way to the server. Again a presentation element more introduces itself into the backend.
ExtJs 4 has only a limited support for associations ( and it is not compatible with version 5 ). Advanced features of REST like the ones explained in the post linked by #Jaimie are not supported by ExtJs. ExtJs has a flat approach to REST, each table has its own endpoint. There is a way to send data from a linked table in a tree-like data structure, I wasn't able to get it work, but if you implement that you'll end up with another ExtJs specific feature in your backend.
My current approach
With all these requirements from ExtJs's side, I felt forced to write something really ExtJs specific. What I tried to avoid in the beginning is now the force of my backend : specificity.
I have a class that implements crud operations, paging, filtering and sorting for any mysql table, all secured with authentication. It does exactly what ExtJs expects it to do.
I can create a subclass for a table to allow finer grained control :
authorization using an ACL
serve a join or a view
extended validation before update or delete
custom filters
send notifications via a websocket for special actions
expose any data as a table ( e.g. list of files in a directory )
Conclusion
As you can see, the backend has very powerful features and is quite far from a mere data provider.
It is not an answer to your question about how to integrate a HAL REST api, but somehow it answers the pro and cons part : ExtJs has such specific requirements on its backend that without implementing them you would loose too much functionality. Modify the way ExtJs connects to the server could be an option, but I don't know to what extent you had to rewrite the code. It could require an important investment.
Related
My project would be a kind of craiglist, a site where users could post anouncements (evereday-life objects, cars, flat etc.). So, authentication, profile page, content creation, display the for-sale objects etc.
I have developed a very large part of the backend: I have a RESTful API in three-tier architecture developed in java. It makes the link with the db, to provide me with different urls and send me the relevant JSON.
URLs example:
http://api.mywebsite.fr/user?userid=1 sends me back:
{"user": {"username": "jdoe1234", "email", "jdoe1234#gmail.com"}}
I have urls for all actions performed on the entire site (anouncement creation, last data updates ... everything, and I've carefully declared them POST, GET, UPDATE, DELETE, etc.). There is also oAuth to protect the API from queries that are not allowed for the token.
That's all for the "server" aspect, I think that there is no problem with that.
But if all the actions are managed by the webservice, I do not see the interest that could bring me a big server-side framework like Symfony/cakePHP, Zend, etc., to make HTTP requests on my different entry points, retrieve JSON and populate the HTML.
So I looked at client framework, like Angular, Ember and so on. At first, it seemed very suitable for my case: possibility of http requests, manage what to do in case of success or error, directly exploit the resulting JSON to populate the view etc.
I didn't even manage to make my choice between angularjs and Ember, both being very similar, but with the release of Angular v2, I fear the maintainability of v1 (if I choose Angular, it will be v1 , because the majority of tutorials and questions relate to Angular 1.X).
I don't know if I'm doing the right thing by choosing client-side framework, I am afraid that they 'brident' (not sure of that word, sorry) me. Plus, it's fully instantiated in the browser, so the user can change absolutely all code and data I provide. That seems weird to me.
I want to be absolutely sure of the technology that I use in case I make this application available to the public for example. I want to do things properly, in order to avoid maintainability or security problems.
Summary: With the things I already have (webservice / api), is it a good idea to use a client framework like Angular or should I stay on big server-side framework like Symfony/Zend etc? Knowing that I position myself in the context in which this platform would be massively used (craiglist comparable traffic).
I'd say - depends whether you want to be more frontend guy or backend guy in future. If you want to be full stack developer then it doesn't apply.
In my opinion, both Symfony/Zend or other big server-side frameworks aren't so exciting as dynamic frontend JavaScript frameworks like Ember/Angular/React.
Also, if you have already RESTful API and OAuth authentication implemented in backend part I'd go with Ember. Why? Ember Data is great tool for talking to backend API. It's mature, it lazily loads records when they're needed and it's very customizable.
it's fully instantiated in the browser,so the user can change
absolutely all code and data I provide...
Ember has built in security like sanitizing data which is rendered in it's templating language - HTMLBars. Also, there's CORS and content security policy (CSP) standard which is implemented in Ember.
I want to be absolutely sure of the technology that I use in case I
make this application available to the public for example. I want to
do things properly, in order to avoid maintainability or security
problems .
In Ember you can create mature, secure, production-ready applications, but you need to comfortable with your Ember skills to some degree to build such ambitious web application, but it's part of building every application.
With the things that i already have(webservice / api), is it a good
idea to use a client framework like Angular?
Yes, it's very popular solution to use MEAN stack or go with Ember + RESTful API.
Why should I choose Ember instead of Angular (which have a larger
community/tutorials/answered questions) ?
Angular has larger community/tutorials/answered questions, but when I started some side project with Angular to learn its possible advantages over Ember, I was surprised how there was no consensus in it's community for doing one thing. So, instead of fast search how to declare and use directives (I think it was the thing that confused me) I have to do another research which way is the best. Also, there are lots of ways to setup project (where to put custom directives, different Angular objects) and you have to do another research which one to choose. I ended up using repo healthy-gulp-angular as my template, but you can see it hasn't been updated for 8 months, but I think during these 8 months Angular had a lot of changes and I'm not sure if this repo is the best choice.
In Ember you have Ember CLI tool which is built with Convention over Configuration principle. You have also Ember Data which utilizes JSON API standard - if you don't have JSON API compliant server side right now, you can write custom adapter to normalize server responses or change how backend replies. In Ember you don't have all that headache and different best solutions to do 1 basic thing depending who you ask.
What means "Single page application" ?
Single-page application is basically a page which doesn't have to reload all assets and HTML when you navigate. It's advantage over PHP - when user moves to another location he downloads only new data for that route. More info here.
Does those frameworks allow me to create real routes ? (
www.myapp/profil/userid etc )
Yes, of course. You don't even need # in your URL. With simple rewrite rule and small amount of logic for profile route and specified path profile/:userid, when user will open URL www.myapp/profile/userid he will be automatically taken to profile route, and userid would be interpreted as route parameter, so you can take this userid and find user record from the store in model hook.
Client = speed, Server = stability
JS frameworks updates once per week
Non-Js back-end once per year
Client side depends to behavior depending on browser
Back is related only on machine but not on environment
I chose FE coz I tired to debug code by writing variables values to database to actually see what is going on in controllers -_-
Breeze JS is only supported in net 4 or 4.5?
can i use breeze only in client side and my server is .net 3.5.
I am using ADO.net as datalayer and not using Entity Framework.
Will I miss any of the features of Breeze JS if i use .net 3.5?
I had seen many articles with Breeze JS and MVC.
How this can be done with .net 3.5?
Any suggestions will be appreciated.
To support the BreezeJS client, the server should do 3 things:
Provide metadata to the client
Interpret queries from the client, and respond with data
Save changes that come in from the client
All three of these are provided in .NET 4.5 by the EFContextProvider (for Entity Framework) and NHContext (for NHibernate). You will need to find a way to implement these for your solution.
Metadata: Can be written by hand or even generated by EF at design time (even if you aren't using EF at runtime). If you just need metadata for your project, you don't need a general-purpose metadata generation tool.
Queries: Can be as simple or complicated as your application requires. Filtering on a single field, sorting, and skip and take for pagination, may be sufficient. You can implement most everything as parameterized queries, so you don't need to parse the URL. This limits the types of queries that you can perform from the client, but it may be all you need.
Saves: Breeze "save bundles" are an array of entities, each with an EntityAspect than tells you what type of change it is (Added, Modified, Deleted) and what fields changed.
You will need to apply these operations to the database. Note that the order in which they are applied is important
(parent records must be added before child records, child records must be deleted before parent records).
In EFContextProvider, a lot of this work was done by EF itself. In NHContext, the queries are mostly taken care of using NH LINQ,
but the metadata generation and save handling had to be written in Breeze.ContextProvider.NH. You can look at the code on github for inspiration.
Also look at the NoDB sample, which doesn't use EF or NH.
Please let us know what you come up with. Breeze without an ORM is an interesting topic.
We are attempting to create a few dashboards for one of our Businesses, fetching data directly from the SQL server. We know what kind of business logic & display we'll like to do - having already built the prototypes from SQL data exported in Excel, and now - having prototyped their wireframes as well. The dashboard will include dynamic timeline based line & bargraphs & geographical map overlays.
We are trying to identify the best platform to do it. Here are the constraints:
The database is SQL based
The frontend should be browser accessible - hence a pure desktop application is ruled out.
While for the first usecase, the database is MSSQL - we'll like the platform to be say PHP based (or Python etc, but not ASP.Net)
Prefer to have the platform giving the option to host it on our systems (since our database server may not be online, but behind a company LAN - and hence not accessible from any public server, without port opening, etc), as opposed to it being only on online SAS.
Now, we are trying to architecture pieces. One approach is to have a technology stack consisting of:
Database - which we can live with what we have (our data isn't large enough to require anything beyond SQL).
An application logic framework (preferably MVC), along with a good set of libraries for Analytic applications (eg processing time series, statistical analysis - or some glue logic for calling, say R).
Frontend JS / HTML libraries. For this, we have looked at GoogleCharts, HighCharts, Paper.js, Raphael, Angular.js, D3.js, and new Razorflow. We haven't yet been able to figure out the best options amongst these.
Any suggestions / comments for the JS libraries (point 3) to use? And if in PHP - suggestions for good application framework + analytics library (point 2) to use above? Or if not, another language along with a good supporting framework for this?
Another alternative we're exploring is moving to a completely UX based dashboarding - eg qlikview, Tableau, or klipfolio. kibana - on the same lines looks interesting, but seems more suited for logs & text data, not exactly our use case.
Within the Microsoft world (we are trying to avoid), devExpress seems like a complete suite - with frontend JS to the backend database integration.
Any suggestions / comments on the right platform to use?
Arvind
I am the co-founder of RazorFlow. Are you still looking for a dashboard framework to use among the options listed? Our PHP Bindings are quite powerful allowing you to build your entire application in pure PHP and not worrying about the HTML/CSS parts of it.
Let me know if you want to discuss further by reaching out to our support email at support -at- razorflow.com
For a team of pure UI developers, without any idea about how oData service is implemented (a UI team without any dotNet knowledge/experience):
How can we make sure that the backend oData service layer will work fine with our BreezeJs frontend/UI code?
Is it important for BreezeJs javascript coders to have backend odata implementation knowledge?
Is there a way to validate/certify that a given URL/odata service point can work fine with BreezeJs?
The reason I ask these questions is:
With our backend oData service implementation, we find oData url/services accepting POST method for update and delete operation. This is, in my opinion, incorrect from REST conventions.
Our oData url/services also accepts some special headers like X-HTTP-method with values like 'PUT', 'MERGE', etc.
That is why I ask: should breezeJS coders have odata backend implementation knowledge?
Our edit/save operations are not getting sync'd with the backend by BreezeJs. However, our read operations are working fine.
Please note: we use AngularJS along with BreezeJS. We want to use the databinding between AngularJS and BreezeJS entityManager for all sync'ing.
The other answer is uninformed and incorrect. Breeze follows the conventions you tell it to.
Breeze is highly configurable to use whatever back end technology you choose. If you choose to follow RESTful conventions when naming your service endpoints then have a quick helper service on the client to construct those end points however you wish. I do it all the time. If you want to perform a checklist on your api services on whether they follow rest conventions by all means let the backend team do that.
You do have to know what parameters your services accept and the manner that they are accepted.
For the record, PUT and DELETE are not currently in the Html 5 spec as they are inconsistent. Using POSTs for adds and deletes is more secure and browser compliant.
This is a common problem when 2 teams, one pure front, one pure back, are working on the same project.
If you use REST, you adhere to conventions so that Fronters/Backers knows that they speak a common langage.
If you use SOAP, you can define an XML file that act as a contract between the two worlds.
BreezeJS do not follow REST conventions, neither adhere to a contract, and following the docs might not be enough. So the answer is : yes, you have to know the backend implementation, and add robust integration tests to ensure that communication happens with no surprise.
I want to develop a relatively simple application that calculates some value based on several inputs. I dont want a backend, all the calculation can be done in the browser.
Im a little new to JavaScript and WebApps and I came across Backbone.js.
I really like the MVC design, however, they mention a backend a lot. My question:
Is a backend server absolutely required?
Is a backend server optional but without one there isn't much point in backbone.
Or will backbone will really help me out?
Backend is not required.
Backbone can fully work without any backend if your application doesn't require one.
That depends on your application. If you want to retrieve value of some inputs and calculate a result then Backbone won't do that for you - it will help you structure your code. If you app is simple and don't need support for models, views and collections or routing, then there is no point in using Backbone. Hard to answer this question.
For example: Classic todo example application doesn't use any backend.
Backbone.js implements fetch(), save(), destroy() etc. methods on models automatically performing appropriate AJAX requests and parsing response. So it has a strong support for backend via REST services, but it is optional.
You can still use models, views, routers and events without any server-side code. Just don't call REST methods (or override them at your wish).
You can use localStorage for persistence (you'd have to implement this yourself or find it on the web, like here) but if you don't even need that then you don't need to use any of the persistence methods in backbone.
Backbone is meant to help you structure a medium-large sized application (js-wise), so it doesn't become unmaintainable jQuery spaghetti. With short applications (js-wise) it's really an overkill unless you are trying to learn how backbone works.
Note with js-wise I mean the client side code, if you had a huge backend but the only js would be something that focuses some form, it would not even count as a short application (js-wise).
You can use backbone.js without a backend. However you obviously won't be able to store or retrieve data. Backbone may still be useful for keeping your code organized, however it really shines when you want to separate presentation logic from logic that manipulates your data, which is a goal of the MVC pattern. Generally your data will be stored on and retrieved from a backend.
If you want to play around with data persistence, try out backlift.com. [disclosure, I work on backlift.com] We've tried to make it easy to get a backbone app up-and-running without having to setup a server or deal with compiling templates.