4 ms·

Your code generation point it's good - it's great when you know the different parts, but for learning the tools it's horrible, just a lot of files that you do n

Your code generation point it's good - it's great when you know the different parts, but for learning the tools it's horrible, just a lot of files that you do not have a clear understanding.

st3fan 3y ago
Couple of thoughts The documentation explains every part of a Phoenix app pretty well. The code generator is not there to learn you anything. That is your own job. Adding a controller or schema to results in a small number o f new files. Git commit before you do and you can easily understand what was added.
linkdd 3y ago
The problem is that the code generation tools does not let you learn the different parts. On top of that, all the documentation around just tell you to use the codegen tools and unless you go look at the API reference (or the source code directly), there are no resource to learn the different parts. Take a look at how django does it. `django-admin startproject` creates: - settings.py - wsgi.py - asgi.py - urls.py Then you just need to add your models and views. There is the `startapp` command, but you don't really need it. Even with the codegen tools, you still need to learn what a plug router is, what a phoenix controller/view is, what an ecto repository is, etc... The codegen tools just overwhelm you with irrelevant code (i'm making an API, why the hell do you generate static files? and why do i need to edit so many files to take it out?) Another point I don't like about Ecto is that you can't easily switch the database backend depending on the environment. With django, I can have an sqlite3 db for the dev environment, and a pgsql one for the production. I don't want to run a docker image for pgsql on my machine. I just need to read the DATABASE_URL environment variable, and the ORM takes care of the compatibility. If later on I need some specific pgsql feature, I will have to run the docker image on my computer anyway, but until them please keep the complexity out of my way.

Your code generation point it's good - it's great when you know the different parts, but for learning the tools it's horrible, just a lot of files that you do not have a clear understanding.

st3fan 3y ago

Couple of thoughts The documentation explains every part of a Phoenix app pretty well. The code generator is not there to learn you anything. That is your own job. Adding a controller or schema to results in a small number o f new files. Git commit before you do and you can easily understand what was added.

linkdd 3y ago

The problem is that the code generation tools does not let you learn the different parts. On top of that, all the documentation around just tell you to use the codegen tools and unless you go look at the API reference (or the source code directly), there are no resource to learn the different parts. Take a look at how django does it. `django-admin startproject` creates: - settings.py - wsgi.py - asgi.py - urls.py Then you just need to add your models and views. There is the `startapp` command, but you don't really need it. Even with the codegen tools, you still need to learn what a plug router is, what a phoenix controller/view is, what an ecto repository is, etc... The codegen tools just overwhelm you with irrelevant code (i'm making an API, why the hell do you generate static files? and why do i need to edit so many files to take it out?) Another point I don't like about Ecto is that you can't easily switch the database backend depending on the environment. With django, I can have an sqlite3 db for the dev environment, and a pgsql one for the production. I don't want to run a docker image for pgsql on my machine. I just need to read the DATABASE_URL environment variable, and the ORM takes care of the compatibility. If later on I need some specific pgsql feature, I will have to run the docker image on my computer anyway, but until them please keep the complexity out of my way.