Persistence (DB, Firebase, etc) library in ReasonReact and Reason?

reasonreact
interop
bsb

#1

Hi!

I am a Reason newbie writing hist first production app, and facing a problem to save simple contact form data from a ReasonReact app. There won’t be any data updates, just keeping track of people wishing to know more, with their contact info.

Do you have a library you recommend, if possible with a nice tutorial? Or is my only option to write a backend app accessible by API calls?

Thanks in advance for your insight.


#2

You can bind externals to the IndexedDB or if you could consume Dexie.js as a module using bucklescript. Those are both local DBs though.

I don’t think it would be too hard to write bindings to Firebase’s API.


#3

I’m using this fork, but very small part of it, works fine for me. https://github.com/jappeace/bs-firebase


#4

Do you only need to keep track of it in the browser’s local storage? Or do you want it to be available across different browsers?

For local storage, I wrap https://github.com/localForage/localForage (I only wrap a tiny part of the API, just get and set basically). I originally wrote a library to do this: https://github.com/bloom/reason-browser-persist, but I don’t use it anymore, because the external code necessary to wrap the API that I need is so small.

If you want persistence across browsers / computers firebase is a great way to go. I’ve been working a lot with firebase lately, and though there’s the library @Ebuall mentioned that exists, I’ve written my own wrappers for firebase, initially because I needed to use APIs that weren’t covered in bs-firebase, and because I wanted to experiment with different approaches to wrapping the calls.

It’s unfortunate that using external to wrap things takes a non-trivial bit of work to understand, and that it’s one of the most important things to understand when starting out if you want to be productive right away in a Javascript world. Maybe that can get better in the future. But as it stands right now, I’d recommend taking the time to get comfortable with external, and use it as often as you need. (just be very careful that the wrappers your writing reflect the real values coming through. External code is a ripe source of baffling bugs)


#5

Out of curiosity - would you generally use that directly from the client/browser or from the server? If the client, is there a way to not expose things like the API Key to anyone who inspects the code? Or maybe I’m off-base and that’s not something to be concerned about?


#6

If it’s front-end, it’s exposed because you can access/inspect it. You can encrypt things, use .env files located on the server, but a dedicated attacker could eventually get them. If you follow OWASP practices you should generally be okay. Dumb clients and smart servers are probably the most secure way to fly though.