Maintenance of rest-layer going forward.

[smyrman]

At Clarify, we use rest-layer internally as an API for our end-user apps. Rest-layer however, is not actively being developed by the original author @rs, as he doesn't currently have any projects that needs it. Rest-layer have served us well, but we have also started to hit many of it's short-comings. There are other interesting technologies out there, ranging from jsonapi that we use in other projects, to JSON RPC that we are already using for both internal and customer-facing APIs, however a full on migration to one of these solution is unrealistic for us to prioritize. There are also parts of rest-layer we really enjoy, such as the filtering syntax, and we wold not be able to migrate to another solution if it meant loosing this.

Realistically, we are going to continue to use rest-layer for our internal APIs for several years, and in this time-period, we need the features that we depend upon to keep working, and perhaps improve. We need to be able to fix bugs, and effectively test them.

Creating a fork (this repo), is one way in which we can perhaps ensure continued basic maintenance of the project, including control of project CI, review rights etc. We might stand freer to introduce breaking changes and simplifications, including dropping unused features, reducing the maintenance surface and do independent decisions on how to change things.

There might be other ways in which future maintenance can be ensured effectively, hence this discussion.

[rs]

Forking would mean having the main maintainer (you) leaving this project. What prevents you from doing all the changes you described in the main project?

[smyrman]

So I am the most active, but not particularly active. It's not so much about what's preventing us from doing these things, as it is what would be the most efficient way for us to do what we need. It's hard enough to prioritize rest-layer fixes as it is, so what kind of changes can we do to make it easier?

At the moment, there are almost no active contributions against the rs/rest-layer repo, so it seams most likely, to me, that for our company to get what we need from rest-layer going forward, we need to own it ourselves, and perhaps get more developers involved than just me. If it's largely us doing the contribution, I think it would be more efficient to move the development to our company organization, and it would be possible to alter the communication for rest-layer from being something that should be useful for others, to being what is useful to us to maintain, and perhaps for others to use.

[smyrman]

I also want to be clear, that I don't think we will actively add many features; probably we would remove more than we would add. GraphQL, for one, is going. There are better and more maintained alternatives for doing this in Go now. JSON PATCH might be going; we are not using it. JSON Schema might be going; we are generating swagger docs, but we are not actively using them.

[smyrman]

We will maintain a fork of rest-layer in https://github.com/clarify/rested, at least for the time-being.

I think our goal would be to gradually morph the API into what we want for the future so that we can maintain old and new packages/interfaces side by side, and use both side-by-side.