Flask or Django & React\Redux — good practice?

Good day!
Did a little programming in Python on Flask microframework and loved everything about it (language and framework) because of its simplicity and understandability of the server written on it, unfortunately can't say the same about express.js I tried to write an api. On the Internet there is little information about the express (relatively), I mean the official documentation, it is too poor in details, and Flask and Django is...
Question - is it good practice to use React'om Pytnon''s framework provided that there is ssr? Are there any significant disadvantages? Isn't it better to continue to teach express.js?
March 23rd 20 at 18:53
2 answers
March 23rd 20 at 18:55
Solution
Question - is it good practice to use React'om Pytnon''s framework?

It is a normal practice.
The frontend separately from the Backend.

API is well suited https://www.django-rest-framework.org/
But this is IMHO
March 23rd 20 at 18:57
Solution
You will rest in the desired ssr or not
If you don't, then anything with anything
If you need, you will have to splice node and Python on backend

But if you want ssr and sharing code on Beck and front, even the most amazing things (Clojure code) may not seem so amazing
By the way, Yes, I forgot to write, ssr cannot do if Python? - Madison.Haag commented on March 23rd 20 at 19:00
@Madison.Haag, you can. There will be two servers: a simple render server Express and API in Python. - Kaley51 commented on March 23rd 20 at 19:03
@Madison.Haag, ask yourself the question - in Python, you can write code and transpirirovat it into the code on reacte? - Pierre commented on March 23rd 20 at 19:06
@Pierre, but you can use third party tool? next.js for example? - Madison.Haag commented on March 23rd 20 at 19:09
@Kaley51, that is, routing exprress and the database in django I understand you correctly? - Madison.Haag commented on March 23rd 20 at 19:12
@Madison.Haag, it all depends on what tools will be used for implementation. If you use next, you will have to use their fancy server-side routing with masks on the client. If you write SSR on their own, we can restrict the react-router. - Kaley51 commented on March 23rd 20 at 19:15
@Madison.Haag, you can. I use just Next.JS - I norms. It's better to use a ready-made solution to render than to cut his balalaika for similar tasks. You have a SSR with the Python not in any way related, so IPAS drank anything. The only one not suggest Django because using it for regular REST api is redundant. I think all gin/gonic (go). - Scot.Jacobs commented on March 23rd 20 at 19:18
@Kaley51, @Scot.Jacobs, thank you for your time and good advice - Madison.Haag commented on March 23rd 20 at 19:21
@Scot.Jacobs, Django yuzayut due to the fact that he harvester

Those can not advise at the beginning of a paragraph not to cut the bike, but in the end - to advise the opposite - Pierre commented on March 23rd 20 at 19:24
@Pierre, that is developing microframework is velosipedista is? What exactly is the Django will Ustica in the Rest API? Think ORMка Yes routing. Maybe something else on the little things. The first is solved by screwing to the project any IMCI in the form of a third-party library (same for Python Gorm for th), the second is, and so in any microframeworks out of the box. What kind of batteries from Django-harvester makes it easy to create rest API? The ability to develop quickly unless. And the barrier to entry for a newcomer in any micro framework is clearly lower than in Django. Therefore, it is also a controversial issue.

Yes, and it really will not be in Django bikes? The same burning question "where in Django to store business logic" is already leading to disputes and disagreements. Someone in view hrenachit someone sawing thick models, and someone makes your service layer. What is not velosipedista? - Scot.Jacobs commented on March 23rd 20 at 19:27
@Scot.Jacobs,
that is, the development microframework is velosipedista is?
or the search of another bike
aka
any IMCI in the form of third-party libraries

or your
+ attempts to make a smooth vzaimodeistvie between components

The ability to develop quickly unless.
actually this phrase can be completed

And the barrier to entry for a newcomer in any micro framework is clearly lower than in Django.
for practice - approx. Wrote 10 projects to /dev/null and got the experience

Microframework in production available on the levels above the middle
June without strict structure falls into the bad code immediately

Yes, and it really will not be in Django bikes?
will. But they will be in the form of an extension, rather than square wheels

The same burning question "where in Django to store business logic" is already leading to disputes and disagreements
Fat models - Pierre commented on March 23rd 20 at 19:30
@Pierre, well, Yes, I agree that "Microframework in production available on the levels above the middle
June without strict structure falls into the bad code immediately".
Why so confident: Fat models? Mixed in fact the entity with the business logic of the project. The files themselves models are often very growing. What is the architectural advantage of this approach over the imposition of business logic in services? - Scot.Jacobs commented on March 23rd 20 at 19:33
@Scot.Jacobs,
Why so confident
because it's easier.
Everything is at hand
If something in the model - so it is directly related to her

Have a look at the draft - he's weird
Constructs the view and form and call services

With the same success it is possible to make common_views_func, add celero and call business logic
Easier if it's something?
Don't know - Pierre commented on March 23rd 20 at 19:36
@Pierrewell, I (purely my opinion) good architecture see something like this: entity - repository - service - controller. Entity is just a data model (e.g. a table view from the database). repository operations like selections, inserts, etc. that implement a common interface. Need to abstract from the type of store. Service - the actual business logic. Well, controllers - everything is clear. Controllers that pull service methods. Any helpers/validators, etc. I've deliberately not announced.

"Constructs the view and form and call services" - and there it is all wrapped in a transaction (optional). Actually, a handy thing, because the service layer should validate the data that it transmitted, and then implemented directly into Jankowski forms. That is, no matter from the view function or pulled from a console command or something - validation is already there.

"because it's easier." - but the business logic may affect several models. In some of the models then this method to implement?

"Easier if it's something?" - give the ability to abstract the business logic from a specific framework, it Ormoc etc.. Yes, I understand that this particular Liba still goes against this statement because of its reference to Django, but generally, ideally the service layer should be independent. - Scot.Jacobs commented on March 23rd 20 at 19:39
@Scot.Jacobs,
It's better to use a ready-made solution to render than to cut his balalaika for similar tasks.

Here I do not agree. Own decision for SSR if you have experience written in a few hours. - Kaley51 commented on March 23rd 20 at 19:42
@Kaley51, and what advantages will it give?

P. s. "if you have experience written in a few hours" - with the tests, no?) - Scot.Jacobs commented on March 23rd 20 at 19:45
@Scot.Jacobs, mind you, I have nothing against next.js and didn't say anything about the advantages or disadvantages of a decision. I merely pointed out that your statement is not wealthy, as you give your value judgment as fact. The only argument, as I understand it, the word "cut", but saw there's really nothing special: one is middleware for express, server the entry point, HOC, Provider, and helper function for asynchronous expectations executing queries on the server side. - Kaley51 commented on March 23rd 20 at 19:48
@Scot.Jacobs,
good architecture see something like this: entity - repository - service - controller
KISS

"Easier if it's something?" - give the ability to abstract the business logic from a specific framework, it Ormoc, etc.
why? - Pierre commented on March 23rd 20 at 19:51
@Pierre, KISS - so where unnecessary complexity? More precisely, where is the limit between normal and excessive architecture complexity? Someone sites all in one file sculpts on PHP, mixing php, html, query the database and layout and says that the main thing - simplicity.

"why?" - in order for the project to be maintained, to develop, to test and to eye not bleeding)) - Scot.Jacobs commented on March 23rd 20 at 19:54
@Scot.Jacobs,
more precisely, where is the limit between normal and excessive architecture complexity?
here
entity - repository - service - controller
When you start to add patterns on top of MVT

"why?" - in order for the project to be maintained, to develop, to test and to eye not bleeding))
I don't see how an abstraction from the ORM (and the inevitable overcoding) simplify unit-testing and functional testing
And it will also abstract the ORM Moka

And I probably incorrectly asked the question
He sounded so
Why do we need to get rid of the OPM, if the inevitable happens parallel API to the ORM, which will duplicate the ORM?
Want to use raw queries to Postgres - OK
Want alchemy - OK
Want Django is OK
Want all together - PTA? - Pierre commented on March 23rd 20 at 19:57
@Pierre,
When you start to add patterns on top of MVT

I'm not suggesting this (entity - repository - service - controller) to do over jankovskaja design pattern. In the case of Django, I suggested only to add a service layer to avoid the projects it growth models in which to store the business logic, in my opinion it is not logical. "Thick models" in many projects seek to escape - and there is a logical question, where in this case transferring the business logic. Because over time, the model does not become smaller - and dig in files with thousands of rows, not a pleasant occupation. It's one thing when some getters of the type of __str__ in the shove model - yet clear, but the business logic that can interact with other models to perform the treatment without third-party services, working with the cache etc. - it's weird. Because in this case, "simplicity" is questionable. Moreover, in the case of testing services Moka will have clearly less than in the case with a hefty methods of the model (where often in a single method and sql queries, and http otsuki elsewhere are mixed). Yes, you can and model great methods to split up into smaller parts and test them separately, but it really makes sense to them then in the model to keep?

Why do we need to get rid of the OPM, if the inevitable happens parallel API to the ORM, which will duplicate the ORM


I so understood, speech about the repositories? If Yes, then this design pattern is needed in order to hide the source. You need to be able to easily if you need to switch to another data source (not only SQL database, and any). Today you have a mysql is used to store list of products online boutiques and tomorrow pinned redis for the same purpose to use (well, purely for example). In the case where you have a repository that is enough to create the new class implementing the same methods as the old repository to test and that's it. In the case without the repository will require a much more serious edits. Tomorrow will tell - and give back on MySQL, roughly speaking - and you switched to past repository. If no repositories, it will be hard. And just the presence of a repository allows you to change one ORM-ku on the other. Although specifically in the case of Django it does not make sense, because ORM out there impacted tightly. - Scot.Jacobs commented on March 23rd 20 at 20:00
@Scot.Jacobs,

the business logic that can interact with other models to perform the treatment without third-party services, working with the cache etc. - it's weird
First in Manager
Then in a separate file with functions
In severe cases - make your class and added to the inheritance chain

Because in this case, "simplicity" is questionable
just no
We have a mantra of Python and everything is described

Moreover, in the case of testing services Moka will have clearly less
no. Those parts of services that are strongly tied to the ORM simply test how the model together with the data

Testing code that was written by a man who does not know about functional approach - always a torment
But that's not a reason to continue to write the dirty function

I so understood, speech about the repositories?

no, it is about
"Easier if it's something?" - give the ability to abstract the business logic from a specific framework, it Ormoc, etc.


Today you have a mysql is used to store list of products online boutiques and tomorrow pinned redis for the same purpose to use (well, purely for example)
no. Just no
muscle never
Radish is not used for permanent storage of anything

Tomorrow will tell
no. Always Postgres. In advanced cases, Oracle

And besides, overengineering because of what might happen tomorrow - is sheer folly
I will say that because of this overengineering and slowing down writing code, the project will cover today, because yesterday wasn't written a single line of code for the solution of business tasks - Pierre commented on March 23rd 20 at 20:03
@Pierre,
I will say that because of this overengineering and slowing down writing code, the project will cover today, because yesterday wasn't written a single line of code for the solution of business tasks


Following this logic, and the tests not to write, because it takes time and does not solve business problems. Tests is a technical debt, as well as sophisticated architecture. The use of design patterns is not in any way overengineering and is not any kind of premature optimization or something in that spirit. Following Your logic, the introduction of levels of abstraction invented for fools who develop for the sake of development. In this case, the use of the service layer solves a very specific task: to get rid of the fat models.

Then in a separate file with functions


The same level of abstraction, which is what I say. The file functions that the services in this case are roughly the same.

muscle never use. Radish is not used for permanent storage of anything


Well I wrote it as an example that specifically said. You can replace "Radish" in this statement to any store of any kind. - Scot.Jacobs commented on March 23rd 20 at 20:06
@Scot.Jacobs,
Following this logic, it is possible and not to write tests
no
Tests remove fear of making changes in a big project
Overengineering adds to fears that tomorrow, TK will turn on the head

The use of design patterns is not in any way overengineering and is not any kind of premature optimization or something in that spirit
in the form that you describe - is overengineering and premature optimization
You need to be able to easily if you need to switch to another data source


Following Your logic, the introduction of levels of abstraction invented for fools
my logic is - if the levels of abstraction complicate my work - they are not needed

In this case, the use of the service layer solves a very specific task: to get rid of the fat models.
Again, in the example shown, the thick model is replaced by fat view
Any simplification is not happening

The same level of abstraction, which is what I say. The file functions that the services in this case are roughly the same.
When I do a decomposition and Vino pure functions that are easy to unit-test, I'm not making any services, repositories, etc things
I simplify the code

When I instead of pure functions lead the class hierarchy - my allergic reaction begins

Well I wrote it as an example that specifically said. You can replace "Radish" in this statement to any store of any kind.
I probably wasn't clear - all stored in Postgres, Keshi - where the
No changes Orme
No "I read a book about patterns, let's introduce a couple"
Conver - from the garden
The customer explained how many years he will pay the money without solving its current problems - Pierre commented on March 23rd 20 at 20:09

Find more questions by tags Web Development