Thanks, guys.

Um, you can hear me, OK.

All right.

Yeah.

So Good morning.

I'm really excited to be speaking at J s.

Khan.

Uh, I've never really spoken at a conference before, or at least one with.

Thanks.

So on.

Um, it's really exciting, because in 2015 Patricia Garcia gave a talk here in Berlin A J S.

Khan on offline for status on.

I wasn't there for it, but I saw it a year or two later on YouTube.

Um, and I kind of figured out where her Lincoln profile was.

There was no job.

So I found her get her profile, and I found a link to Repo, um, at Justin's organization, which is field intelligence, where I work now by email.

Justin in.

Two weeks later, I was on a plane to Nigeria, and now Patricia and I are colleagues, and I'm speaking here about, um, offline first stuff.

Um, So the work we do is in, um, trying to deliver health care commodities where it's a bit tougher to deliver them, expanding access with partnering federal governments and with down to small pharmacy traders.

Um, and doing that with software supply chain software um so we're headquartered in Abuja, where we work.

It's in the middle of the that just below the red part in Nigeria.

And this map is population.

And, um, kind of one of the reasons why Nigeria is because it's huge and it's growing like crazy.

It has a massive market, and it's like about 1/6 of the continent, like 200 million people.

We're a small team of soft developers, operations people.

We have an office there, a small one here in Berlin and then a couple operations offices in Lagos and Nairobi.

Um, so three years ago, four years ago, when the company started, you kind of asked the question.

OK, what text stack are we gonna use for pharmacy supply chain management?

Um, you could buy one.

You can use one that's already built.

There's a lot of them you can customize on top of ah development platform, like an oracle or a s, a p lot of warehouses in places and Nigeria do this or you do what a lot of large companies do.

A lot of large tech companies and Fortune 500 companies where they, um, just build their own.

And if you're gonna do that and it's 2015 2016.

You're probably gonna choose, like a very boring but sensible stack, maybe something like C sharp dot net or jango with python or ruby on rails, something with a post press or some sort of sequel.

Relational back end.

Um, which works really nice with enterprise resource planning.

You get a lot of stuff out of the box, a lot of tools that can really help you.

Um, but for us, our requirements were a lot different than that.

And the contrast that I kind of like to invent.

People will talk about these cities in different ways, but I like to think of Abuja and Lagos as the two places we need to operate and Legos.

For people who have been there is a mega city.

It's like a country.

It's 20 million people.

It has tons of growth, tons of money, tons of opportunities.

And then it also has, um, networks that sometimes work and sometimes don't work.

You're a small pharmacy.

You connect thio the Internet on a cell tower.

There's tons of cell towers.

You see them everywhere.

But then there's a traffic jam right outside of your business, and suddenly 10,000 people are trying to use the same cell tower and you don't have network.

But you need to keep working.

And then Abuja is a planned administrative city of just like a 1,000,000 people.

And I always have Internet there.

People don't carry cash they pay with bank cards.

Are partners at the federal government, have this giant command center room that has network.

It has HD TVs.

It has a rotating Web camera.

That fall is because you talk and they need to see what's going on in the whole country.

Um, so we want to make something that's better than just a traditional, boring Web application.

We need something that can work in both of these places, Um, and so that means doing something that's offline, capable and offline is not binary.

It's not a it's an offline, capable operates or it's an online app.

You have Well, it looks crazy on the screen.

You have, like a lot of different options.

Um, the 1st 1 is what we called small offline.

These are names we made up for these categories, and it's kind of like a marketing gimmick that a lot of Web based APS use where they say we're offline, capable and people who aren't software developers don't know what that means, but like we know what this means.

It's like kind of like you're working on an issue ticket and get hub and you lose the network, an activity you can keep typing.

Um, you know, the data will stay there.

Maybe it's thrown into local storage, but you don't want to, like, refresh.

You don't want to click around so we couldn't use this model.

It's not gonna work for us.

Um, medium offline, which is our word for like just using a native app like a iPhone app, an android app or writing for Platt like Windows or Mac, a less is a lot more attractive, and I've done work on acts like that before for pharmacy supply chain.

Our company has well, and it's not something that we're necessarily gonna rule out in the future, but it is still very manual.

There's question marks for how offline it is because it totally depends on you.

Is the developer what kind of data base that you're working with?

What rules are you setting up and how are you sinking with remote.

So like the example is like you pay tohave offline features in consumer APS like like Spotify and like do a lingo that give you offline features That duel Inglis seems to work really well.

But like Spotify eyes, it seems like every time I get on a plane, it forgets what I said to download off line.

Um, big offline is really important to think about, because this is how hospital I t systems work most of them.

Historically, this is changing.

But what you've had over the past couple of decades is Excuse me like a very large on site deployment of servers, even a server warehouse.

You have high tea staff, you have a local area network, and it's because clinicians need their software to work off line.

It's not like offline is new to tech companies in this industry, But as I said, like, that's not gonna work for us.

We can't put a server in, um, like, right now we're working with about 30,000 pharmacies, and there's hundreds of thousands to plan for.

So we went with the Web with offline first in the Web.

That gets us kind of the things we want.

Lo I t support You could do the whole thing off line, but it's still the Internet.

It's still sinking.

Um, and there's a lot of talks on which distributed database to use, like the basic set up for an offline app.

Web app is, You put a service worker in you tell it to cash the static application, and then you work with local storage in the browser, which has become a lot more attractive over the last several years.

You get to use a lot of the user's available disk space, a percentage of it.

But how do you work with the in browser database?

And what do you replicate with?

And, um, Couch TB and pouch TV, which some people at this conference helps build, are kind of like the tools that most people end up using.

We're really happy with, um, the area that they cover for us.

If you know of some cool tool that somebody has, like this question that I often get is like, Oh, why don't you just write your own super cool like replicating thing that uses Blockchain and Kafka and is events sourced and the thing is that, like with these two are problem is never in the actual replication protocol.

We're never We don't have engineers sitting around wasting time trying to figure out what steps went wrong.

If there's a little bit of network, the documents sink.

So these two have been really useful for that.

Like somebody gave a talk a while ago where they said friends don't let friends build their own replication protocols.

Gregor said this And, um, yeah, all of our problems are elsewhere.

Um, we have our stack.

Uh, we're sticking with it.

Um, and like, what could go wrong with this somewhat non traditional, um, application.

And, um, for those of you who have maybe done work in, uh, like global public health, um, you know that it's not actually this very well clearly administered, highly educated system of people with clear incentives like it's constantly in a state of emergency.

Um, the whatever the current situation is, however, the current administration's air working, there's just this constant need to build things quickly and make things happen and very sort of unclear incentives.

It's not like a market economy that's just working off of, um, bottom line taller.

So we started heading, like, a lot of problems right away.

Even though all of us have had experience in building these kinds of applications, we were building them at a very much bigger scale than what we done before.

And the first problem you hit right away is what do you sink?

Um, you have to segment the data somehow.

You can't.

I mean, we did.

We started by just giving all of the data to every client we say like you get the whole database.

But then over time, you need to start segmenting on something.

Um, because if it's all gonna get stored in the user's browser doesn't matter how much space they have.

The data is growing linearly.

Over time, we're getting hundreds of thousands of documents of reports and shipments.

So you can't just tell the user take everything.

Um, and the way you segment data using these databases using couch TB is you set up a partition for a user.

You say this user is gonna get these documents and the way you get it from the main database is you just sink them.

So your rules for setting this up are just entirely custom code.

Um, your it's entirely up to you, so you have to take into consideration.

All right?

What are our rules?

We need Thio.

You know, somebody in Delta State should not be seeing the same data.

Somebody in Lagos State.

Okay, cool geography.

Next time, time based data becomes a really big issue because you need to sink.

Um, some of it, but not all of it.

But then this comes into, like, the domain model of what is okay to cut off because like to calculate how much stuff you have at a store or how much money you have in your bank account.

It's usually like what was the opening transaction.

And then let's add all of the debits and credits over time until I get the current balance.

But if I only sink your last 10 transactions, that's not going to give you the right data to get the right and number.

So you look at what to sink as a developer, and you have all of these different choices.

The other thing that I'm not gonna spend a lot of time on, is it with supply chain management, you have really crazy access rules.

You have tons of dynamic lis of who's allowed to see which certain sponsored commodities at which certain locations?

Two years ago, at this month, Um, so there's not, like a ton of Yeah, um, really clear ways to model.

Um, your data, um, next is network storage, and this is kind of exciting.

Um, normally in an application, you have, um, a database that you're working with, and so your code to access the data is just in one place, and you try and keep it abstracted.

Maybe someday you're gonna re platform, and you're gonna choose it from database.

But typically, you're working from one type of data store.

If we had gone the traditional, like web framework application, Um, And with, um, online offline, you have data that can be coming from the index TV browser database through pouch.

You have data that could just be, like, in and in memory.

Excuse me?

Cash.

You have requests from the browser to get remote data that you don't have locally.

And then you have, um, back in service functions that are also talking to the same database that need to do similar business logic.

So developers don't really have a framework for where we're busy.

We need to throw our code somewhere.

If this was rails, I'd have an end point.

I'd have a new table and set up a new entity, and I put the coat under it.

And even if it's messy, everybody in the organization is used to that pattern.

But for us, it was just like just put it wherever you want.

Let's put it in the Lambda.

Let's put it in this back end script.

Let's put it, you know, in the front end.

And then over time you don't have, like, an isolated place because you're working with different network storage adapters.

Um, the biggest one of the bigger problems.

That isn't just us on the front end.

Doing Web based applications is, is modeling Jason, Um, modeling, Um, sort of without a relational database.

And there isn't a SW far as we know so far, like there isn't one clear way to do this that always wins.

There's a lot of different strategies to deal with the problems.

So normalization like you want, um, this table and this table and this table to be neatly separated, and you have foreign keys between between them like this is a database.

That's awesome.

That's what you want.

And so you you're a developer and, like, I'm gonna do this and Jason.

So I'm gonna create a document, a document, a document, a document, and then to get this document and to join on them, you're making http requests over a network because you don't know what the relation is yet.

So So then you say, OK, that's too much.

I'm gonna put everything in the Jayson document, and then a user says, Hey, we need to change the name of this item use.

Okay, Let me just do a bulk update on half a gig of data and hope that there aren't any conflicts.

So and it's not always clear what the right strategy is.