Max Chernyak

https://max.engineer Hosted by amazingly convenient https://blot.im. Articles on software architecture. I'm also looking to make new friends to discuss these topics. Working remotely in my 30s from a not-major-city makes this difficult. In my blog there's a place to leave your email if you'd be up for it.

Read this article recently while doing additional research on the points brought up by other articles such as "Don’t Build A General Purpose API To Power Your Own Front End"[0] and "Splitting Your Data & Application APIs: Going Further"[1], and found it to be very insightful. [0] https://max.engineer/server-informed-ui [1] https://htmx.org/essays/splitting-your-apis/

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

Because of the simplicity, flexibility and power of the hypermedia programming model. - simplicity: e.g. something like active search can be implemented with a few attributes: https://htmx.org/examples/active-search/ - flexibility: e.g. because of the uniform interface, versioning is much less of an issue - power: e.g. deep linking is trivial Additionally, there is increasing awareness[1] that Application APIs and Data APIs have different needs and "shapes", and, once you have split them up, reconsidering using hypermedia for your application API[2] is a reasonable thing to do [1] - https://max.engineer/server-informed-ui [2] -https://htmx.org/essays/splitting-your-apis/

Here's a pretty good essay by Max Chernyak on why using a generic JSON api to power your application's front end is a bad idea. https://max.engineer/server-informed-ui tl;dr: Your JSON api has to figure out: - How to predict and enable all possible workflows - How to avoid N+1 requests for awkward workflows - How to test functionality, performance, and security of every possible request - How to change the API without breaking the existing workflows - How to prioritize API changes between internal and community requirements - How to document everything so that all parties can get stuff done And on then on the front-end, you have to figure out: - How to collect all the data needed to render a page - How to optimize requests to multiple endpoints - How to avoid using API data fields in unintended ways - How to weigh the benefit of new features against the cost of new API requests He goes on to point out that the "re-use" value of an api endpoint is extremely low. You can re-use virtually all the code that produced that endpoint to produce a different one with a different structure for precisely what you need in this new use-case.