Validate user data inside of firestore

[CaelumF]

Even if we restrict where users can manipulate data on firebase, it may be incorrect data.

We should still make our michaelservices fault-tolerant, but we need a way of ensuring this data is valid in firebase, and before a michaelservice can be affected by it.

Solutions?

• A validation proxy?

• Firebase already has methods of limiting access to data, perhaps it can allow us to validate its shape as well

[ericm]

I think we should consider combining these michaelservices into a backend repo since this michaelservice fault-tolerant essentially acts as a backend for all firestore queries.

[ericm]

Also, I assume we are using Kotlin for all the michaelservices?

[ericm]

I created a repo at https://github.com/fixiversity/backend if you want to initialise a project there

[CaelumF]

Is there no Firebase-only approach? I will have a look later. I want to avoid having unrelated feature functionality and data domains inside of a single repo. I think a "backend" repo would confuse our micro-service architecture (not necessarily with separate processes). If you have any ideas for another backend architecture then let's talk about them, but I think there is a universal value to separation of concerns :)

[CaelumF]

Also, Victor and I were talking about it 2 Saturdays ago (where you weren't free/available) and I think there was a consensus that the language of a michaelservice should be up to whoever is working on that michaelservice. Obviously, some languages and technologies are objectively better for certain tasks than others, and some are completely eclipsed by others, but I trust the judgement of whoever is so interested as to be one of the main contributors for a michaelservice

And with separate languages, we have more freedom to learn about technologies and use our favourite ones, and this depends on separate repos.

[ericm]

Is there no Firebase-only approach? I will have a look later. I want to avoid having unrelated feature functionality and data domains inside of a single repo. I think a "backend" repo would confuse our micro-service architecture (not necessarily with separate processes). If you have any ideas for another backend architecture then let's talk about them, but I think there is a universal value to separation of concerns :)

After some digging, I think that this may solve our problem of data validation but I'm not entirely sure yet.

[ericm]

Also, Victor and I were talking about it 2 Saturdays ago (where you weren't free/available) and I think there was a consensus that the language of a michaelservice should be up to whoever is working on that michaelservice. Obviously, some languages and technologies are objectively better for certain tasks than others, and some are completely eclipsed by others, but I trust the judgement of whoever is so interested as to be one of the main contributors for a michaelservice

And with separate languages, we have more freedom to learn about technologies and use our favourite ones, and this depends on separate repos.

That's a good way of looking at it. Personally, I'd like to use Kotlin since I've never used it in a project before so it'd be a good learning experience for me.

[v-pan]

{
  "rules": {
    "foo": {
      ".validate": "newData.isString() && newData.val().length < 100"
    }
  }
}

From the link you referenced, this is Firebase's Realtime Database, not Firestore security which looks like this:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if request.auth.uid != null;
    }
  }
}

I can't find anything equivalent to the rules you can define in the Realtime Database in Firestore. There are comparison operators, and you can get the fields of a document / request and apply these comparisons to them. There's no datatype validation within the security rules, making it difficult to validate a structure within these rules

[ericm]

I'll look into it. Worst comes to worst, we're writing a michaelservice

…

On 25 May 2019, 12:21, at 12:21, paranoidcake ***@***.***> wrote: ``` { "rules": { "foo": { ".validate": "newData.isString() && newData.val().length < 100" } } } ``` From the link you referenced, this is Firebase's Realtime Database, not [Firestore security](https://firebase.google.com/docs/firestore/security/rules-conditions) which looks like this: ``` service cloud.firestore { match /databases/{database}/documents { match /cities/{city} { allow read, write: if request.auth.uid != null; } } } ``` I can't find anything equivalent to the rules you can define in the Realtime Database in Firestore. There are comparison operators, and you can get the fields of a document / request and apply these comparisons to them. There's no datatype validation within the security rules, making it difficult to validate a structure within these rules -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #18 (comment)