Separate (repository) code for website from the API code

[angoca]

The API is the OSM core, and it progresses very slowly. The same 0.6 version has been for almost 10 years with a small extension (notes-bugs) included after the initial 0.6 definition. But the rest has been unmodified.

The API implementation is used for OSM clients, and it is the only way to access the OSM data on the database. Therefore, it has to be extensively tested and very robust, and it is the most preciously cared thing in the osm world.

On the other side, the osm website is like any other OSM client that uses the API to render the page. The problem is that this code is in the same code repository as the API. I think this is one of the reasons the website is stuck in a 2000s look-and-feel. And website maintainers do not want to break things or take risks with new developments.

If we want a new osm website, the code should use the current API implementation to convince people of the benefits of the new design, language, design, evolution, time-to-market, etc. But, changing the API implementation is much more complex, and many people will criticize the initiative because if an error is critical, it could block the whole osm ecosystem.

Also, API 0.7 is still being defined. And osm-ng could be the opportunity to be the official implementation, but this is only possible if the website is separated from API implementation. There could be people interested in testing the osm website and others the API, and having them separated is better.

We could think a adoption roadmap like this:

• (current) osm website (ruby) -> API 0.6 (ruby).
• osm-ng (python) -> API 0.6 (Ruby).
• osm-ng (python) -> API 0.6 (python).
• osm-ng (python) -> API 0.6+ or 0.7 (python).

By 0.6+, I mean the features you could include that are not really part of the initial definition (retrieve all traces, all notes for a user, etc.), but it does not affect the current version.

Also, open historial map could eventually be migrated to osm-ng code, but separating the API and the code will also benefit them.

I already talked about this in communities and this idea received a lot of likes: https://community.openstreetmap.org/t/the-next-generation-of-openstreetmap-in-python/105621/96