DEV Community

loading...

Discussion on: Good Bye Web APIs

Collapse
sarafian profile image
Alex Sarafian

If I understand this correctly, the client pushes it's state over the "wire" to the server. Isn't this what ASPX Forms did in the past? Everyone loved the convinience but everyone ran away at the end?

  1. Serialize state
  2. Transmit (POST with state)
  3. Deserialize
  4. Process on server
  5. Serialize state
  6. Transmit (Response with state)
  7. Deserialize
  8. Render

ASPX is almost 25 years old and it was build for wired intranet and failed with the advance of the public internet. One of the reasons was that the client had to transmit often too much data and that was slow and had other problems as well. Back then java script was not easy but js evolved just to be able to drive a client's inteligence within the browser and only ask for the data that is necessary to drive the inteligence. ASPX Forms was also customizable and you could control what goes in and what goes out but we all know how it goes. Even before google development became a thing, people would just copy code if it seemed to work somewhere.

Obviously things are different nowadays and MS is doing something similar with the Blazor, where you get to choose if "server-side" rendering happens. As far as I understood Layr, doesn't do server side rendering, only server side processing.

I personally consider a frontend and backend API the same. I don't understand why people make these distinctions. Same nfr rules should apply, like versioning. The only difference is who is the audience of the API or what is the business it tries to serve. With front end, that is data optimized for one audience (the client) and the backend is for all. This difference changes many of the nfr and lifecycle as well but conceptually it is the same.

I always consider layers important. Maybe not convienient to developers but still very important with longivity in mind. Layr takes this transparency away and that makes it a problem for this requirement. I expect that, for most with architectual background, removing/hiding the FE API would raise red flags.

The counter example is very easy and doesn't automatically raise the alarms for many but experience does and my advice is to market this with more complicated examples and make sure that you show that primarily you are in control of what is put in the wire. Gut feeling, this code will lead you back to the

But the worst thing is that the API layer generally forces you to degrade the quality of your codebase. Indeed, it's quite challenging to keep your code DRY and cohesive when your frontend and your backend are separated by a web API.
Enter fullscreen mode Exit fullscreen mode

I hope you find the feedback useful, even if I'm not correct. History has lots of good paradigms to learn from. I'm not this is silly. God knows when I was young some attempts I had to framework some things and I learned from the effort, the feedback, the failures and the success.

Collapse
mvila profile image
Manuel Vila Author

Thanks, @safarian, for this long comment but I'm not sure to fully understand your point.

Except for the ability to expose a backend to some third-party developers, what are the benefits provided by an API layer?

Collapse
sarafian profile image
Alex Sarafian

Structure, control, real segregation of concern.

I'm not sure as what you are asking. I mentioned that BE/FE API are both important and if you try to hide/remove the FE API on the principal of developer convienience, then many architects would get worried.

Very simplified, just because it is FE API, it is not there to remove because it is inconvienient. :)

Though some words might be considered judgemental, I'll remind you that they are not used like that.

Thread Thread
mvila profile image
Manuel Vila Author

I am sorry but you didn't convince me. I can agree that for some complex projects with a large team an API layer can provide some useful guardrails, but for 95% of the web apps, I believe that an API layer is just an unnecessary burden.

Thread Thread
sarafian profile image
Alex Sarafian • Edited

In my original comment I mentioned long term and there is our different in mental approach and probably our professional engagement.

There is no argument against the context you describe but I consider them under the classifications of "quick and dirty", "fire and forget".

I'm not trying to convince you. Just sharing experience: ) :) . I probably wouldn't have convinced my younger self as well.

Thread Thread
mvila profile image
Manuel Vila Author

I won't bet you're older than me. :)