Is it better than React functional components in any way? I don’t see benefit over React functional components or even Lit’s class components

Library built this way because it supposed to be flexible and provide ground for complex usecases. It can only be flexible if your API works with simple abstractions which you can then compose. It’s not driven by “I need this specific utility for this specific scenario”. That would be zoo you have in JS where you have 10 ways to iterate over array and 9 of them wrong for your scenario.

Java’s OO is great because they design library with SRP in mind making sure there is few but good ways to do things.

BufferedReader cannot accept file name because it makes arbitrary reader… well buffered. It’s not BufferedFileReader, even that would accept something like Path or File, not string, because File can be remote file, should Reader now know all possible local and remote protocols and path formats? What else it must do?

Having it designed the way it is, allows Java to have utilities for various scenarios. Your scenario covered by standard lib too. See Files.readAllLines which, surprise-surprise, built on top of BufferedReader.

Char count is poor complexity metric. Perl is better than Python with your logic as it is more condensed.

Can anyone actually tell what exactly complicated in Java? Verbose, maybe it was at some point but I find it very straightforward and easy.

I don’t know german but it seems to be more logical to have one word for “health insurance card” since it describes one class of objects. Better than spelling 3 nouns where one partially describes what object is and other nouns act like clarification

Though in reality, management will push back any unorthodox approaches/solutions/approaches as risk and additional losses on R&D.

‘’’ Note: When I say “top-level” I am talking about the URL that you see in the address bar. So if you load fun-games.example in your URL bar and it makes a request to your-bank.example then fun-games.example is the top-level site. ‘’’ Meaning explicit creds won’t be sent. Even if fun-games knows how to send explicit creds, it can’t because fun-games does not have access to creds which stored for your-bank. Say suppose your-bank creds stored in local store. Since current URL is fun-games it can only access local storage of fun-games, not your-bank.

Thank you! I was always wondering why the heck this (mostly) useless and broken mechanism exists. I had hesitations about disabling it but had doubts about my understanding. Now I know I’m right

“Stateless” is not what “I” want, it is part of definition of REST.

Can do != what spec says you should do. You can also send clown version from the post but don’t be surprised people will find it… funny

Again, I’m not telling you are doing wrong. I’m telling you are mixing REST and RESTful web services

REST calls are same as in 2001. There is no REST 2.0 or REST 2024. Because REST is architecture guideline. It’s just more data sent over it today. HTTP code IS code. Why your system issued it is implementation detail and have nothing to do with resource representation. Examples you provided are not 403. “Too many users active” does not exist in REST because REST is stateless, closest you can get is “too many requests” - 429. Insufficient permissions is 401. I don’t even know what is “blocked by security” but sounds like 401 too. Regardless, you should not provide any details on 401 or 403 to client as it is security concern. No serious app will tell you “password is wrong” or “user does not exist”. Maximum what client should hope for is input validation errors in 400.

For those with “internal tool, I don’t care” argument - you either do not know what security in depth is or you don’t have 403 or 401 scenario in the system in the first place.

Now hear me out, you all can do whatever you want or need with your API. Have state, respond with images instead of error codes, whatever, but calling it REST is wrong by definition

Do you have to unlock? You can open wallet from blocked screen without unlocking phone

Do you have to unlock? You can open wallet from blocked screen without unlocking phone

Folks really trying to argue about example code. Even created “global state” straw man. Here is secret - if you are using global state then code is shit in the most cases.

Kinda, I guess we all can agree it’s more typical to deserialize into POJO where theres is no such thing as missing field. Otherwise why would you choose Java if you don’t use types. This great precondition for various stupid hacks to achieve „patching” resources, like blank strings or negative numbers for positive-only fields or even Optional as a field.

Agree. I find “get started” usually is the best way to give an example of “entry point” to API. After that API documentation should get anyone covered for most of the cases. If API is big then it probably has primary and secondary set of features. Secondary then can be covered as tutorials.

How about SQL in PostgreSql? query: select array_length(Array[]::text[], 1) Output: null

Dont get me wrong JS is still awful

No it’s how Python wants you to format. Many times I want to separate two logical sections in one function and can’t coz Python go crazy

MAYBE :)

My colleague was working on migrating around dozens of batch jobs written in Java. All jobs had JPA/Hibernate but people which were writing those jobs didn’t understand abstraction and encapsulation. It end-up as vendor locked as you can imagine. Procedures, reading cursors, Oracle specific functions, metadata, logic spread between Java and PL/Sql, all the fun stuff, you know. So it took around one year of work to migrate to Postgres. And that’s with support of DBA who was helping with rewriting most complicated queries and procs. So yeah, don’t worry about that DBMS specific features.

Don’t get me wrong, though. Efforts spent on making design decisions should be proportional to potential size/complexity growth of the software. If you building todo list , how many different queries you might have in fairly pessimistic scenarios? Maybe couple dozens. Don’t bother with JPQL or HQL. If you expect your app to grow significantly. I’d do as much as possible to avoid my colleague’s fate.

I don’t think loop vs recursion choice is what significantly impacts performance in most cases. Most of the software I saw, suffer performance because of wrong API design or overall architecture. If app needs to fetch 100 objects from API which can provide only one object at the time no optimization will save that app.

App team - we need bulk API.

API team - cannot because of capacity, budget, backward compatibility, DB, 3rd patry API, not a KPI

Also it’s mostly QAs measuring performance and validating it with product guidelines which set by person who mostly detached from specific product and sometimes reality.