Placeholder Image

字幕列表 影片播放

  • Cool.

  • 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.

  • Sometimes it helps to de normalize.

  • Sometimes it helps normalize, um, and document conflicts.

  • Patricia Garcia's talk had some really cool in depth details about strategies for using multiple documents, tohave to users, working on the same entity at the same time without causing conflicts.

  • Um, yeah, And then, um the other one is like around what you sink to who so like kind of access stuff you might have a list of pharmacy commodities that you need to send thio supplier, but it turns out there's two suppliers.

  • One for cold chain commodities, one for non cold chain commodities.

  • So you need to split the document.

  • So it's It's like a business rule that impacts how your modeling, the Jason and when a user says, Hey, I need to make a new type of database table you know, Couch people What?

  • Why do you say like it really depends on what you're doing?

  • Um, so it makes having a single framework for everything.

  • Um, difficult.

  • Um, so deciding how to segment data on DDE What to sink to users.

  • We created this thing we call an I D dispenser on.

  • It's just a remote endpoint that when a user starts may initialize the application.

  • Um, we have the browser make a call to a lambda and the land it takes the the user who it is, what their location is, what programs they have access to and it goes into talks to couch deviants is Hey, what document says its user need couches.

  • Okay.

  • Based on your business logic, it's X y and Z.

  • Landis's thanks sends it to the browser, and then the user has a subset of the data that they get to use and as an aside like this has so far been working for us.

  • But, um, if you're gonna use, like, infinitely scalable server lis functions, um, on behalf of clients, remember that other resource is of yours are not infinitely scalable.

  • And you might de dos your own database.

  • Um, yeah.

  • Uh, this is really exciting.

  • Like what we've started to do in our ap eyes With this problem of sometimes your network storage adapter is a local database.

  • Sometimes it's a remote data.

  • These sometimes you're a node is having a pee eyes that have all of that defined in them per entity.

  • Um, it's one a p i that we're using all of our different places in lamb does in the back end and on the front end in scripts.

  • And you're a P.

  • I can know what kind of network storage adapter you're using.

  • So, um, you have situations where you ask Hey, give me all of the reports and the FBI goes Okay.

  • Cool.

  • I'm looking in the database.

  • I have found three months worth of reports, and that's what I know about.

  • It's offline and the user then says, But I want a page back further than that.

  • This isn't fair that I should only see what's offline.

  • And the A p I, at that point says, I'm gonna switch networks toward adapters, and I'm gonna go fetch the remote dogs and give that to you.

  • Um, and then a lot of this ties back into, like, how do you designed this kind of application for the user?

  • Um, you have to, um, tell the user what's going on.

  • If they look for a report on their facility, some facility that's remote, maybe they don't submit reports that often, and they want to know.

  • Has this report been submitted and they're working off line?

  • The idea dispenser told them.

  • You should know about this range of documents.

  • You should have these offline.

  • So if you go in check and the documents not their display to the user, this thing doesn't exist.

  • I don't care about what's on the remote.

  • I know that this document was just never submitted in the first place or that it's there.

  • Then if you're going too far back to a segment of the data that we can't sink something that's much older.

  • Um, we tell the user, and we display in the u I, like this has got to be an online resource.

  • This is something that you're not gonna have offline.

  • So if you have network, you make the remote call comes back, says, Yep.

  • We don't know about that report or Yep, Here's the report.

  • Display it.

  • But if you're offline, you have to display to the user.

  • Um hey, like we don't know, like we were offline.

  • We don't know if this report exists or if it doesn't exist.

  • Um, so, yeah, that the last thing is some pictures where, um, this is like a remote clinic that has a pharmacy.

  • Um, and you can see there's like, a little bit of a visa, which is for satellite Internet.

  • And this clinic, um, had a pretty good Internet at the time.

  • It was, like 2014 and they had, like, 5 12 killer bits a second down.

  • And that was fine.

  • Like they could have an application on site on a laptop and dispense point of care to patients so his patients would come up still for the supply chain.

  • Not for the clinicians, necessarily, but you would track the movement of pharmaceuticals.

  • Um uh, electronically.

  • Um, And so when you're designing for this place, you think Well, hey, we can just use the network will just really make sure that that VI sat always works.

  • We'll talk to the I t.

  • Team will be really serious about it.

  • But that's not the case.

  • This visa would very frequently get slightly misaligned, and the clinic would lose Internet.

  • And what's really kind of the point of using this somewhat difficult and nontraditional application is that for that pharmacy, like it didn't matter, the application worked fine.

  • It continued to work.

  • They could create patients they could create, dispenses, they could look up their stock transfer stock internally.

  • And then, um oh, I should show the pharmacy the pharmacy is like that one in the back there all red and look the same.

  • But the, um the cool part was that when a shipment would come once a month from the central warehouse, um, what would you do?

  • You would have to manually enter that like you're using an offline system.

  • Um, and then, also worse is that you have hundreds and hundreds of transactions daily about really important commodities that the central team needs to plan and think about.

  • That's why they asked us programmers to build something.

  • So if you're not going to send that data back home, then it's like, wiry, you know, why are you tracking it in the first place?

  • Unless it's something later, some analysis or something, which is what a lot of systems end up being used for.

  • So the team would do is they would walk to this river, and I like this photo because it looks really nice.

  • But this river was like, really directly behind the pharmacy.

  • It's like just less than a kilometer, and, um, there's a cell tower over there now that when you're at the river and you have a cell phone and your tethering to your laptop, you have, um, find connectivity, and they didn't really do this every day.

  • They didn't need to, but they could just go over there whenever a shipment would come.

  • They would learn from the remote about the shipment, would update their inventory levels, and then they would sink to the central server and the central team.

  • These are all the commodities we dispensed over the last couple of weeks and the central team could see Okay, Cool.

  • They need more of this.

  • They're good on that, Onda.

  • We can know what to do next.

  • Even though they're ve sat is misaligned and the i t team is busy.

  • Um, yeah, that's kind of like the It's really exciting work.

  • Like we have to know a lot about JavaScript.

  • And, um, we have to do new things and try and talk our own team and our own self into trying to use patterns and put code in the right place so it can feel really frustrating.

  • Andi, At times we many times we will kind of look at each other and be like, What are we even doing?

  • Like what?

  • Why don't we just make a rails up or a jangle up like this is so hard?

  • Um, but like ultimately, it means an application that is more like a robust, like it can get us more data and it can work in the places we want to work in.

  • So even though, like a year or two ago, it was looking pretty scary, Um, there has been a lot of learnings from us about stuff we've done wrong.

  • Uh, that, um have made it possible to kind of safely start delivering this type of application at a pretty large scale.

  • So a lot of time, but thanks very much, guys for your time.

  • And it's happy to talk.

  • He Oh.

Cool.

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

A2 初級

離線優先的數據。Getting Bigger by Kevin Doran | JSConf EU 2019 (Offline-first data: Getting Bigger by Kevin Doran | JSConf EU 2019)

  • 3 0
    林宜悉 發佈於 2021 年 01 月 14 日
影片單字