[OSM-dev] Andy Allan joining web site maintainers

[Andy Allan]

On 10 July 2017 at 13:25, Matthijs Melissen <info at matthijsmelissen.nl> wrote:
> On 10 July 2017 at 11:14, Andy Allan <gravitystorm at gmail.com> wrote:
>> Thanks Tom. My intentions for the next few months are to continue to
>> do whatever I can to encourage new contributors. I've done a lot of
>> refactoring recently which will help whoever tries to make code
>> changes, but there's other things I think I can do too.
>
> Currently, the openstreetmap-website is both responsible for the
> openstreetmap.org web application, and for the API.
>
> How hard would it be to separate these two functions, perhaps even
> into two projects?

It's not hard, but I personally think it's not worthwhile. But as I
said in my response to Frederik, opinions vary and other core OSM
developers will disagree with me. I'll give some counterpoints to your
statements:

> Would there be any advantages in doing so? Intuitively both functions
> seem to be separate projects.

I don't see them as being different at all. If you want to "view a
way" or "view a diary entry", then there's a choice of output formats
- XML, html or json (in the future, perhaps). So one app can easily
have three different views, rather than having an entirely different
application just to change the display format.

Our API currently covers only a small part of the function of the
website. In future we could allow you to post diary entries via the
API, or add new friends, or get a list of comments on your diary
entries. Again, it would seem strange to me to have a rails app that
lets you view your list of friends as a webpage, but then need a
different app running to see that same list in json or XML.

> I could imagine having two smaller
> applications might make maintenance easier.

Or it would spread the developers thinner, and lead to a lot of
duplicated effort.

> It would also mean we
> could, for example phase Ruby out for the app but not for the api or
> vice versa.

I'd rather phase out low-level code like C++! Even better, we can also
phase out home-grown ruby code and use third-party libraries much more
often. There's very little about what we do that needs anything
special, beyond the map call. Most of OpenStreetMap is completely
routine things like signing up, resetting passwords, CRUD on simple
objects and RESTful API calls. And we don't even do much of that -
we're not dealing with millions of requests per second or anything
like that. So the less code we have of our own to maintain, the
better, and the higher-level language it can be written in the better,
as far as I'm concerned.

> Lastly, making the website make only use of well-defined
> api endpoints instead of interface with the database directly might
> also makes things clearer.

I've said similar things in the past, but I realise different
developers have said similar meaning slightly different things. For
me, that means that we should unify the internals of the rails port
(e.g. not having a separate "BrowseController" for viewing a way, and
a different "WayController" for viewing a way in XML). For other
developers it means changing the rails port to make API calls (e.g.
BrowseController would fire off HTTP calls). For other other
developers it means turning the browse html pages into a javascript
SPA that fire off http calls to the API for the data it needs. I'm not
in favour of 2 and 3.

> Have there been any thoughts in this direction?

There's been many thoughts over the years, but nowhere near enough
implementation!

Thanks,
Andy