bug: When deploying Dart Frog project to globe getting issue as: A directory corresponding to fileSystemPath "public" could not be found

[komiljonovshohjahon]

Is there an existing issue for this?

• I have searched the existing issues.

CLI Version

0.0.5

Project ID

44402c9f-bea5-48a5-a925-5611b6d21d98

Description

Cannot deploy to Globe with public folder included.

Steps to reproduce

When deployed Dart frog project without a public folder for static file serving, it deploys fine.
But when adding static files in public and redeployed getting an issue as Invalid argument(s): A directory corresponding to fileSystemPath "public" could not be found.

Expected behavior

It should deploy without any issue

Screenshots

No response

Additional context and comments

Full log from Globe build log:

22:39:05.220
Start the production server by running:
22:39:05.221
22:39:05.221
dart build/bin/server.dart
22:39:05.390
22:39:05.390
Compiling entrypoint "/workspace/archive/build/bin/server.dart"...
22:39:05.390
Running command: dart compile exe /workspace/archive/build/bin/server.dart -o /workspace/archive/.globe_build/dc10cbf6-04b6-4021-9ebc-564cec0fb182.exe --verbosity=warning
22:39:05.391
22:39:10.109
Generated: /workspace/archive/.globe_build/dc10cbf6-04b6-4021-9ebc-564cec0fb182.exe
22:39:10.143
Successfully completed step BUILD.
22:39:10.143
Step BUILD took 31961ms
22:39:10.934
Starting step VERIFY.
22:39:12.411
Failed to verify deployment. Status: 503
22:39:12.411
Unhandled exception:
22:39:12.411
Invalid argument(s): A directory corresponding to fileSystemPath "public" could not be found
22:39:12.411
#0 createStaticHandler (package:shelf_static/src/static_handler.dart:50)
22:39:12.411
VeryGoodOpenSource/dart_frog#1 createStaticFileHandler (package:dart_frog/src/create_static_file_handler.dart:7)
22:39:12.411
VeryGoodOpenSource/dart_frog#2 createServer (file:///workspace/archive/build/bin/server.dart:19)
22:39:12.411
VeryGoodOpenSource/dart_frog#3 main (file:///workspace/archive/build/bin/server.dart:15)
22:39:12.411
VeryGoodOpenSource/dart_frog#4 _delayEntrypointInvocation. (dart:isolate-patch/isolate_patch.dart:297)
22:39:12.411
VeryGoodOpenSource/dart_frog#5 _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:184)
22:39:12.411
22:39:12.411
{
22:39:12.411
"code": "exit",
22:39:12.411
"description": "Process exited.",
22:39:12.411
"trace": "unknown:7543089f22c298ffb766a4d90de6f8c3",
22:39:12.411
"time": "2024-01-31T17:39:12.383830Z",
22:39:12.411
"exit_code": "255"
22:39:12.412
}
22:39:12.414
Step VERIFY took 1479ms
22:39:12.414
Step VERIFY failed.

[Ehesp]

Will look into this soon - my understanding is that Dart frog is using the shelf_static (https://pub.dev/packages/shelf_static) package which serves files from a directory, which we do not yet support (although have workarounds for).

I'll see what we can do.

[komiljonovshohjahon]

Thanks

[lesnitsky]

@komiljonovshohjahon could you please describe your use case for static files?
We're trying to understand if deploying static assets to CDN (so that requests don't even get to your shelf server and are served from CDN directly) would solve this issue

[komiljonovshohjahon]

Trying to use my simple json files as db.

[lesnitsky]

is this a read-only "db" or do you plan to modify it when request comes in?

[lesnitsky]

Just to clarify a few things about Globe as a platform:

When you deploy your project to Globe it is not spinning up some VM instance somewhere, it is being run "everywhere" (across >30 regions). It is also not up all the time, we are scaling deployments up and down when needed. I understand the simplicity of using local files, but things don't work this way in real-world applications.

Given that your deployment is not a single instance, but could be handling requests in multiple regions and also being spun up multiple times in different sandbox environments in the same region, you will end up with inconsistencies in your FS.
Imagine you have instance A and B spun up in a single region:

• request POST /foo with a body 1 comes in to an instance A
• your server writes { "value": 1 } to foo.json
• GET /foo comes in, but this time is routed to instance B -> it doesn't have {"value": 1}, it's a completely different instance, you'd fail to read the value which you think was previously written to FS.

We might add some FS overlays and probably handle file locking as well, but it will ruin your app's performance since all FS ops will be essentially handled over the network and hit some persistent NFS host.

So essentially, solving the "fs problem" only brings more problems.

The "right" way would be using some 3rd part db provider, such as neon.tech, mongo atlas, firestore (via firebase admin sdk for dart), or supabase.

[komiljonovshohjahon]

It is read-only db

[Nikoro]

@komiljonovshohjahon could you please describe your use case for static files? We're trying to understand if deploying static assets to CDN (so that requests don't even get to your shelf server and are served from CDN directly) would solve this issue

My use case for static files will be serving privacy policy, terms & conditions as html files for instance. (These can be easily served in a different way hosting them somwhere else)

But what about configuration file for Firebase Admin SDK?
service-account.json file.

I'm not able to make it work when deploying to Globe:

CLI Version
v0.0.10

Project ID
55aaee1f-fe1b-4016-a9b7-16c2c25b86da

Description
I've got this project structure:

The whole project is deployed and I specified backend as a root directory:

[lesnitsky]

@Nikoro Deploying static assets to CDN is something we're absolutely willing to do.
As for initializing firebase admin, we have a PR invertase/dart_firebase_admin#32 that will make it possible to use env vars.

[moshe5745]

@Ehesp Didnt get you

Isnt public folder is the default folder for dart_frog? An i guess is derived from shelf_static...
So how can it be its making some conflict?

What is the workaround? Switch to other dir name?

[indratrisnar]

is there a solution?

[Ehesp]

cc @codekeyz for more details who is currently working on a solution