91–100 of 107 posts
I daresay that if you need to: a) scale, and b) adapt over time you're going to find yourself decoupling and slapping APIs on both ends to adapt to the transport mechanism. So for a boutique app, you might get away with a client-server model.
one word: security
Because the separation is more or less obligated if people wanted to do interactive web pages, instead of people want to separate them as different services for different problem domains.
People who don't like write JavaScript can stay tuned, as WASM age comes, there would be a burst of things like this but not in JavaScript (eg: Blazor).
RPC - this isn't anything new. When I started doing web development in the late 90s for about ~5 years I was the designer, front-end, and backend developer all in one. Then over time things changed to allow for specializations and we now have many different functions, and that's a good thing. RPC has a place, and it's not for web apps, at least most of the time. I've noticed over the years that JavaScript developers…
Wouldn't you prefer to talk in your mother language instead of using a new language for every country you visit?
Earlier quoted context omitted.
As someone coming from web dev to back-end JS I take with me the love for instant feedback, which allows for extensive manual testing during development. And I also use automatic regression tests before pushing to prod. Node.js is infamously known to use small modules, it however gives you battle tested code run by thousand in production. I usually take a front-end first aproach, but there are also lots of people tak…
Instant feedback is pretty common on backend thought? I know that at least Flask and Django in Python have it. And automated regression tests before pushing are in ever other language as well.
Earlier quoted context omitted.
What ever happened to Meteor? It was flavour of the month a few years ago, with many a frontend dev ranting about how great it was. Now seems to be forgotten about.
I ran into a company recently that was still using Meteor (B2B with roughly 50 million USD of funding). It made me realize the consequences of choosing a technology for a major project before it's gotten widespread acceptance. Made me realize I need to be a bit more cautious, and that I've gotten very lucky.
Earlier quoted context omitted.
At first, but not if it made it harder to communicate in each country I visited if I was visiting those countries regularly. I think the parent is likely onto something in that the spread of JS into backend services is not beneficial to those who spend most of their time on the backend, but it beneficial to those who don't. That's IMO creating an inherent tension. Personally I have never understood backend JS as you…
As someone coming from web dev to back-end JS I take with me the love for instant feedback, which allows for extensive manual testing during development. And I also use automatic regression tests before pushing to prod. Node.js is infamously known to use small modules, it however gives you battle tested code run by thousand in production. I usually take a front-end first aproach, but there are also lots of people tak…
> the love for instant feedback
What languages can you not get this with?
> And I also use automatic regression tests before pushing to prod.
That's 100% language agnostic...
> Node.js is infamously known to use small modules, it however gives you battle tested code run by thousand in production
Many other languages have extensive packages pulled in, but that says nothing about how battle tested the code is unless all of the packages have high use. Python has plenty of packages with the same use level. Java has tons as well. The list goes on.
I'm the author. I'm glad to see that RPC is getting more and more traction.
As other have noted, someone caught on to the simplicity of RPC. It always baffled me how so-called RESTful APIs became popular, despite virtually all of them being RPC APIs with a veneer of rather pointless HTTP semantics. Virtually none of those APIs do anything to serve the intentions and goals behind REST[1]. Furthermore, many RESTful APIs end up being wrapped into language-specific clients anyway, because they h…
That said, for an API consumed by third-party developers, REST makes a lot of sense. Otherwise, which is like 98% of the APIs out there, RPC really is superior.
I've implemented a tool similar to what OP is building: Wildcard API [1]
> rather pointless HTTP semantics.
Agree. Actually, while implementing Wildcard API, I made sure to abstract away all HTTP semantics. With Wildcard, you don't think in terms of "HTTP verbs" but you think in terms of functions. Like you are naturally used to.
> It always baffled me how so-called RESTful APIs became popular
I believe REST became popular because it got lot's of exposure since all third-party APIs were using REST.
As other have noted, someone caught on to the simplicity of RPC. It always baffled me how so-called RESTful APIs became popular, despite virtually all of them being RPC APIs with a veneer of rather pointless HTTP semantics. Virtually none of those APIs do anything to serve the intentions and goals behind REST[1]. Furthermore, many RESTful APIs end up being wrapped into language-specific clients anyway, because they h…
Simplicity? Have you ever tried to integrate distributed applications that do not share the same codebase?
And calling REST anti-pattern tells me that you aren't that familiar with alternatives.
>despite virtually all of them being RPC APIs with a veneer of rather pointless HTTP semantics.
If you want to do RPC over HTTP and pretend that it is REST interface, it isn't really a problem of REST.