search

intercellular / cell

A self-driving web app framework
https://www.celljs.org
MIT License
1.51k stars 94 forks source link

Suggestion : Limiting complexity of inter-cell dependency #171

Open smailq opened 6 years ago

smailq commented 6 years ago

Hello,

Very interesting project! I love how Cell utilizes least amount of concepts to let programmers build very capable application. Thanks for taking this cool idea and implementing it.

Having said that, I would like to share my concern about building large application with Cell.

I do understand that one of the design goal of the Cell is to be "decentralized". Cell allows each/any Cell to communicate(invoke other Cell's functions, read/manipulate data) freely with any other Cells via query selectors and using "context inheritance" (may be other methods that I am not aware).

With small number of Cells interacting each other, the program is not too difficult to reason about, or understand. However, as the number of Cells increase, and inter-cell dependency increases, I'm afraid that the program will quickly become too complex.

Any changes to existing data fields, function signatures, etc could have unknown/unforeseen side effects very easily with large number of "edges".

With careful design and planning programmers could delay the program becoming too complex, but as the program ages and more features are added/removed/modified, it's bound to cross the line(from simple to understand the program -> difficult to understand) at some point.

So I have a suggestion to address this issue.

How about adding well defined restrictions on how/who each Cell can communicate?

There are many different ways to implement it, but here is my suggestion.

Let each Cell define a specification on how other Cells can interact with self.

Say, $spec: "Only the Cell with $id = 'Hi' can call function _hello"

Or, $spec: "Allow any Cell with $id = 'Bye' to access all functions"

Or, $spec: "Only the function 'Xyz' can be invoked by any other Cells".

Such specifications can help reduce complexity, since we do not allow "any to any" dependencies(by default). Programmers will need to explicitly allow certain communications between Cells, so we could be certain that when we modify a single Cell's code, it will have well known side effects.

It's like a defensive wall agains other cells to prevent inter-cell dependencies becoming too complex to manage/reason about.

There are many different ways to implement this, which isn't the scope of this article. (One such example is private/public functions in OOP)

I'm not sure whether this belongs to core module, or it should exist as an extension.

Hope this suggestion was useful, again, thanks for implementing Cell!

gliechtenstein commented 6 years ago

Would this be like AWS IAM permissions? https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_grammar.html (Of course we don't want something as complicated as this but you get the point)

There are a couple of issues you've raised I resonate with.

  1. The querySelector as an accessor method is less than ideal. Would be nice to have cleaner way to handle this
  2. Permissions, and more generally a "spec" (or blueprint) of a cell

I hope there's a good way to handle issue1 (I've been experimenting with different approaches but haven't yet come up with satisfactory one yet)

As for issue2 (if I understood correctly) I think it's a great idea, just haven't figured out how to express the permissions nicely in JSON. I think this has a great potential not just for policy specification but also as a way to auto-generate a blueprint of a cell, meaning if you write a cell component using this scheme, if it can be expressed in JSON, it can sort of function as its own documentation, allowing others to easily see how they can interact with the cell.

If you have more specific ideas on how this could be implemented please share. I will spend some time to think about this too.