4 ms·

> documentation is really low tier compared to Django, especially when it comes to Phoenix. I was spoiled by how good the Django docs are and with Phoenix it’s

> documentation is really low tier compared to Django, especially when it comes to Phoenix. I was spoiled by how good the Django docs are and with Phoenix it’s been mostly digging through old forum threads for basic stuff. Docs assume a lot of prior knowledge about the elixir ecosystem, making it hard for beginners, unlike rails and Django. Their docs need a lot of work. Are there any concrete areas of the Phoenix/Elixir docs that you could point to? I'd love to make some doc PR's to make it more understandable, especially to Elixir beginners. > there is no equivalent of something like Django REST framework for Phoenix, which is annoying, but writing Phoenix is quite productive so it’s all pretty trivial It's not quite ready yet, but I'd recommend keeping an eye on https://www.ash-elixir.org/ https://www.ash-elixir.org/ It'll even generate an admin for you: https://www.youtube.com/watch?v=aFMLz3cpQ8c https://www.youtube.com/watch?v=aFMLz3cpQ8c (although I haven't used django so I can't compare it to that, although I hear good things about django's admin) > community can be a little elitist or idealistic. Try asking how to get JWT auth running on elixir forums, watch it get shot down in minutes because “jwt is insecure”. they can be very friendly but also very unhelpful, sometimes lacking pragmatism Yeah this makes me sad sometimes. > Maintainability and reliability is important for me as a solo maker. I want a resilient web app that can operate without babysitting, I'm a full time student. Great point! Have you written about your web app anywhere? I think solo development of an application is a really interesting space that I'd like to investigate further at some point.

sergiomattei 5y ago
1) I don't know if I can pinpoint it... I have some notes, but it's mostly just little moments of frustration with the docs here and there. Functions that are undocumented, the docs glossing over important parts of the framework, etc. Can't put my finger on it, it's just constant frustration. I'm eager also to contribute to the docs: but specifically a tutorial for API development. This is an area where the docs are severely lacking. Best practices is also another one. I feel they take too little opinions on how to use the framework, and it's difficult to find a best practices source (think a book like Two scoops of Django). This can be jarring to beginners. I get that they're trying to be configuration first, but... People who use frameworks like Phoenix are trying to escape the freedom of systems that take too few opinions. Phoenix strikes me as trying to be Flask but also trying to be Rails. I'm not sure it gets that middle ground right. On the prior knowledge assumption: the tutorials for Phoenix assume too much Rails knowledge. Where Rails takes a beginner friendly approach with RailsGuides, Phoenix immediately assumes you're moving from Rails and the docs can be confusing for that reason. The docs are sometimes made exactly for people who use Rails and that's very annoying for everyone else. 2.I'll be keeping an eye on Ash, that looks fantastic. An API framework that feels like Rails or DRF would be a killer app. As a note, it's also baffling to me that Phoenix is trying to go the Rails route and completely ignoring modern API development. There's zero tutorials, just a generator. I really don't believe in LiveView: moving the UI state to the server is just a recipe for disaster. I feel if Phoenix doesn't try to move where the industry is heading (API-first), they'll rapidly fall into irrelevance. Rails can afford to take that risk, they're too big to fail. Phoenix and Elixir can't. They're too small and the incentives to move are not huge. They didn't kill Rails. 4. I haven't written extensively about it, but you can read my journey at my Twitter account (link in profile). I haven't been too active though, taking a break.
- bostonvaulter2 5y ago
  The best external Phoenix API tutorial that I've seen is https://lobotuerto.com/blog/building-a-json-api-in-elixir-with-phoenix/ https://lobotuerto.com/blog/building-a-json-api-in-elixir-wi... (which the author has done a great job of keeping up to date), but I think many people would have a hard time finding this blog post. And I 100% agree that it would be great to have a "Building a Phoenix-powered API" section in the official documentation (and I believe the Phoenix team would accept such a contribution). > 4. I haven't written extensively about it, but you can read my journey at my Twitter account (link in profile). I haven't been too active though, taking a break. Cool, just followed you! Although I'm not really very active on Twitter either, I mostly just interact with whatever @elixirlang retweets (which I read via the Elixir Slack).
- nivertech 5y ago
  > I feel if Phoenix doesn't try to move where the industry is heading (API-first), they'll rapidly fall into irrelevance. Rails can afford to take that risk, they're too big to fail. Phoenix with Absinthe is great for GraphQL-based API-first systems. With Absinthe GraphQL, you don't need to to use much of the Phoenix's controllers/views/templates. You write GraphQL resolvers instead of Phoenix controllers and they talk to your Phoenix contexts which either using Ecto to communicate to DB, or talk to other services / APIs. GraphQL subscriptions are event simpler, you either auto-trigger them from mutations, or trigger them programmatic from your code using Absinthe.Subscription.publish/3. IMO it's best to implement Web UI using Phoenix LiveView and mobile/offline/desktop/SPA UIs and publicly-facing APIs using Absinthe GraphQL.
- zachdaniel 5y ago
  Hey there! I'm the author of Ash Framework, happy to answer any questions you have. A few people have deployed to production with Ash and are seeing good results, but it is definitely at the "sharp edges" phase, where its great if you're okay with hanging out in our discord and troubleshooting, and even better if you're the kind of person who can dive in and PR whatever change is needed. Feel free to join the discord as well if you just want to follow along: https://discord.gg/WZCECgMe https://discord.gg/WZCECgMe

sergiomattei 5y ago

1) I don't know if I can pinpoint it... I have some notes, but it's mostly just little moments of frustration with the docs here and there. Functions that are undocumented, the docs glossing over important parts of the framework, etc. Can't put my finger on it, it's just constant frustration. I'm eager also to contribute to the docs: but specifically a tutorial for API development. This is an area where the docs are severely lacking. Best practices is also another one. I feel they take too little opinions on how to use the framework, and it's difficult to find a best practices source (think a book like Two scoops of Django). This can be jarring to beginners. I get that they're trying to be configuration first, but... People who use frameworks like Phoenix are trying to escape the freedom of systems that take too few opinions. Phoenix strikes me as trying to be Flask but also trying to be Rails. I'm not sure it gets that middle ground right. On the prior knowledge assumption: the tutorials for Phoenix assume too much Rails knowledge. Where Rails takes a beginner friendly approach with RailsGuides, Phoenix immediately assumes you're moving from Rails and the docs can be confusing for that reason. The docs are sometimes made exactly for people who use Rails and that's very annoying for everyone else. 2.I'll be keeping an eye on Ash, that looks fantastic. An API framework that feels like Rails or DRF would be a killer app. As a note, it's also baffling to me that Phoenix is trying to go the Rails route and completely ignoring modern API development. There's zero tutorials, just a generator. I really don't believe in LiveView: moving the UI state to the server is just a recipe for disaster. I feel if Phoenix doesn't try to move where the industry is heading (API-first), they'll rapidly fall into irrelevance. Rails can afford to take that risk, they're too big to fail. Phoenix and Elixir can't. They're too small and the incentives to move are not huge. They didn't kill Rails. 4. I haven't written extensively about it, but you can read my journey at my Twitter account (link in profile). I haven't been too active though, taking a break.

bostonvaulter2 5y ago
The best external Phoenix API tutorial that I've seen is https://lobotuerto.com/blog/building-a-json-api-in-elixir-with-phoenix/ https://lobotuerto.com/blog/building-a-json-api-in-elixir-wi... (which the author has done a great job of keeping up to date), but I think many people would have a hard time finding this blog post. And I 100% agree that it would be great to have a "Building a Phoenix-powered API" section in the official documentation (and I believe the Phoenix team would accept such a contribution). > 4. I haven't written extensively about it, but you can read my journey at my Twitter account (link in profile). I haven't been too active though, taking a break. Cool, just followed you! Although I'm not really very active on Twitter either, I mostly just interact with whatever @elixirlang retweets (which I read via the Elixir Slack).
nivertech 5y ago
> I feel if Phoenix doesn't try to move where the industry is heading (API-first), they'll rapidly fall into irrelevance. Rails can afford to take that risk, they're too big to fail. Phoenix with Absinthe is great for GraphQL-based API-first systems. With Absinthe GraphQL, you don't need to to use much of the Phoenix's controllers/views/templates. You write GraphQL resolvers instead of Phoenix controllers and they talk to your Phoenix contexts which either using Ecto to communicate to DB, or talk to other services / APIs. GraphQL subscriptions are event simpler, you either auto-trigger them from mutations, or trigger them programmatic from your code using Absinthe.Subscription.publish/3. IMO it's best to implement Web UI using Phoenix LiveView and mobile/offline/desktop/SPA UIs and publicly-facing APIs using Absinthe GraphQL.
zachdaniel 5y ago
Hey there! I'm the author of Ash Framework, happy to answer any questions you have. A few people have deployed to production with Ash and are seeing good results, but it is definitely at the "sharp edges" phase, where its great if you're okay with hanging out in our discord and troubleshooting, and even better if you're the kind of person who can dive in and PR whatever change is needed. Feel free to join the discord as well if you just want to follow along: https://discord.gg/WZCECgMe https://discord.gg/WZCECgMe