4 ms·

I have seen people arguing that you shouldn't be using the same API endpoints for front-ends and for integration. I can see arguments both ways though... https

I have seen people arguing that you shouldn't be using the same API endpoints for front-ends and for integration. I can see arguments both ways though... https://max.engineer/server-informed-ui https://max.engineer/server-informed-ui

k__ 3y ago
Didn't GraphQL solve this issue already anyway?
- fl0ki 3y ago
  How? GraphQL is just another way to make query API with structured output, almost always JSON in practice. If you wanted server-side rendering, you still need another endpoint even if it happens to use GraphQL internally, just like you could made a rendered endpoint using another form of API internally.
- b33j0r 3y ago
  Have you implemented it? The orm aspect is actually pretty weak. You end up implementing an RPC api anyway. And then you wonder how this was sold to you as declarative and idempotent. I exaggerate here because graphql does not solve the datalake problem. And it doesn’t do graphs (you can). The curb appeal looked super promising, but then it was just rpc with a bespoke ORM syntax.
b33j0r 3y ago
I mean, I’ve built both ways. The least productive thing I have seen from the debate involves two teams doing the same thing, but one team are python nerds making an API and the other are node nerds making an API. N’er the twain shall meet, right? I don’t mean to exaggerate, but your code will tend to mirror your organization structure. I have worked at companies where I thought our product was great because the API rocked. Then in my last 3 months I got to meet the frontend (definitely a jobsmell: not seeing the frontend every day.) Definitely misjudged the quality of our product, because apparently we wrote two different products (shrug) ;) Pretty strong argument for htmx, actually. But again, in a weird way where we fire the frontend and become actual full-stack engineers for everrrrything.
- arethuza 3y ago
  https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

k__ 3y ago

Didn't GraphQL solve this issue already anyway?

fl0ki 3y ago
How? GraphQL is just another way to make query API with structured output, almost always JSON in practice. If you wanted server-side rendering, you still need another endpoint even if it happens to use GraphQL internally, just like you could made a rendered endpoint using another form of API internally.
b33j0r 3y ago
Have you implemented it? The orm aspect is actually pretty weak. You end up implementing an RPC api anyway. And then you wonder how this was sold to you as declarative and idempotent. I exaggerate here because graphql does not solve the datalake problem. And it doesn’t do graphs (you can). The curb appeal looked super promising, but then it was just rpc with a bespoke ORM syntax.

b33j0r 3y ago

I mean, I’ve built both ways. The least productive thing I have seen from the debate involves two teams doing the same thing, but one team are python nerds making an API and the other are node nerds making an API. N’er the twain shall meet, right? I don’t mean to exaggerate, but your code will tend to mirror your organization structure. I have worked at companies where I thought our product was great because the API rocked. Then in my last 3 months I got to meet the frontend (definitely a jobsmell: not seeing the frontend every day.) Definitely misjudged the quality of our product, because apparently we wrote two different products (shrug) ;) Pretty strong argument for htmx, actually. But again, in a weird way where we fire the frontend and become actual full-stack engineers for everrrrything.

arethuza 3y ago
https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law