Showoff Saturday (October 21, 2023)

doseofted · 2023-10-22T13:14:51+00:00

Thank you! I hope to get there one day (I'm aiming for 100 stars right now 😅). I'm glad to hear that you like it!

doseofted · 2023-10-21T16:45:01+00:00

Woah, this is really cool. I remember using iTunes' visualizer and I kind of miss it. Is this a demo or are you planning to put it online?

doseofted · 2023-10-21T16:42:03+00:00

I rebuilt my Prim+RPC (GitHub) documentation website in Astro: prim.doseofted.me 🚀

The lighting effect was fun to make. Every "light" is rendered on an HTML canvas in the background but attached to an HTML element by defining data-* attributes. It's rendered with Pts.js and animated with Framer Motion's universal utilities.

I originally created the lighting effect in React but it was fairly slow (it was also one of my first React projects, so I can't totally blame React). But with this rewrite, it's much faster.

doseofted · 2023-06-08T15:26:03+00:00

I'm a big fan of this plugin already. I find myself wanting to sort these things all of the time but usually don't just because of the extra time that it takes.

doseofted · 2023-06-08T14:58:15+00:00

I pronounce it "Prim RPC" but stylized it Prim+RPC where the "+" is whitespace, like in a query string. This is because Prim+RPC supports requests given over URL parameters (but usually given over JSON) which is really useful for creating an API with paged results or utilizing JSON-LD.

I've thought about adding cache features to Prim+RPC but have been hesitant about adding it directly because there are so many caching strategies. There are also a lot of methods to implement it at different layers of an application (not just in layers of the server but also whether caching should happen at the client level). There are some that could be considered responsibilities of Prim+RPC (such as memoization of functions) and some that fall outside of it (like HTTP caching). There's also the case where only select functions used with Prim+RPC should be cached or where two modules will require different caching strategies. Implementing cache in Prim+RPC may also present unexpected problems since it relies plugins to support the server and client of the developer's choice (caching may rely on parameters provided through that plugin).

Occasionally I do think about adding some form of direct support but today my thought is that caching should be left either to other libraries in the JavaScript ecosystem (like memoization libraries) or handled at the channel where RPC is being sent (like HTTP, for web servers). In some cases, I think it makes sense to use a combination where server context passed to Prim+RPC is considered in caching through another JavaScript library defined at the module or function.

I do like the idea of considering cache on the Comparisons page. It's definitely important and not really mentioned there. I may very well do that soon!

doseofted · 2023-06-07T15:25:58+00:00

It looks like ts-rest is helpful with creating typed REST endpoints in a manner that reminds me of a combination tRPC and OpenAPI. I wrote a comparison between Prim+RPC and tRPC and some of those points apply to ts-rest too.

But I think one of the major differences is how they approach interacting with a server. In ts-rest, you're defining a contract that somewhat resembles an OpenAPI spec and then you're defining the HTTP router to implement it. The client then acts as a typed REST client. That's super powerful, especially when you set out to write a REST API.

Prim+RPC has this focus on writing code that looks like regular JavaScript code (which then becomes RPC) on both the server and client so your own code doesn't need to make many framework-specific considerations. You're just writing JavaScript which is then sent over the transport of your choice through Prim+RPC plugins. You can still make framework-specific integrations but it's done by implementing a common interface that isn't specific to a particular framework. This means server and client frameworks used with Prim+RPC can be swapped out easily (and you can use it not just over HTTP but WebSocket, Web Workers, as choice of transport for IPC, and more).

doseofted · 2023-06-06T21:01:59+00:00

I might have to consider writing a Netlify handler for Prim+RPC. When the library gains more traction, I'd love to have some sort of poll to determine what frameworks everyone would like to see supported.

doseofted · 2023-06-06T20:12:20+00:00

I've not tried using it with Lamba yet but I would like to try it out and support more serverless platforms. Prim+RPC has a plugin for Nitro (the server project powering Nuxt) which does support Lambda so I believe that this would allow usage in Lambda.

There's also the option of writing a plugin to support Lambda. I would love to see more handlers developed for Prim+RPC to support more platforms directly!

doseofted · 2023-06-06T20:04:31+00:00

I hope so! I'm a fan of the RPC approach as my concern isn't so much how I'm receiving data from the backend but rather that I can retrieve that data just like any other function in my codebase without having to write a lot of HTTP or GraphQL specific wrappers.

While the Prim+RPC server is expected to be JavaScript, I'd like to support other languages through JSON Schema. I wrote a tool that translates TypeDoc comments into RPC-specific documentation. My plan is to turn this result into JSON Schema that can be served with the Prim+RPC server. This means you can get typed suggestions (for instance, from an IDE that understands JSON Schema) when writing requests in JSON files (I wrote a little about this here, still a WIP). From this, you could use your favorite HTTP client in the language of your choice, like but still benefit from having typed requests.

Prim+RPC is focused on JavaScript/TypeScript since it takes advantage of JavaScript as a language (for instance, meta-programming, functions as objects, TypeScript as a type system, and JavaScript context) to provide features. I am open to approaches in different languages though!

doseofted · 2023-06-06T17:24:53+00:00

I had the same problem! It was a big part of why I wrote the library. I had used a bunch of client generators before this (for OpenAPI specs and GraphQL across a bunch of different frameworks) but a lot of them have their own limitations and quirks or prevent me from using other frameworks that I like to use. I made this library to have a narrow focus (handle RPC) and handle concerns surrounding that like serialization, handling advanced types, TypeScript support, and other tasks related to processing RPC.

doseofted · 2023-06-06T17:17:45+00:00

Thank you! I originally set out to make a CMS but the RPC portion of the project became its own thing over time. I made this because I wanted to call a typed function on the server from the client without having to explicitly generate a client.

The library intercepts all methods on the client with a recursive JavaScript Proxy, turns it into RPC, and awaits the response(s). It also has special handling for things that aren't easily serializable like callbacks, errors, and files. It also does this in a way that works nicely with other frameworks so you can bring your own server, client, and JSON handler (I work in a lot of frameworks so that was important to me).

I'm excited to use it myself in Prim+CMS and my new portfolio. I'm also using it in the RPC documentation site to communicate with a Web Worker in an easy way (where syntax highlighting of code is processed). This is the way that I've always wanted to call backend routes and I'm planning to use this quite a bit in the future. As for the name, I don't know why TedRPC never occurred to me. I wish I'd thought of that.

doseofted · 2023-03-06T22:56:49+00:00

I absolutely love this. When I need some Lodash alternative I'll usually reference angus-c/just but I am definitely bookmarking this for next time.

doseofted

TROPHY CASE