Why OOP HTTP frameworks?

yujiri8 profile image Ryan Westlund ・1 min read

Some HTTP frameworks (for example, Grip and Amber) bill themselves as "object-oriented". I'm really not sold on this. When I look at the code examples, it seems to mean "does the same thing as Kemal but way more verbose".

My take is that OOP makes no sense for an HTTP framework because an API is fundamentally a set of functions (endpoint handlers), not a world of objects.

What do you think?


Editor guide
tofraley profile image
Taylor Fraley

If you're saying that handling HTTP requests fits an FP approach really well, I agree with you there. I wouldn't go so far as to say that OOP doesn't make any sense there, though. There are tons of OOP web frameworks, so it seems like they make sense to a lot of people.
I know we like to talk about using the right approach for the job, but that's not usually so obvious. OOP folks are quick to say that UIs are inherently OOP and FP makes no sense for a UI. But, in my opinion they often have a limited understanding of FP. They've never used Elm or something Elm-like, for example. They often confuse classes and types, and assume FP languages can't accurately model data.
I'm not saying there is no right answer. I'm saying it's easy to tell ourselves that the right answer is obvious.

jrop profile image
Jonathan Apodaca

Agreed. This is in general how I feel about NestJS/Angular, but only slightly better than the frameworks you posted. In frontend, this is why I prefer React (+ all of the React-like frameworks): it's functions all the way down.