That’s amazing! Keep me posted, I would love to know how the community uses Ordered DataStores now that its on Open Cloud !
Excited to see what you can do !
The Ordered DataStores limits are here. We also currently have a 100 req/min per API key for Ordered DataStores but you can just use more API keys.
Let me get back to you on MessagingService.
I desperately needed this, lol. THANK YOU SO MUCH!
I support this kind of thing but am concerned about outside uses that could be considered abuses and violations of the terms of service. Specifically about people being able to make USD purchases outside roblox and they’ll be able to set DataStore values, like buying Premium. Sure I support people not having a heavy for Robux, but is there any plan to avoid abuses like this?
Nice to see Open Cloud getting more APIs added to it.
Is a Group API on the roadmap for Open Cloud? Anytime soon?
Ordered Data Stores are now supported and documented in my Python library:
Is there any plan on in the future of making OpenCloud API’s scale? Or Apply for higher limits at all?
Currently if you wanted to create a interactive website with your game, that i.e a user could log in and see their data, in truth this would work fine. But if you have a 80k concurrent players, you’d hit that limit pretty instantly.
is this a on the radar for future at all?
Decent release I guess but we really need the option to view someone’s numerical placement in an OrderedDataStore. This is a very limiting factor and will be the reason the number of integrations will not be maximized.
Cool to see this!
One frustration is the lack of consistency in API naming. I know this is kinda minor, but it makes writing SDKs et. al. quite difficult. Some examples between this and the standard DataStore API:
Endpoints
Ordered: https://apis.roblox.com/ordered-data-stores/v1/universes/{uid}/orderedDataStores/scopes/{s}
Standard: https://apis.roblox.com/datastores/v1/universes/{uid}/standard-datastores
Inconsistencies
- Ordered uses
ordered-data-stores
in the path; standard usesdatastores
.- Inconsistency between “datastore” vs. “data-store”
- Ordered uses
orderedDataStores
at end of path; standard usesstandard-datastores
.- Casing inconsistency; probably not great to have capitalization, e.g. “orderedDataStore”
- Ordered requires
scope
in path; standard requiresscope
in query string. - Ordered pagination uses the naming of “token”; standard uses “cursor” (cursor is preferred IMO).
- Query params in ordered use
snake_case
; standard usecamelCase
(and sometimesPascalCase
…)
These are just the ones I’ve picked up on in the last hour of trying to add ordered datastore support to my rbxcloud tool.
I would like to strongly advocate for consistency across these APIs, especially as they expand. I don’t want to write tons of custom code for every single API just to handle naming convention changes.
/v1/universes/{universeId}/orderedDataStores/{orderedDataStore}/scopes/{scope}/entries/{entry}:increment
Is this supposed to be /increment
? I’ve not come across this syntax in APIs before.
No the :
is correct but I agree /
would be better
Hey serverless, we’ve gotten a fair amount of feedback asking for Groups in Open Cloud. I can’t make any promises regarding timeline, but it’s definitely on our radar! Thanks for calling it out.
Thanks, I shared this with the docs team, along with a suggestion that we add some automated spell-checking to our docs CI pipeline.
Thanks for the feedback - I agree that API consistency is important and that this inconsistency is pretty awkward. We are actually investing a lot in improving API consistency, but that’s going to come with some short term growing pains. Please bear with us on this.
Just to give you an example: datastores/v1 - which predates some of our recent focus on consistency - isn’t really consistent with “Data Stores” having a two-word product name, e.g. in the docs. So for Ordered Data Stores, we either had to keep going with that inconsistency (ordered-datastores/v1) or try to fix the problem going forward (which is what we did, with ordered-data-stores/v1). And of course, if we do a v2 of the Data Stores API we’ll face a similar choice. This is somewhat inevitable; if we want things to be consistent and we have an inconsistent status quo (e.g. “Data Stores” and “datastores/v1”) then we’re going to have to break from something in order to build a good foundation.
I’ve seen feedback elsewhere that Roblox focuses a lot on taking the long view at the expense of the short term, and it’s valid, but an initiative like Open Cloud is really a long view kind of project…which means that we will probably choose to make tradeoffs like this in the short term. Hopefully you’ll eventually agree it was worth it.
Is there a way to list the available Ordered Data Stores like there is for standard Data Stores?
I tried the delete endpoint, which, according to the documentation should return the status code 204 when successful. However, it looks like I get the status code 200.
Got this too, i just make sure it checks for both to confirm that it deleted the data.
Yes this is on our radar, but unfortunately there is no timeline I could share at this moment.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.