Open marcglasberg opened 4 months ago
Good catch! Let me think about the best way to handle this.
Thinking about this some more, I believe there will always need to be a split between the client functionality and the server functionality. Having both available in the same interface will introduce too many footguns.
What would you think about a celestBackend
global that is only available on the backend? It would be as close a possible to the frontend's celest
global while having divergent functionality where appropriate, for example admin actions, etc.
Yes, you are right. In client.dart
:
final celest = Celest();
final celestBackend = CelestBackend();
Only problem is, since it's not possible to make celest
only visible in the frontend, and celestBackend
only visible in the backend, people will still be able to use them in the wrong place, and then get a runtime error. So I think it's important for the plugin to take care of that, by marking it with an error when you use them in the wrong place. I'll add this to the plugin issue: https://github.com/celest-dev/celest/issues/34.
In a cloud function, if I check
celest.currentEnvironment
it throws me an error:However, it's very useful to know, in the backend code, if it's running locally or not. For example, suppose an
admin
function that should only work locally (and staging) but not in production. This function can be used to set up the database to some initial state for testing purposes:Since the
celest
object is visible from the function code, I think it should have this information (and other information, like the cookies https://github.com/celest-dev/celest/issues/40 maybe). But if you try to accesscelest.functions
from inside a function it should fail with an appropriate error (and notCelest has not been initialized.
anyway).