I'm wondering if a server exists to translate the JSON (or other format) feeds from existing web services into what the frontend expects.
For example, currently my backend team sends us JSON feeds and they doesn't always meet what we need. We could file requests for them to change the feed, however, this might not be compatible with other teams and if nothing else would take time. It would be ideal for them to make all the data available and have a layer that would translate it into what is most convenient for our frontend code.
Does something like this exist?
Clearly I could roll my own or build code for each service, but I'm hoping a system like this already exists.
Not exactly an answer to your question, but I was genuinely delighted to see how easily Angular binds data. We (our small company) have also been developing a framework that generates forms from JSON based on XML configurations, but the project's still pretty much an infant.
Related
I'm working on an Angular 4 front-end for an API built by another team. The API follows HATEOAS and provides me with hypermedia links with every single response.
I know the shape of the API and I figure I can just hard-code the URLs into Angular Services with minimal fuss. However, a colleague (who is a backend developer) is trying to convince me that I should take full advantage of the hypermedia because it will mean less coupling between the frontend and backend (and potential breakage if the API changes).
However, I'm stumped on how I'd even go about implementing a simple HATEOAS pattern using Angular's built-in Http service. How would I store/share the hypermedia/URL information in a way that doesn't couple all the services together and make them hard-to-test? There seems to be no examples out there.
Would trying to create a HATEOAS-friendly HTTP client even be a good idea, or is it likely not worth the trouble?
Your colleague is right, you should use the meta information that the back-end provides. In this way you are not putting responsibility on the client that doesn't belong there. Why should the client know from where to fetch the entities? Storing the entities (in fact the data in general) is the responsibility of the back-end. The back-end owns the data, it decides where to put it, how to access it, when to change the location or the persistence type, anything related to storing the data.
How would I store/share the hypermedia/URL information in a way that doesn't couple all the services together and make them hard-to-test?
Why do you think using HATEOAS makes the testing harder? It does not, in fact not using it makes the testing harder as the URLs are static which makes the back-end non-stub-able.
You can extract the information from the back-end response and store it as meta-information in the angular model, on a _meta key or something like that.
So I am new to web development and all I've learnt so far is how to write HTML and CSS to make web pages and forms.
I'm specifically looking for a language that will help me store the data that is input into the form onto a database for easy access later.
I think PHP does that, but I was looking for anything JAVA related, and somewhere I could learn how to do it.
So far,
I've looked into JavaScript tutorial on W3Schools, but it seems like JS only helps make the front end more dynamic, but doesn't help store the input data anywhere.
I've also looked into the AngularJS tutorial on CodeSchool and it looks like Angular helps present the forms in a better manner and again, not in storing data anywhere.
Once again,
1) What do you use to collect the data input into a HTML form and store it somewhere?
2) I don't need help making the actual form itself.
Me personally, i use PHP, it allows you to take the data that was inputted and store it in a database. You can also use JavaScript/JQuery with PHP via Ajax that will dynamically fetch and store data.
Any backend lang can do it (python, php, java, ruby, js with node), but each one has it own ways to do it. Even JS at client side can do it, using LocalStorage objects, but it not solve all problems at data storage yet.
Angular is just the client-side. You will need a server, which will handle the requests and store them into a database. I would work with Spring Boot (JAVA) on the server side, and Angular 2 on the client side. Use REST for the communication bewtween them. Its really not hard.
Node.js is a fast Javascript runtime combined with a low-level API similar to the standard libraries of many programming languages (file system access, buffers, streams, i/o, etc.).
Angular is a model-view-controller framework for client-side JS development. It can be used with Node.js as a backend, or anything else. Its main feature is 2-way data-binding, and addresses most of the concerns of a single-page web app within the framework.
React is often compared to Angular, because it is a front-end library, but it is not a framework. It is simply the view layer, with a large ecosystem of open-source projects supporting it. The big conceptual difference is a uni-directional data flow, rather than 2-way data binding. You need a lot more besides React to make a full application, but React handles it's use case exceptionally well. React is amazing on the client side, but it’s ability to be rendered on the server side makes it truly special. This is because React uses a virtual DOM instead of the real one, and allows us to render our components to markup. Node.js makes a great backend for React as well, but again, it can work with any backend.
The MEAN stack is a popular web development stack made up of MongoDB, Express, AngularJS, and Node.js. MEAN has gained popularity because it allows developers to program in JavaScript on both the client and the server. The MEAN stack enables a perfect harmony of JavaScript Object Notation (JSON) development: MongoDB stores data in a JSON-like format, Express and Node.js facilitate easy JSON query creation, and AngularJS allows the client to seamlessly send and receive JSON documents.
MEAN is generally used to create browser-based web applications because AngularJS (client-side) and Express (server-side) are both frameworks for web apps. Another compelling use case for MEAN is the development of RESTful API servers. Creating RESTful API servers has become an increasingly important and common development task, as applications increasingly need to gracefully support a variety of end-user devices, such as mobile phones and tablets.
This was the overview of all the new booming technologies.. Based on this you can decide what you need and what you want to learn.. Thanks, Hope this overview helps you to decide.
My favorite for Rest Api is Flask(python micro framework) it is build for create Rest Api. and for php falcon has it own micro frame work. if you use nodejs it is easy to communicate between backend and frontend and good with not sql dB like mongo db.
The right answer should be the database or localStorage/sessionStorage.
The decision in between which answer chose, depends if you want to share the data between Browsers/Computers or if you just want to temporarily store the data for the user so he won't need to fill the form once again.
For temporarily storage chose localStorage/sessionStorage (javascript).
For other cases chose to store the data in a Database.
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 -_-
I have an iOS app in which I use parse.com as backend service. Now, I hired someone to do a website interface using HTML and CSS. I want to share the same data between iOS app and website, I know parse.com offers me a few ways to do this, including creating a javaScriptapplication. The problem is, my programmer doesn't have any experience in JavaScript, nor do I.
My question is: Is it possible to use what I have (objective-c, xcode) as far as retrieving data from parse.com and showing on website? Even if I need to code something new, is it possible to use objective-c together with HTML and CSS?
Thanks.
Parse has several APIs, one of which is REST. Your web developer should use the REST API to get data from Parse
https://www.parse.com/docs/rest
If there is will there is way, but you'll be making something really specific to your use and will be non standard and will be immediately hard to maintain, I recommend that you hire another developer and do things properly using the technologies given to you by parse !. if the cost will be high now I can promise you it'll be much higher if you went the path you're going to now.
So my answer is:
Yes, everything is possible and no, don't do it ! :)
Edit: Added an example to a possible way to do it to actually answer OP's question.
Example case:
1-Create a simple Mac Application in Xcode that fetches data exactly like you do it on iOS, and store the needed data into a database of your choice on your server
2-You now have access to the data you needed from parse, but on a local mirror. you will need some tool to fetch that data though, I recommend a simple PHP script.
Note that this will require an OSX server to always be running to fetch that data, you'll also need of find a way to fetch data on demand when a user needs it Vs. polling at specified intervals, this will hardly scale and will be costly as I said.
I'm planning to write a web app using either Backbone or Angular. We want to push "widgets" from the server to the client (i.e. semi-complicated, dynamic but largely autonomous UI elements... something maybe like the popular TodoMVC app). So we'll need to send over a template, some javascript (controllers etc.), probably CSS, and JSON data (models).
We're debating how to send over all the information. How much can be, and what should be encapsulated in the JSON?
Is it possible to create files out of data passed over? i.e. could we pull out CSS and apply the rules to our document? I believe it would be easier to run javascript passed over this way.
I'm under the impression that being able to cache the template is important... does that require loading it as a (separate) resource rather than as part of some huge JSON object?
As for CSS, it needs to be loaded before inserting into the DOM (so we don't want just a promise). Would it make sense - or even be possible - to pass our CSS rules in the JSON and extract them somehow?
EDIT: to more fully describe what I'm working with, I'm focusing only on the front-end. The back-end can be customized to send over resources however we want - they'll optimize that depending on what the front-end needs. Our backend stack includes MongoDB, Tapestry, ActiveMQ.
The payload that needs to get sent over will be all the resources necessary to push something like a Mac Dashboard Widget or Windows Gadget into the browser. So HTML, CSS, Javascript, data will all get sent over. We want things to be snappy and minimize server requests as much as possible, as some of these payloads may get to be somewhat large.
Your questions are rather vague and the answers can change by coding on a different build platform. Your chosen application design can also impact the best practices to follow for implementing X type of application to X device(s). There's more than one way to skin a cat ya know.
What information are you sending over? Is it a lot of raw data arrays? Is it more document based where XML could be more beneficial? You'll need to work with your DBA if the data is stored in a repository and you'll be querying it. Will you need to write code to format your data or will the DBMS output it in the format you need?
What do you mean the CSS needs to be loaded before being inserted? Everything loads in the order you specify so making sure your CSS loads at the proper time shouldn't be an issue. If you're using ASP.NET, you can also use a SSM (style-sheet manager) to serve your CSS and only load whats required. SSM's are great if you have a lot of style-sheets to serve.
A lot of the questions you asked will be answered as you get further into the design phase. In order to get some solid answers and not just speculation on what is the best method, you will need to publish a lot more details than this. Any answers at this point shouldn't carry much weight in your decisions. They certainly wouldn't mine.