Zango: Accelerating Business App Development with an Opinionated Django Meta

Speaker 1: Okay, so hi everyone. Uh it's so nice to be here and uh this is my like first ever Django Con and uh I'm it's my first time uh being a speaker as well. So it's so nice to be here Okay, so let's start. So this talk will be about Zango. It's a framework which is built to accelerate the business app development, right? Okay. Okay, so a little bit about me. My name is Bhunes Sharmat, and currently I'm working as SD1 at Zeldi.

Speaker 1: And I'm maintaining the Django framework full-time. And I'm also the co-chair at social media working group at DSF. So how many of you have seen the hashtag Django Feature Friday posts? You have? Yeah, so those are written by me. And uh uh I was also Mentee in Google Summer of Code 2023. In 2024, I was a mentor and this year this year I am an org admin. And I'm also the founder of Django India community. So if you are active on LinkedIn, you must have seen some meetups post floating around LinkedIn. So yeah. Okay.

Speaker 1: The story. So I believe that uh every software that is built uh it it has a unique story behind it. The problem it solves it comes from the real-world scenarios that people are actually facing, right? And okay Yeah. So at Zeldi, we have been building custom business applications for years. Like we are we have been serving like some of the biggest pharmaceutical companies in the world. And we faced a lot of uh critical problems on a business level and we solved them in a really cool way. And we are going to see how we solved them and what was the conclusion that came out of it.

Speaker 1: Yeah, so first challenge was uh building apps from scratch. So every time uh we Went on building a software, we have to start it uh everything from scratch, uh like running uh installing Django, installing Django and then uh creating like apps and running migrations and all those stuff. So it was kind of uh hectic for us, uh I guess everyone And deployment cost. So every time we used to deploy any software, I mean there are a lot of tricks which can save cost But uh what we used to do, uh we used to spin up our instance, obviously, and uh

Speaker 1: then you know do all the configurations and stuff. And it was kind of costly, uh obviously And uh repetitive code, right? So suppose you are building uh any custom business application, so you Most importantly, are going to need the user management, right? You need a role-based access control, then you need authenti authentication frameworks and all those stuff So if you have that in one app and you are going to need that in another app, so the the most common way is copy paste, but I don't think that is uh Like a really good way. Yeah, so this was uh a really uh

Speaker 1: important problem. Uh similar to this, we have a lot of things which are uh really common in different business applications that we were building. Yeah, we broke things and we fixed them. I think everyone breaks things. Okay. And gradually a superpower was born. We named it Zango. So after uh years of uh breaking and fixing things we came across uh a common uh structure of code that we thought we could convert it into a framework. Right, and we named it Zango. So it's a Django meta framework for building custom business applications.

Speaker 1: It extends the Django's opinion approach, focusing on faster development, maintainability, and security. Okay, so what does a Zango project look like? So this is the structure of a Zango project. So basically it has one root directory. In that there is a folder which is workspaces and then there is another folder with the same name called Django Projects. And the manage. py file uh stays in the root directory. Then uh inside the Zango projects uh folder we have all the important things uh which are uh at a project level uh like settings.

Speaker 1: py urls and uh all those stuff Then in the workspaces we have uh different apps. So these are not the traditional Django apps. Sorry, sorry, Django apps, these are independent Django projects. Now we'll see how it works at the architecture level in the upcoming slides. Yeah, so suppose to do app is a project. It contains some files, settings. json, manifest. json, and to do is a module. So module is a different thing. And migrations are uh like These migrations are specific to to do app and they are independent of the other apps like uh

Speaker 1: portfolio and issued record. So these are independent migration files And inside the to-do modules, we have tables, URLs, views, like just like the traditional Django projects. Yeah. So here are some of the uh key features that uh we are going to talk about uh in Django. Uh first of all, uh user management. So one second Yeah. User management. So uh in the Django framework, uh we have created um A common user management module.

Speaker 1: In that module, uh what we can do is we can create users uh from the project. Like we don't need to like go to the code and do all the stuff manually. We can just create the user from the dashboard and then we can just decide the roles for each user uh which like which user has access to what part of the code or what view it has to go to So this is the complete user management end-to-end and the good thing is it is customizable because it's the traditional Django code. So you can just you know customize, override the things and uh like uh do it as per your requirements. Then we have app lifecycle management.

Speaker 1: So the apps which I showed you uh in this slide like issue tracker portfolio and to do apps so these are like uh the Django projects which Can be created dynamically from the dashboard itself. So that dashboard will be like the Zango dashboard. Okay. And uh yeah. So suppose you want to create a new project, you can Like run the Zango project and go to the dashboard and you can just uh click on the launch new app button and it will create a new app for you. It will apply all the migrations And your code will be uh there in the directory. Right, uh application security. So uh

Speaker 1: we have Uh done a lot of things to improve the security. It contains like most of the data is encrypted, and we have uh IP tracking, IP restrictions as well Uh suppose uh you created a view and you want it to be viewed only uh via particular IP. So you can define it in the code that you just want this uh view to be accessed via this uh particular IP address. So that is very, very easy. Like this, all all of these things can be done in like Just three, four lines of code. Uh package ecosystem. Yeah, so this is kind of really interesting. Package ecosystem is like Modularizing the common

Speaker 1: uh features that are found in every almost every business application. Suppose you are writing emails, like you want to create a functionality to send an email. So what you have done is we have We have uh modularized those email things and we have created a package for it. And that that package is also open source and this is not like a Traditional Python package. It's like a code which is staying on, like which we have hosted, and you can just uh install that in just one click and it will be there in your code as well Observability. Yes. So we have also created a module called Optel.

Speaker 1: It's the full form is open telemetry. So what you can do is you can just configure uh all the uh you know the observability tools like uh sentry and all those stuff and uh you can get all the logs and everything uh on that Right. So it's like a pretty easy way to configure. And it is all there in the Django framework itself. Yeah, unlimited customizability. So it's like a Django project only. So you can customize it as per your needs. Anything you want to change, it's very, very simple.

Speaker 1: Okay, so we are going to talk a bit about architecture and how we are doing the things at Like if I divide it in a more simple way, I can say that it is divided into two layers. One is database layer Like how we are isolating the apps and projects on a database level and then how we are separating it at the application level. Okay, so let's first talk about the database layer. Okay, so uh for isolating the databases we are using a library called Django Tenants. So what does this library do is

Speaker 1: it divides uh like it creates a schema for every app you create in the Zango project. So suppose you are creating a to-do app. So what Django tenants will do? It will create a different schema for the to-do app And all the migrations will be applied inside that schema only. Like it will be completely isolated from the other schemas, and uh the other schemas will not have any idea of How the data is stored in other schemas and how it's working in different apps And each tenant gets a separate schema which ensures the data is strongly isolated

Speaker 1: and it is obviously it will be secure because uh every schema is different. And it's actually very scalable as well. And there is one public schema which holds all the details related to the tenant and domain names. And uh database layer. Okay. Uh now we will have a look at how it actually works. So uh Django identifies the uh schema from its domain name. Uh suppose I created a to-do app And I gave that app a domain called to do.

Speaker 1: zango. com. Now Django knows that the schema which it has to go to is to do. Right, then it automatically switches the schema and send all the requests to that particular schema This keeps the like ORM behavior consistent and it maintains the per tenant boundaries as well Benefits uh like obviously it's lot more beneficial. Uh it Does not need separate databases. So you are saving a lot of cost if you are hosting it somewhere Suppose AWS, so you will save a lot of cost

Speaker 1: because uh all the projects live in a single database and you just have a different schemas for every project And it's compliance friendly and regulated for industries. It enables custom workflows per tenant without major code changes Okay, so let's talk about the application layer now. Uh database is separated. Now how we are uh you know checking uh separating the code at the application level like how the Django knows that uh which app is it has to check Yeah, so we are using the plugin architecture to separate the different projects at the application level.

Speaker 1: And it Django treats each app or we can call it each Zang Django project as a self-contained plugin. And it uses the plugin -based library to dynamically discover and loads the plugin at runtime. We can also say that plugins are like independent Django projects. Yeah, so how it works, it identifies the app name uh from the Django tenants library from the domain. Like it has the domain, it knows which app it has to go Then it will search in the workspaces that where is this app? And as soon as it found that app, it will load it into the memory

Speaker 1: and Then it redirects all the request uh as per the uh app name Yeah, so advantages of this plugin -based design. So it keeps the code really modular. Like You can have multiple Django projects and all the code will be separated. You can create like you can handle the projects of multiple clients in a single project. You don't need to create multiple things, right? And it's a plug-and-play development. You can create new apps and you don't have to uh you know uh touch the other apps to create new apps

Speaker 1: And it has cleaner team workflows. Suppose you have multiple teams and they are working on a same project. So you can just uh assign teams to a different app and they will be working on separately on uh different apps and everything will be separate. But the main Zango project will be single. And Cherry on Top, Django is completely free and open source. It has 280 plus GitHub stars, 20 plus contributors, and 10 plus apps running in production. So we are already running this Dango in production at Zeldi.

Speaker 1: And it has been working really well for us. It has saved a lot of time and cost. And yeah, we are Uh continuously improving. Uh let's see uh where it goes. Yeah, thank you. Thank you so much. Thank you And if you want to like know more about uh framework uh you can have a chat with me or you can drop a mail uh at bhovnesh at the ratezeldi. com. Thank you so much. Thank you. Uh any questions?

Speaker 1: Yeah. Do we have online questions? Oh okay.

Speaker 2: Hello, thank you for this uh very nice presentation. Um you said uh that the uh different uh uh tenants live in separate schemas. So um how do you manage running migrations in in this situation? Do you run them somehow for all of them together or Are they just run separately for each tenant?

Speaker 1: Okay, so uh for migrations we have to run it for all the apps For now, but again, we are experimenting on one thing. We are trying to uh you know isolate uh all the Django projects in the development process as well So that you don't need like if you are deploying a particular application, you don't uh have to you know disturb the other applications. So we are experimenting on that thing as well right now

Speaker 3: Thanks for the talk. How do you manage if let's say you have this to-do app and this other app and there are different projects? Um if you have like this one project needs a package that the other doesn't because it's like in this meta framework. How do you do this?

Speaker 1: So for every project, like for every different app, you can install packages separately. Like if you want to install a package in to do app. So you can do that And if you want to install a package in other app, so you can do that as well in that app. So that are also separated. Packages are also separated. They are not in common thing.

Speaker 4: Hello. Uh you mentioned it was ready for or some of it ready for uh certification of ISO. 2000 one. What what other examples can you tell us about that? Specifically because everything is separated, is it also separated in the database well?

Speaker 1: Sorry.

Speaker 4: Uh is it like the admin stuff for example? Is it also separate in the database as well?

Speaker 1: Admin stuff.

Speaker 4: For the security side more specifically. Like can a super user see everyone's data?

Speaker 1: Yeah So even other apps. Yeah, so you have super users like you have an admin which handles the complete Django project. Right, then you have users for particular apps. So those are different. Now if you want to suppose uh you want to uh Like you want a patient to access your portal. So what you do you create a role in the particular app, not the whole project, just the app You create a patient role and you create a user and that you you will just assign that user the patient role and then that patient will be able to access that particular app. That's how it works.

Speaker 5: Thank you for your presentation. I think my question actually got answered, so I'll come up with a short one. Where does the name Zango come from

Speaker 1: Well, that's an interesting question. Uh hmm

Speaker 5: Yeah you can up come up with an answer now or we can talk it over a after a couple of years.

Speaker 6: Thank you for the presentation. Uh if I understood you correctly, so each app has independent packages, for example. So how do you handle that? Does e the each app has this uh its own virtual environment or

Speaker 1: No, virtual environment is common. Like the packages are not Python packages. These are like the code which is reside which we have hosted on our AWS servers. And you when you just install it, like you don't need a command to install, you can install it from the dashboard, the main dashboard. You just uh click a button install and it will download the uh package from the AWS and it will apply all the migrations. So that's how it works and then you can like uh add uh whatever things you want to on top of that package

Speaker 7: Say that you've you've set up and started using this to manage several projects and then as a company one of your projects really takes off and is scaling, you know, needs to scale much more largely than the others Is getting it back out of this framework if you decide that okay this actually needs to be its own thing now, is it getting it back out gonna be something you've considered or something that's straightforward

Speaker 1: Okay, how I think I think it would be a little difficult, but you can definitely take out the project. But it would require a lot of efforts because you will have to uh you know migrate all the tables from the schema to the to a new database, then there will be a lot of code changes that you will require So you can do it, but it will be a little, you know, time consuming. Yeah. Thank you for the presentation.

Speaker 8: It was very interesting. I kind of have the opposite question. Is it possible to migrate an existing vanilla Django project into Django? And if so, what's what what are the kind of recommended steps involved? How much effort is it?

Speaker 1: Existing Django projects I think it is possible, but it will require obviously a lot of efforts. You have to migrate the code. and like you have to create an app for your project then you have to manually you know uh enter all the data uh from your existing project into the schemas but uh I think it's kind of possible but quite difficult Yeah, yeah. But I can help if you want, you can just send me a mail.

Speaker 8: Thank you for the talk. You mentioned compliance in the in the slides there. Do you have a mechanism for developing cross-cutting applications for compliance, for instance? to audit all your apps for GDP or or that kind of um that kind of structure of applications, that kind of workflow for for compliance and auditing.

Speaker 1: Uh I I didn't get your question. Can you see that again?

Speaker 8: So so for compliance. Do you have um tooling for auditing across all the uh all the apps for a compliance point such as privacy or consent

Speaker 1: Okay, so uh for compliance what you you can do is uh like we have uh an IP level restrictions that is a different, but for CSRF uh you can Configure things in the project for each app level. Like if you are like willing to you know pass only a number of users, so you can configure that in the project itself So that's how it uh kind of works.

Speaker 8: The project is is one app, such is it to do or is it the the running Django system?

Speaker 1: So uh you can like it's for per apps Per apps different. Yeah.

Speaker 8: Okay, thank you.

Speaker 1: Thanks. Great. Thank you, Babanaj. Thank you.