v1 is designed with usability and discoverability and over the past few week I have come to realize that that is not good for Web applications. For Web applications, especially for mobile devices like phones, small response times and response sizes are more important then anything else. To that end, I have now made a variant of Boundlexx that designed specifically for Web applications.
v2 still has all of the same great features as v1 and v1 is not going anywhere. Some changes between v1 and v2
Many of the âlistâ endpoints for resources have been simplified and all relations have been removed. You must now call the âretrieveâ endpoint to get all of the original data. This reduces response sizes and greatly decreases response times. Ex: If you want to know what world another world orbits, you must call the /api/v2/worlds/{id}/ endpoint for that world. It will not appear in /api/v2/worlds/
No more URLs! URLs ate up a huge amount of response size. As such, they are completely gone (except for URLs to images for objects).
Simplified relations. All locations where relational data is provided, it will now only provide the look up ID for that relation. No other date. This further reduces response sizes a great deal and also greatly improves response times. For a Web application, it is expected you cache the basic lookup data for these relations. Ex: If you get a world, the assignment relation will now only contain the World ID. It will not contain the world name or any other data anymore.
Just to mention this again, v1 is not going anywhere. If you are making a non-Web application, like a Discord bot, Web backend, etc. Keep using it if it is more helpful. That being said, v2 is designed for Web applications. So v1 is now deprecated for use with Web applications. Starting on 1 January 2021, I will remove all CORS headers from v1 and you will no longer be able to make XHR requests to it from Web application frontends.
Here are some raw stats from performance testing on v2:
items/?limit=1000 saw a 90% reduction in response time and 99% reduction in response size.
/api/v1/items/?limit=1000 = 10.49s, 398kB
/api/v2/items/?limit=1000 = 1.04s, 54.7kB
worlds/simple/?limit=1000 saw a 85% reduction in response time and a 14% reduction in response size (worlds/simple/ is already designed to replace the worlds/ so the size reduction is not as great)
/api/v1/worlds/simple/?limit=1000 = 3.16s, 30.7kB
/api/v2/worlds/?limit=1000 = 516ms, 26.8kB
A nearly full list of load of necessary metadata from the list endpoints comes in at ~83.4kB using msgpack.
Other changes in this update:
All of the Serializers/OpenAPI Schemas have been updated and should not more accurately reflect what is actually being returned. This applies to v1 and v2.
Replaced the _average_per_chunk filter with average_per_chunk. I finally got all of the world polls backfilled and renamed the actual database field
Looks like the theme is not being loading dynamically on the âdisplayâ pages. So if you switch the them on, it will not update the cards correctly until you reload that component. I will definitely fix it, thanks for letting me know!
In the near future, I will be removing all data about non-public Sovereign worlds from Boundlexx. It has been brought to my attention via discussions with the devs that some players have complained about the data for their âprivateâ worlds are being leaked. So that means in the near future, any worlds that currently is_public = false will stop returning data via Boundlexx. You will start to get 404s instead of data. This also applies to any Discord Webhook as well. A notification for a new Sovereign world will only be generated when the world is set to global âCan Visitâ.
I totally understand why some players would not want everyone to know about their world if they are not ready to let players to know about it. I apologize for any inconvenience this might cause any awesome things you have built.
In line with my previous comment, removes private Sovereign worlds from the Discord notifications Webhooks. A Discord message will be pushed out on the first world poll after the world is made public, if ever. Sorry for the duplicate/old messages while I was working out these issues. I probably should have disabled everyoneâs subscriptions while I work ironing that out. This will only affect Sovereign/Creative worlds, not Homeworlds or Exoworlds.
Shop data! I finally got an API key for the Live Universe and now shop data is starting to get populated in Boundlexx. You can start building against the existing APIs, just please be aware it may still take me a day or two to get the polling up to expected performance levels/timing intervals.
Adds text_name and html_name (similar to the same fields on the Worlds API) for both Leaderboard Record APIs and Shop APIs.
But this means that as an owner you canât check any of the data either. Plus canât check if one like you requested has just been created.
I mean that when I created one I kept looking out for a pop up of a planet with similar characteristics. And before going there I checked the resources.
This is a shame that is now not possible anymore.
I also donât understand why anyone would want to keep things a secret. Thereâs no player name associated with the planets so we donât know who owns it. All we can see is the amount of resources and why on earth would you want that to keep a secret.
What nefarious plans do people have to want this secrecy?
Am I understanding correctly you now have to set your world to public (via the discord hook or some other method Iâm not aware of) manually, not just the world control, to be visible in the API? The methods require your world id, right? How does a normal person get this id?
Iâm assuming heâs setting the âis_publicâ flag from the worlds list endpoint (https://ds.playboundless.com:8902/list-gameservers) as any world that restricts visitors doesnât appear in there.
The is_public flag in Boundlexx maps to the public property that is returned by Sovereign worlds in the game API. That value is in turn is determined by the global âCan Visitâ on Sovereign worlds in the World Control. For Homeworlds, Exoworlds and Creative worlds, public is never returned so I always assume they are public.
That is part of a feature set I would love to do if I can get game auth integrated in to Boundlexx, but that is currently not easy to do in a secure and âtrustfulâ way. The Boundless Accounts SSO server is designed to only work with the forums and the game servers so I can make my own login page that can send the credentials you give to the Boundless Accounts server to auth, but I still have to accept your credentials, which is not ideal. I would need an OAuth or similar open SSO implementation so I could send the user to the Boundless Account server to auth and then send the user back to me after they are done.
There is no actual way to tell from a user that they own a world, but I could block their Boundlexx account in the case of abuse. Boundless auth integration would help stop some abuse that I rather not have to deal with:
Does this person actually own Boundless?
What stops the user from just making another Boundlexx account if they abuse it?
Some of the things I have thought of implementing if users actually had accounts:
Customized notifications (push/Discord notification for things like change in shop item prices, etc.)
Obviously access to the worlds they own even if they are private
Automated control over managing forum posts for worlds you own
The DS list-gameservers does not return Creative worlds. Only public (global âCan Visitâ) survival Sovereign worlds and Homeworlds. As far as I know, it also does not show Exoworlds either.
Correct. @DreamEvilâs new crowdsourcing with Nixbot thing can only allow users to self-report global âCan Editâ and âCan Claimâ permissions, not âCan Visitâ since I can get that data myself.
