I plan to build Web application for which the structure is:
My questions are:
Is that correct structure in the commercial?
I plan that FrameWork of Frontend is express(nodejs) at first, but I try to change to django or flask because nodejs is my first use. I wonder if react can be used in this combination.
How about using firebase? You can handle authorization, store and retrieve data. I believe that it will be much easier than any other alternative.
This great article will enable you to implement authentication in few hours. Handling data is also simple, I would use redux as well...
Related
I'm experimenting with these 2 technologies to make a secure web app [Currently learning React (60%) and Django (<50%). This is intended to be like a medical database, so doctors and nurses enters their patients' information. They need to login obviously. I wanted to implement React-based UI (And not using the classic method to create views from django), so I've found many tutorials just like this one:
https://www.digitalocean.com/community/tutorials/build-a-to-do-application-using-django-and-react
It basically turns Django into a restAPI, and then the React frontend uses axios to retrieve data from the endpoint. Sounds not bad at all (comparing to the native method of rendering data in a webpage from Django), but the problem is that I have no idea on how to make this secure, you know, Django provides an auth system, which is pretty good and secure, I have to say, but in a project with this structure, the auth needs to be done in React, so there many questions appear:
To start with, is it a good idea to make a project of this structure? (If no, then what could be a good one)
If it's a yes, how can I protect the API so only logged in users can interact with it? (What mechanisms to ensure protection)
Yes, this is absolutely a good idea to separate the client application and the backend server application.
You can access the backend through the rest api basically with any frontend framework/app/script.
Customers are able to extend their own applications with the abilities of your backend service.
You can create multiple different frontends that use the same backend or different parts of the same backend via the rest api (multi-branding, reselling). Or you can just swap the frontend framework every second year to a new one.
It's also easier to create different automations by using the rest api.
And the list goes on.
For django rest api auth I would recommend Token Authentication which is already included in the Django REST Framework and for React use this tutorial for implementing the login and the token handling.
And don't forget to use TLS on your servers, and create API documentation. (Example)
I am learning web dev and I am planning on developing a simple web app using React: a decision matrix tool.
I need users to be able log in and save their matrices under their profile so I prefer to not use LocalStorage and thus learn more about databases. I am thinking of using JSON as the data format and I will also need to store basics user data for login and their profile.
I wonder how to tackle such a project since so far I have only been using GitHub Pages to host my static websites. Most of what I find by googling seems confusing or irrelevant for such a small-sized project.
My questions are:
What is the simplest way to store, access and edit JSON data as well as user data for a web app?
Are there any simple databases that can be “hosted” together with the app files on a server? Not sure if the question makes sense but I don’t understand where the database is.
What article or resource would you recommend to understand the concepts for data storage?
Ideally you would want to create a backend server using any language/framework e.g nodejs, java, django, php etc and expose the required data through APIs. But, if you don't want to create a separate backend app you can use Firebase database Firestore to save and fetch all of your required data. You can even use firebase hosting to deploy your app. Moreover, firebase also have their Authentication service which you can leverage for your app's authentication.
I am developing a React app that needs to be connected to a backend server so that the user can login using Google OAuth, and then once that access token is granted, they are able to see the rest of the app. However, I am having a difficult time understanding just how to connect the front-end app to the backend. If someone could enlighten me on this, using SpringBoot MVC and PostgreSQL, that would be great. Thanks!
You have several ways to communicate your FE(React) and your BE(SpringBoot MVC).
You can have REST endpoint on your Backend, and then try to communicate from your react application, you can use [axios][1], request or the native fetch.
Then you can just make calls to the BE, and try to read, update, delete or create information, you should read about CRUD.
The most common this days is build something like this:
(FE) <---> (BE) <---> (DB)
But I strongly recommend you to read more about:
- React SPA.
- REST, you can also read about SOAP or even GraphQL.
- CRUD.
You will found a lot of tutorials with very good examples of how to do it.
Hope this helps you to understand a little more what approach to use.
I have a Laravel + mySQL app that use either ajax or Angular $http service and I want to integrate websockets into that mix.
So I thought of trying Firebase, which is great and easy to use, but am a bit confused about a couple of things. I am seeking for someone's help in clearing that confusion.
is it possible to change the app url name for firebase ?
So instead of something like https://vivid-torch-xxx.firebaseio.com can I change it to https://myawesomesite.firebaseio.com?
how the schema on Firebase should be structured ?
Or better yet how not to use it all and just use Firebase as websocket server instead of ajax ?
I essentially don't want to have 2 databases to manage the data.
there is a Firebase package for php/laravel, but I don't know why would I need it. Or what exactly is the benefit of using it if am already using a REST-ful backend with angular.
The schema will basically be how you want your JSON for your front-end will read it. Are you displaying notifications? Then investigate how that would be structured. Firebase will give you the power to push updates to the front-end which then will no longer have to pull data via the API on what the actual data is it needs to display the notification.
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.