I am planning on creating a React/Django web application. I plan on creating an API on the backend to communicate with my React app. I understand you can integrate React with django by including your react app in the django project directory and pointing to the index.html in react.
I'm still not sure what the benefits of this are. Would it be better just to separate the django and react application. Whenever I would need to store or retrieve data I could just make requests the django API?
The best approach is to separate, and use DRF (Django Rest Framework), this library will offer serializers which basically going to interpret your request and then process it in a view class/function in Django, the whole process goes like this (between frontend and backend):
You create the tables in database (models).
You create the views, and some views are going to retrieve data from the serializer, to process the request being sent from client side (react).
You map the views to urls.
Now react part:
You make some api calls.
The request is sent to backend (in this case it is django).
The request is sent as "JSON" data format, but python does not understand such format, this is why serializers exist! the serializer will interpret the data and convert it to something that python understand (a dictionary), and then the request is going to be processed by a view.
A response will be sent to react.
Hope this clear it for you, for more info about DRF:
https://www.django-rest-framework.org/
also serializers can also change the lookup field for some resource in your backend, which is pretty useful when you want to look up for name instead of an id in the url
more info about serializers:
https://www.django-rest-framework.org/community/third-party-packages/#serializers
The better is to separate the two projects because a lot of reasons, The main reason is when you need to build a mobile or desktop application on the same backend or database here comes the advantage of APIs, there are a lot of reasons such as: separate the servers to handle requests of both frontend (static files) and the backend (APIs and DB).
Related
I'm implementing a Django web service, which is about to have different platform apps,
Reactjs for computers, a swift app for ios, and Kotlin for android devices. the protocol is rest API and perhaps a chat feature included then Django channels are used as well. The data format is JSON. For deployment, I intend to use docker which includes Django, celery, and ReactJS app. And the database is on another separate server which is PostgreSQL. I was thinking to collect some user activity data and some history logs to show the user itself what she/he has done so far. After hours of searching, I came up with Kafka! unfortunately, I have no idea how can I use Kafka and integrate these stuff together and how can I deploy these things. I wish there was a system schema for this specific kind of system that shows what is what and where is what?
Kafka will only integrate your database and Django, with some effort, and ideally a separate Kafka Connect service.
From React (or other clients), you'll need to query some Django API routes which will then query your database. Kafka won't help with your frontend, and isn't really what is exposing the history/activity you're interested in displaying. In other words, you could simply write that to the database, and skip Kafka entirely.
Essentially, you're following the CQRS design pattern if you properly separate Kafka writes from end user / UI reads.
shows what's what and what's where!
Unclear what this means, but data lineage and metadata tools are a whole separate thing. For example, LinkedIn DataHub collects information such as this
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'm trying to host a database (on either AWS or Heroku) to store data from my web app. I also need to create an API to interact with the database. Basically, like this picture from Google.
Image source: https://dzone.com/articles/an-introduction-to-restful-apis
What I'm trying to figure out:
Is the API and database typically hosted separately? Or are they often hosted together? I'm not sure if the API and DB are together 1 component (with sub components being API and DB), or if they are 2 separate standalone components.
If they are 1 component and they can be hosted together, then I believe you can use something like Express.js for your API which can query the database and respond to HTTP requests from the website.
If they are 2 separately hosted components, I feel that means I have to have 2 APIs, unless my API can directly talk to the database (I'm not sure if this is proper). So I would need my API to talk to some server side technology (PHP, Java, etc.) which would then query the database and return result to the API. So basically my API is talking to an API which is talking to the database. I'm not sure if this is over complicating things, but it sure seems like it.
I'm trying to clarify how this process works.
Is the API and database typically hosted separately? Or are they often hosted together?
Since the API service needs to make lots of requests to the database, you want the minimum network lag possible between them.
So generally they should be hosted together. What that means depends on the style of hosting. Using the same cloud service makes sense if you are using something like AWS Lambda. Otherwise using the same machine for both the database and HTTP service until you scale to the point where you need to separate them.
If they are 1 component and they can be hosted together, then I believe you can use something like Express.js for your API which can query the database and respond to HTTP requests from the website.
This is a common approach.
I have Web application with angular as frontend and Django REST as backend.
My web application does the request like
/api/options/user?filter={}
Now is it possible that if those requests are made from application then they go through but they type that in broswer directly and edit some filters then they don't work
Although the data is not sensitive and they can still see it via console but i just don't want them to play with it or at least make it hard
You can't rely on the URL to distinguish between the two cases. You could have your application provide information in the headers of the request, which a browser would not know, but someone writing their own application could mimic your technique.
So, I've been fiddle:ing with some isomorphic React + Flux lately and have found some concepts quite confusing to be honest. I've been looking into best practices about how to structure isomorphic apps and are looking for advice.
Suppose you are creating a webapp as well as a mobile app backed by the same REST API. Do you bundle your REST API together with the webapp? I've seen people advocating both bundling and having a separate codebase for the REST API.
Any advice or suggested reading is appreciated!
Fluxible (atleast from the examples) does advocate using the service layer inside the application calling it directly from the server and via xhr from the client without duplicating the code
https://github.com/gpbl/isomorphic500/blob/master/src/app.js
This is an example I followed religiously while building the isomorphic app
The idea is very simple. Let's assume you have SPA and a backend wich provides REST API.
SPA (in browser) <====> Backend REST API
in isomorphic case, it is absolutely the same, except you will run your SPA on the server too.
So, it will work like that:
SPA (in browser) <====> Backend REST API
SPA (on server) <====> Backend REST API
If you have a mobile app then it will be:
SPA (in browser) <====> Backend REST API
SPA (on server) <====> Backend REST API
Mobile app <====> Backend REST API
Here is a real isomorphic production application opened by us to the community - https://github.com/WebbyLab/itsquiz-wall . You can just clone it and run.
Here is my post which describes all the ideas behind the app in details.
Let's see if I can help you.
Please keep in mind that Isomorphic Javascript is quite new and it is hard to find clear definitions for every use case.
By definition, if you create a RESTful application you should have a clear separation between server and client:
"A uniform interface separates clients from servers. This separation
of concerns means that, for example, clients are not concerned with
data storage, which remains internal to each server, so that the
portability of client code is improved. Servers are not concerned with
the user interface or user state, so that servers can be simpler and
more scalable. Servers and clients may also be replaced and developed
independently, as long as the interface between them is not altered."
Regarding isomorphic applications, the main benefits are:
Not having a blank page when the user first enter the site (points for UX)
Therefore it is SEO friendly
And you can share one logic between server/client (for example regarding React Components)
This means you should deliver rendered React Components from the server to the client when the user first enters a URL. After that you will keep using your REST API as usual, rendering everything on the client.
If you can, share more details about your case and it will be easier help.
I wouldn't recommend you to bundle the REST API in the browser, as you are limited to using browser-compatible modules in your API, and you won't be able to make any direct database calls.
There's a library that makes it so you can build your APIs in an isomorphic fashion, and re-use it in the client and server without bloating or breaking the bundle. This is what we're currently using in a big single-page application.
It's called Isomorphine, and you can find it here: https://github.com/d-oliveros/isomorphine.
Disclaimer: I'm the author of this library.