kingstinct / zemble Goto Github PK

https://deno.com/blog/comparing-deno-kv

Maybe use something like keyv/packages/keyv/README.md at main · jaredwray/keyv

The @zemble/routes is very easy to get started with, but is missing a few things to make it on par with GraphQL:

• Support for OpenAPI. https://github.com/honojs/middleware/tree/main/packages/swagger-ui
• Client-side type safety. Could be done through OpenAPI or through Hono RPC. Since OpenAPI is the standard I think this would be preferable.
• General approach for @zemble/auth similar to what we do with GraphQL directives. Using hono middleware is probably an approach worth exploring.

Using the sofa plugin on top of your GraphQL schema would be the easiest way to achieve feature parity with GraphQL right now.

We should probably try to support validating flows that can’t fit all validation inside a JWT.

Do we need to extend our GraphQL directive for this - to support as many use cases as possible?

Clerk is interesting from two perspectives:

• The bundling of UI and backend
• Adding support for it to as a Zemble plugin

Since our ootb validation is solely based on JWT validation we need to invalidate tokens when things like a permission change happens.

One approach would be making tokens very short-lived.

Another would be invalidating all tokens before a certain time.

Both requires some sort of refresh flow. Either with a refresh token or by providing the previous token.

We want to enable bundling with bun build to easily support a wide range of runtimes.

Right now many files (primarily in routes and graphql packages) are dynamically imported which doesn’t include them in the main bundle. To do this we need to:

• Add a build step where we create files statically importing files we currently import dynamically (to be used by for example the routes and graphql middleware). We want to abstract this away (I think we probably want to still dynamically import in dev and test mode).
• Ensure static files (.graphql and other non-code-files) are handled correctly).
• Make it easy to bundle for different targets. ’bun build’ supports targeting bun and node, in most cases I suppose bundles build for node would support many other runtimes as well.

Purpose:
This way we can keep the source code (even in published libraries) in TypeScript, no need for a build step when publishing plugins. And still produce bundles that can be used on as many runtimes as possible.

https://docusaurus.io/

https://resend.com/

We already have some powerful abstractions, and code reusability reducing the code we need to write and maintain per project. But the final step to make this low code is being able to put together an app in a GUI.

The step shouldn’t be gigantic, essentially we just want to dynamically wire up the plugins we want to use:

• Make plugins findable through NPM package keywords
• Make it possible to install and configure these plugins.
• Dynamically generate an “app.ts”, or maybe a JSON representation of it.
• Restart the server (or just reload plugins) after config update

Examples use cases:

• Auth plugin that provides UI and state management for login, logout and password reset
• Chat plugin that provides a UI for chat
• CMS plugin that provides a UI for editing and viewing content

Ideally we want something that:

• Supports as many target platforms as possible
• Not tightly coupled to a runtime, for two reasons: bundle size and compatiblity
• Easy to use, like providing a /resetPassword page out-of-the-box from a plugin
• Themable
• Customizable - so it can be integrated in an app

Of course hard to check all the boxes :)

There are combinations we could look at. For example adopting React Native Components as our standard would:

• allow rendering and integrating these components on a wide range of platforms
• could potentially be used for SSR, microfrontends and RSC
• could easily be themed

Something to also consider is how to minimize bloat in the plugins. Let’s say we just want to expose a React Native Component we might not want to have it in the same NPM package as the backend code, since it would force UI dependencies when installing it on the backend and vice versa. On the other hand if we expose this Component through any kind of Server Side Rendering this might be desirable to some degree.

For state management using a cross-framework state management system like Zustand or Redux should do it. A library like this is easy to use in any UI framework.

The goal of the CMS and CMS-UI packages is to provide a base Content Management functionality.

To make it a complete solution it should be possible to:

• Easily extend it with custom fields

Interesting projects to look at:
Payload CMS
Strapi (many good things, but TypeScript and GraphQL support is so-so)

Passkort support is rising, and it definitely looks like the future of passwordsless.

I think it might be a good fit for zemble-plugin-auth-anonymous, since it in itself is not connected to any other user identifier.

What would make it complete is adding support for carrying over users between differetn auth providers. In GraphQL it should be a mutation called something along the lines of addAuthenticationMethod that adds passkeys to an existing user, or vice versa. It needs some kind of configurable hook for the implementation to wire it up.

Some links:
Passkeys: A No-Frills Explainer On The Future Of Password-Less Authentication — Smashing Magazine
https://blog.google/technology/safety-security/passkeys-default-google-accounts/
https://developer.apple.com/passkeys/
https://www.passkeys.com/

https://typeorm.io/
https://www.prisma.io/
MikroORM

Add support for chatting with the API:

• Using REST (https://js.langchain.com/docs/modules/chains/additional/openai_functions/openapi) - should be possible to use with Sofa for GraphQL
• Using directly with GraphQL (langchain-ai/langchainjs#596)

I think the main use case is ”LLM-enabling” the API, but other features could of course also be interesting to bundle in this plugin.

Many plugins provide general functionality, but are still dependent on a provider for certain tasks, some examples:

• zemble-plugin-otp needs an email provider (currently zemble-plugin-sendgrid).
• zemble-plugin-kv can be configured to use in-memory, cloudflare kv or redis.
• zemble-plugin-bull is tightly coupled to bull, this should instead be a common queue interface with different possible providers (bull with redis, in-memory, others).

A few design patterns we could use:

• Provide common interfaces that plugins could implement directly on the global context object. This is currently how otp/sendgrid deals with it. This is very effortless but is not very flexible (let's say we have a common redis interface which is
• Expose provider hook from each

Some things to consider:

• Flexibility - Should preferably support providing similar providers with different settings for different plugins (maybe we want to point at different redis or db instances).
• Maintain connections - a redis or db connection provider should handle connections in a nice way that ties into the app lifecycle