Main idea
- All functions/types/constants are stored in packages (and not in canvases)
- a package name can be used like a repo eg
@darklang/homepage
- so no UserProgram types anymore, just builtins and packages
Implications
Canvas/service
A “canvas”/”service” only has Handlers, DBs, and Secrets (not fns and types or constants), and one or more @darklang.io
domains or custom domains
- handlers map routes to functions
- can call any function (in any package) with the signature
HttpRequest → HttpResponse
- or maybe we allow a little bit of wiggle room to make that easier
- or maybe the AI handles the wiggle room, creating functions like
@darklang.package-server.api.packageHandler
automatically
- DBs can use any type in any package
- Service templates could exist which bring in routes and DBs
- Issues:
-
if DBs are in canvases and code is in packages, how do we write code that uses DBs?
Idea for DB/workers/Secrets in a package world
-
where do tests live? If only in packages,
-
it seems natural to want to make a http handler out of a multiple functions (a middleware one and the one with the handler’s logic)
Packages
- packages are immutable types/fns/constants
- names point to specific hash
- eg
@paul.stuff.do_v1 ()
is really 572faed-23dab395
- updates create new versions
- eg
@paul.stuff.do_v2 ()
- changing a lower level function may change it all the way up
@paul.blog.getPosts_v1
references @paul.blog.getAuthor_v0
. If we create @paul.blog Our editor must create
@paul.blog.getPosts_v2` when
Permissions
- access permissions and roles can go across services and packages