I am looking at an angularjs 1.5 application that has a lot of ajax requests. To minimize the amount of requests to the server , I was thinking of using redux for ng1 but this looks like there is a lot of boilerplate that needs to be written first. I could not find any alternatives, what would be another way of storing jsondata locally available globally in your app?
There are many different ways to store data in this case, and you have to choose depending on the features you want. The most common ones are localStorage, sessionStorage, cookies, or just in-memory (like $cacheFactory). There's also sqlite and the browser http cache (which would just be for http requests, and is based on headers).
There are also many different angular libraries/packages that have abstractions of these storage mechanisms on github, npm, bower, etc that you can find by just googling.
Related
We are just starting to create a new product. We would like to use Django at the backend and Angular at the frontend to form a single page app. This means we would not be using Django's templating system at all (except for maybe the one necessary HTML file, but this one could be static).
Doing research we have come across the Django REST framework which offers REST functionality for Django allowing easy communication from Angular.
Since we are all more or less new to web development we asked a guy who is maintaining python packages. From his experience with the REST framework he suggested us to scrap the idea to use it since it would clutter up the code (serializers), would be slow, introduce other problems etc.
We are now thinking of using plain Django and designing the URL structure as REST-like endpoints for Angular. We would have one view method for each URL, then perform an action depending on the request type (GET, POST, PUT...) and return only JSON.
Is this a good idea? What would we lose in respect to using the REST framework? What would we gain? Will using Angular for server calls be at all different for any of those approaches?
I am not a fun of DRF but I've been using it in a couple of projects lately. The answer to most of your questions is application-dependent, that meaning size and type of your webapp matter.
For what I took away from using DRF it could give you a boost on:
Objects serialization (and validation): I think it's much easier (avoids typing) making the serializers thru' DRF instead of building them in Django. While models and querysets and usually easy done, if you need some more structured JSON response the DRF layer to support the serialization helps.
Permissions and authentication: being addressed to REST APIs there are good shourtcuts to provide security and restrict access to methods, both in terms of methods type and user permissions checking.
Plugins: if you have to deal (you'll probably do) with CORS and/or token-based authorization there are a bunch of niceties you can plug into DRF to get the work done. I am not sure it is that straightforward to put them in place direcly in Django.
That said the CONS:
If you start by using the high-level interfaces of DRF (Viewsets, Routers and the like) you'll eventually end-up refactoring a little bit to address specific needs for which you'll need more control over the code.
As Django is already a quite big ecosystem, DRJ adds'up to the steepness of the learning curve, probably slowing down a little the implementation, at first.
Don't know about the performances of the requests passing thru' DRF, but I wouldn't care that much unless your app has specific requirements. DRF wan't probably add up much on well-written code (...and queries to the DB).
These were my two cents. Hope it helps.
I have used django for few projects and used heroku to deploy. I have been looking into front-end frameworks such as Ember, Angular and was confused as to how it will integrate with a django project. Reading some Docs, it appears i need to have developed a REST api for my app using the backend framework in order for Javascript framework to communicate with the database. In this case the backend mostly works as a thin layer that provides access to the database. But what if I use something like parse and their Javascript API, would I even need a Backend Framework like Django?
How frameworks like Django will work with frameworks like Angular or Ember depends a lot on what you want to do with it and what your view on architecture is in general, so it's hard to give a one true answer. But in general no, you don't need one, but you still might want one.
You don't need one because as you surmised frameworks like this want a REST API (although it doesn't have to be specifically REST-like that is definitely the most common way of doing it), so you wouldn't be using Django templating or anything like that.
But one of the good part of using these frameworks, and the part that makes the question impossibly to answer, is that they don't care about the backend!
Why does this matter?
When backend and frontend is properly separated you get a great deal more flexibility on both ends. As long as they work with the API you can build them however you see fit. If you find Djangos ORM nice to work with you can use it to create the API. If you feel like using something super lightweight like Flask you can do that. If you want to host a Java app on AWS you can do that, etc, etc.
The key is that you can let your backend needs determine how you build the backend, and your frontend needs determine how you build the frontend. That's why the question can't be answered. You strictly speaking don't need Django or any smilar framework but depending on what the backend is going to do you might want some of the features from them, like the ORM or the general structure.
So look at what your backend needs to do in order to serve the API and choose based on that.
I am building a simple app that allows users to search for popular products in amazon by how much they are willing to pay by calling the amazon product api. I will probably only need 3-4 screens and won't have a authentication system.
Do I need a back-end framework? Or can I just use angular to make the api call and redirect them to the amazon with the shopping cart populated?
You can do everything in AngularJS on the front end. Which means you don't need a backend database.
However, like #MingShun mentioned, you do need some way of serving up your static files, such as your HTML, CSS, JS and images. But there are plenty of options for static file hosting out there, many of which are free or very cheap.
Context: I'm a beginner programmer, self taught in the hope of making a SPA. I've started with JavaScript, Jquery, PHP and MySQL, and now feel pretty confident with all. I've started with Ember, and am now moving away from having a PHP API to Node. Which has then brought me closer to Meteor... I'm aware I'll need to use Mongo instead, but having an integrated front and back seems to be sensible and have some advantages.
So my question is what are the advantages of having a separate REST backend API (eg Express) rather than an integrated front/back (eg Meteor).
One that springs to mind is that my app will be tablet/pc based, but in future I'll want a different mobile version, so I'd be able to use just use the same API. I'm conscious that the above question is the main concern with this stack question, but perhaps if a meteor developer could clarify whether this is indeed a concern.
Thanks in advance!
well for me you'll get a lot of advantages using a rest API, they are lightweight, extensible and overall reusable.
today it's a trend to use a vertical architecture that means having a RestFul service with a single responsibility, why because it scale better and it's easier to assign a team to an api, so that way you'll be able to manage several teams and apis in a very ordered way. This is probably how Twitter, wunderlist and other companies works, because it's a solution to scale better.
take a look to this talk by Raffi Krikorian he was the head of architecture of Twitter for a while is a little bit old but it worth every minute and to illustrate some of the advantages.
Also you can look at the diagram below, I did while ago it explains the differences between the MVC and API first type of architecture.
I've authored one rest app using angular and rest services and it has been a very nice experience to me there's no way back.
good luck
Meteor doesn't really "integrate" the front (client) and backend (server) as you describe. It still maintains them as two separate layers. The beauty of meteor (aside from the insanely awesome reactivity) is that it uses Javascript everywhere, instead of using JS on the client and some other language on the server, so you can use the same APIs on both the front and backend. Although Meteor does snazzy things like let you write client and server code in the same file, it still requires you to distinguish between the two, and server code is still stored only on the server and client-side code is still served down to the client.
Meteor is still young, but the developers and community are very active, and everything you described can be achieved with it at this point. I've been working with Meteor for about 6 months now, and it hasn't let me down yet. I'm working on a production-level application that also requires exposing a REST API for consumption in mobile apps, which I'm doing quite successfully with Meteor (I just updated a user profile using a REST endpoint from an Android device and watched it change in the Meteor app in realtime. So cool!).
I was using this great package, RestStop2, for building REST APIs in meteor, but it was unfortunately deprecated, so I released an updated version. Check it out for an example of building REST APIs in Meteor. It's available through the Meteor package manager: https://atmospherejs.com/nimble/restivus
So to answer your question, you always want to separate the REST API into it's own layer, but that is entirely possible with Meteor. To make it clear, you would never consume this REST API from within your Meteor app. Meteor uses DDP (not HTTP), which gives you a much more direct connection with your server, so you're doing something wrong if you're accessing data on your Meteor server from a Meteor client via HTTP. Of course, with Meteor, you have the advantage of being able to use existing code from your REST API.
There's a really good write-up that explains some of the considerations of writing a REST API in Meteor: http://www.meteorpedia.com/read/REST_API.
The design of a architecture separated in layers like frontend, backend (Rest Api) and DB, is for obtain a better a scalability, reusability and logic separator of features of the application. For example:
Today make a web applications separated in 3 layer (frontend, backend,
and databases), if tomorrow you wanna do a mobile application you can
develop the application like a extra project in the frontend layer,
but use all the features developed in backend. Then the frontend
application not need servers why run inside every device, but maybe
the load in the backend servers increase, and you only need add 1 more
server in the backend layer.
Its a little example, but is the most common case in this new era of mobile applications.
Remember always this in MVC architectures:
Frontend: Always call services from the backend, render the view, and capture data. Sometimes make a litle logic.
Backend: Receive the request, apply all the business logic, read and write operations in databases, and return a response preferred in json format.
Model: store data, backups, slaves, etc.
PD: If you use meteor in this example you gonna need to make a api Rest to develop the mobile application.
I am currently using serve-static to serve up a very static Angular single page application (SPA), but now need to expand to my SPA to be able to also load/change dynamic data from the server.
From my research, I thinking the best approach might be to replace the existing "serve-static" module with express.js, which should allow me to augment the backend with a RESTful service (which would then in turn provide the access to data as required).
Since I don't have too much experience in this and because architectural questions are not easily googleable, I had following questions:
- Can express.js serve both static and RESTful services simultaneously? If so, is this a proven approach or are there better methods?
- Or should I be running a separate service (lighttpd) for my REST api? Can they co-exist?
This will be running in an embedded Linux environment, so the amount of traffic is minimal, I'm thinking max 2-3 users simultaneously, more typically one user at a time.
Yes, it can do both. Just put your static middleware near the top of your middleware stack and put all of your routes below that. That way if a static file isn't found at the requested path, execution will continue to the routes you have defined.