3 ms·

Splitting Your Data and App APIs Up: Going Deeper

dang 5y ago
The other article mentioned was discussed here: Don't build a general-purpose API to power your own front end - https://news.ycombinator.com/item?id=28511570 https://news.ycombinator.com/item?id=28511570 - Sept 2021 (106 comments) Also the other other article: Why I No Longer Use MVC Frameworks - https://news.ycombinator.com/item?id=11104356 https://news.ycombinator.com/item?id=11104356 - Feb 2016 (194 comments) Why I No Longer Use MVC Frameworks - https://news.ycombinator.com/item?id=11041999 https://news.ycombinator.com/item?id=11041999 - Feb 2016 (2 comments) Why I no longer use MVC frameworks - https://news.ycombinator.com/item?id=10740029 https://news.ycombinator.com/item?id=10740029 - Dec 2015 (92 comments)
recursivedoubts 5y ago
heya HN: in this article I argue for using hypermedia for your application API, once you've realized that your app and your general data APIs have different needs would love feedback
- harryvederci 5y ago
  Thanks for htmx! I recently noticed a similar issue in my side project, your timing with this article was perfect for me :)
- henryfjordan 5y ago
  I think the article which yours is based on is attacking a bit of a straw-man, at least now that 5 years have passed. The original complains of needing to write an application-specific API in addition to a general-purpose API but techniques like Redux/Sagas or GraphQL have helped to build that "Application Specific" data-layer in the frontend on top of general APIs. Now-a-days you query that general API and build your application-specific data layer in the browser before rendering that to HTML using React or a similar framework. In this new world, sending Hypermedia instead of JSON over the wire is still a very compelling idea (why send JSON and make the browser process it?) but maybe it would be best to explore how to accomplish that from within a React-Server-Side-Rendering layer instead of pushing that logic all the way down to the Backend-API layer.
bvrmn 5y ago
Yep, from one end backend devs don't want to provide API tied to current month UI, on other end they tend to religiously stick to "REST" API and frontend guys need to fetch zillion requests. You can do marvelous things with simple `GET /api/model?ids=1,2,3`.
eyelidlessness 5y ago
I’m curious whether the author has thoughts on: 1. The conceptual overlap between this and React Server Components, which seems to have arrived at similar implementation details from a different set of use cases. 2. Generalizing even further by client libraries allowing you to return existing DOM nodes instead of requesting anything from any networked API. I’m coming from a perspective where my main interest is performance of mostly static MPA websites, and where isomorphic libraries typically double bundle static content. Just as sending HTML instead of JSON on the wire might have huge optimization benefits, so too would having primitives for transferring nothing at all.
1vuio0pswjnm7 5y ago
Use a Gemini site as an "endpoint" for a "modern" website, web "app" or whatever. There at least one user who would skip the Javascript go straight to the Gemini site.

dang 5y ago

The other article mentioned was discussed here: Don't build a general-purpose API to power your own front end - https://news.ycombinator.com/item?id=28511570 https://news.ycombinator.com/item?id=28511570 - Sept 2021 (106 comments) Also the other other article: Why I No Longer Use MVC Frameworks - https://news.ycombinator.com/item?id=11104356 https://news.ycombinator.com/item?id=11104356 - Feb 2016 (194 comments) Why I No Longer Use MVC Frameworks - https://news.ycombinator.com/item?id=11041999 https://news.ycombinator.com/item?id=11041999 - Feb 2016 (2 comments) Why I no longer use MVC frameworks - https://news.ycombinator.com/item?id=10740029 https://news.ycombinator.com/item?id=10740029 - Dec 2015 (92 comments)

recursivedoubts 5y ago

heya HN: in this article I argue for using hypermedia for your application API, once you've realized that your app and your general data APIs have different needs would love feedback

harryvederci 5y ago
Thanks for htmx! I recently noticed a similar issue in my side project, your timing with this article was perfect for me :)
henryfjordan 5y ago
I think the article which yours is based on is attacking a bit of a straw-man, at least now that 5 years have passed. The original complains of needing to write an application-specific API in addition to a general-purpose API but techniques like Redux/Sagas or GraphQL have helped to build that "Application Specific" data-layer in the frontend on top of general APIs. Now-a-days you query that general API and build your application-specific data layer in the browser before rendering that to HTML using React or a similar framework. In this new world, sending Hypermedia instead of JSON over the wire is still a very compelling idea (why send JSON and make the browser process it?) but maybe it would be best to explore how to accomplish that from within a React-Server-Side-Rendering layer instead of pushing that logic all the way down to the Backend-API layer.

bvrmn 5y ago

Yep, from one end backend devs don't want to provide API tied to current month UI, on other end they tend to religiously stick to "REST" API and frontend guys need to fetch zillion requests. You can do marvelous things with simple `GET /api/model?ids=1,2,3`.

eyelidlessness 5y ago

I’m curious whether the author has thoughts on: 1. The conceptual overlap between this and React Server Components, which seems to have arrived at similar implementation details from a different set of use cases. 2. Generalizing even further by client libraries allowing you to return existing DOM nodes instead of requesting anything from any networked API. I’m coming from a perspective where my main interest is performance of mostly static MPA websites, and where isomorphic libraries typically double bundle static content. Just as sending HTML instead of JSON on the wire might have huge optimization benefits, so too would having primitives for transferring nothing at all.

1vuio0pswjnm7 5y ago

Use a Gemini site as an "endpoint" for a "modern" website, web "app" or whatever. There at least one user who would skip the Javascript go straight to the Gemini site.