Sort of. It's a bit different this time around. When Rails came about we didnt fully understand the nuances of client side state management and full capabilities of JavaScript in the browser. Rails hasn't really adapted to that where these solutions are sort of coming from the perspective of having those learnings and trying another crack at it. I think a lot has been learned in the last decade which changes how we'd approach certain parts of the problem.
That being said I am expecting people to borrow some of the ease of use tools from Rails. Once you've unified things again, that sort of scaffolding including stuff like databases right into your solutions via easy CLI commands become a thing again.
I think the difficulty has been that developing APIs are like developing a UI. There are a lot of particulars around the design. It's more than just getting something functional up. There is an aesthetic to it. You are building a product.
When these solutions are going to be autowiring up solutions, sort of rebuilding the monolith we're back to a place where you can bootstrap everything. It's probably obvious to someone doing Rails but the cost of having a separate API is that you doubled your product surface. Perfectly fine if you are making an API product but for many things it's unnecessary and with that boundary to contend with things get more complicated.
Nothing says these technologies need to be used monolithically just a matter of understanding what the proposed surface area is.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sort of. It's a bit different this time around. When Rails came about we didnt fully understand the nuances of client side state management and full capabilities of JavaScript in the browser. Rails hasn't really adapted to that where these solutions are sort of coming from the perspective of having those learnings and trying another crack at it. I think a lot has been learned in the last decade which changes how we'd approach certain parts of the problem.
That being said I am expecting people to borrow some of the ease of use tools from Rails. Once you've unified things again, that sort of scaffolding including stuff like databases right into your solutions via easy CLI commands become a thing again.
I think the difficulty has been that developing APIs are like developing a UI. There are a lot of particulars around the design. It's more than just getting something functional up. There is an aesthetic to it. You are building a product.
When these solutions are going to be autowiring up solutions, sort of rebuilding the monolith we're back to a place where you can bootstrap everything. It's probably obvious to someone doing Rails but the cost of having a separate API is that you doubled your product surface. Perfectly fine if you are making an API product but for many things it's unnecessary and with that boundary to contend with things get more complicated.
Nothing says these technologies need to be used monolithically just a matter of understanding what the proposed surface area is.