3 ms·
Sure, it's going to take a while the first time, because your gradle cache hasn't be populated yet. You should find subsequent builds to be much, much faster. I
by mindcrime 5y ago
Sure, it's going to take a while the first time, because your gradle cache hasn't be populated yet. You should find subsequent builds to be much, much faster. If not, something is wrong with your setup.
Startup time? I personally don't care about startup time for a long-running server process; at least not if we're just talking a few seconds. The JVM is better at optimizing long-running processes than things that are starting and stopping frequently (although to be fair, JVM cold startup time has improved dramatically in later JVM releases).
Anyway... if you'd rather write Go, then write Go. Presumably nobody has a gun to your head making you work with Spring / Java. shrug
- sriram_malhar 5y agoThanks for your response. Alas, Go is not an option for me ... I only have access to Java programmers. They know Spring Boot better than I do, but their systems reek of complexity, and I suspect that is because there is a huge weight of enterprise practices that they feel they should conform to. For example, in a latency critical path, I identified 4 microservices in a chain; it seemed to me that all one needs in that situation -- they all have similar scaling needs -- is a simple modular structure where one module enqueues an in-memory request for the next task in the chain. No json, no network etc. Their response? "Monolith bad, microservice good". If you want microservice, spring boot it is. And they must be packaged with docker, and managed by a cluster manager. I blame the complexity of these enterprise models because they lead these engineers to believe that simple solutions are not possible.
- mindcrime 5y agoFair enough.