invertase
bug: When deploying Dart Frog project to globe getting issue as: A directory corresponding to fileSystemPath "public" could not be found
Is there an existing issue for this?
- [x] 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 https://github.com/VeryGoodOpenSource/dart_frog/pull/1 createStaticFileHandler (package:dart_frog/src/create_static_file_handler.dart:7) 22:39:12.411 https://github.com/VeryGoodOpenSource/dart_frog/pull/2 createServer (file:///workspace/archive/build/bin/server.dart:19) 22:39:12.411 https://github.com/VeryGoodOpenSource/dart_frog/pull/3 main (file:///workspace/archive/build/bin/server.dart:15) 22:39:12.411 https://github.com/VeryGoodOpenSource/dart_frog/pull/4 _delayEntrypointInvocation. (dart:isolate-patch/isolate_patch.dart:297) 22:39:12.411 https://github.com/VeryGoodOpenSource/dart_frog/pull/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.
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 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
is this a read-only "db" or do you plan to modify it when request comes in?
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 /foowith a body1comes in to an instance A - your server writes
{ "value": 1 }tofoo.json GET /foocomes 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 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:
@Nikoro Deploying static assets to CDN is something we're absolutely willing to do. As for initializing firebase admin, we have a PR https://github.com/invertase/dart_firebase_admin/pull/32 that will make it possible to use env vars.
@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?
This feature will ship early next week. We made some huge progress, this potentially enables FFI support on Globe. 🎯
cc: @indratrisnar @Ehesp @kaziwaseef
@moshe5745 You should now be able to deploy your shelf/dart_frog project without issues.