Im not a tech nerd and all computer language is like reading klingon to me.
That being said i still find it fascinating reading about where eves hardware started and where it is.
Im not a tech nerd and all computer language is like reading klingon to me.
That being said i still find it fascinating reading about where eves hardware started and where it is.
True. However for EVE, protobuf (or similar) makes sense, since itâs at least binary efficient and you get the added benefit of type safety. I was mainly arguing for server<->client communication and internal systems communicating, not for the ESI API.
Even though GraphQL can spit stuff out the way you want it (which indeed is nice), if the underlying source calls larger sets of data, you will still be waiting. And if you have 99 fast and 1 slow part, you are still waiting until that 1 remaining one is available. It also smells and tastes like SOAP all over againâŚ
Sending a lot of JSON data is costly and slow. Serialization is slow. Itâs unsafe to parse. However for edge APIâs like ESI, it still makes sense so hobby devs can make cool and usable applications/tools utilizing the data provided.
Every time I see huge JSON blobs stored in databases it makes my eyes bleed. The âonlyâ benefit of JSON is that itâs somewhat human-readable. And if you want readability, just use YAML already. Applications doesnât give a crap about readability of the data exchanged. It just needs to (preferably securely) be able to interpret and use it.
Itâll be interesting to see how gRPC + HTTP3 (QUIC) will work out. TCP overhead begone.
Iâm aware of the differences between the two. My focus is purely on âhow can we make EVE better, faster and strongerâ as a game. Every little bit that can be optimized will have huge impacts on anything large-scale. While I mainly do very small-scale stuff in EVE, I do want the game to prosper and grow.
Whatever the data format becomes FOTM tomorrow, for anything at scale JSON just isnât the answer.
Byte life matters, yo. o7
Man you do sound salty. The amount of posts in this thread certainly tells me itâs not a âBS postâ. A lot of the player-base is above average competent or in the IT industry. For us, them putting in the effort to be transparent on infrastructure changes is a cool thing.
Of all the threads you could hop on to rant about something, this was probably one of the least deserving of it in a long while.
You can also use binary serialisation, you are not limited to JSON even though many use it, GraphQL does not limit that choice. Binary payload can also be unsafe to parse.
See GraphQL
For third party client side, it is far more suitable, clients do data querying, not RPC with ESI and not all clients are the same. As for performance, it will be cached for third party clients (cached on the local client as well as the server edge), as long as youâre not generating expensive errors, itâs performant.
It is heaps faster than MSSQL and it is certainly competitive. Thereâs a reason why financial institutions and big players with huge datasets are throwing out Oracle/MSSQL for PostgreSQL, and it ainât because of licensing reasons. Every DB has bugs that âmayâ lead to data corruption, but the majority of those cases happens because of underlying hardware/network or human errors.
For the rest, thatâs the usual FUD spewed at an Oracle/MSFT conventions or by sales agents.
In the past, to get discount, just start talking âI might migrate to Linuxâ, however, that no longer works as they donât care what you run as long as itâs on THEIR cloud.
Watch every educational institute using Office 365 online switch to their hosted Cloud PC offerings to cut more costs with cheaper hardware.
Theyâve went from Unix systems (SunOS, Solaris HP/UX etc), to Linux / Windows / Novell, keep moving the Admin offices to the lowest dungeon and downsized with Office 365 educational services, soon now to Cloud PC and reduce their Admin to a robot/webpage.
Microsoft won education in the cloud, taking over from Novell in that space.
The added benefit is when the students leave the education instituation, they let them keep their Office 365 accounts, and converted new customers retention.
The right time to buy MSFT was the day Ballmer was ousted (see my previous chart here A History of EVE Database Server Hardware - #99 by Emotional_Support_Clown).
Many financial institutions are moving off or reducing their usage of Oracle for licensing reasons. The democratization of financial services has put them under extreme price pressure and Oracleâs licensing costs are just nutty.
Interesting, I thought GraphQL only understood JSON. Rejoiner looks nice, shame itâs Java.
As for parsing binary payloads, thatâs certainly true. Hell, parsing anything is scary in general. And the more codebase, the worse it gets.
I just want interoperability, predictability, security and speed. Is that much to ask for?!
Sure, but thatâs mostly not the primary motivation from my experience, but their draconical licensing schemes and shady practices sure doesnât help.
And when you are dealing with astronomical sums of IRL iskies, you arenât going to take DB choices lightly.
Granted Oracle has a decent database and the toolsets generally works well, I wouldnât voluntarily use their products unless forced to at gun point. And even then I might refuse.
But donât take my word for it âŚ
Meh, you could use PL/Python for procedures! That alone should make it worthwile.
Jokes aside (or maybe not), I fully understand the concerns if you have a massive amount of em. Regarding monitoring and metrics though, that is probably not a dealbreaker. As for institutional knowledge I mean itâs same same, but different.
I know you probably canât answer this (but Iâll ask anyways), Iâve always had a sneaky suspicion that wormholes are generated by the a trigger or schedule in the DB. True or false? ^^
Appreciate the response! o7
Hehe - indeed. Iâm all for running stuff in the cloud when it makes sense, but I fear for whatâs to come in terms of pricing and license cowboyism in the next few years when the big three has everybody by their balls. Itâs next to impossible to compete as a smaller provider, when you canât order the volumes of hardware. You either sell your services utilizing the cloud or die.
Microsoft has already pulled a multitude of fast ones with their licensing schemes, to punish customers in AWS/GCP/on-prem. And they all want you to heavily invest in their proprietary ânice to haveâ solutions to lock you in.
The funny thing is that management often thought itâd save money, and youâd be able to run services with a skeleton crew because âcloudâ. But even now, with huge incentives to make the switch ($100k+ or more of free usage is not unheard of at all) - the bills are starting to add up⌠fast.
Good DevOps engineers ainât cheap, and in such a demand that they wonât take the peanut salaries formerly accepted by OG sysops who just loved their work. Most rely on consultants to keep the ship afloat. Security is thrown out the window, because it doesnât work to apply on-premise strategies there. A lot are not even utilizing Kubernetes or other container tech and runs VMâs still. And those that do, lose track of all the instances further running up the bill.
Educational institutions has historically always had bad security practices, just hiring fresh outta school staff. The sheer amount of GDPR violations during COVID for education is insane.
The practice of long-term adoption of slaves to their ecosystem has been Microsoftâs business strategy since forever. Itâs one of the main reason why getting Linux with OpenOffice/LibreOffice in edu didnât stick. Generations upon generations was too used to MS Office. And the demand in the private sector was the knowledge of using the MS ecosystem.
This might sound very anti-cloud, but I do think microservices, infrastructure-as-code and proper automation is fantastic. If done right, it can be a godsent.
The benefits are not cost, long-term.
you just threw out all your credibility there. invocation of âFUD,â is another indicator.
You can run multiple interfaces gRPC for RPC between game client and server, GraphQL for third party data querying. Nothing states you have to only run a single interface technology on everything, inappropriately, in fact that would be an anti-pattern.
You donât need breakneck speed performance on ESI as it is updated only so often depending on the data being queried.
GraphQL (a long with gRPC) also support âstreamingâ data, but chances are the data we query on Eve for third party will still only be periodically refreshed as it is currently for REST.
Third parties are performing data querying, not RPC, GraphQL makes more sense to me in that use case.
False. Wormholes are generated and managed by the Wormhole Manager, which is in the game logic code (Python). (The state is persisted in the DB.)
Probably took a whole agile sprint to come up with that name.
No
YAML is like Python, hideous, and itâs like the dragon we cannot slay no matter how many times we try. Somebody always comes along to say âhey why not use X, itâs bestestâ, because theyâre its number 1 fan and doesnât know better and wants to use it everywhere just because itâs all they know.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.