Build your app using whatever you're most comfortable with because in the end an existing product is better than no product. Will you enjoy spending an extra hour per day working with this framework over another? That's an hour more of progress.
Personally I think Spring Boot with Kotlin is a way better choice today for monoliths that transition well to micro services. But if you're already deep in the RoR world just go with that.
Running into stack or framework-related scaling problems is an honor and a huge accomplishment. Those are good problems and there are many ways to solve them, which will be extremely motivating at that point because people are actually using your thing.
Really? I'm doing Java contract work for a living (thankfully not only Java) and, while it pays the bills, I'd use almost anything else (except .net which is just Java without the ecosystem). I think the whole Java stack, with its myriad of metaprogramming silos, overreaching build pipelines, outdated HTTP libs and paradigms, absurd class loader configs and layers of module systems, unsound abstractions, and third-party libs, many of which are starting to reach EOL, really stinks and sends you into a world of incidental complexity. It might not be so obvious if you're coding greenfield Spring "microservice" apps or, good forbid, Spring MVC apps in 2019, but believe me it'll hurt you down the road once you need to update your project to newer versions of third-party libs.
The problem with Spring isn't that it's badly developed (it isn't, and usually gives you good diagnostics, though your stack traces gets spoiled with Spring's ugly-as-sin reflection shite). The problem is that there are people who think Spring has a reason to exist in the first place. Spring Boot is a config framework on top of the Spring framework to make it bearable - that alone should tell you to stay away from it.
I know all too well ); Only three years ago I contracted for an insurance company for JSF, and worse, using portlets under Websfear. Well, it payed the bills.
I use Grails which is very similar to Rails and a lot easier and productive than Spring Boot. Good defaults makes application building a much smoother experience. Grails is still Spring Boot, and you can still code like it was a pure Spring Boot application.
Grails has its own ORM called GORM, which can use several different backends like Hibernate/MongoDB
Groovy is a great language, with the best from dynamic languages and yet still very similar to Java. I would say there is no learning curve for Java developers with Groovy.
Grails has also been highly optimized the last few years and runs great on systems with 1 vcpu and 256MB RAM. Grails also has a great and friendly community, come and say hello in our Slack channel https://grails-slack.cfapps.io/
I've had some not-so-great experiences developing web services with Spring Boot, Hibernate, Groovy itself, Grails.
We now stick to plain old Java with no annotations, Ratpack, jOOQ, etc.
In my experience, and opinion: Lack of static typing is a good way to make shooting yourself in the foot easy. Annotation-driven magic sucks. Just Writing Queries causes fewer headaches than using an ORM. Basically, libraries over frameworks. YMMV.
I do understand why you feel like that, I've been there too. No framework is a silver bullet, but over time you will see the value in them.
One thing though, with Groovy you can choose between dynamic and static typing. These days everyone agrees that you should use static typing with Groovy as much as possible. Use dynamic typing when static typing becomes hard, for example when working with JSON objects.
And Hibernate is really flexible with how close you get can native queries, the documentation however is not convenient there. But Hibernate developers like Vlad Mihalcea is working hard to document how you can do this and is writing blog posts and answering questions on Stack Overflow. I am really grateful for the effort he puts in helping everyone.
I'll second the thought on Kotlin, and in fact I just trained a diverse team of PHP, RoR, and Python developers on Kotlin with Spring Boot, and our platform migration project to Kotlin massively reduced our LoC and increased each engineers understanding of the platform. We broke off a couple pieces into microservices which need to scale independently, and it was a great experience. I'm hoping Kotlin continues to grow in adoption.
Java has JPA (Java Persistence API) which is an abstraction layer over various ORMs. However, most people use Hibernate. Hibernate is nice because it also gets out of the way when you need it to, like when you're inserting or selecting a massive amount of data. It also supports the Stream API now, which is super convenient.
I've found Admin interfaces on the same server to turn into liabilities and infosec in bigger orgs usually has strict rules around segregating admin access off into its own subnet with restricted access only to internal traffic.
That said, for simple monololiths I use Jhipster, which auto generates Admin pages for you similar to ActiveAdmin.
I recommend to not use an ORM. Really, with a modern language, an ORM is mostly redundant. If on Spring boot, simply use JDBCTemplate and TransactionTemplate to deal with raw SQL queries and transactionality. Get rid of all the annotation magic around this.
Then you need a bare minimum of mapping code. Mostly this boils down to a single line of code to call the relevant constructors while you extract columns from your rows in a type-safe way. Kotlin makes this stupidly easy. I'd argue this type of code is actually easier to maintain than misc annotation cruft all over your codebase. One way or another you end up expressing in some place that column foo is of type Int and goes into some property of a class MyLovelyFoo with a foo field. So MyLovelyFoo(foo=row.getInt("foo")) kind of does that in a really compact way and there's not a lot more to it. Of course Kotlin having default arguments, sane property handling, immutable data classes, etc. helps a lot. Mostly ORM made sense when people were doing JavaBeans on Java.
The problem with many Java persistance frameworks is the amount of magic that happens that leads to hard to understand bugs, sub optimal joins, and other stuff that just isn't worth having. A side effect of using an ORM is also overengineered table structures because people are pretending they are doing OO and thus end up with way to many tables and columns, fragile and more frequent migrations, and a lot of silly joins. This magnifies all of the above problems.
If you know what you are doing, you can actually fix this of course and do it properly even while using an ORM like hibernate. At this point you lose most of the advantages of using an ORM because now you are knee deep into framework complexity and trying to coerce it to do the right thing while spending disproportionate amounts of time inspecting and guiding all the magic it does for you. I've been parachuted in more than a few hibernate projects gone bad. The fix is always pruning back all the copy paste annotation magic propagated by juniors, vastly cutting down on the number of model classes, use of inheritance and the silly hacks that come with that, fixing the transactionality, etc.
I have dynamically generated queries that span over 200 lines. Doing this without a query builder is pure madness. It doesn't matter how modern your language is, manually concatenating SQL shouldn't happen in 2019.
100% this. Whenever folks recommend simpler options like JDBI, I have to shake my head. Rolling your own query builder with string templates feels like an SQL injection attack waiting to happen. If you know 100% going into a project that you won't have to modify the structure of your queries based on user input, then it's an acceptable option. But it's quite common, at the very least, to have user input that results in variable number of terms in where clauses.
Hibernate is quite powerful and the tooling in IntelliJ (or Eclipse) catches many common mistakes at edit time. Where most folks get themselves into trouble is with all the caching setup. Not surprising, but if you want to just use Hibernate as a cache-less mapper there's always the StatelessSession interface.
I also don't get the oft-repeated notion that ORMs result in bad table design. You can map any tables you can dream up. And if you insist on doing inheritance, Hibernate has 4 different strategies for mapping to classes. Certainly one of those has the performance characteristics you're looking for.
Do those queries need to be that long or is that just a limitation of your ORM tool and the table structure it generated so you can pretend to have an object database? I've simplified quite a few domain models to fit the querying needs and gotten rid of lots of tables, joins, etc. in the process. There's no wrong or right here but my observation with ORM is that it leads to needlessly complicated table designs, which in turn makes querying the database needlessly hard.
Often long queries with convoluted joins are a good sign something is wrong with your table layout. ORM lets you get away with some bad design but it always catches up with you eventually.
If you're going this way I would still recommend a library like jOOQ.
It gets out of the way and is very low-level, but it still allows you to build type-safe SQL instead of having to randomly concatenate strings in order to build your query.
This is especially useful if you have dynamic joins and things like that, which can get hairy fast if you're building them manually.
+1 for jOOQ. I prefer to Just Write Queries than muck about with quirky ORM magic that gets turned into queries. jOOQ lets me do that with safe query building and type checking through to the DB level (with code gen).
Personally I think Spring Boot with Kotlin is a way better choice today for monoliths that transition well to micro services. But if you're already deep in the RoR world just go with that.
Running into stack or framework-related scaling problems is an honor and a huge accomplishment. Those are good problems and there are many ways to solve them, which will be extremely motivating at that point because people are actually using your thing.