WatermelonDB with Radek Pietruszewski

    0
    296

    React Native Radio | Episode 109

     Panel:

    • Nader Dabit
    • Mike Grabowski

    Special Guest: Radek Pietruszewski

    In today’s episode of the React Native Radio podcast, the panel talks with Radek Pietruszewski who is a software writer. The panel and Radek talk about WatermelonDB, React, React Native, and GraphQL. Check out today’s episode to learn more!

     Topics and Questions Discussed:

    0:38 – Nader: Tell us about yourself, please!

    0:43 – Radek: I am Radek and I work with React Native and React work nowadays. Also, I use IOS among other things.

    1:10 – Mike: I know you were originally an IOS developer, b/c you were wearing an awesome SWIFT shirt when we met. There are a lot of people saying IOS developers don’t like React – what made you to go through the shift?

    1:43 – Radek: I am doing React Native to progress. Considering what we need with our small team it made sense to us. It simply the best available option on the market right now. What is exciting is that you can express yourself really well. Working with React and React Native it’s more pleasant than using other things. If you already know JavaScript then it’s the best of both worlds. A lot of complaints that people have don’t apply.

    3:34 – Mike: How does the adaption of React Native look like?

    3:47 – Radek: This is a tricky question b/c we haven’t shipped anything with React Native through our company, yet. We are using React Native with a new product that hasn’t been shipped, yet. Before that we were in JavaScript camp, so going to React was to have people deal with native code.

    4:44 – Mike: So I guess that’s the main topic of the recording, which is WatermelonDB. It started as a development with…

    5:14 – Radek: Exactly right. We looked at other options. We had many requirements of specific combinations, which was very niche. We stared building WatermelonDB and then it got out of hand and grew into its own

    6:04 – Nader: Why would someone use WatermelonDB?

    6:15 – Radek: WatermelonDB is a full stack – web browser, Android, etc. It’s a database framework solution, sort of thing. It is a couple of things. We need a local database. We need to share the same code through React native and the browser, which disqualifies Elm. It has to scale to relatively big sizes for mobile apps. It has to be sync-able and it has to be fast. I mean the app has to launch fast. You have to be able to load everything lazily when you need it so even when you have tons of data in your app it can launch fast. Like a TO DO app.

    9:51 – (Guest continues to talk about the details and the ins-and-outs of WatermelonDB.)

    10:35 – Nader: Cool. First question: If it is an implementation of sequel light if you have a data source does it have to be a certain type of data source?

    10:56 – Radek: For WatermelonDB, you have adapters and you have 2 that work right of the box. You can hook up any raw database under WatermelonDB. There is an adapter interface. You can do some pretty crazy things in principle. You can connect to some remote things even.

    12:05 – Mike: What I am interested to understand is the reactiveness?

    If I have a remote source or a full source- how do I deliver those updates and what is the overall cost of the update for the network?

    12:56 – Radek: There are a couple of things: observability and syncability.

    Observability is how you plugin data to the components. (Guest continues with this topic.)

    Most of this is in the JavaScript realm. The data interface is purely imperative. Watermelon is the API on top of that.

    Syncability needs a little bit more work to synchronize. Here are the changes that occurred (x, y, and z) and you can apply it to the local copy. That part needs documenting. Sorry this has only been in opensource for a few weeks now.

    15:55 – Mike: Thanks for that. How does that implement to the JavaScript side? What happens under the hood?

    16:22 – Radek: So we are talking about how components update when the data changes? Correct? (Yes.) So what we do right now there is a higher component called observables. WatermelonDB exposes observing changes to queries. WatermelonDB exposes an observable that changes over time. You wrap a component with and l=plugin an observable. When a change to this list is detected Watermelon will change. It will get the data that is changed to the list and it will be rendered to the new component.

    In the future we could do it even smoother and better but we are waiting for the React suspense to make it better.

    18:11 – Mike: Thanks!

    18:16 – (Nader asks Radek a question. It refers to GraphQL.)

    18:33 – Radek: There is nothing specific of GraphQL to Watermelon. There is nothing there. Having a backend for the data it really doesn’t’ matter. Watermelon is about synchronizing the WHOLE database. Not pulling data online and caching bits of it. For synchronization you really don’t need a query language like GraphQL.

    19:55 – Nader: That makes sense. When you are sending data to your source is Watermelon the intermediate layer? Do you have to make 2 requests or 2 API calls for this to happen?

    20:20 – (Radek answers the question.)

    21:07 – Nader: In reference to the offline piece is concerned…when you implemented this what were the biggest technical difficulties.

    21:44 – Radek: Mostly performance. (Guest goes into much detail.)

    Finally – you have to make sure things work together.

    24:12 – Nader: How hard is it to learn RxJS? If someone is interested do you have any pointers?

    24:37 – Radek: Reactive programming is one of those things that it’s a sort of thing that is getting popular. When you see examples your brain is saying what’s going on?! It’s odd. But it’s one of those things that when you spend some time learning it and putting things together it starts making a ton of sense. If you would like to learn it I wish I had specific links to it but definitely Marble Diagrams. This will explain how RxJS works. It’s a good visualization. It shows data overtime. Observables are useful b/c when you have synchronized things and variables that change overtime; it is good.

    27:16 – Nader: For USE CASES: A.) Good use cases? And B.) Where to learn it?

    27:30 – Radek: Watermelon will be great for use cases. If it’s something you have built offline. If you have scaled from smaller to larger sizes, and need to synchronize to other things. Ember is a competitor to ours, but there are features that we have that they don’t.

    29:03 – Nader: Anything else?

    20:09 – Mike: I wish people would share code between React and React Native. You would think that people would share code between the 2 platforms but they aren’t.

    30:17 – Nader: It is an interesting topic between React and Reactive Native. You can’t do a lot of things w/o starting from scratch.

    30:40 – Mike: It is tricky and lots of people aren’t reaching into it. It’s my general impression and maybe we need to build more kids and how to educate people effectively. Making sure your app works in both app and mobile. If anyone has any questions feel free to IM me.

    31:53 – Radek: It’s not easy you are right. I think some of it is b/c some people don’t want the same thing as an app and as a web thing. You might want to build a different thing.

    33:05 – Nader: That’s a good topic and that can be a different episode.

    33:18 – Picks!

    Links:

    Picks:

    Nader

    Radek

    Mike

    • None, really.