As I'm diving into Redux this is the question that is stuck with me the most. There are tons of articles and tutorials about Redux but it seems there are lots of different opinions on how to deal with APIs.
In my case, I'm working on a full stack web app that will use two APIs to collect the necessary data we need for our React front-end.
REST API #1 will be developed outside of my web application, most likely written with Python/Flask.
REST API #2 is a Node/Express app that will communicate with API #1. And it will serve endpoints directly to our React/Redux front-end.
Now in our past applications, we structure our back-end with your typical data model and a controller to communicate with the front-end through an endpoint.
I think my confusion is coming in here. Is there a correct/incorrect way to build a REST API that needs to communicate with React/Redux? I like this diagram, but it obviously doesn't say anything specific about the API structure. Does Redux not care about the back-end structure? Can I build an endpoint as I described above and have Redux just call the appropriate endpoint?
It is my understanding that Redux does not care about the structure of the API endpoint. You can use whatever middleware you see fit (Redux Saga, redux promises, redux thunk).
This redux boilerplate should help understand one way of handing redux side effects using redux-thunk. The boilerplate also presents an example server side api using expressjs and mongodb utilizing the MVC paradigm.
This is the redux-saga example.
Related
I am new to Angular and I have an initial understanding of the special basics and these questions are facing me and I want to understand them well.
I've been reading around trying to understand what RESTful API is all about.
1- In Angular, can we say about (Fetch Data Using HTTP Client With Angular) it is an Api or Rest
2 - Using Json obj taken from a page that gives us the obj and using the data in it and showing it in my web page Can it be called using api
3- Is the creation of the API related to the tasks of front-end or back-end in the case of dealing with the framework of Angular
I will answer simple to you and shortly:
RESTful transfers a representation of the state of the resource to the requester or endpoint. Check it out for more info here REST API
API stands for (application programming interface) is a connection between computers. It is a type of software interface, offering services to other pieces of software.
HttpClient in Angular is a module helping developers to do http requests to that API for accessing/manipulating recourses.
Keep going, hope to help you a little bit.
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.
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.
I am quite new to web programming. I've started developing a single-page web application using React.js with a Node server.
I've read the tutorial, played with boilerplates, and quickly I understood React would take care only of the view aspect. So I tried to put my data-processing functions with the export keyword in a JavaScript file so I could use them in my React components. But that way was pretty "dirty" and it didn't feel satisfying at all.
Then I looked for a way to effectively separate the model and the controller from the view, so that I could completely change the GUI with little effort, and thus allow the project to grow and multiple people to work on it at the same time.
I've came across this article explaining the Flux architecture, and I saw a major implementation to use with React.js was Redux.js. I was quite surprised that I didn't see it at first, and now I wonder how much frameworks one has to use when working with JavaScript and Web.
My question is simple : is Redux.js all I need to effectively separate data, treatments and GUI components ? Or did I miss something else ? Are there any other major architectures you would recommend ?
Many thanks,
Redux is generally used to contain all the data that your app needs. It acts like a store which can pass the required data to the components that actually needs the data. For example, if you need a particular data fetched from an ajax request to be distributed among two components, then redux is a perfect fit. Whether you need redux depends on how your app is structured. If you have an app with a large number of components and most of these require data from your server or api, I'd suggest you go with redux. Once you learn it, it's incredibly simple. And yes, redux is all you need to separate data from ui. To get a nicely formatted structure, put together all your ajax requests under a folder and export it so that you can call it from the ui component. And when you receive the data pass the payload to the redux store which will automatically pass it to all the components which are connected to that particular reducer. For details on how to connect react with redux, check out their documentation:
https://redux.js.org/basics/usage-with-react
Remember not to confuse the state mentioned in redux with the state in react. Redux state refers to the application state. Do check it out and if doesn't work for you, another alternative would be flux.
I'm very new to the React and Flux consept and I'm confused as hell..
I come from a background of Sails.js so I can't really tell whats what with React.
I plan to use Sails.js (as a restful api, isolated from the front end)
+
React (as my front end using restful calls + perhaps websockets to communicate with sails)
but I don't see where flux fits in!
No.
Flux is a design pattern, rather than a framework or library. You can use Flux without using React and vice versa, although they are optimized to work well with each other.
Flux applications have three major parts: the Dispatcher, the Stores, and the Views (not be confused with Model-View-Controller). EventEmitter is typically used as a basis for Stores and React as a basis for Views. The one piece of Flux not readily available elsewhere is the Dispatcher, although you could write one yourself if you want.
Controllers do exist in a Flux application, but they are controller-views -- Views often found at the top of the hierarchy that retrieve data from the stores and pass this data down to their children. Additionally, action creators — dispatcher helper methods — are often used to support a semantic dispatcher API.
Flux eschews MVC in favor of a unidirectional data flow. When a user interacts with a React view, the view propagates an Action through a central Dispatcher, to the various Stores that hold the application's data and business logic, which updates all of the views that are affected. While you don't need React to implement this pattern per se, it is designed to work especially well with React's declarative programming style, which allows the store to send updates without specifying how to transition views between states.
More info can be found at the official Flux repo.
Flux is definitely not a requirement for using React and does not operate as a "back-end" for React. It's just a common pattern for structuring applications written with React. It's well documented here.
It is only a client side solution. It does not have a hard requirement on any particular web server (but it is convenient if you have NodeJS installed so that you can use something like Browserify to compile and package scripts).
It's not clear from your question what parts of Sails you're planning to use. If you want to use React in an isomorphic way (meaning you'd run React code on the web server and it would be then "attached" by the React client code, without re-rendering), then data management could be an issue if you're using Waterline. But, if you're only going to use React on the client, then it may be an easier integration.
But, again, it's not necessary to use Flux. You can just follow the basic principles of using React JS regarding data flow (parent to child) and use other data storage and synchronization libraries. React is not opinionated that way.
Also, while Facebook has a Flux implementation here, you'll find dozens of implementations of the pattern with various tweaks and enhancements located here. You'll also note on that same page that there are lots of other complimentary libraries that may be useful.