I have heard of people who use Flask with Reactjs to build REST APIs. However, I am very confused by why Flask is needed when Reactjs can handle GET and POST requests.
To bring some context behind why this question is important for me: At work, we build web apps where a customer/user inputs some data (e.g. favourite food). This data is then processed using python libraries and scripts and then an output (e.g. recipe for the food) is returned to the user.
Why might Flask with React be better than React by itself?
React and flask are two separate solutions for different problems. In the context of a REST API, flask (on top of python) can be used to provide the API. React on the other hand is a client-side framework and is thus at best indirectly involved in consuming it.
Neither React nor flask is needed, both are independent convenience frameworks. React for the JavaScript client-side, flask for the Python server-side.
React makes it easier to provide an HTML interface to the user, flask makes it easier to reply to incoming HTTP requests on the server.
React is just a javascript library which helps in building user interfaces, whereas flask is a microframework for building web applications.
Handling http requests in the context of React means that it can make http requests and make decisions based on what they output. React does not have control over the business logic i.e the way the requests are going to get processed, which in your case is deciding recipe based on user's input. That's where flask or a backend comes into picture, it would take the input given by the frontend, do some processing and return some output. Over here http is just a medium of passing information from frontend to the backend.
To understand these concepts a bit more you could research more on the MVC architecture.
Related
This could be a silly question but I want to confirm about it. I am a backend Laravel developer and have created my website. Now I want to create mobile mobile apps but have no knowledge of front-end.
Due to lockdown situations I want to use this time to create the backend API for my apps. Now I want to know is it ok or a normal practice to create APIs without knowing anything about front end. (Like is it possible that I just create all the endpoints now that are throwing data in JSON and then the front-end developer will use them to integrate in the front-end? Thanks
P.S: I dont know how the app front-end will look like but I know what data will be needed in each page/view.
I think you can do this easily with graphql.
A Frontend dev and also beginners with Apollo in the frontend can easily introspect and build the stuff.
If you can choose your Frontend stack there is no problem with rest either.
I always do the Frontend first approach.
Mocking the data for graphql types and building the api later seems to me the best workflow ever.
See ya. Much fun with your project
Yes it is possible very possible to do that it would be nice is the API is well documented using postman or swagger for a better experience when frontend engineers want to integrate
Many API's in the world today are never consumed by a browser or app on the frontend, sure it can make life easier knowing why you are building it.
But at the end of the day, a good API is simple and easy to understand. It just allows a developer to fetch data from a system but normally with some idea about each type of request.
For example, if you had an API for a university the endpoints could be as follows:
/pupils => Get/Sets pupil data.
/teachers => Get/Sets teacher data.
/classes => Get/Sets class subjects and references ID's of both Pupils and Teachers.
So if you wanted all the Pupils in a given class you would query the /classes endpoint and then for each Pupil ID you would query the /pupil endpoint.
Sometimes not having a frontend makes the API even more generic because you might think differently when you do not have a frontend.
So I have an isomorphic node based application running (with react). The page is rendered on server first and then the client JS takes over. I am having the data populate first on server (via an api endpoint) and then the same api is being accessed on client side. On the server side I am using "request" library and on the client-side I am using AJAX for fetching the data. I observe that there is duplication in the code I am writing for making api calls on server and client side. Is there a way I can unify this (via some library)?
Your best bet would just be to set up your build pipelines properly to allow you to share the code. You could then have a client, server, and common directory, and tell your build tools (Webpack, Rollup, Browserify, etc., whatever you may be using) to include everything from client and common for the front-end, and common and server for the backend.
There are lots of other ways to deal with it, but that's one of the cleanest. You might also want to take a look at Meteor, which does a lot of what you're talking about for you out-of-the-box (and allows you to use React as a front-end).
Is it worth it to use DRF+Ajax+bootstrap to build a website where no app is needed, or is it better to stick to the normal django template language without even Ajax? I want to avoid using angular since I don't want things to get complicated.
I want to create a website where a user or an admin logs in and accesses a different set of views and performs different actions.
Sorry for my primitive question, I'm a newbie in web development and Django.
Django REST Framework is only necessary if you're building a RESTful API; An HTTP service that reads and writes data, usually as JSON payloads.
Services are typically created to allow external clients such as mobile apps, single page applications (React, Angular, etc.) or 3rd parties to gain access to your data.
It is not necessary to create a service if you just want a traditional "form-based" web application. What you're describing in your question is totally possible with the standard Django implementation. User logins, user access levels, database access via the ORM and templating are all built in. All without any need for a REST service.
You can always add Django REST Framework later when you know you'll need RESTful services since DRF uses the same models that the normal views do, it just wraps them in serializers.
You can accomplish what you're suggesting easily without any special additions or changes to Django. Just because a certain way of development is popular does not mean it works in every situation.
I'm starting a project that basically is a single-page app that downloads and shows a bunch of stats (using d3.js). The data layer is Mongo-powered, served through a RESTful API, and the client app will be coded in Ember.js. We want all data to be exchanged through the API, since we also have some mobile apps in the back burner that will hook to the same API.
I'm debating on whether write the API (using Express.js or other server-side MVC framework), or just serve the API use Deployd and not using a server-side framework at all, besides Deployd. I'll provide some hints about the project characteristics:
The main feature is basically a dashboard that shows aggregated stats that are already computed and stored in the Mongo database.
User interaction is minimal, enough only to allow users to customize their dashboards, but users never upload data (other that customization preferences).
Most of the app is a lot of d3.js to create and render a bunch of graphs, which can customized in many ways.
It requires a very rich and responsive user interface.
I proposed skipping completely the server-side framework, and simply go with a bunch of static HTML+CSS and do all the heavy lifting with a client-side MVC such as Ember.js. Since all data download and upload can be handled by Deployd, a pure static site would load much faster and is also easier to scale. Also, (I think) all user-related data and validation can be done with Deployd itself.
The thing is, some of my colleagues had a heart-stroke when I mentioned this idea. So I'd like a reality check: do I really need a server-side framework besides Deployd to cope with problems I cannot foresee yet? Are the benefits of having a pure static site a good enough tradeoff versus having, say, Express.js just in case?
I haven't worked with Deployd before, but from a quick skim of its docs, it is a server-side framework. It accepts requests and respond with json. It's just oriented to APIs and json and neglects html, unlike, say, default Ruby on Rails.
The main issues I can think of that might arise due to a lack of a traditional server-side framework are things like auth, CORS, and XSS/CSRF/other common security issues. You could cater for this through Deployd if it's built in or easily added, but that may be difficult.
Looking further into Deployd's docs, I see there's a guide for users and CORS. I can't find anything about XSS or CSRF.
I'm developing an app for Firefox OS and I need to retrieve/sent data from/to my DB. I also need to use this data in my logic implementation which is in JS.
I've been told that I cannot implement PHP in Firefox OS, so is there any other way to retrieve the data and use it?
PS: This is my first app that I'm developing, so my programming skills are kind of rough.
You can use a local database in JS, e.g. PouchDB, TaffyDB, PersistenceJS, LokiJS or jStorage.
You can also save data to a backend server e.g. Parse or Firebase, using their APIs.
Or you can deploy your own backend storage and save data to it using REST.
You should hold on the basic communication paradigms when sending/receiving data from/to a DB. In your case you need to pass data to a DB via web and application.
Never, ever let an app communicate with your DB directly!
So what you need to do first is to implement a wrapper application to give controlled access to your DB. Thats for example often done in PHP. Your PHP application then offers the interfaces by which external applications (like your FFOS app) can communicate with the DB.
Since this goes to very basic programming knowledge, please give an idea of how much you know about programming at all. I then consider offering further details.
It might be a bit harder to do than you expect but it can be easier than you think. Using mysql as a backend has serious implication. For example, mysql doesn't provide any http interfaces as far as I know. In other words, for most SQL based databases, you'll have to use some kind of middleware to connect your application to the database.
Usually the middleware is a server that publish some kind of http api probably in a rest way or even rpc such as JSONrpc. The language in which you'll write the middleware doesn't really matter. The serious problem you'll face with such variant is to restrict data. Prevent other users to access data to which they shouldn't have access.
There is also an other variant, I'd say if you want to have a database + synchronization on the server. CouchDB + PouchDB gives you that for free. I mean it's really easy to setup but you'll have to redesign some part of your application. If your application does a lot of data changes it might end up filling your disks but if you're just starting, it's possible that this setup will be more than enough.