What I did just this week is implement two simple endpoints for federation and compliance in our API. Very straightforward once you figure out that these are very simple APIs. This is not very obvious from the documentation.
Basically with federation, you return a small json blob in response to a name query with the full stellar address (uid*yourdomain.com) with the memo and stellar account key of your deposit account. I don't see why you would need the stellar federation server for that.
Similarly if you want to support the compliance protocol you need a single end point that answers the question whether it is OK for a third party to send a particular transaction. What we do is very simple:
- we check the signature using the sender's key from their toml
- we pick apart the transaction to dig out the memo so we know who on our side it is intended for
- we check whether that user has done KYC; if not we deny the request.
- we deny info requests for aml info. We may change this in the future if we find that this is actually needed. But with GDPR we need to be careful what information we leak via APIs like this.
IMHO the stellar documentation is super confusing on this. They present all these different servers and moving parts with complex configuration without actually pointing out that these are example implementations of very simple REST APIs that in all likelihood don't match your architecture at all. It's much easier to simply implement the API directly.
Similarly the bridge server is a bit of a question-mark as well. It seems to do some unspecified magic that boils down to simple interactions with horizon, and federation/compliance servers on both sides. I don't see any big reason why I could not do that manually. IMHO it only makes sense when you are doing federated to federated type transactions and you could probably do this manually as well.