6 ms·

> ““Zero-API” data layer lets you import server code directly into your React components instead of having to manually add API endpoints and do client-side fetc

> ““Zero-API” data layer lets you import server code directly into your React components instead of having to manually add API endpoints and do client-side fetching and caching.“ Sigh… I’m sure the author(s) of this framework mean well and sincerely believe this to be a good thing. I can tell you from having experienced php templates that did stuff like this that this is a terrible idea in practice. Worse, you won’t know it is until you’ve built quite a mess. Consider for example needing to make a change to a view but your existing view has tons of data access logic embedded right in it. Now consider if there was tons of mission critical data access code inside sub components. Right there you’ve got to do a pretty risky rewrite just to change some UI. I’m sure it’s possible to use this framework and speak to server concerns in such a way as to keep presentation and business logic concerns separate? but it’s way harder to do at scale. Thin clients are the way to go in pretty much every case I’ve ever encountered.

flybayer 5y ago
> your existing view has tons of data access logic embedded right in it. This is not at all how Blitz is set up to function. Your data access logic is clearly separated into query resolvers that run on the server. What the "Zero-API" does is in practice is handle all the HTTP stuff for you. So as a developer all you are thinking about is "function calls". The function call happens to occur over the network, but as the dev you don't have to think about the details of how that happens.
elygre 5y ago
> Sigh… That comes across as very condescending, and took all of my attention away from your actual arguments.
- brundolf 5y ago
  In the space of all the dismissive/abrasive comments on HN, I think the GP ranked pretty low
atraac 5y ago
> I can tell you from having experienced php templates that did stuff like this that this is a terrible idea in practice. Worse, you won’t know it is until you’ve built quite a mess. We use Blazor in production(admittedly for internal facing app) and it works wonders for us. We mainly share models with frontend part, it's an insane productivity boost. You don't have to embed data access or server business logic into your views. You can, but you don't have to(and you shouldn't). Even just sharing models and calling endpoints like you would call a service is just... convenient.
kfajdsl 5y ago
> Consider for example needing to make a change to a view but your existing view has tons of data access logic embedded right in it. You can separate these out. Treat public functions from your data/business logic layer as if they were an API in terms of organization. Your views shouldn't be doing any logic, they should be dumb. Overall, we've found switching to a MVC framework for new applications (React/Express -> Phoenix) has increased productivity a lot, especially with a tiny team. Then again, I'm pretty green, so if there are cases where that kind of separation isn't possible, please let me know!

flybayer 5y ago

> your existing view has tons of data access logic embedded right in it. This is not at all how Blitz is set up to function. Your data access logic is clearly separated into query resolvers that run on the server. What the "Zero-API" does is in practice is handle all the HTTP stuff for you. So as a developer all you are thinking about is "function calls". The function call happens to occur over the network, but as the dev you don't have to think about the details of how that happens.

elygre 5y ago

> Sigh… That comes across as very condescending, and took all of my attention away from your actual arguments.

brundolf 5y ago
In the space of all the dismissive/abrasive comments on HN, I think the GP ranked pretty low

atraac 5y ago

> I can tell you from having experienced php templates that did stuff like this that this is a terrible idea in practice. Worse, you won’t know it is until you’ve built quite a mess. We use Blazor in production(admittedly for internal facing app) and it works wonders for us. We mainly share models with frontend part, it's an insane productivity boost. You don't have to embed data access or server business logic into your views. You can, but you don't have to(and you shouldn't). Even just sharing models and calling endpoints like you would call a service is just... convenient.

kfajdsl 5y ago

> Consider for example needing to make a change to a view but your existing view has tons of data access logic embedded right in it. You can separate these out. Treat public functions from your data/business logic layer as if they were an API in terms of organization. Your views shouldn't be doing any logic, they should be dumb. Overall, we've found switching to a MVC framework for new applications (React/Express -> Phoenix) has increased productivity a lot, especially with a tiny team. Then again, I'm pretty green, so if there are cases where that kind of separation isn't possible, please let me know!