Containerized stuff, too?

W/ K8s on both, might help ease that.

@fellshard Ah, problem solved by introducing another layer of abstraction...? 🙂

As I'm preparing a Meetup around APIs I may now ask my API question more precisely ... I think there are several types of API like function frameworks, REST or exchangeable components. All these types of APIs need solutions for documentation (in order to be used by others), validation (failing fast for fast bug hunting) and tested contracts (for stability). More precise my questions are: * how do you solve documentation, validation & contract-testing in general? * Is there a cool SWAGGER-stack for REST APIs? * As I offer exchangeable components - has someone a good strategy here (we are using Record + Protocol + Multifunctions) ?

Yesterday I saw https://github.com/oliyh/martian - seems really cool. Too bad it seems quite hard to integrate to existing product. Using macros to have one source-of-truth, I think, is wonderful idea, compared to codegen

@jerger_at_dda > how do you solve documentation, validation & contract-testing in general? At a high level, I think questions around rest api's is really similar in nature to questions around functionality in general. To me, what were all asking about is how do we communicant what something does and why with the goal that someone else be able to change the what or how to better match the why. OR possible change the why based on new information. When you approach a new system (lib, applications, etc...) its code can only tell you "HOW". which is possible the least interesting aspect of the story. However, i believe its possible to design a system such that you can push how closer to what by raising the level of abstraction high enough that the language of the system is understandable to a human. Nothing but the collective creators can express "why" they did it, or why they did it this way. Its up the those authors to fill in that why, assuming its important. ------------- > Is there a cool SWAGGER-stack for REST APIs? At a low level, clojure has lots of documentation options. The sky seems to be the limit, two new version of apis -> docs got releases yesterday. We have swagger docs for apis. You can use Schema and Spec to correct human readable error messages based off validation functions. > As I offer exchangeable components - has someone a good strategy here (we are using Record + Protocol + Multifunctions) ? Not sure what you mean. Those are all methods of achieving runtime polymorphism.

@drewverlee Here you find an example for a simple Plugin-Mechanism using an atom for registration: https://github.com/yogthos/Selmer/blob/968af8e057ec5a890faa00223664980d54100ebf/src/selmer/filters.clj#L73 You can use such a registered Filter

(add-filter! :add? add?)
(render "{{add_me|add:2:3:4}}" {:add_me 2}) => 11

A more complex example using component with defrecord + protocol + multifunction you can find here: https://github.com/journeyman-cc/smeagol/blob/05eafe603ff29a8144def4cb6a9111173cc457e7/src/smeagol/include/resolve.clj#L10 Example usage here: https://github.com/journeyman-cc/smeagol/blob/05eafe603ff29a8144def4cb6a9111173cc457e7/test/smeagol/test/include.clj#L43 and Line 57. Whether it's a good idea to mix component and multifunction I'm not sure ...