jlaamanen / flayer Goto Github PK

The "type set" doesn't seem to merge duplicate TS types in more complicated examples - the same type/interface may exist in the set multiple times, causing an error.

Handle errors of two levels:

1. "User errors": Errors thrown while executing a function
2. Internal Flayer errors

On user errors, it's possible to access the original error class name via error.constructor.name, but is it of any use? I doubt you could easily make it work with instanceof checks on the frontend side, unless all the error types are included in the codegen...

Internal Flayer errors should use the FlayerError class, so it'd be easier for users to handle them differently with instanceof

• Exposed server-side functions getSession, setSession, destroySession
• Generate some session ID and persist it in cookies
• Get cookie parameters from configuration
• Basic in-memory session store with memory leaking
• Safer session ID generation with hashing (similar Express session's secret)
• Make session store API compatible with Express session stores
  • See https://www.npmjs.com/package/express-session#session-store-implementation
  • Example https://github.com/tj/connect-redis
  • Test with some simple existing stores

Build caching doesn't work when users who don't have proper rights open a PR. Caching uses GitHub packages for now, because Docker buildx caching only for local images doesn't work.

A couple of alternatives:

• Use artifacts instead of packages (was considerably slower when I tried them out)
• Add write rights to packages for any PR (might actually be very risky)
• Ignore caching altogether in case there is an error (good for me, not so much for others... but would at least work)

On the server side, it'd be nice to have visuals for the available modules & functions. Maybe this should be made optional/configurable?

Maybe something like this (although the package root name would only be known in generatePackage?):

Flayer started on port 1234

Modules:

📦 "server-pkg/hello"
├─ 🟢 getStuff
├─ 🟢 getSomethingElse
└─ 🟢 setSomething

📦 "server-pkg/hello/subModule"
└─ 🟢 getFoobar

Also some better logging for generating the client package would be nice, with some coloring

Client packages generated in 12345 ms to <path>

It would be nice to be able to track function invocations and callbacks with a dedicated dev tool. All the data is accessible in the network tab already under "WS" filter, so this should be possible.

Requires a hefty amount of UX design and work.

When installing Flayer to the SvelteKit starter and running package generation in hooks.server.ts, the client package generation errors out, because it doesn't correctly determine the function locations. This is because func-loc relies on Node.js's Inspector, and when starting a session, Debugger.scriptParsed event returns a weird URL under the root. For example:

# Determined function path:
/src/modules/test.ts

# What it actually should look like (using Mac path as an example):
/Users/me/projects/sveltekit-flayer-project/src/modules/test.ts

Add full SvelteKit support and write an example.

List all exposed functions either somehow from the generated client-side package, or its own "catalog" message type.

It would be very useful to get the list of all available functions (along with all the typings & JSDoc) especially for the dev tools extension (#5) for trying out individual functions as easily as possible.

Risks

Could it be a security threat to list all the functions? They are visible in the generated client-side package anyway. All the admin functions would also be visible, as there isn't a way to exclude them.

Before releasing 0.1.0, it would be very useful to have E2E tests for all examples to more easily catch regressions.

• Migrate examples into this repository
• Create a Dockerfile for each example
  • A single runnable server image with all the static frontend files included
  • The current package version should be used in the build via npm link
• Create a Docker compose file with healthcheck
  • Healthcheck required for waiting the stack to be up & ready before running the tests (docker compose up -d --wait)
• Implement the GitHub workflow
• Test all examples concurrently with "matrix strategy"
• For each example directory:
  • Build & cache the Docker images
  • Start up the server with Docker compose
  • Run Playwright tests

Support callback functions on invocations or invocation results.

Basis for the support is already there, but should still be implemented:

1. After serialization, start listening to any callback messages for the functions in functionMap
2. In deserialization, replace the callback function with some kind of an emit function to send the callback result

Hey,

I find this package similar to TRPC, could you elaborate on how both compare?

Thanks!

Add more sections to the readme, e.g.

• Best practices
• How does it work
• Motivation
• Known issues/limitations

One caveat of Flayer is that it cannot take advantage of HTTP request caching, because all messaging happens via WebSocket. There should probably be some kind of configurable cache control on the client side package.

There are some problems when trying to make a server use a client package created by Flayer. The client package is ESM which shouldn't be a huge problem, but there also seemed to be some other problems.

Try if there is a nice way to add runtime schema validation e.g. via Zod.

Current implementation bundles all resolved types into one file without namespacing, making it impossible to have multiple different types with similar names. The types should somehow be namespaced, or maybe somehow inlined to make this work.

Seems like a marginal use case, but there quite possibly are viable use cases where different types share the same name, and it's confusing to the users that this wouldn't work.

Not to be confused with the bug #3

It seems to be bit of a chore to always have to include the auto-generated package along with the other source code that it's based on. It is possible to .gitignore the server-pkg directory now, but you'd need to generate the package locally whenever you clone a project, and if the package didn't exist, you couldn't run npm install on the client-side because of the missing dependency.

Maybe it should be recommended to add a separate script for generating the package, and executing it on postinstall on the server-side package.json?

• Figure out the best practices
• Write to documentation
• Update example projects accordingly

Resolving even the most simple functions take 10-20 seconds to generate. Also the generation is blocking the server from responding to other requests.

Find out the worst bottleneck(s) in type resolver and try to fix them somehow.