> You just described my wife and me - and the getting along part is the
> tricky part ;) Coding-wise I swing between both ends, depending on task
> on environment, but in either case I try to keep Eisenhower's wisdom in
> mind: "plans are useless, but planning is indispensable".

Heh. That's one of my favorite quotes too :)

>     I thought the clients and server can (and should) co-evolve constantly.
>
> I fail to understand how, without having some upfront spec. If we want
> to minimize upfront planning and white-papers, we need something to code
> against, so we could simple let the server-side code talk and the
> client-side follow. Setting up the server and implementing 3 APIs should
> be a short enough lead to not thwart the overall development process
> significantly.

This again depends on the protocol. Since GraphQL is based on an object
model, it's pretty uncontroversial how to find the classes. E.g. a
Scheme API would have an Implementation class, a SRFI class, a Report
class for RnRS (or a combined Document class into which both SRFI and
RnRS fit). A Package class for libraries in package managers like Akku, etc.

Those again have straightforward queries: get all implementations, get
implementation by its id ("chibi", "kawa", etc.) Then various search
queries (e.g. list all packages with "xyz" in their name).

With REST it's more complex because you have to also design the response
formats, which are the hardest things to design (and the more time
passes, the harder it is to keep them clean).

>     If we choose GraphQL, it solves this problem handily because the API
>     response format is completely client-dictated.
>
> That's again not fitting squarely into my brain ;) If we just imagine
> two Scheme clients and an Emacs client, I think that they can share so
> much more than just what they expect from the server - and I would hope
> that we would greatly improve the quality of the client implementations
> by sharing common best practices and ideas as they come up during
> development. If so, that sharing can be heavily simplified by not
> starting from completely opposite ends. Admittedly the tricky part in
> this case is to find the right balance between alignment and creative
> flow of thoughts, but this anyway our daily business.

I'd leave it up to the people writing the clients to figure out how to
best work together. People usually know what works best for them, and
it's different for everybody. So for example, if one person is most
enthusiastic about making an Emacs client, and another about a CLI
client, then they can each work on those clients and find a way to
communicate that is the best match for their personal styles.

It's definitely nice if clients can share code, but there are times when
code sharing gets in the way (by slowing down development, or if the
clients need almost the same thing but with some variations, and the
variation makes communication slow or code complex). I think the best
way to do this is that people start writing the clients, and then they
discover what makes the most sense. They can always be refactored later.

For me, the overarching concern is that I've been in many projects where
lots of time is spent debating things that not based on any field
experience. It's faster (and usually more fun) to gain real experience
as fast as possible by trying things. Often the results are surprising.
Software is so complex that the right solution or approach is usually
not obvious beforehand. So for the most part, I'd be in the "code wins
arguments" camp.