I'm interested in using Firestore to authenticate users to my Flask web app, and I am following this demo provided by Google.
In the demo code, there is a backend service that handles AJAX requests and a frontend service that presents a single page app (one each of an html, js, and css).
It seems pointless to break this code up into two services when one service should be able to handle it just fine.
Am I missing some aspect of this that requires two services? I just don't understand why Google would needlessly complicate the demo by using two services...
Nope, not required. Just a really good idea to get used to. See also Separation of Concerns as an architectural pattern for a very robust argument.
The answer to your question is NO, you don’t need more than one service to have implemented your back-front end. As mentioned by Paul the sample is using the separation of concern as a good practice.
Finally the sample is also a good guide to implement the pieces of code that are relevant for you, and the whole sample will let you have a running environment that you can use to perform local tests in order to better understand the functionalities.
Related
I know normally I have to ask questions about specific code problems. But I need advice to get started at all. I was thinking about making a webapplication with react the application is a admin controll pannel things like, employee costs, orders and so on for a family business. For the authentication part I wanted to keep it simple and do it with google but before doing that, I wanted to ask the experienced developers here if that makes any sense or if I should use Jhipster/Keycloak.
Benefits of google would be I think it is easier to implement and the security part would be handled by google but what could be possible problems? I hope someone could give me a good advice.
with regards
Using Keycloak/JHipster would probably be overkill for a simple family business application.
I would rather use simpler authentication types offered by JHipster that do not require external applications like session. An alternative would be to use provided Okta integration, this way you get a ready-to-go solution.
If you want to use Google, then you'll have to use spring-security-oauth2-client and build your own solution on top of Spring Boot or adapt JHipster generated app if you still want to use JHipster.
Also, do you have decided of where you want to deploy your app? Your cloud provider could offer a good integrated solution for authentication.
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'm planning to build web application on top of a REST api. I have been thinking about 2 different ways to write web UI layer for controlling the views, user session management, etc.
One way : Just write everything in Javascript using Angular or similar frameworks. But, the problem I see here is, user session management and also it may not be good idea to expose everything to client. I'm thinking anybody with good knowledge of web design, can find out javascript logic and end points.
second way: Write a thin controller and user session management layer on REST in may be Spring web mvc project / Node JS, etc, and control everything from there. But, the problems I see here are, we have to have some end point lookup logic here, to map web ui request to REST end point. Everytime, we we add more end points, we have to maintain that catalog as well. Also, the JSONs will go through many transformations, and which may add some overhead.
can anybody suggest some architecture ideas for this ? Am I missing anything here ? Can we write secure Javascript web ui layer on REST ?
I was also thinking about having Message broker like RabbitMQ to scale it. Any suggestions are appreciated.
Thanks in advance.
You should first decide on how you divide responsibilities between the client and the server. What do you want the server to do, and what do you want the client to do? You already figured out that the server should hide the sensitive information, to keep the application secure. Is there anything else you need from the server? If there is a database, you probably also want to let the server handle all access to the database.
Notice that there are also alternatives such as Firebase, where they take care of the backend for you, and you focus on the front-end mainly. Might save you a lot of work on authentication, and data access.
You also need to think what kind of communication style they will be using? If it is Request-Response, then REST is suitable. If it is some kind of bidirectional messaging such as chat, I recommend to take a look at Meteor. In Meteor, you write in Javascript for front-end, back-end and mobile.
You mentioned that you're concerned with having to transform your Jsons often. If you do your server-side with NodeJS, this problem disappears. It's Javascript on the server-side.
There are many ways to implement an application. You can more specifics about what you're trying to do, and then we may recommend the frameworks that are better for you.
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 trying to develop a web application that can communicate with another web application. App1 is an app developed using Angular.js and Struts2. This apps sole purpose is to perform search queries on several databases and returning the information about the products for the user to view. App2, the current app I am developing, will be developed using Angular.js and Flask/Python. This app will be responsible for storing the products the user selects in a shopping cart and allowing the user to make a purchase.
I am stuck as to how to get the two applications to communicate(passing login information, selected items ids, etc.) with eachother.
I have tried passing information via a url redirect (http://www.example.com/?myVar=someData&...) but Angular is giving me a lot of trouble to try and get around that. Even if I can get this to work, I think it would be insecure as data the user shouldn't know will be exposed in the url.
My second thought would be to somehow access the session data from App1 in App2 but that could also lead to security issues.
My final thought would be to some how make a call to App1 that returns a json object that can be parsed in App2 but I am not entirely sure how to pass that information along.
How can I get the two applications to communicate with each other?
Thanks for your help
In my opinion this isn't really within the scope of AngularJS. However, I believe that the best, most accepted practice for communication between web applications in this day and age is RESTful Web Services.
It's not a small topic, but once you get the concept behind it you can use it in any programming language that supports web applications (Java which I'm assuming you're using because of struts has multiple REST libraries, I prefer Jersey but that's just me).
It's also an amazing way to use your Angular front end to talk with its own back end. The entire Angular $resource framework is built around the idea of using RESTful services.
Check out this link on Wikipedia for a brief synopsis of what makes a service RESTful: http://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_web_services
Now, that applies to most of what you asked. As far as login information is concerned, that's going to depend on your security implementation. A lot of times you can put information like that in the header of a web services request, and only accept requests that come from trusted servers, etc. but there's a good bit of stuff to understand there. It's an entirely separate topic.
Hopefully this helps you get started. Let me know if you'd like more information or pointers.