Maybe I interpreted it differently, but playing an RPG where every NPC is essentially its own agent/AI with its own context would be very interesting. In most RPGs, NPCs are very static.
I think they would just pay the taxes but increase their prices so their bottom-line looks about the same. In the end it would be the consumers in Germany that paid the price.
What LLM is it using? Is it something local? Or does it call out? It wasn't obvious from the docs, and I didn't want to dig through all of the code to figure it out. Should probably be clearly stated on the front page.
But the project looks interesting, I have been looking for something similar.
You posted your opinion without any kind of accompanying argument, and it was also quite unclear what you meant. Whining about being a target and being downvoted is not really going to help your case.
I initially understood your first post as: "Let's not try to make the internet faster"
With this reply, you are clarifying your initial post that was very unclear.
Now I understand it as:
"Let's not try to make existing protocols faster, let's make new protocols instead"
Agree, and he even mentions in the article "If you process less than 10k requests per second, you’re not Google nor are you Facebook."
There is a huuuuuge gap between services handling 10k req/s and Google/Facebook.
I think one big upside with JWT that he doesn't mention is that if you have some services geographically distributed, then having decentralized auth with JWTs is quite nice without having to geographically distribute you auth backend system.
So, yes, if you have a monolith or services colocated, or have some kind of monolothic API layer, then no, perhaps JWT does not make sense. But for a lot of distributed services, having JWTs makes perfect sense.
And you don't have to introduce JWT revocation for logout, if you have short token expirations, you can accept the risk of token leakage. If the token is valid for like 30 seconds or 1 minute, you would probably never be able to notice that a token has been leaked anyway.
Did you actually read the conclusion at the end of the article?
"Of course, we can't conclude that you should never export to CSV. If your users are just going to try to find the quickest way to turn your data into CSV anyway, there's no reason why you shouldn't deliver that. But it's a super fragile file format to use for anything serious like data integration between systems, so stick with something that at the very least has a schema and is more efficient to work with."
I very strongly disagree. Having "integration" tests are super powerful, you should be able to test against your interfaces/contracts and not have to spin up an entire environment with all of your hundreds of microservces, building "integrated" tests that are then dependant on the current correctness of the other microservices.
I advocate for not having any integrated environment for automated testing at all. The aim should be to be able to run all tests locally and get a quicker feedback loop.
We have been using all those GCP products and more without any significant problems.
But I do agree, there are some gotchas. PubSub examples: Duplicated messages, shitty DLQ implementation (in my opinion), some developers had improper error handling which lead to to infinite resends of messages (because they nacked message on error), etc..
However, I think the scaling and setup weighs up for all of that. You just need to specify a topic and subscription, and then you don't really have to care about resources or scaling at all, and that is SUPER nice. Also, PubSub is stupidly cheap in comparison to any other similar product, at least that I know of.
I agree to an extent, but I don't really see the problem either. If I book a meeting or something through any calendar application, the timezone will be fixed to the local timezone. Let's say I book it for 13:00 in my calendar, it will show up as a meeting at 14:00 in their calendar if they are +1 from me.
So whenever I specify a time with someone that could be in a different timezone, I would either make sure that I am using some application that solves it for me, or I would AT LEAST include the timezone.
Maybe I'm just not encountering the same problems that you do.
If they have a clone of an intranet gateway, I would have to agree that the phishing attempt is a bit more advanced, so calling it sophisticated is not too far fetched.
For managed products, upgrades are often automatic and there is almost no maintenance that needs to be done. At least that is my impression when running stuff in GCP. For example:
* CloudSQL Postgres, automatic minor/patch upgrades, they working on seamless major upgrades.
Automatic disk increase. You would only need to make sure that you have enough resources in terms of CPU/Memory.
* PubSub, no maintenance or updates required.
It is more work to keep java and the related dependencies up to date. We use renovatebot to help us automate things like that.
In my experience it is very easy to change and setup the managed products, I declare them in code using terraform and then I don't have to do much at all. This is what is so awesome with the cloud managed products.
If you are trying to be cloud agnostic, then you are just treating the cloud as another datacenter, and then you don't really get any of the benefits of using cloud specific managed products. Then you need a professional to keep maintaining your infrastructure.
I don't see how your example of querying elasticsearch has anything to do with the above. I do agree that it requires the developer to at least understand the basic concepts of kubernetes, if you are running your application in kubernetes.
I rather like to think of it that certain things that was handled by other professionals are now managed or automated with cloud technology. Take Google PubSub for example, a message bus with pretty much zero operational overhead. You simply create your topic and subscriptions and it just works. Compare that to running and maintaining a system like Redis or Kafka on your on-premise hardware.
As a developer you still need to understand the interfaces of the products you are working with, regardless if it is a database, a messagebus, a REST api or kubernetes.
I don't think it has ever been enough to JUST look at the java. You said you were pretty good at SQL, so you must think about the performance of your queries, what indexes you use and such.
You can try to improve your java performance as much as you want, but if your database can't handle the load, then you need to look at the database. In my opinion it is NOT enough to look at just the code, you need to look at all of the parts of the system.
Just declaring that you want a database instance in code, using something like terraform should not be an overwhelming thing. Most of the management would be handled by the cloud vendor, you would just need to make sure that it has enough cpu/ram for example. There are probably even easier products where you just store data with some kind of API and you don't even need to bother with the performance of the data store.
But if you just want to write your java code and not care about anything else... Then yeah, maybe the direction of the industry is not aligning with the direction you want to go.
Just imagine a weekly newsletter with 100k subscribers.