Transcript: Production APIs - Calvin Hendryx-Parker

I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

Hi, Calvin.

Hey Will.

Last time we talked about Python Web Conference, Loudswarm, projects you're working on.

The new version of Python Web Conference is coming up very soon, so I thought I'd ask you to say a little bit about that virtual conference and what people can expect.

This is the fourth year.

Yeah, fourth year for the Python Web Conference.

We started in 2019, uh pre-pandemic, but fully virtual.

Uh it's always been a virtual conference since the very beginning.

We felt it filled a gap where there weren't a lot of web talks, it seemed like going on at uh various other conferences.

And it gave an opportunity for those who couldn't normally make it to in-person conferences a great place to kind of gather and see great talks from the people in the Python community who rock doing all kinds of work.

Um so this year is gonna be March 21st to the 25th.

So if you're hearing this now, go grab a ticket really quick.

There's probably plenty of space uh left since it's a virtual conference.

We don't have constraints like catering and things like that, which is nice.

But we will have uh definitely more attendees this year than last.

We've already had probably about 3x the signups that we had of last year, which last year was double.

Uh so I was super excited about the growth of the conference itself.

The speakers this year are fantastic.

Uh, if you go if you go to look at pythonwebconf.com, you can see on the speakers page, it's my favorite page to go to uh because it is a beautiful page of just amazing folks who've who've you know given their time to come and speak at the conference.

And I I think you'll find it's just not your same boring old panel of people.

Uh there are really diverse, interesting folks from all backgrounds telling all kinds of stories.

We're gonna have you know two tracks of app dev.

We've got a cloud track, a pie data track, and a culture track.

And then we order added in a tutorial track a coup uh uh two years back, and so that's actually running all five days.

So we've got six tracks um almost all day.

It's a it's a kind of starts in the morning eastern time, goes till about one or two in the afternoon, uh US Eastern, trying to make it friendly for most folks who could join.

Uh, but we're expecting people from all over the world.

We've had you know 30 plus countries last year, you know, almost 20 time zones uh covered uh for folks who are joining.

One cool thing with the the platform we're on, it's built in Django, uh the Loudswarm platform actually allows for the recordings to be posted right away.

So we're actually you if you miss a talk or there's conflicting talks in about 10 minutes after that talk, those talks are online and actually people are time shifting and watching, you know, 24 hours a day, and you know, they're all hanging out in the in the chat.

We just use Slack for chat.

And so you'll see you'll wake up in the morning and find people from all over the globe chatting about the talks they were watching, or or Python, or open source, or who knows what.

Um, we've got some really cool socials planned as well.

Uh so each day there'll be some kind of a social activity.

One of our speakers is giving a talk on burnout, and she's gonna do a um breathing exercise and a mindfulness exercise that I'm really looking forward to.

I think that's really important for folks during you know these obviously troubling, trying times uh for us to focus on.

If you can't focus on yourself and help yourself first, you can't help anybody else.

So you you need to make sure that you're taking care of yourself.

So we've got a whole session on that plus a social dedicated to some mental health.

And I'm I'm looking forward to that.

Um, the keynote speakers, again, amazing group of people.

The last one on the last day is a gentleman I met out in San Diego into last year, and he's gonna talk about a project he's been working on, uh, a real passion project for him.

And I think it it should hopefully I I think it'll bring the room to tears, uh the virtual room uh to tears.

But yeah, it should be tons of fun.

I'm super excited.

The community really shows up for this one.

We've got over 90 speakers, which is I mean, I think last year we had 60.

So we're looking at you know 50% more, more of everything.

It's all all more.

It's an amazing conference.

It's it's been interesting too because everything, everything's been virtual the last couple of years.

The Django cons have been.

I think both US and Europe are planning to be in person this fall.

Um, but it's you know, even hopefully once we're back to normal, there's something to be said for a virtual conference because you can have more speakers.

It it doesn't limit people.

I mean, it'd be interesting to see if there's some hybrid approach or how that how that works going forward because a lot of the uh all the Django cons they they post the videos pretty quickly thereafter to YouTube, but there's something about yeah.

Yep.

So I'll be there.

That is the the format that we want it to be in.

We really want to reach folks who couldn't normally come.

And if you have a a need or some means by which you can't make it to the conference because of you know financial constraints, let us know.

Uh reach out.

And I'll be at DjangoCon as well.

So I'm looking forward to hopefully seeing you all at DjangoCon US.

Crossing fingers, right?

That's that's definitely on my bucket list.

Um when they announced it was gonna be in Porto two years ago.

I got so excited um to go.

Take all your kids and um Yeah, well,

Yeah.

We did talk about it a little bit, a little bit um the last time you were on the show, but yeah, I'm sure it's come on in the last year and you've you've made enhancements, so perhaps you can talk technically there.

But um perhaps as a kickoff, I wanted to ask about what was the motivation for loudswarm creating Python Web Conference?

Was that

The bulk of the platforms are pretty rigid and don't allow for a lot of uh that tight kind of tightly coupled engagement between chat, the speaker, uh, QA, the the podium experience afterwards of talking to people, you know, the the whole social aspect of it.

And we just felt there's a definitely had to be a better way to do that.

So we built one.

Um it's been really an interesting journey.

The technology we used underneath the covers for Loudswarm actually has helped us build other projects for other clients, which I'll talk about today because I think we're gonna talk about one of our other projects that we worked on.

And a lot of the the ideas that got spawned during the Loudswarm project have now shown up in a lot of our other projects, especially when it comes to things like serverless and scaling Django and doing things like WebSockets and real time.

Those are all really interesting topics that came out of that.

But yeah, the the Loud Swarm experiment has been totally fun.

Uh, it gives our developers a chance to kind of you know breathe a little bit and stretch and uh and work on technology that's that's a little more interesting than some of the other client projects.

Not that any of our client projects aren't interesting, but there are definitely aspects where they would love to try things and not have the risk of it being on a production project for a client, but something that's really owned by us and built by us.

Like you've got a template view, you've got a template, you get your HTML out there, you've tied up in some JavaScript, static files does its things, problem solved.

Oh, well, what did I need?

I need a template view and a URL conf.

Well, that wasn't that exciting.

But then I get, you know, there's all this other stuff you can do.

It's you hit basically a whole bunch of buzzwords there.

I don't mind which of those you kick off on.

Or helping to

Yeah.

Um, I'm keeping channels Yeah, I'm keeping channels alive, basically.

I I it's very much like, okay, this is where I want to spend my time, this is where I want to, you know, my my my my volunteer open source, but there hasn't been any of that time for probably six months now.

Um and okay, that will come back and I'll you know I tick it over.

But yeah, channels is in a sort of maintenance mode at the moment, like close a few issues and make sure it's compatible with the latest version, but it's still waiting for it, you know, the next.

I know.

I I I wish I had more time to spend on it as well.

I feel like channels is a almost a critical technology for Django due to the the real-time web web sockets and the fact that applications are more like applications than they are stateless, you know, web web pages.

100% channels.

Uh we actually just so the latest rather stuff we did was mostly to bring everything up to date.

So latest versions of Django, latest versions of channels, latest versions of Flower, which is a troublesome story, you know, because those things, you know, the the various as Carlton laughs because it he knows the the version dependencies between these things are sometimes tricky to get to get upgraded right.

So most of the work has been done on just shoring up the platform, making sure it's always on the latest um stable updates of things.

Same thing for the front end.

So we updated all the React um bits here and there, solved some you know, little niggledy type bug things.

But generally the platform is is how I want it.

Like it it really solves the problem well, uh, gives people a great place to come and view content together and and and and chat and socialize.

So you'd form is consuming channels.

And I I look at it and I think, well, you know, basically it's it's it's kind of okay.

You know, the the core consumer layer, the c the ideas, uh they're they're they're nice and solid and there's not much to it, and it's kind of simple.

And what's missing is like the the maturity and the the extra features around the top.

Um would you think would you say that's fair, or would you would you point to no, actually, this is where our problems are and we need that fixed?

Uh I think the simplicity of the framework allows it to be used in any way we want, um, much more easily than if you had kind of been a little more opinionated with certain features.

So the fact that a consumer is just dead simple to write, uh it makes WebSockets much more approachable to folks.

So if you've ever tried just talking to a raw WebSocket with like, you know, WebSocket cat or whatever on a command line and you just get a stream of junk back at you, uh it makes all that a lot more approachable.

So I some some open source projects maybe are feature complete and as they should be.

Uh I don't know if we've got a bunch of wishes for it uh necessarily other than to keep it easy, simple.

Uh it's easier to understand, it's easier than to probably maintain, easier to keep keep it secure.

I I go gay, I got one.

I got one for you.

It's probably and then that and I guess the issue really doesn't, it's not channels issue.

It's it's WebSocket issues, is that there's no formalized like authentication mechanism.

So a lot of times you're contriving your own means of of validating or authenticating or authorizing who should be connecting to a specific channel and what what kinds of things they're allowed.

So you have to basically come up with your own protocol for that.

Maybe some opinions are needed there to just guide new new folks in that realm.

Because it's not it's not straightforward.

I mean, a lot of the a lot of the issues that come up on the repo are things like um getting it working with Nginx or get um or a client keeps disconnecting and you know what JavaScript library should it use?

And quite often I'm a bit like, I have no idea what JavaScript library you should use.

I'm sorry, I do I just don't know.

So you have the Django backend hosted on a server and then the React front end.

What are you using for the React front end for hosting?

Because there's you know, there's Netlify, there's all sorts of options.

I'm just curious your setup.

Uh, I love the fact that we don't have to maintain you know Ubuntu machines and go in and patch them.

We do have to rebuild images.

So it's all done with uh Docker images that are deployed onto Fargate in Amazon, which is basically a a more easy version of Kubernetes.

Um that's probably doing it a disservice, calling it that.

But you you I want a place to run containers, I want a place to run my Celery tasks, I want a place to run my uh channels workers, and Fargate makes it very easy to deploy the backend pieces like Django and the workers and Celery and all those pieces just as tasks, is what they're called inside of the Fargate ecosystem.

And for the front end, we're just using React that's hosted on S3 bucket.

Uh there's nothing fancy about the front-end pieces because they all just it runs solely in the browser.

It connects back with WebSockets through CloudFront and the load balancer.

And we actually use the load balancer.

We split the load balancer in two so that WebSockets traffic goes to a whole separate pool of workers for the channels bits, and the uh API calls all go to a dedicated set of workers just for the Django bits.

Uh they're using the same image, but they have different characteristics and they need to scale differently based on memory usage, especially in the case of WebSockets, because each socket connection takes up so much memory, you want to be able to scale that separately from the API um servers, which actually are pretty low utilization.

Most things are cached when possible.

Uh, we use a lot of Redis uh to cache complex queries back so that you know anything coming in for like the big schedule for an event comes most of the time right out of Redis.

Although we're not doing anything fancy on the Django side uh as far as async, other than talking to uh salary workers and the the channels workers.

So I think we talked last time when we were doing a a Discord integration on the back end for uh Loudsform.

That Celery worker, that's not a seller worker, that's actually a channels worker.

So we're using the background workers feature of channels, which is pretty awesome, to basically start things on run.

So when Django starts up, there's no easy way to kick off a request to something or maintain a uh a stateful connection to anything other than like a database connection.

This allows us to actually say on run, run through these set of asynchronous tasks.

Some of them can be short-lived and some of them can be long running, and that's how we start up and actually connect to Discord servers to establish a web connection, a web socket connection that is server-to-server and not server to client.

I guess that's that's definitely one of the things that being opinionated versus being you know a little more open about how you do things for and it's unfortunate for new people, it's hard to grasp that.

It's hard to not know like what's the way what's the one way.

There's not always a way, but there's definitely some patterns.

So I think that would be a good idea.

I just I just did the update to my Django for API's book, and I you know, the only way I know is just by asking around to people, you know.

It's much simpler, but still the new update gets more complex, and yeah, it's like people have questions.

I'm like, I'll you know, if there is a if there is a consensus in the community, I'll I'll tell you, but sometimes there isn't.

Right.

So maybe as a lead and speaking of case studies, you do have a whole bunch of projects on your site will link to, and one of the ones we wanted to talk about, I don't know if this is switching over too early, but the flash predicting lightning strikes.

Um, so for folks who aren't aware of six feet up, you know, we're just a Python and just we're a Python and cloud consulting company, but we recently, well, in the last couple of years, have set like our 10-year objective.

Like where does what does Six Feet Up want to accomplish across a 10-year uh time frame?

And really it was to get 10 impactful projects in 10 years.

So when we think about impactful projects, we were trying to define a do-gooder.

Like what is a what is a do-gooder these days?

Like that you it took us two years to try and define that, and we still failed at defining do-gooder, but we did define what impactful meant to us.

And so the project I want to talk about, and if you go to our site, there's a there's a link for our impactful projects.

It's basically an acronym for criteria we use to measure a specific project against to see if it's impactful or not.

And the one that you're asking about is really cool because it's doing something that you know, as a kid, you're obviously fascinated with the weather, and or even growing up, like you you see lightning, you send thunder.

Although maybe most people, I don't know if most people do or don't.

I grew up in the Midwest, and so there's thunderstorms.

Yeah, there's lots of awesome thunderstorms, and so you'd watch these things roll by as a as a kid, and I just I'm obviously you know infatuated with it a little bit.

But we had a a friend of us, ours from the Python community, call us up and say, Hey, I've got a a friend who w wants to basically take a Python notebook where he's developed an algorithm for predicting lightning.

And you may think, Well, haven't we done this and we haven't?

Uh all the lightning watches and warnings that you get are based on knowing where lightning is striking now, not where lightning will be.

And so this is actually a new thing that doesn't had not existed until we helped him put it into a like a production state.

So he's developed this algorithm in a just a Python notebook, a Jupyter notebook.

Obviously, you can't deploy a Jupyter notebook into the cloud and say start start selling this as a as a service to folks, but he has come up with a way to give basically 99.6 accuracy and a 15 to 25 minute uh lead time.

Like so he can say within you know 99 plus percent accuracy, lightning will be here and within a so I can't remember what the radius is, but just like

is, yeah.

Uh it was kind of interesting, you know, as we're working through the project with the client.

At some point, he was actually with a race team down in Daytona for the the Daytona 500.

Uh, they had him basically in the pit trying to helping to predict if you because if you're not familiar with Florida, Florida is one of the lightning capitals of the world.

And so they run car races in a lightning capital of the world.

They want to know when this is coming so they know how long they can go until they have to kind of call things.

And that's actually one of the big reasons for this project is that there are lots of activities where if they didn't have to, if they could shorten the window by which they had closed down certain kinds of activities like planes taking off or landing or sporting events or construction equipment uh being energized or not energized because there might be lightning in the area, uh, I mean, the amount of savings globally is is kind of ridiculous.

Like it's a it's a very, very large number.

Uh I I hesitate to even fathom a guess uh at what that would be.

But the ability to not only just save lives, like if you know little league games are going on and you can accurately say we probably should, you know, get everybody to take some cover, you know, 20 minutes early, to the fact that you can save money from the the delays in flights cause million hundreds of millions, if not billions of dollars, to the economy each year.

And a lot of times they can't they have to be conservative.

Obviously, there's these are people in planes and it's a big deal.

But if you can narrow those windows, the the amount of money and time saved by people is tremendous.

So that's why this project was important.

Because it has this impact on the planet, the globe, people.

Um, there are now, you know, there's obviously more commercial sides of this where if I'm protecting if I'm an insurance company protecting giant equipment on construction sites, if that equipment can be de-energized when lightning hits it, then there's no damage or less damage to a piece of equipment, apparently.

And so they want to be able to use that information in an automated fashion to, you know, automatically shut down or turn on these these pieces of equipment or tell the airlines when they can and can't, you know, open up their windows for people to take off.

Also, that would be kind of handy back to the future type scenarios where you need to.

Exactly.

Your DeLorean.

And so we will go and run it and see like where the lightning's coming and w when it's gonna hit.

Like I'm in, I'm in Boston and there's all sorts of science and medical stuff, and I meet people all the time who are who want to put it up on the web.

And you know, there's less of a need of real time or these other things, but even just taking a Jupyter notebook and putting it up on the web, you know, is is challenging and there isn't a one size fits all solution.

Oh, that's for sure.

And uh if someone could solve that drag and drop, uh that would be worth a little bit.

I think a lot of times Flask is probably an easy answer for these kinds of things, but maybe you don't have authentication needs or you maybe your your needs aren't sophisticated, you just need to get an API on the web.

Where choosing like Django was is an easy choice.

You know, Django Rest framework is super easy to get you know something off the ground with quickly.

Uh, we're using the Nox um API tools for doing security, so you can actually easily rotate API keys and like enforce you know single clients at a time uh authenticating and using the API at once and then and also kick off people who shouldn't be off on there.

So it's a nice tool for generating like things like API keys because API keys, when you think about doing APIs, the I don't know the for me, the first thing that doesn't come in my head is how do I gonna authenticate and authorize I authorize people?

I just want to like build the cool tool that's gonna return some cool data to folks to do something interesting with.

Now I gotta figure out how to like, well, how do I like track their usage, you know, maybe build them, how to like protect certain usage, you know, uh levels, all kinds of like that back office stuff that goes into making a thing real.

And I think actually maybe I referred to it when I did a DjangoCon talk on auth.

But that is the yeah, the challenge of you know, you know, with JWTs, that's one of the appeals is you can time limit them and stuff.

Though there's I actually I'm curious to ask you, it's almost like the Docker question.

How do you feel about JWTs?

Because I feel like everyone was all on board with them, and my sense is now people are like a little less completely on the JWT bandwagon um for authentication.

Uh we because you know obviously I consume APIs in various projects, and it seems like every org has varying levels of sophistication with doing like API tokens.

Some it's still like basic auth.

And like, oh man, like I can't believe we're still here.

Uh the bearer tokens or doing like the you know, the rotating uh bearer tokens where you that seems to be a good pattern that it is is easy for folks to like comprehend and use.

Like it's easy to plug into Postman to try it out.

Like you're not it's not a stretch.

Um, so I don't I don't have a huge uh opinion on it other than make it easy.

I mean, there's some some systems out there where I've had to like sign the requests going back with the cookies and the tokens, and then you get back a signed response that you have to then validate the signature, and it was all for a like a video streaming service with nothing sensitive.

Like I was like, this this is that extreme uh for that, you know.

Um even for otherwise knowledgeable clients, I guess.

Right.

Let Nox manage the tokens so it has an API endpoint for authenticating, and then once you authenticate, you get your token.

And at that point you can manage those tokens and this the parameters of those tokens with with Nox, which is I I found to be really just a nice elegant solution uh to that problem.

Now on the front end, we also used um I think it was Django Sesame for doing like one-time passwords.

Uh we had done a project in the past where we tried to go passwordless, you know, where you basically put in your email address, get the token over in your email, come back over, and like you're logged in.

Ugh, email is still such a mess.

It is just, I wish that would work, but it really was a headache.

Now we still use it for things like password resets or invitations.

That's where we use sesame.

So it's really easy to send out a you know a couple thousand invites to people for an event.

They click on it, it's already got them logged in, they fill out their profile, they click accept, and they're in.

Like that that user experience is so you know smooth as opposed to like a lot of the signup experiences you may get at different sites.

So using the combination of Sesame for getting the invites out and then Nox for the front end having the token.

And we don't use any cookies in the Loudswarm application at all.

It's all using local storage with uh Nox tokens.

So maybe we're a privacy first uh event platform, but there's no no tracking, no cookies.

I mean, there's tracking obviously going on when you watch a video, uh, so we can know how many people are watching, you know, what videos and how long they watched for and things like that.

Uh but that's all done mostly server side or with the player.

It's not like, oh yeah, it's it's Julie that's watching this video, it's just a number of users.

I don't believe we try a specific user to what their viewing was.

We just want to know how many people were viewing a specific track or specific video.

Um is that your preferred client for consuming APIs?

Because there's I just saw in the orange site there's a new open source one.

There's pop or max, which are um I was curious as a practitioner, what do you like?

Um also I guess I'm kind of split 50-50.

I'll use Postman if it's real quick.

I need to like launch something.

But if I'm actually actively developing on a project, I'll be using I'm a PyCharm user.

I I like PyCharm Pro a lot.

And the HTTP client built into PyCharm is pretty awesome because you can actually have it run through and do full like save session state.

You can do this in Postman too.

You can save off variables in Postman and then like reuse them later in subsequent calls.

You can do the same thing in PyCharm, but just as plain text.

And so instead of having to like kind of drill through GUIs to set everything up, you can actually set up variables and you know do the login, get the token, then reuse the token to like now call these you know 10 calls afterwards and simulate uh a real set of transactions back and forth between you and the the server.

And you can actually do assert assertions, so you can actually make kind of unit test like uh bits in PyCharm to assert.

And actually, Postman has this too.

They they both got similar sets of features, but one's more kind of graphical.

If you're if you're not if you're kind of intimidated by lots of text, uh maybe you're new to it, or you just want a quick and simple way to do it, Postman's way to go.

If you're really diving in deep and really want to like you know, check the stuff into like source control and and have it right alongside your project, uh, the PyCharm HTTP client is really nice.

Oh, fancy.

So I guess it's not that new.

But I

Right.

I mean it depends the tool for the job, right?

For sure.

You're you're building butt button, you know, you're doing APIs.

And it's the same kind of thing, it's got a request builder and you can um you know uh customize absolutely every aspect of the request and you can view the request that the response in different ways and you can you know extract a bit and and then it will what one thing I really like is at the bottom it's just got you know a drop-down for um expressing this in in whatever so curl or requests or httpx or swift or rust or you know and and and I find that really handy because you say okay you've sort

of prototyping in poor and then um you know cut and paste it's into into your projector's working code um but yeah they all of these all of these tools have very similar capacities but that kind of um HTTP laboratory environment you kind of really need when you're developing against an API because the docs are never quite as good as you want them to be you know even like take Stripe they've got the best API you know they're not they're they're kind of great but you still have to make

the request see what comes back work out exactly what path it is you can't just go from the the API documentation um so yeah I use poor but uh and have been doing for a very long time but um yeah they're all great I'm gonna go try the PyCharm mod next I didn't realize it was built in there there's so many things to PyCharm I never you know I'm always discovering any

you.

It's kind of cool.

That sounds good.

So can I ask the flash you you you said the flash um the the tech on flash was uh built from what you've been working on in loud swarm so is is that built around channels and and as well or is it more the the serverless deployment and the it's

's no real fancy front end application around the front of it it's not a consumer app it's really a a business to business type application the pieces we leveraged from loud swarm though were definitely the Fargate deployment technologies and and techniques this project goes a little step further in that we're also using lambdas uh we I don't think louds loud swarm does use a couple lambdas here and there but it's not in the main flow of the application where this one actually is in the main flow we have uh lambdas listening to uh S

NS topics which are just basically messaging coming from Amazon for weather data so the National Weather Service the NOAS has a a bucket a public bucket full of weather data which is really again so cool when you start exploring some of these areas that there's like this open data I mean just like terabytes upon petabytes upon petabytes of weather data are available to you as a as a human being on this planet.

It's all open and free and accessible via APIs or just it's just sitting in an S3 bucket.

So we we take those notifications there's like a real time uh feed and an archive feed and I say archive in air quotes because it's like every 10 minutes is the archive feed and the real time feed yeah it it really and the real time feed is a few times a minute you get uh the radar sweeps that are that are coming through.

But with that uh archive data we now have a lambda that can go grab the data out of the bucket uh pre-process do some some level pre-processing against it throws the results into a Redis and then that's available immediately for the Django API now to consume and reuse and republish back out.

So a lot of these things is about how do how can we speed up that prediction process.

When we were first handed that notebook to take an archive weather file and process it into the model needed to then do predictions against uh we were talking in the order of like minutes.

I can't remember maybe in the case study we said how many minutes, but it was it was not a fast process for them to process it.

We got that down to uh in seconds now you know using lambdas to be able to scale that out changing up some of the you know algorithm to be a little more efficient.

And it's it's like it's a great combination having like scientists working with real software developers because scientists have amazing ideas and when they can explain it to a developer who can truly take that idea and accelerate it on the web their eyes just light up like crazy.

They're like I can't believe this can actually happen so fast or we can deploy it to to you know into production and be able to use it.

So that that's really fun it's like I love that part of the experience of but it's

It's beautiful and then then wrapping all those trimmings around it.

So we we use a lot of the cloud native tools in Amazon for this project.

Whether we're deploying the the main library we actually extracted the the part of the notebook that was like the important bits into its own dedicated python library that we deploy into code artifact that is now used in the building of the couple containers we use.

So we have a container that runs the Django bits which is the API and then we actually deploy a container for the lambdas.

I don't a year and a half ago and Amazon announced support for Docker images uh as a runtime for Lambda which is we have a really good blog post up on the 6V site um because it's not straightforward.

If you've got C dependencies this starts to get a little tricky so packaging it up in a way that actually works.

If you just got you know simple hello world you know Python you just use the the base Python image for Lambda and on you're on your way.

But as soon as you've got something where you need to do some C compiling and like for example using um NumPy and pandas and things like that, the more scientific type tools data science y tools that gets tricky.

So we documented all that put it up on the the blog post uh for how to do that.

So we deploy our Lambdas as Docker images.

We build those Docker images using the code artifact where we deploy the the wheels for our Python library so the same Python code is used in the lambdas that's used over in the Djangos and it's all deployed together using uh the code pipeline actually we aren't using code pipeline on this one we used GitLab a different customer had used the GitLab this time and I actually like GitLab um that was kind of my first experience with using the CI tools in it and I'm definitely uh GitLab curious now and want to tr

y out some more but we in the past we've used code code pipeline and code build on Amazon or we've used Bitbucket pipelines.

We're currently doing a project where we're doing Azure DevOps pipelines.

So we've got a lot of experience across all these different ones and I'll say the the GitLab ones are really nice.

I'm really impressed with that one.

I mean are you using particular packages to help you get from the kind of um scientific Python world into the API world into j something that's JSON serializable or are you right what are you doing?

Now I will tell you that uh if you are going to try and use Redis outside of Django and basically have them both share the same cache it is possible that you will the you'll stub your toe hard uh probably the first time you do because the settings for Django's Redis, which is where we're basically doing these kind of move this data I think we don't store the data frames in a in a more native way than I think taking them to JSON data, putting that in the

Redis cache and then being able to serve it back out through the the API.

But there is a setting you'll have to be aware of on the Redis cache side which is to allow it to be used from other tools.

Otherwise it Django's Redis cache functionality starts kind of doing some native things that aren't compatible with like just getting a key and setting it in Redis.

Because that's the that's the sort of tricky question.

Yeah message back I think the knee wasn't there yet and it's obviously easier to keep it uh non-binary until we you know we don't have to until the performance is a problem.

And the performance there wasn't the problem.

The performance was really in the in the the data frames and the the pandas, you know, work against the numpy arrays.

Because there's some big arrays.

When you think about data or weather data, and I didn't know much about weather data until we started on this project.

Uh, but there are just tremendous amounts of data that are generated every second of every day uh for the atmosphere and all across the whole like well, we're only dealing with the United States right now, but basically that you can split the whole United States up into this giant grid, and then you get layered data uh for the various you know h altitudes in the atmosphere, and you get all that.

I mean, you now you gotta figure out what to do with it.

So you can see, you know, more or less real time what the wind's doing.

Um, and so it's it's a very sort of accessible way to see weather and realize, yeah, there's sensors picking up everything.

But as you say, the question is, what do I do with it?

You know, how do I compute it and how do I present it?

That's kind of the and the hard hard Oh,

And so we actually use that to feed back into the system and do like almost like unit tests.

You know, did the predictions predict where lightning was going to be?

So we have a a feed from the lightning providers into the system as well that we periodically run tests against of the predictions.

That reminds me a little bit of I was gonna say there's there was an app, um, Dark Sky, which was built in Albany, New York, which is near where I used to live.

Um, I think Apple bought it.

Um, but it was one of the first.

It did, yeah.

Um and it was again, it was using that's how I first knew, oh, there's all this government, you know, taxpayer funded data.

Um, and nobody had thought to do predictions around it.

I think hopefully Apple's bringing that into the default Apple weather app.

So I don't mean to necessarily slag on Apple.

I'm sure it was a good exit for them, but it was very cool.

But I remember it was um because I almost I almost interviewed with them.

It was, I think it was it was like six or six or seven recent college grads who you know had that insight and took the time to build it.

And um these predictive models based on existing weather data, I that's really interesting.

And you know, as you said, lightning strikes, there's so many consumer business to business applications of that, especially if it is truly accurate and you're testing it to confirm that.

Um that makes a lot of sense.

Yeah.

Science experiments driven by Python.

Um I I looked up, so when I was mentioning um, so it's drug molecules, uh, where there's millions and mil like millions and millions and millions of molecules around specific compounds.

So um I know specifically like like Harvard is building its own data set, all these different places are building, so they're private, but they're looking for ways to you know license it to pharmaceutical pharmaceutical companies or this, that, and the other thing.

And so the structure isn't that crazy.

I mean, they basically need to put a database onto the web, but like lock down, you know, proper restrictions.

And they have you know good developers in-house, but it would be better if there was like an age.

I'm sure you could have an agency that just took scientific databases and put them on the web as you know, B2B APIs.

Um anyways, lots of science stuff happening.

It's actually a big Django shop um Path AI that's doing that's building it it that's doing pathology with um AI and they're testing it against actual pathologists, so they're building their model, and you know, they're gonna have a database that they sell eventually and use.

So variations of that are yeah, especially around here in Boston.

There's it's not so much web first, but it's very heavily Python is being used science first, which is kind of interesting.

Uh well I just wanted to ask you about like we we've kind of half touched on it, but as you know, experienced Django folks, what do we think on, you know, what what could we offer to um folks who like I've got some science data I want to get on the road?

Like what what are we missing?

Like what's the the the the if we say if we if we took where we are now and we said no uh but now you've we've got you know manage dot pie do some science, what would that do?

That's what you know, what's the the what's the the thing that we could offer the scientific community depending on

There's well and that's that's the the hard part, right?

But when you kind of do more than just the hello world or default kind of path in those tools, I feel like they fall down a little bit when it comes to real permissions.

Uh, you start doing a lot of like putting stuffing code into strange places to basically simulate a good authorization uh system in the tool.

I feel the tools like Django with the middleware and and the ability to have the that control at the views, uh you have much easier way of expressing authorization than you do in some of these like low-code type tools.

Um here's a web page, here's an API for it, here's some authors.

Is that that's what we've got to offer you?

I mean, you you can go in and and you know there's like logged in version or or the anonymous public versions of of the APIs.

I think it needs to go a step further, maybe, and show more granular roles than just the logged in, you know, mix-in type type typical um view is you see.

So um that's there.

I was just thinking Well, that's what's needed.

We'd love to have you on and talk about this problem because it's something I'm surrounded by here in Boston and I don't have any particular insight on what the what those challenges are.

You know, I suspect maybe it's almost administrative more than technical, um, but I don't know.

I mean, they want to they're not just sharing it, it's not government, but they may not be thinking how do we monetize this.

Um or if they are, you know, it's like a custom thing with a lot of times, you know, they're selling it to pharmaceutical companies who use it for their research.

Um, anyways, if a listener wants to come on.

I I was gonna ask you though, Calvin, um, about training employees, because you're doing such cool stuff and you run an agency, you know, people come in at different levels.

In-house, you must have some version of scaling people up.

And what does that look like?

Uh, with being an agency, you almost have to have more senior talent.

Uh, we really don't have a a junior pipeline uh in in place just because of the way the way we work with with companies is not the way like a staffing company would work with companies.

We're not putting people into to seats necessarily or just providing them with talent sitting in a junior role.

People come to us really to solve hard problems.

So our our staff is really focused on heavily senior people.

Now that's not to say that we don't want to make sure that they're always staying up to date and not kind of just sitting back and using you know what always worked uh type things.

We encourage our folks to go to conferences.

So I know we've got a big group, a few of us are going to PyCon.

I know a lot of us are going to go to DjangoCon this year, and that's a place where we learn and connect with the community.

A lot of the learning happens in the hallway still, uh, where you're you know running up against uh some folks and saying, you know, hey, I got this problem.

And and man, it's amazing how many problems are solved, you know, just in a quick chat in the hallway or or even in a Slack uh channel for those things.

And then once a week we do a code review with our team.

And I say code review, it's really a show and tell.

Uh it's really much more I find it more fun than a code review.

If someone had a code review type problem, we would we would talk about code review-y things, but most of the time it's let me show you some cool tool I'm playing with, or some new library I'm using on this project, or some new technique, or some new framework, or even some old thing that I've kind of brought back from the past and reused on this interesting problem in a different way.

And that that helps keep everyone up to date because I I can't tell you how often I see like a wheel reinvented only because someone wasn't aware of a technique we've already used to solve that same problem.

Uh, that actually happened this week.

We're doing a lot of airflow work recently, and so there's some new people who aren't as familiar with Airflow, which if you're not familiar with Airflow, it's pretty dang cool and it's written in Django and it's used for orchestrating typically like data pipelines, although I've seen customers of ours use it in other ways.

So having a wealth of knowledge now that we can call upon to let new people join projects who were not familiar with Airflow, but to speed them up or ramp them up quickly is mostly through just some how we can share knowledge amongst the team.

So we have a daily stand-up you know 15-20 minutes where even though everyone's on possibly different projects from different companies and different different walks of life type thing they all talk about what maybe there is a if there's a blocker or if someone else in the group who may not even be on their project can help them uh it really makes that that transfer of knowledge a lot easier and a lot quicker.

So people aren't stuck and not spending their wheels and wasting time.

So that's a lot of what we do.

Yeah.

I mean I I love learning.

I mean I I'm I'm just an eternal lifelong learner and I just have a huge passion for solving crazy fun problems.

And so the more I can spread that to my people who are on the team the better.

Yeah yeah I just didn't think I wonder if it'd be fun to have someone from there come on if it's written in Django.

Oh that's

where Airflow projects that's where uh Andrew got Andrew is Andrew Godwin Godwin that makes sense yeah

ve got tasks that have dependencies and I need got resource constraints and I want to make sure certain things run and other things don't run and it's that whole orchestration of running either a data pipeline you're moving you know petabytes of data across a pipeline each day or you've got uh some kind of process that you need to ensure runs in a specific flow airflow is your boy.

I've learned a ton.

Carlton do you have any I mean we're close on time.

Anything else spring to mind?

fresh for me and to to have a a company and build around that as a as a as a part of the company culture I think that's fantastic.

So I'm just you know just giving sending loads of hearts your way and well

I mean because my you know maybe where I'm at in my career my favorite Django con talks are you know the uh mental health ones and then the ones that are like we had this really hard problem and here's the tools we threw at it and it's not necessarily canonical but you know like like Django Rest Knox like I remember really diving into that and learning about that a couple years ago but I didn't have examples of it used being in the wild so I was like I don't know like it seems really cool that makes sense but I just didn't know of teams using it.

So now I'm I'm gonna go poke again at it because I was just you know so that's great.

That spurs that in me hearing that

Ooh yeah there you go the me and the the lead developer from the flash team uh will be co-presenting a this case study uh I believe I've proposed it to the DjangoCon uh call for papers if it's uh maybe it's not even opened I don't think it's open it will be it it will be pitched because it's a good it's a good one.

I agree.

Great.

So first

We'll put it in the show notes but it

we'll link to everything great Calvin always a pleasure thank you nice thank you so much for taking the time to come on again we'll just have to slot you in every year you can tell us the

Thanks Willow