Generic state support

[fenske]

User Story
As a developer, I want to be able to store data that is not user specific and is used across my application.

Example
A coding interview platform.

• User specific data: user profile
• Generic data: the list of available coding challenges.

[j-berman]

Question on this, do you want your users to be able to modify this data in a way that all other users are able to see that user's modifications, such as a means for users to add a coding challenge to the list of available coding challenges for all other users?

Or alternatively, will you have a static set of generic data that all users have access to, such as a static list of coding challenges?

[fenske]

I believe I want a way to store and access non-user specific data that only I can control.

[j-berman]

Got it, we'll keep this feature in mind in our roadmap!

For now, a suggestion: you could serve this data to your users the same way you serve your web app to your users. Wherever you're hosting your site, host this data as well. Does that make sense?

[notrab]

It would be useful to have some kind of "global" database that all users can interact with by default.

For example, I want to allow users to comment on blog articles, and I want those comments to be retrievable by the Admin SDK to display on the page to guest users. But only authenticated users can interact with it.

Perhaps some built-in permissions around the items you add can be modified by you...

[j-berman]

Following up, working on a feature that I believe satisfies all use cases requested above (except item-level permissions, saving that for #208)!

Will soon be able to make data stored through the SDK available to any user of the SDK.

@fenske your use case will definitely be ready soon!

@notrab following up on your use case, I'm wondering if you're thinking about authenticating your users beyond just checking that your users are signed in. For example, do you only want paid users to be able to comment, or users with some special value in their protectedProfile to be able to? Or do you only want to allow users who are are signed in to your app to comment?

[notrab]

@j-berman awesome work!

To answer your question - it might make more sense for now to restrict it to signed in users? Doing this I'm guessing would reduce the need for any workarounds later with any user level permissions.

[j-berman]

Got it, sounds good!

One thing I’m thinking, it’s a fairly large lift to allow non-signed in users to interact with data.

You could work around this once the feature to access global data is released like this: if someone visits the blog as a guest, prior to loading the blog comments from the global data store, just call signUp() in the SDK with a randomly generated guest username and password. Your client could then check that the user is a guest user, and simply not display the field to add a comment to the article, all client-side.

I figure there isn't a ton of value-add in terms of security in preventing unauthenticated users from commenting on articles server-side for your use case, since anyone is able to sign up to an app today by calling the signUp() function in the SDK (and could therefore pretty easily become authenticated). If you wanted to use more complex logic to "authenticate" users beyond just checking that they're signed in, then there would be value-add in preventing unauthenticated users from commenting on the articles server-side.

That suggested workaround sound alright to you?

Edit: forgot to tag @notrab

[notrab]

@j-berman You're right. Do you see such problems if the protectedProfile path was taken?

One other use case, and I'm not sure if this PR would address it, but it would be super useful to be able to use this global database via the Admin SDK. Do you think the implementation here would impact the behaviour that would require? If so, I think the simplest path forward should be taken here.

Userbase at its core has a simple API, and has very low barrier to entry. I think we should keep this for as long as possible, so avoiding the recommendation to users to make calls to signup in the background for guest users. While this would work, could we maintain the developer experience by going the other route of protectedProfile?

[j-berman]

@notrab

Do you see such problems if the protectedProfile path was taken?

So basically seems like there are 2 problems here:

1. needing to call signUp() in the background to create a guest user in order to access global data.

2. not preventing blog article comments from unauthenticated users server-side.

The 2nd problem is absolutely preventable using the protectedProfile route. Could definitely offer a way to only allow users with a particular value in their protectedProfile to comment on articles server-side. Will make sure this is possible with the initial release of this feature.

Unfortunately the 1st problem isn't solvable via the protectedProfile route alone.

Userbase at its core has a simple API, and has very low barrier to entry. I think we should keep this for as long as possible, so avoiding the recommendation to users to make calls to signup in the background for guest users.

I agree. And the idea to make the global data available via an Admin SDK would solve this issue. Will think on this some more.

[j-berman]

@notrab Assuming non-signed in users could access global data directly through the client SDK, would you still have use for retrieving data via the Admin SDK?

[notrab]

@j-berman I think having data accessible through the Admin SDK would be beneficial, maybe for reporting, or some "admin dashboards". What do you think?

I'm trying to think of a real world use case to apply our discussion to.

If we go on the theme on a multi tenancy blogging platform...

User signs up, creates a blog, and can invite others to the blog to write posts.

These posts can be by any user that has some flag (TBD), and then on the frontend, you can query all posts on at build time through the Admin SDK to render the page statically.

Then anyone who signs up, can comment on these.

There could be some holes in that use case 😅

[j-berman]

@notrab those use cases make sense! Someone also requested the same feature a while back so they could run a CRON job that reads or modifies the data. I'm sure there's a bunch more use cases. Was just curious if there was something in particular you wanted to do with it here :)

With the approach where non-signed in users can access global data directly through the client SDK, you could have an admin user that creates the global data that others could access while not signed in. In the example you gave, a user can create a blog other users could write posts to, and non-signed users could access the posts at page load.

I think either of the 2 approaches we're discussing here would take a large lift (1: allowing non-signed users to access global data directly through the client SDK, or 2: just allowing access of global data through an Admin SDK). And the 2 approaches don't really overlap in implementation. If there's not much desire for the 1st approach, and there's a strong push for the 2nd instead, not really much reason to go with the 1st it seems.

Selling the 1st approach a bit further: users would get real-time updates to the data out of the box, it would be much simpler for developers to figure out how to use (it's nearly identical to opening a normal database now), and it would maintain the serverless component.

[j-berman]

PR #250 deployed in userbase-js v2.6.0!

The PR highlights how the main use cases discussed above could be accomplished.

Will keep this issue open in light of the above discussion regarding the ability for non-signed in users to access global data and/or enabling admins to access global data via an Admin SDK.

[j-berman]

@notrab been thinking on this lately...

• allowing non-signed in users to access global data is now on the roadmap.
• getting userbase-js to work in node would enable admins to access global data from a server. Definitely want to get this done soon too :)

[spiffytech]

Where does Node.js support sit on the priority list? I'd just assumed Userbase supported Node, and my use cases include a lot of scheduled/triggered activities I'd expected I could run from the server.

[j-berman]

Happy to push it to the top of the priority list. It's been sitting on my mind personally. Think I may be able to get it done this weekend.

[Fubinator]

We would be very interested in node support as well. We're currently building something in node.js with puppeteer, which works, but is slow and quite tedious.

[j-berman]

Done 😃

[Shubhampratapsingh]

@notrab @j-berman @fenske @jneterer Kindly help me in this usecase.
Use Case: There is a multi author blog app based on react and userbase. I have one database i.e "Blogs".
All the user create their blog post in the same database.
Currently only creator are able to read and write blog post.
But I want every user to just read other blog post and only blog post creator can edit or delete that.
Share database not working, it's giving error as ShareTokenNotAllowed, may be because i am using only one database for every user to write blog post.
Issue raise with ticket #418 .

How can i achieve this feature?
Also can i do it using only client sdk?