We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Migration strategies: Or how to get rid of a deprecated framework

00:00

Formale Metadaten

Titel
Migration strategies: Or how to get rid of a deprecated framework
Serientitel
Anzahl der Teile
266
Autor
Lizenz
CC-Namensnennung 3.0 Deutschland:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Deprecation of a used framework is a common risk for software projects. Migrations are very time-consuming and costly, without showcasing any new functional features. This can make them an unpopular task, that tends to be postponed until there is no other choice, be it for a customer or the community of an open source project. During the last decade for instance, AngularJS has been one of the most popular web frameworks around. This was not any different in FOSS4G projects, where it had been adopted in geoportals and other frontend components. With the end of the decade, active development of AngularJS came to an end and since summer 2021 no more security updates are provided. This has become a major challenge for many web ecosystems - including FOSS4G ones - where AngularJS is still very present, but will have to be replaced in the long run. This talk will present various open source projects and how they differently approach this challenge. It will reflect on lessons learned so far and aspires to provide inspiration for other projects in a similar situation. Geomapfish is a WebGIS framework that allows to build geoportals. It is a community driven project. Its frontend is based on the ngeo javascript library, which has been built on top of AngularJS and OpenLayers. Due to its wide functionality, the project’s goal is to prevent a one shot migration. It has been decided for a continuous migration based on (Lit Element) web components, that allow to integrate migrated functionalities step by step. Geoportal.lu is the national geoportal of Luxembourg. It is based on the Geomapfish framework, but has a very customized frontend. The requirement here is similar. Instead of migrating all at once, the different parts should be continuously integrated. After following the Geomapfish migration strategy based on web components at first, the project is finally migrated to another javascript framework (vue), without giving up on the continuous migration. Geonetwork is a well-known FOSS4G catalog application. On top of its powerful backend, sits a frontend that is also based on AngularJS. Once again, its functionality is so vast, that a complete rewrite would be enormous. Thus came up the idea of geonetwork-ui: A new project that could live alongside Geonetwork without the goal to become isofunctional, but to complement it. A project providing libraries specialized in proposing user interfaces by leveraging Geonetwork’s backend capabilities.
SoftwareProjektive EbeneFlächeninhaltMigration <Informatik>Strategisches SpielPunktFramework <Informatik>Open SourceFront-End <Software>SoftwareentwicklerDatenverwaltungInformationSoftwareExpertensystemInhalt <Mathematik>Physikalisches SystemFlächeninhaltAutomatische HandlungsplanungMigration <Informatik>Framework <Informatik>Open SourceUnternehmensarchitekturXMLComputeranimation
SoftwareWeb SiteMigration <Informatik>Framework <Informatik>
Produkt <Mathematik>InternetworkingComputersicherheitPunktClientSoftwareentwicklerMigration <Informatik>Strategisches SpielGoogolXMLComputeranimation
CodeProdukt <Mathematik>Konfiguration <Informatik>Projektive EbeneMigration <Informatik>Kontextbezogenes SystemSoftwareentwicklerTermersetzungssystemProdukt <Mathematik>Migration <Informatik>Strategisches SpielComputeranimation
FunktionalLokales MinimumMigration <Informatik>Strategisches SpielURL
CodePhasenumwandlungProgrammierumgebungAggregatzustandDebuggingFunktionalMereologieSpeicherabzugVerzweigendes ProgrammMigration <Informatik>Zusammenhängender GraphHeegaard-ZerlegungArithmetische FolgeKartesische KoordinatenWeb SiteEvoluteMultiplikationsoperatorBenutzerbeteiligungDokumentenserverSoftwareentwicklerApp <Programm>MathematikPhasenumwandlungProgrammierumgebungFunktionalInverser LimesSpeicherabzugMigration <Informatik>Zusammenhängender GraphFront-End <Software>EvoluteKontextbezogenes SystemCross-site scriptingSoftwareentwicklerXMLComputeranimation
InternetworkingPhasenumwandlungMigration <Informatik>Computeranimation
PhasenumwandlungAggregatzustandNavigierenMigration <Informatik>InformationsspeicherungKartesische KoordinatenWeg <Topologie>MultiplikationsoperatorApp <Programm>SynchronisierungPhasenumwandlungStellenringMigration <Informatik>InformationsspeicherungURLComputeranimation
CodeDämpfungDatenverwaltungTopologieProgrammbibliothekProdukt <Mathematik>MAPIntegralPhasenumwandlungSoftwaretestProgrammierumgebungKonfiguration <Informatik>AggregatzustandMereologieProjektive EbeneSpeicherabzugE-MailMigration <Informatik>Zusammenhängender GraphParallele SchnittstellePunktQuaderKartesische KoordinatenAbschattungFramework <Informatik>Element <Gruppentheorie>MultiplikationsoperatorRechter WinkelBenutzerbeteiligungSoftwareentwicklerCodeProgrammbibliothekGebäude <Mathematik>Produkt <Mathematik>IntegralPhasenumwandlungSoftwaretestProgrammierumgebungHybridrechnerSpeicherabzugGüte der AnpassungMigration <Informatik>Strategisches SpielZusammenhängender GraphStrömungsrichtungUmwandlungsenthalpieFramework <Informatik>Element <Gruppentheorie>Computeranimation
MaßerweiterungOnline-KatalogKartesische KoordinatenInklusion <Mathematik>Front-End <Software>Kontextbezogenes SystemSoftwareProdukt <Mathematik>Automatische IndexierungInverser LimesKomplex <Algebra>Leistung <Physik>Online-KatalogMigration <Informatik>Strategisches SpielSystemverwaltungKartesische KoordinatenAppletArithmetischer AusdruckFront-End <Software>Kontextbezogenes SystemTesselationComputeranimation
Pay-TVComputeranimation
CodeComputerarchitekturProgrammbibliothekMereologieCASE <Informatik>Kartesische KoordinatenDifferenteWrapper <Programmierung>DokumentenserverSoftwareentwicklerCodeComputerarchitekturProgrammbibliothekMigration <Informatik>Strategisches SpielApp <Programm>Computeranimation
CodeSoftwareExpertensystemMAPPhasenumwandlungSoftwaretestProgrammierumgebungTaskGrenzschichtablösungBitFunktionalKomplex <Algebra>Projektive EbeneResultanteTexteditorMigration <Informatik>Zusammenhängender GraphVollständigkeitFeuchteleitungStrömungsrichtungSchnittmengeOffene MengeKartesische KoordinatenRichtungMetadatenMailing-ListeStabilitätstheorie <Logik>DatenmissbrauchViewerDifferenteWrapper <Programmierung>SystemplattformMultiplikationsoperatorRechter WinkelBenutzerbeteiligungInterface <Schaltung>SoftwareentwicklerCodeSoftwareProdukt <Mathematik>ProgrammierumgebungGrenzschichtablösungTotal <Mathematik>AggregatzustandMaßerweiterungOnline-KatalogTexteditorMigration <Informatik>CASE <Informatik>Strategisches SpielZusammenhängender GraphModul <Datentyp>MetadatenFokalpunktStabilitätstheorie <Logik>ViewerSystemplattformInterface <Schaltung>App <Programm>Computeranimation
ExpertensystemMigration <Informatik>Strategisches SpielOpen SourceComputeranimation
Transkript: Englisch(automatisch erzeugt)
Thanks a lot for the welcome. Today I will talk about migration strategies or how to get rid of a deprecated framework. I work for Camp2Camp. We are based in Germany, France and Switzerland.
We are specialized in open source software development and help our customers implement sustainable solutions. We have three active areas we are working in, which is ERP software development based on UDO, IT infrastructure management, as well as GIS, which is why I am here today.
I am a front-end developer at Camp2Camp in the geospatial department, mainly working on the two projects, GeoNetwork UI and the GeoPortal of Luxembourg, which will both be the topic of today's talk as well.
So today I want to talk about a problem that many of you might be already familiar with, the deprecation of a framework within your website or within your software. I want to give a common example for this, talk about reasons why to migrate, point out some approaches to do so, and most of it talk about the lessons we have learned
within the two projects of the GeoPortal of Luxembourg as well as GeoNetwork UI. So who here knows a popular website or software where you know it uses a deprecated framework?
Okay, so it might be, I hope, a topic of interest, I guess. Today I want to talk about AngularJS. AngularJS was very widely used in the last decade. However, in 2022 it ran out of live support, being still very present in the internet on many websites,
which was not different for a couple of Phospho-G products. But why should we migrate? Why should we just not keep on going with the legacy we have? I think one central reason is the maintainability, which will become very hard in the future.
At the same time, we as a developer become much less efficient. So this causes us many headaches, these two points. Last but not least, there is also the problem of security issues,
which might arise a certain fear at other stakeholders like the client. So what possibilities do we have to get rid of the deprecated code we have in our software?
I think there are three quite obvious options. The first one, to rewrite all at once. The second one, to do things step by step. And the third one is a little different approach to develop a new product.
Today I don't want to talk about the first option, because in the two projects I am working on it was not really an option, because it is just too extensive to choose this way. So today I want to talk about progressive migration on the example of the GeoPortal of Luxembourg,
as well as the development of a new product on GeoNetwork UI example. So let's have a look first at the progressive migration. The context is the GeoPortal of Luxembourg. It is a very extensive GeoPortal. There are a lot of topics, a lot of layers.
There is 3D, there is street view, there is routing, so a lot of functionality to migrate in the end. It is based on geomapfish, but it is highly customized on the front end. And it has a complex and grown darker composition which has become more complicated due to its history.
So in recent history it was not really fun to work on it. The requirements from the customer were, on the one hand, ISO functionality to have the same things afterwards than before,
but at the same time to consider constant evolution in the master branch and not do a migration on the site during two or three years and then switch to the new development after this. So this is why we chose the progressive migration here. Now I want to talk a little about the last year, split into three phases more or less.
The first phase was that we migrated parts of the existing components within web components without really touching a lot the existing app state of the AngularJS application, without touching too much the CSS part.
Lessons we have learned from this was that it was possible to go like this, but in the end limited and we felt it more and more essential to have a new state and we were not really satisfying with the things we had to do in the code to make things work.
And in the end we hadn't really gotten rid of our existing development environment and didn't really feel efficient. So we sat back and reflected on how we could get more efficient on the developing as a developer.
And we came up in what I call the second phase, what I call the web component machinery, which is nothing else than a separate repository to create the new components like a new application with the idea to later integrate them piece by piece into the legacy application.
At the same time we started to develop a new core based on RxJS and we integrated Tailwind CSS into this new application. Lessons learned here, things started to become fun again, we started to feel more efficient again, we had a feeling that LIT and RxJS worked well together even though they are not that often used together
when you look at examples in the internet and so on, and it's a little verbose maybe. This brought us to the third phase where we did more or less a migration within the migration.
We switched from LIT and RxJS to Vue and Pinja. This was on the one hand due to the fact that the customer had more know-how in-house on Vue than on LIT, and on the other hand also because we realized with this new application from scratch, we were really free to choose what we wanted as technologies and we went on this track.
At the same time we developed a new state-persistor that takes care of synchronizing the new app state with the URL and the local storage of the navigator. And lessons learned here was that it was just becoming more and more fun to work on the project.
The migration from LIT to Vue was pretty quick. We really appreciate the out-of-the-box reactivity within Vue with Pinja together. There is a good testing given by the test.
However, we also noticed that the code we are writing now might be a little more specific to the framework than the code we had with LIT before. After these three phases, we are now in what I call the integration phase. This is where we built the components that we have within the new application from scratch
as web components within a library together with a new core. Then we set up a rather rustic integration environment to be able to turn some screws in the legacy code and on the new code at the same time.
And the last step is finally to make these new components work in the legacy code. Lessons learned here, I think we can say that the new core really facilitates the integration now. It shows us that the new components work well together.
And at the same time, it works in parallel to the existing what was called the permalink manager which handles the URL in the legacy code. Then go with the new, glue the legacy. I said this because at various points we had to make the decision, do we
already take everything new we developed like the part of the core or the new map? Or should we try to plug in the new components we have developed, for example to the old map? But in the end we decided to go for the new parts. This on the one hand prevents us to throw away the glue we would have had to write for the old parts.
And on the other hand it was not that complicated in the end, like for the map it was just sufficient to pass the open layers map to the old tools and they work, most of them, almost like this.
Regarding technical limitations, within Vue you can create custom elements or web components. But there is no out of the box option to ignore the shadow DOM. We had to do a little work around for this.
Ignoring the shadow DOM is important when you use a lot of web components in the same application. But you want to use the global CSS of the application.
And in the part where we now integrate the new components in the legacy application we still have to do some tweaks on CSS, sometimes on the new developments and sometimes on the old. Because there are just influences from parts that we don't have in the new environment.
So this is the current state of our migration, what you see in green here on the left side. The side panel which includes the layer manager and the layer tree as well as the map with some tools on the upper left side. It's all new code based on the new core and with the new components.
And what is red is the legacy code like the header and the footer with most of the tools of the GeoPortal. And some map tools on the bottom right. But most of them work together with the new code.
Many of them are functional, there are of course a lot of things that don't work yet. We still have a lot of work to do but they work together. So much to the progressive migration, now I want to come to a totally different idea which is to develop a new product.
This I want to talk about on the GeoNetwork UI project. The idea of GeoNetwork UI came up in the context of GeoNetwork which might be familiar to a lot of you. A very extensive catalog application with a very powerful backend.
Also a complex frontend which also has AngularJS included. Here it was clear that the rewrite would be too extensive also. So the idea came up to develop a new UI complementing the existing one.
And maybe replace it one day. The architecture of GeoNetwork UI is a mono wrapper architecture. So we have libraries split up into UI and feature parts that allow a use case driven development of different applications based on these libraries.
So we have a lot of applications within the same repository. This is a rather code oriented customization. The technological stack of GeoNetwork UI is NX for the mono wrapper.
Angular with RXJS, Teruen CSS, OpenLayers, Storybook. I forgot the testing is Jest and right now we are working on doing end to end tests with Cypress as well. Right now we have different applications in GeoNetwork UI. The first one that came out of GeoNetwork UI is the Data Feeder which is a very simple interface.
It allows data publication. It's like a wizard that goes through different steps. Allowing the user to upload a data set that is then published in GeoServer and the metadata is provided by GeoServer and the metadata is published in GeoNetwork.
The second application is the Data Hub. It's a search interface with the goal to stay rather simple as well, which you see on the right side here. With a search bar there is a timeline, a little bit reminding timelines of social networks.
Then the third application is still in the conception phase. It's a data platform that will be more extensive than the current Data Hub. There is a simple map viewer which exists, but which is not really used yet, but it will allow you to visualize cartographic data.
Then there is the editor which is about to take off in development. I think there is a talk tomorrow afternoon about it by my colleague Olivia and Flor.
Last, but not least, there are the web components that allow to integrate any of this functionality based on the same code within other applications. Here in the middle, it's very small, but you see the result list of a search within MViewer which is a completely different web.js.
On the right side, it's the search bar integrated in Geocrystra, which is a complete IDE solution. Lessons learned in GeoNetwork UI, I think we can now identify certain strengths of the project. I think it's a well-tested software.
The reactivity within GeoNetwork UI works really well. There is a clear separation of concerns between the UI and the feature libraries, which allows for a good reusability in the different applications, but also in the web components. All this together has given us a certain flexibility, in particular, to focus, for example, in this project, more on open data and the user.
Challenges, I would say, one is that the architectural demands might be a certain barrier for people to get started.
The same code in different applications is also a challenge, in my opinion, because when you develop on one, you have to take care that you don't break the other one. Stability has its price, so writing tests simply takes time.
Regarding the user interface, I think we made the experience that it's really worth to hire an expert. The data was completely accompanied by UX designer, and we are really happy with the result of this, because it's just things, as developers, we wouldn't come up with the ideas.
We just think, okay, we put a button there, but in the end it's maybe more complex than that. Last but not least, I think creating a community is also not an easy task. It has taken quite some time that the topic has generated interest, it takes a lot of work.
I think Flo and Olivia are very invested in this topic to get a certain interest for the project. Now it's finally really taking off, we have the feeling there are more and more demands coming for it.
Just to conclude quickly on the two approaches regarding our projects, this is not something that should always be like this. I think progressive migration is feasible, but you should be aware that in the end it will be more work, I think, so there is a certain risk of a higher cost for it.
If you have a complex development environment, it's really worth to get rid of it, or as much as you can, and set up something new to be more efficient. Regarding the development of a new product, I think it bears many opportunities, like in Geonetwork UI we went into the open data direction.
It also allows rather flexible financing, because you can start with something small, with a small application, and keep on going from there. However, I think there is a certain risk of non-acceptance, or that it takes time for a new project to be accepted or to be adapted by others.
Thanks a lot for your attention, I hope it was somehow interesting. I'm here for questions.