4 ms·

Makes little difference to me, it has been few years now that I create API backends consumed by separated frontends, them being either CLI or JS etc. If anythin

Makes little difference to me, it has been few years now that I create API backends consumed by separated frontends, them being either CLI or JS etc. If anything for me this approach has done wonders for e2e tests using api mockservers But probably for simpler projects and new starters makes sense But I would really suggest anyone out there just to avoid backend-frameworks-based view/templating (guess json responses are view layers) layers

thex10 4y ago
> But I would really suggest anyone out there just to avoid backend-frameworks-based view/templating I personally struggle to let go of backend templating. It's so easy to translate your data into the right pieces of markup in the template, and just serve the fully-baked HTML to the user instantly. How should I be looking at this differently?
- lnxg33k1 4y ago
  I think few reasons that made me go with this new (for me, at the time) approach were: - Backend/API that can be consumed by anything, are frontend-agnostic - Frontend that depends on JSON/source-agnostic data so that can have functionality tested faster (no "proper"/"dynamic" backend involved, just give it some ApiBlueprint/swagger mock server - The frontend rendering isn't a concern of the backend removing some load
  - Existenceblinks 4y ago
    Business-wise, I cut the JS only part as a free plan (local use only), so it's zero dollar cost. The paid plan has the Phoenix Channel integrated.
- gedy 4y ago
  As company gets larger, it's so nice to have "important business logic" via API only, that way mobile apps, web apps, partners, etc can use same logic/data. Server side templating is a real drag on enabling this.
andrewmutz 4y ago
> But I would really suggest anyone out there just to avoid backend-frameworks-based view/templating (guess json responses are view layers) layers Are there client-side rendered frameworks that can match the developer productivity of Phoenix or Rails for early stage, small team products? It seems they are still the best for small teams moving quickly in the early phases of a project.
- lnxg33k1 4y ago
  So, I am not sure what kind of developer productivity are we talking about, I think it's about what people are comfortable with and know of. I am a solo dev working on a side project with rust+phoenix backends (one doing IO-intensive/Multithreading stuff and the other presenting the info/business logic through API) and svelte frontend and svelte for me is very simple. On the other hand if there's an emphasis on developer productivity, and your team has experience on Phoenix/RoR, then you can't fight experience

thex10 4y ago

> But I would really suggest anyone out there just to avoid backend-frameworks-based view/templating I personally struggle to let go of backend templating. It's so easy to translate your data into the right pieces of markup in the template, and just serve the fully-baked HTML to the user instantly. How should I be looking at this differently?

lnxg33k1 4y ago
I think few reasons that made me go with this new (for me, at the time) approach were: - Backend/API that can be consumed by anything, are frontend-agnostic - Frontend that depends on JSON/source-agnostic data so that can have functionality tested faster (no "proper"/"dynamic" backend involved, just give it some ApiBlueprint/swagger mock server - The frontend rendering isn't a concern of the backend removing some load
- Existenceblinks 4y ago
  Business-wise, I cut the JS only part as a free plan (local use only), so it's zero dollar cost. The paid plan has the Phoenix Channel integrated.
gedy 4y ago
As company gets larger, it's so nice to have "important business logic" via API only, that way mobile apps, web apps, partners, etc can use same logic/data. Server side templating is a real drag on enabling this.

andrewmutz 4y ago

> But I would really suggest anyone out there just to avoid backend-frameworks-based view/templating (guess json responses are view layers) layers Are there client-side rendered frameworks that can match the developer productivity of Phoenix or Rails for early stage, small team products? It seems they are still the best for small teams moving quickly in the early phases of a project.

lnxg33k1 4y ago
So, I am not sure what kind of developer productivity are we talking about, I think it's about what people are comfortable with and know of. I am a solo dev working on a side project with rust+phoenix backends (one doing IO-intensive/Multithreading stuff and the other presenting the info/business logic through API) and svelte frontend and svelte for me is very simple. On the other hand if there's an emphasis on developer productivity, and your team has experience on Phoenix/RoR, then you can't fight experience