Deploying this task with 8base deploy will work perfectly fine.
But the problem arises when trying to monitor the task from the 8base application.
This new custom function will appear in the list of all custom functions deployed. But clicking on it won’t actually do anything. Making it impossible to visualize any log.
I suspect the problem comes from the fact that the name tableName/newFeature contains a slash /.
I believe it enters in conflict with the routing of the 8base application since the URL of monitoring is: https://app.8base.com/workspace/${workspaceId}/functions/${functionName}/logs
Do you think we could fix that issue so that we can monitor functions that contain a / in their names, please?
@andreasblondeau
Hello!
Maaaan, this is pretty cool use case and a nice bug actually
I see you use [FUNCTION_NAME] argument of generate command to quickly create structure for your custom functions (which is pretty cool, again, and understandable) but I’m afraid we didn’t take this use case into account (and if you try to deploy resolver with slash in name - CLI will throw an error). So basically it’s kinda a hack which we don’t validate (oops).
I’m not sure we will handle this thing on the frontend side (escaping the slash in function name), but I guess it would be cool to have -p (--path) flag in generate command of CLI which will give the ability to specify the location of your custom function. Anyway I’ll have to advice with our dev team and come back to you with the feedback.
For the record, I kinda wish I didn’t have to manually name each function in the yml file. It’s pretty common for development platforms to pick up functions and generate endpoints automatically based on the file structure. Maybe fixing this would be one step to streamlining the whole thing.
I know I can generate a function with the CLI, but I often do it in the file system (when I copy a file) and I have to maintain the .yml file by hand. I also have to keep it up to date when renaming or moving functions. It’s easy to make minor mistakes there.
Got it. Yeah I’m not sure how we could detect manual changes to your directory (copying file/dir) and then accurately reflect that in the 8base.yml file, given that it should be a shared module, custom directory structure, or other code.
Have you seen any products that do this well and you endorse?
Vercel, Netlify and others have this kind of system for their serverless functions. Similarly, 8base could have a predefined file structure that is used to generate endpoints/triggers/task names.
Just from this, the system can already know which tasks, triggers and webhooks I want and what their paths/names ought to be. You could have a different naming convention, whatever makes the most sense:
I’m not sure I really gain anything by defining arbitrary file paths by hand in the .yml, it’s just another thing to maintain and break. Descriptions are not very useful, although you could optionally support adding meta data in the yml as well. I have 80 lines in my yml for 10 functions, and when I look at it I just see boilerplate.
I think the only thing left for the YML file is schedule. Which actually makes sense, because that’s a bit of a separate thing on top for some tasks. The yml could look like something like this:
schedule:
trail: "rate(7 days)"
I think you could match current functionality with much less manual configuration (and developer errors) this way.
Okay, I think I understand where you’re going but still feel a little fuzzy.
So we do have a “preferred” file structure that when you use our CLI generator commands everything gets organized according to. For example:
$ 8base init myProject --empty
$ 8base g task trail --syntax=js --shedule='rate(7 days)'
$ 8base g trigger afterProjectCreate --syntax=js --operation=Project.create --type=after
$ 8base g trigger beforeTeamCreate --syntax=js --operation=Team.create --type=before
$ 8base g webhook getUsers --syntax=js
These commands would generate a directory structure similar to the one you expressed above with all the YAML declarations appropriately configured.
With this said, are you then suggesting that:
We discard the YAML declarations file and instead simply deduce the the functions and settings based on an expected directory structure, file naming convention, and possibly meta data exported from a file?
We create a feature like “recipes” we using a single file with an entry like the one below, it generates the entire project directory:
Number one, exactly. Not really sure what you mean with the second option, but basically it’s best to just minimize configuration and avoid duplication and manual maintenance.
CLI generators can be a helpful tool for some people, but they don’t help me maintain the codebase, edit file names etc. (and I almost never use them). In this system, the CLI generator would only have to create a file, not YML (except for schedule).
It’s funny, you and I may be oil and vinegar when it comes to this one Personally, I get scared when too much “magic” happens behind the scenes. That said, I totally get where you’re coming from, as I too have run into issue where I change a function name in one place, deploy, and then run into multiple errors because I didn’t make the update at all levels.
I’d be really interested to hear more developers opinions on this, as I know that a number of people use custom directory structures for organizing their projects.
Personally, I get scared when too much “magic” happens behind the scenes. That said, I totally get where you’re coming from, as I too have run into issue where I change a function name in one place, deploy, and then run into multiple errors because I didn’t make the update at all levels.