3 ms·
Sounds like your architect was a bad fit. Uncomfortable with Docker? Today? Or microservices? Or mixing Kotlin with Java? I haven't used gRPC myself, but it l
by SomeCallMeTim 8y ago
Sounds like your architect was a bad fit.
Uncomfortable with Docker? Today? Or microservices? Or mixing Kotlin with Java?
I haven't used gRPC myself, but it looks like a strong standard. I have used Protocol Buffers in the past, though, and I certainly wouldn't be afraid of it just because I hadn't used it.
I've seen this kind of ultra-conservative outlook with Java developers fresh from enterprise jobs. Worked with one developer briefly who insisted that every new API would take at least two weeks of work. Even if the API was completely trivial CRUD. When I mentioned that I was using a framework that could stand up a new CRUD API in minutes, complete with authentication, validation, and user-based access protection, the developer called me a liar.
Which was funny because I'd just done _exactly that_ for another client, standing up the entire stack _and_ creating ~40 CRUD REST APIs (with parallel Socket.io APIs for real time updates) in about 8 hours. Adding or changing a model for one of the databases from that point forward just required a few lines of model specification code; additional custom code per-API was entirely optional. Of course I wasn't using Java Spring, so that may have been an unfair advantage, but there's a reason I don't use Java Spring...
- nevi-me 8y agoInteresting that you talk about Java Spring, because I was partly lambasted for not using a Java framework. I thought Spring is good. What's wrong with it?
- SomeCallMeTim 8y agoIt's slow (execution speed [1] -- it's slower than Node.js by a lot!), and every developer that I've spoken to has given very, very long estimates (from my POV) for accomplishing even trivial API work, so it seems to be prone to low development velocity. It's possible that every single Java developer I've worked with is nigh incompetent, but they had jobs at places like Oracle, Amazon, and high-end consulting companies, so I'm not sure where the strong Spring developers are hiding. I don't know the internal architecture, but given the poor benchmark results, I'd hazard a guess that Spring also functions as a thread-per-connection server, which means resource use would be very high for real-time applications (compared to Node.js or an event-based Java framework). And most applications today require at least a real-time component, so if you need 10x-50x as many application servers because you need an OS thread per concurrent connection, that's a huge additional cost. [1] https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ -- Java and C++ tend to be the fastest in the benchmarks, but Spring is so slow that it hits between 2-16% of the top platform speeds, depending on benchmark.