pancomplex

I looked around, but all the open source analytics projects I could find were bloated with all kinds of UI and unnecessary code paths. They also all seemed to use row-based RDMS as the data backbone (vs columnar stores like ClickHouse). I was looking for a backend-only solution that we could shape for our product use case that could scale.

So TLDR, if you're at a smaller scale (<1M MAUs), you probably will be fine just using a table in MySQL or Postgres. If you have a lot of traffic and users, you will need something like Trench that uses Kafka and ClickHouse.

Good news is you’re not required to write any HTML when your engineering counterpart has wired up your component. We have a visual editor powered by Tiptap that anyone can use

I am not too familiar with Magic Loops, but really there's nothing stopping you from building such a pipeline. Frigade allows you to use any schema for your content and state management.

We're targeting non-tech users who have some engineering resources available to wire up the React components. Once wired up, any non-tech user can deploy new versions of the same component without writing any code themselves (I demo this in the YouTube video around here: https://youtu.be/qrPip41Ecyg?feature=shared&t=70 ).

Not tightly coupled to React. You can use it with our Vanilla JS SDK that works with any Javascript stack (https://www.npmjs.com/package/@frigade/js) using the `getCollections` function: https://docs.frigade.com/v2/sdk/js/frigade#getcollections

Any features specifically you feel is missing in Frigade? Always trying to make the product better!

Ah my bad, Digital Adoption Platform :)

We also have a Vanilla JS SDK: https://docs.frigade.com/v2/sdk/js/quickstart

We’re focusing on React to start as it has most adoption.

Intercom is great too, depending on the type of product you’re building.

Appreciate the feedback — I think we can do a better job for folks not familiar with DAPs to explain the value prop.

Appreciate the feedback! We’re mostly serving b2b saas companies, but we do offer volume discounts.

We also only count people who actually interact with Frigade — not just your total MAUs.

Thanks! Totally makes sense re: who this is for. What we’ve seen work well is that the engineering team does the initial setup, and then after setting up the guard rails and look and feel, non technical folks can come in and manage the system from then on.

And JWTs are live! Thanks for the suggestion. https://github.com/FrigadeHQ/remote-storage/releases/tag/rem...

Hey HN! A week ago I shared an Open Source project I worked on and the feedback so far from this community has been awesome. In this new version we've incorporated a good chunk of the feedback and ideas we got from my last post. Check it out and let me know what you think!

Stay tuned! Would JWT support fit your use case?

You totally _should_ have your own backend / auth when using this. It is not a database.

But it’s dead simple if e.g. using something like Clerk.dev for your auth.

This is handled by Redis, as such, the last write will win. As the primary key is tied to the user id, there will not really be a concept of Machine A vs Machine B as the end user can only be in one place at a time.

Depends on what kind of data you are storing? The good news is you can self-host, so it's trivial to spin up a server in your own datacenter that meets your compliance requirements.

That sounds super useful. If you follow through with it feel free to open a PR with either code or a link to an AWS recipe.

Ideally we have as many different server and client implementations as possible in the monorepo.

Good question. I like the idea of having a configuration that includes optimistic writes and perhaps even reads from localStorage for projects that have very low latency/unstable network requirements.

That being said, the server is blazingly fast as it leverages Redis and Fastify under the hood. In most of my testing, even on WiFi in SF with a server in Oregon, I would achieve <20ms reads/writes.

That's a super valid use case. Let me know how it goes!

Thank you! My goal was to make it as stupidly simple as possible in the first version.

I am also pretty surprised Google hasn't yet built something that solves this. When localStorage first came out, I was expecting a natural extension would be a way to sync it to a centralized store to avoid having state reset between sessions/devices.

You'd need to keep track of that somewhere for now, but as someone else suggested here, we could soon extend the library to support JWTs for authentication.

Yes, I'll get an OpenAPI spec rolling soon. You can easily infer the API here for now: https://github.com/FrigadeHQ/remote-storage/blob/main/packag...

The server is nothing special by design, just essentially Docker/Node/Redis with persistence enabled.

The free hosted community server is supposed to be used for testing / proof of concept.

I didn't actually know about PouchDB but it looks very useful!

I think the main difference here is the use case. remoteStorage is not intended to be used as a database (just like localStorage is not intended to either), but rather to store non PII data such as preferences, impression events, etc. without having to roll and stand up your own DB and API.

Love this idea. Especially because JWTs are so ubiquitous like you mentioned, this could be a very lightweight way to secure the calls without doing too much if any backend work. My main goal is to make it as easy to use as localStorage itself but with all the benefits and security of having a centralized state/store.

Haha good call! Let's do it.

Yup, exactly. I’ll update the readme to make this more clear.

That’s right — my main idea with the library is to make it super simple for front end engineers to store preferences/flags server side without needing backend engineering work. Basically as simple as using localStorage itself :)

Update: we boosted the text contrast and we'll make some more visual improvements to the Blog throughout the day, too.

During the experiment we used Google's PageInsight which will give you a literal "Speed Index". Without RSC Google gave us a Speedindex of only 1.6 vs 0.6 with RSC, which seems to factor directly into the PageRank algorithm: https://developers.google.com/search/blog/2018/01/using-page...