Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
pancomplex
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
91.
▲
by
pancomplex
3y ago
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.
92.
▲
by
pancomplex
3y ago
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.
93.
▲
by
pancomplex
3y ago
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.
94.
▲
by
pancomplex
3y ago
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.
95.
▲
by
pancomplex
3y ago
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 bla
96.
▲
by
pancomplex
3y ago
That's a super valid use case. Let me know how it goes!
97.
▲
by
pancomplex
3y ago
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
98.
▲
by
pancomplex
3y ago
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.
99.
▲
by
pancomplex
3y ago
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 e
100.
▲
by
pancomplex
3y ago
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 s
101.
▲
by
pancomplex
3y ago
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 its
102.
▲
by
pancomplex
3y ago
Haha good call! Let's do it.
103.
▲
by
pancomplex
3y ago
Yup, exactly. I’ll update the readme to make this more clear.
104.
▲
by
pancomplex
3y ago
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 :)
105.
▲
Show HN: RemoteStorage – sync localStorage across devices and browsers
(github.com)
129 points
by
pancomplex
3y ago
|
62 comments
106.
▲
by
pancomplex
3y ago
Update: we boosted the text contrast and we'll make some more visual improvements to the Blog throughout the day, too.
107.
▲
by
pancomplex
3y ago
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:
108.
▲
by
pancomplex
3y ago
Appreciate the feedback, we can likely tweak the colors a little!
109.
▲
by
pancomplex
3y ago
Hey HN! I wanted to share an experiment I ran that tests the performance of RSC vs traditional client-side React on one of our product websites (productonboarding.com). I know RSC is a bit of a controversial topic since server-side renderin
110.
▲
React Server Components made our site a lot faster
(frigade.com)
40 points
by
pancomplex
3y ago
|
56 comments
111.
▲
Show HN: It's time to rip out your iframed Typeform
1 points
by
pancomplex
3y ago
|
0 comments
112.
▲
The Frigade (YC W23) Vanilla JavaScript SDK
(frigade.com)
1 points
by
pancomplex
3y ago
|
0 comments
113.
▲
React NPS Survey Component that wont get hit by adblockers or bother your users
1 points
by
pancomplex
3y ago
|
1 comments
114.
▲
Say goodbye to janky iframed Typeforms
(frigade.com)
2 points
by
pancomplex
3y ago
|
0 comments
115.
▲
We got SoC 2 (Type II) certified in just 3 months
(frigade.com)
2 points
by
pancomplex
3y ago
|
0 comments
116.
▲
Stop Storing Impressions in LocalStorage
(frigade.com)
1 points
by
pancomplex
3y ago
|
0 comments
117.
▲
Next.js vs. the World
(memos.hawkhill.ventures)
3 points
by
pancomplex
3y ago
|
2 comments
118.
▲
by
pancomplex
3y ago
We support i18n through dynamic variables. In short, you can define your flow in Frigade and instead of hardcoding strings in one language, you can simply pass in a variables from your codebase. Do you use any i18n platform? We're thin
119.
▲
by
pancomplex
3y ago
We were surprised too. We started looking for a solution at our last startup and never found anything.
120.
▲
by
pancomplex
3y ago
Coming soon :) -- we started with React and Vue is the next web frontend framework on our list.
More ›