Okay, so now we have both students.
So now we have both speakers here.
We can start the talk, the next talk.
The talk is going to be about a slow migration from Django
templates to Vue and GraphQL.
So Jonathan, Jonathan, Jonathan and Dominic Georg,
both Germans, they're going to talk about a system,
Alexis, which is a school information system,
which was apparently written in using Python Django
templates and they now ported it to Vue and GraphQL.
So give them a warm welcome and thank you very much.
Thank you.
Can we get the microphone for the other speakers?
Thank you very much.
These were speakers, the last one is the prize speaker.
Hello, first them and Python Deafroom.
We are the Alexis project.
That's the all Libra school information system and we want
to tell you how we transitioned from a Django app,
with a templated web front end to an interactive web front
end as the needs arose for one of those in our project
and how we did it incrementally.
I'm Michael Bauer and I'm a developer at Alexis
and I work mostly on the new frontend
and the new features we are enabled with that.
So with that let's introduce the rest of the team.
More of the team.
Yeah, my name is Nick.
I'm more or less one of the founders
of the project.
I started tinkering on the school management system.
When I was still at school,
I don't think I can remember when that was.
Today, yeah.
I don't know what my role is on the project right now,
but someone might know.
So.
I have a microphone on my own,
so I don't need to microphone.
That's decent.
So I'm Jonathan.
I'm the lead developer with the Alexis project
and I'm coordinating the dev process
and everything connected to this.
Okay, so let's get started with the talk.
What's about Alexis?
What is Alexis?
This is a free and open source school information system
and it has a free software license,
a European public license.
So it's thought of as an alternative for schools
that they have a free option to manage themselves
and organize themselves.
It's a modular system,
so any school can just take what they need
and don't have to use the whole system.
And it's also done in such a way
that it complements existing solutions.
So we're only focused on the parts
that aren't there yet in a free software way.
It's developed by software developers,
but also students and teachers.
So we're working together with pilot schools
and already have it in use there.
The main Alexis features,
of course they're divided into these components,
but this sort of the main components
is the base data management.
It's the basis of the schools,
like we have classes and pupils and teachers and so on.
Then we have a timetable system.
It's like a calendar system just for schools.
So you can create timetables
and you can serve them to the students.
So each student has its own personalized timetable.
Also the teachers have them.
And there's a digital class register
to take all the notes and information
for classes seating plans.
So you can design and show seating plans
for the classrooms.
And it also integrates with other services.
We have a matrix integration,
a O of integration,
LDAP and CSV,
V import, export.
And also we just have a calendar system inside Alexis
that's producing standard Eichel calendar feed.
So there's lots of choice
in which ant devices are used to hook up to Alexis.
And it's a quite universal system.
There's also provisions for student ID cards
and inventory management in schools.
With that I would like to give over to Nick.
He is presenting you the telecom technology stack.
Yeah, thank you.
Okay, yeah.
So thanks for making this nice graphic
to help me know how this works.
Jonathan, yeah, well, our legacy code base
was a traditional Django project
and with all the modules as Django applications.
When we started basically everyone was doing
server side rendering with all the nice templating features
of the Django framework.
To introduce you to the rest of the tech stack
on top of Django,
we use PostgreSQL quite heavily.
There's a salary task broker and Redis
for caching and for synchronizing several nodes
when running Alexis in a multi-node setup.
Yeah, and for the front end parts,
we, as I already said, we used the Django templating engine
and some not very well integrated front end utilities
like the materialized CSS framework
which at the time somewhat allowed for making
yeah, modern interfaces following the material design
standards, but it started to bit rot quite quickly here
and Jonathan will give you some idea about that later.
Okay, so that was the legacy tech stack
and where is my name somewhere else here?
Do I have to say anything more?
Yeah, you can see a page in the legacy tech stack.
So you have to.
Yes, yes, nice.
Little overview of how it looked in the past
and yeah, I have to say then the problems started.
We occurred some very ugly bugs like
I think users described to us there
if there was like a select menu,
depressed an item in the select menu
and but actually was selected the item above
or below this item.
So that was not so good
because many users were using iPads.
And in addition to strange bugs like this,
there was also a problem with maintenance,
with materialized as you can see by this issues here.
So yeah, there was a big discussion
whether materialized will be developed any further.
And in addition to these problems,
there was also a request for new features.
As we spoke about time table planning or sitting plans,
we needed some way to do this highly dynamic features
in a better way because the control of time table planning
is a very complicated thing.
Also these customizable calendar views
and auto saving views where you don't need
to press the save button.
It all wasn't possible anymore with our old front end.
So we had an idea Nick will present to you.
Okay, so yeah, probably many of you know that
it's now the new thing to separate front end
and back end entirely and make a nice shiny mobile app
or whatever.
And yeah, Jonathan more seriously already gave a few hints
about why we would want to do that.
I think there's one other challenge that we faced.
Did you mention offline capabilities and caching?
No, because you know, Alexis is used in schools
and things might be different in other parts of the world
but in Germany only two things are certain
in the school system.
Namely that your mobile network will not work at school
and that's the wifi won't work at school.
These two things are certain
and therefore teachers always complain
that they could not use the server side rendered views
when they had no connection to the server.
So I think this was more or less one of the biggest
challenges we tried to solve.
So separating the front end actually makes sense here.
Okay, so what we wanted to do,
we wanted to replace materialize
because materialize was stuck somewhere in 2015
and wasn't really developed, it was abandoned.
We had a few patches on top of that,
I think somewhere even upstream
but it didn't get better and it lacked the dynamics
that we needed for a really new shiny intuitive interface.
Yeah, so what are reactive?
All right, yeah.
Yeah, reactive front end libraries
and yeah, to make the interface,
yeah, to not have it reload on every single interaction
and yeah, and also a very important idea.
Alexis provides a very good foundation
for handling organizational data at schools
but yeah, we want to tailor to the needs
of different schools, of different types of schools.
The ideas they have, one of our most important claims
that we share with schools when we expand
the benefits of free software is that we can make
the software work like the school works
and we can transform the software
instead of transforming the school.
So on top of the foundations for organizational data
management, the idea was now that if we could
replace the front end for some parts,
like make a different class register
for an elementary school because they have
very different needs, we do not have to replace
the data structures, the models and the APIs
but we can make a front end that is more tailored
to the needs.
Yeah.
Okay.
Yeah.
This is not my part anymore.
No.
So we then decided on how we want to do our new
technonesis tech so we, as we said,
we just took the backend set, okay, that's our backend
and then we decided we want to do an interactive front end
with UJS and the front end library beautify
and some other UJS libraries and we want those both parts
at communicate and yeah, we are a graph API.
And so this was our plan and there were some challenges
with this plan.
Oh, just a graph API.
So, yeah, let's see again.
Thanks for helping me keep up with my tradition.
I always give one very good talk before BiaNite
and one very bad talk after BiaNite.
Okay.
So, yeah.
So as we already said, the platform is supposed
to be very modular.
It consists of, don't know, do we have some figure
how many jungle apps we had at that point
when we started the migration?
Like around 15 I think.
Like 50 apps that could be loaded dynamically
into the jungle project.
We actually had quite a bit of magic in there
to discover the modules of the jungle apps dynamically.
So the administrators who deploy servers for schools
could simply install the Python packages needed
for the system they want to put together
and then everything falls into place
in kind of some black magic way.
And now this did not turn out so well
for separating the front end
because normally when we separate the front end,
we want to have one JavaScript or whatever application
that is delivered to the clients,
nicely bundled with whatever JavaScript bundler
is the current type.
And then it is one JavaScript application.
We could not do this because we do not know
which parts of the system are used and in which versions.
This might be very flexible for every school.
So we need to bundle the JavaScript front end application
on the machine where Lexus is deployed.
Yeah?
10 minutes left.
Oh, yeah, thank you.
Okay, and you need these 10 minutes?
Probably.
Probably, okay.
Yeah.
So the right way would be you have one front end application,
one backend application.
They are more or less separated in development.
They could be developed independently,
but we cannot do this because, yeah, what's?
Okay.
I have to switch the display so you can see this.
Okay, this is where we actually generate parts
of the bundling configuration for VIT
because when we build the bundle,
we know which applications are there.
We have the JavaScript front end code bundled
with the Python packages in the same repository
and at deployment time,
we need to extract the JavaScript front end code
and let it all fall in place like we did
with the Python applications,
which was sort of a major challenge.
So, yeah.
Yeah, the microphone is developing, that's good.
And then we faced another challenge.
We said, okay, we weren't able to migrate
all these apps at once.
So we had to find a way to integrate the old front end
with the new front end.
And what you can see here on the Bima
is like how the new front end does look like.
So there is no real optical difference
with the old front end, but it's the new front end
and we have had to find a way to put those old pages
somewhere in this new front end.
And if I just say the word iframe,
I probably get some scary faces here.
So, yeah, we made it and just put an iframe somewhere in there
and then we built some glue, which takes the URL,
which is actually called and then called
the different URL with a prefix
where the old site lives and integrates with in the front end.
And that looks like this.
So what you see within this container is an old page.
And what you see around this container
is the new front end.
So if you can see which URL is dated here,
it has the prefix Django.
So it's within the iframe and if I click the button,
the iframe will navigate to this Django URL.
I will do this and you can see that magically
the actual URL from our new front end is also updated.
So it's a kind of, yeah, ugly magic.
And this also goes one way further.
So this is an old view within the new front end
and now I click one of these links
and it's navigating to a new view in our new front end.
So this needed a large bunch of glue
to put all this together,
but now it's working with some exceptions.
Nick will come too.
Some exceptions, yeah.
So like this iframe with a server-side URL page
in the new view.js front end,
they are always communicating using
some sort of JavaScript message passing.
I did not yet understand.
Okay, so what are we doing here?
This is the dynamically generated bundler config
or something.
Yes, it is.
I don't think we have the time to go into detail about this.
And oh, whoa, there's a video.
Michael is fine.
Yeah, I had to Michael.
Yeah.
Here you can see the new front end in action
and why we did this transition
because we wanted to have more interactivity
and here you see how you can design a timetable now
with the new view front end.
Someone's inserting lessons into the timetable
and it's highly dynamic and all just works.
So we just want to tell you about new problems
and I think this last part will also be done by Nick.
So, oh, yes, this problem.
Okay, we already talked about iframes
and how they communicate
or sometimes we all know communication fails
and that you have Alexis and Alexis and Alexis.
And I think this visualizes quite well
what sort of trouble this slow migration caused for us
but we did not see this too often in the recent time, right?
Mm, not too often.
I don't think so.
Prove me wrong, okay, thank you.
We called it mini Alexis.
Now we call it Alexis Matroszka situation.
If you know what this means.
So, yeah, it did just a good.
It pops up every month again.
Every other month here.
All right, so now we have ugly front end bugs
for the integration and all of this will be sorted out
once we get all applications
and all views migrated to the new front end.
The JavaScript ecosystem shares some of the same problems
we had with materialized situation
because you know there's beautify three
and it's pretty neat.
We needed to migrate to view three.
View two has been deprecated for two years or something.
Pardon?
This year, this year, this is not too far in the past.
Okay, but it's deprecated.
And beautify three is cool
and we would want to migrate to it,
but it's still missing the calendar component,
the calendar date picker component, right?
And we are basically the only thing Alexis ever does
is handle dates.
So this is somewhat of short, some sort of showstopper here.
We hope that this will be sorted out.
I think the release date for the date picker
is moved every quarter or year
to the next quarter of the year of some,
but we will see how this works out.
Yeah, of course there's an easy solution to the problem
and an obvious solution here
because we could just do this, right?
No tomatoes for me?
To get some new problems.
And so we are always shifting from one set of problems
to the next set of problems.
Okay, thanks for bearing with us.
I think I'm slowly getting awake.
You can find us in the hallway track
if you want to get more information and less chaos maybe.
All right, do you have any last words, Jonathan?
I think we have like three minutes for questions
if I'm right.
So maybe if someone wants to ask a question,
otherwise we also will be available via email.
So yeah.
Any question?
Thank you.
I have a question.
Why did you think about GraphQL instead of something
like Django's framework and exposing APIs and using that
instead of adding a new layer in between the front end
and the end?
Yeah, well, I think we chose GraphQL.
Because I think the obvious alternative
would be US or something like this.
So, but we chose GraphQL because we were able to select
what we deliver to the front end.
We have like very complex models.
And we say that, okay, we just take this set of information
for this page.
And from the other page, we need a much larger set.
But of course, this GraphQL integration
is causing us problems with an un-maintained
or slightly maintained Django library and things like that.
So as we said, another set of problems.
Yeah.
I think for the presentation, it's not right.
Help.
Yeah, back to you.
I can just be loud.
Yeah, just be loud.
Okay, I'll just be loud.
So thanks for the presentation.
I know your pain.
I've had to do that job a lot.
So my question is, why didn't you,
what I've been having success now
is the back end for the front end, right?
Because all these fancy new reactive libraries
now have these meta frameworks, which is an awful word.
But they kind of work.
And so like, have you considered doing that?
So the way I like to do it is you have the new back end
for front end.
And when they don't know what to do, okay,
PHP help, then they just get the page back.
So why did, I don't know if you looked at it like,
why did you try to keep a single page application?
You want to answer this?
I can transfer from there.
Yes, I would, what was the question about this?
Have you taken a look at these back end for front end?
Do you like them, do you not like them?
Is that?
What exactly do you mean?
So like next JS, for example, that's the reactive.
Yeah, okay.
It has one like that.
Yes, it's a kind of, we never have been using this.
So it's like two years after this migration started,
we just thought, oh, we could also use, have used this.
So, but now the work is done.
We have to go on with this.
Our developer capacities are very limited.
So yes, it's a kind of knowledge we didn't have.
Okay, so thank you very much for the very nice talk.
Interesting system.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.