For every single minor 5 minute update? That simply isn't efficient enough.
[API] standardise types in API responses
Started by pobk [3171827] on in Bugs & Issues.
Posts archived: 91 / 91 posts (100%) · the total is Torn's reply count + the opening post at the last fetch
Not for minor updates, but bundling these fixes into releases would allow those change processes to safeguard from incidents like this.
Also a change on a prod codebase directly with no prior testing would constitute an emergency change and need even more scrutiny than a normal change.
Also a change on a prod codebase directly with no prior testing would constitute an emergency change and need even more scrutiny than a normal change.
Yes.
Queue them up and do them in a rollup on a schedule if you have to. It's what devs and IT guys worldwide do on a day to day basis.
Queue them up and do them in a rollup on a schedule if you have to. It's what devs and IT guys worldwide do on a day to day basis.
I mean you could compile a list of minor fixes, note to the community you plan on fixing them and what they’re changing about a week ahead of time, and then make those quick changes back to back all at once on that day instead of on the fly, then people would have notice and it wouldn’t affect thousands of users ( a lot of people use torn pda)
Tell me you work in devops without telling me you work in devops ;)
This. All of this.
And versioned releases... or even multiple API versions. It's a read-only API, so it shouldn't be too difficult to maintain a progressive development roadmap... Old API changes can be deprecated in a managed progressive way.
And versioned releases... or even multiple API versions. It's a read-only API, so it shouldn't be too difficult to maintain a progressive development roadmap... Old API changes can be deprecated in a managed progressive way.
That's just not going to happen without taking a lot of time away from other development projects. I need to be able to have a very quick and efficient way of making these changes. I can't even bring on a developer or team to handle the API specifically because pretty much every change involves some kind of legacy structure or database table.
Honestly, from my perspective, I didn't see a huge deal with a script breaking temporarily due to an API change for the better. I'm pretty much always around, if there's an issue it can be quickly reverted or fixed - I really don't get why people get so angry over it and aren't willing to work with me and accept such a tiny sacrifice for the betterment of the API. Or at least that's what I thought before I knew one tiny change could entirely crash Torn PDA for everyone.
Honestly, from my perspective, I didn't see a huge deal with a script breaking temporarily due to an API change for the better. I'm pretty much always around, if there's an issue it can be quickly reverted or fixed - I really don't get why people get so angry over it and aren't willing to work with me and accept such a tiny sacrifice for the betterment of the API. Or at least that's what I thought before I knew one tiny change could entirely crash Torn PDA for everyone.
Torn Pda back working.
It’s what used to happen. Everyone old enough remembers free merit Tuesdays. The weekly patch notes are still on a Tuesday but the updates themselves are rolled out as and when instead of when the patch notes are released.
IIRC it stopped because a few of the updates caused a crash and it was then a massive job to find out which one of the changes caused that crash
IIRC it stopped because a few of the updates caused a crash and it was then a massive job to find out which one of the changes caused that crash
How much time does it take to tell everyone what change is going to happen and when it will happen. Not long.
Did the API change for the better have to happen *right now*? Nothing would be using this new feature or fix for a while anyway. No harm to schedule it.
Did the API change for the better have to happen *right now*? Nothing would be using this new feature or fix for a while anyway. No harm to schedule it.
Ched about to say "screw it" and stop the API being available to players lmao
He could very easily do that too, he gives us access as a curtesy.
He could very easily do that too, he gives us access as a curtesy.
I know this won't happen, but it would be really neat if there could be a v1 and v2 of the API. Where on V2 you can add things like this, along with more, and maybe a V3 later if that comes up etc. On API systems, versioning like that is very common as it allows developers to switch when they have the time, instead of just having stuff break randomly.
Torn PDA and Lite use Dart, which is a statically typed language. While I agree that skills should be a double / float, they were returned as strings when the user model was created. By changing them before the app can be adapted, the JSON > Model conversion will throw an exception and whatever needs the value will fail (and if it affects the user interface, an error will be presented to the user).
There are certainly some ways to avoid this (from a Torn PDA side), for example:
If it's not with API versioning, I think any kind of change should be planned and communicated with sufficient time. And if neither of this is possible, then I think we'll keep having these kind of issues like today.
There are certainly some ways to avoid this (from a Torn PDA side), for example:
- We could accept any type when we convert the JSON and then, depending on what it is, adapt the code so that we can parse the value we need. The problem with this is that it creates an extra workload when creating the models, lots of repetitive code and even some decrease in performance as we need to parse everything (although I doubt this would be noticeable at all).
- We could (and already do in certain places) manage the exceptions more efficiently, so that we control what goes inoperative if something like this happens. This is already the case with certain section cards in Profile, for example, that won't show up if the back-end crashed while building the model. This was useful, for example, when the item's information was removed from the API unexpectedly a few months ago. In today's case, however, this affected the main user profile model, which the app uses for many things (that have not been protected against API changes, because it's probably not worth it considering the refactoring that would be necessary).
- We would need to spend time in protecting the app against unannounced changes. Honestly speaking, and since this is a hobby and not my job, I wouldn't have time to implement new features and worry about this at the same time.
- We would be acknowledging and accepting that we need to work with a weak API, while I think that the fact that Torn offers this API is brilliant and definitively sets it apart from other games. Making it strong and resilient is much easier than it sounds. I see Torn PDA as a client of what should be a strong API system; probably not as advanced as some of us would like (with versioning, etc.), although it'd be the perfect solution, but certainly where changes can be planned with at least (and I say this humbly) those applications that are used by so many players.
If it's not with API versioning, I think any kind of change should be planned and communicated with sufficient time. And if neither of this is possible, then I think we'll keep having these kind of issues like today.
We dont need multiple versions, but if the first element of every response was a schema id (int, epoch, something else) at least we know that something has changed.
This can either be per endpoint, or even just for the whole API (a change in /user would cause the global id to change and would show in /faction)
It doesnt stop applications from "breaking" but does allow devs to check the id against what they have coded against. Devs can then choose to try and process the response, to store the responses and process them later after they have updated the software or just ignore the response all together
No this isnt a magic bullet, but I think it would be a starting point
EDIT:
That said, multiple versions of the API would be nice and I wouldnt say no to it, but im trying of what would be easiest for the Torn Devs
This can either be per endpoint, or even just for the whole API (a change in /user would cause the global id to change and would show in /faction)
It doesnt stop applications from "breaking" but does allow devs to check the id against what they have coded against. Devs can then choose to try and process the response, to store the responses and process them later after they have updated the software or just ignore the response all together
No this isnt a magic bullet, but I think it would be a starting point
EDIT:
That said, multiple versions of the API would be nice and I wouldnt say no to it, but im trying of what would be easiest for the Torn Devs
This is my personal held opinion, and I'm going to be somewhat blunt because I rather like the game and want it to succeed well into the future, but from my perspective as a newbie, your position on scripts breaking with minor changes is becoming untenable in 2024.
Google have been practicing and preaching about SRE for over 20 years now... https://sre.google
You can do quick and efficient, and still run stable systems.
Google have been practicing and preaching about SRE for over 20 years now... https://sre.google
You can do quick and efficient, and still run stable systems.
You make a really good point there!!!
If a bunch of small updates released together break something then you have to go hunting for which one did which.
For smaller updates you immediately can tell what, when and how.
A best of both worlds though would be having a queue and a small delay between each of these changes, especially if they're not critically needed to implement something else.
Was this change needed to do something else? Or was it just for the sake of itself?
If a bunch of small updates released together break something then you have to go hunting for which one did which.
For smaller updates you immediately can tell what, when and how.
A best of both worlds though would be having a queue and a small delay between each of these changes, especially if they're not critically needed to implement something else.
Was this change needed to do something else? Or was it just for the sake of itself?
The issue of what change broke what thing is usually handled with detailed logging.
All changes should of course be run through dev/test environments and should be subject to unit tests also.
Of course Torn isn't responsible for handling 3rd party scripts, but changing something like the types of data served is something that should be caught by unit tests (i.e. expect input from api call --> expected output).
All changes should of course be run through dev/test environments and should be subject to unit tests also.
Of course Torn isn't responsible for handling 3rd party scripts, but changing something like the types of data served is something that should be caught by unit tests (i.e. expect input from api call --> expected output).
I didn't realize it was this simple, and I have made ridiculous workarounds in some parts of my code.
Can you please make it so that when an object is empty, it is returned as an empty object, not an empty list? user log is a good example of this. Just limit the search to something that would return empty, like to=5000.
Can you please make it so that when an object is empty, it is returned as an empty object, not an empty list? user log is a good example of this. Just limit the search to something that would return empty, like to=5000.
As evidenced by this thread... it seems it isn't that simple and breaks everything
I was thinking we can add a v2 where I'm allowed to make fixes and changes without a fuss, and then everyone can just use v1.