For whatever reason, Rails really "fits my brain", which is one of DHH's talking points. I think it's great for building when you know your needs are going to fit generally established web patterns (CRUD, index and show views, etc.) but you don't know exactly what you need. It's really easily to quickly build out a wing on the application when you need it. It's not the "soundest software" per se, in that it's basically built around lots of tight coupling (we call them conventions π)
So I'd say it works for us and I wouldn't poo poo it based on reputation, but if it isn't the kind of environment you like to work in, don't force it. So much of software development is psychological.
I think it's pretty easy to build a GraphQL endpoint. We built one pretty quickly for a project and it went pretty smoothly. I think your mileage might vary on performance in this regard but I wouldn't think Rails itself is the bottleneck. If you put GraphQL in front of, say Postgres, you might be creating some query inefficiencies in the form of some leaky abstractions. This could be dealt with through some caching but you wouldn't get it for free. I would think if GraphQL was layered on top of a different type of DB, it would be more efficient. But I don't know the nitty gritty of this.
Ruby's bad for concurrency and generally running lots of code, but in this case, the query is going to be the bottleneck and I think that would be language/framework agnostic.
For whatever reason, Rails really "fits my brain", which is one of DHH's talking points. I think it's great for building when you know your needs are going to fit generally established web patterns (CRUD, index and show views, etc.) but you don't know exactly what you need. It's really easily to quickly build out a wing on the application when you need it. It's not the "soundest software" per se, in that it's basically built around lots of tight coupling (we call them conventions π)
So I'd say it works for us and I wouldn't poo poo it based on reputation, but if it isn't the kind of environment you like to work in, don't force it. So much of software development is psychological.
Why do you say so much of software development is psychological?. Really interested in that statement.
What about the performance? Is it hard to create a GraphQL endpoint (e.g. mysite.loc/graphql, using graphql gem) with RoR?
I think it's pretty easy to build a GraphQL endpoint. We built one pretty quickly for a project and it went pretty smoothly. I think your mileage might vary on performance in this regard but I wouldn't think Rails itself is the bottleneck. If you put GraphQL in front of, say Postgres, you might be creating some query inefficiencies in the form of some leaky abstractions. This could be dealt with through some caching but you wouldn't get it for free. I would think if GraphQL was layered on top of a different type of DB, it would be more efficient. But I don't know the nitty gritty of this.
Ruby's bad for concurrency and generally running lots of code, but in this case, the query is going to be the bottleneck and I think that would be language/framework agnostic.
Thanks for your answers! I think I'll give RoR a try for my next project.